1. Sample Email Message-ID: This can be obtained from the email headers or via the Dashboard > Logs > Details tab.
2. Log files from  ..\GFI\MailEssentials\AntiSpam\Debug Logs. The various log files for the Whitelisting modules are:
   • ase_ipwhitelist.gfi_log.txt
   • ase_kwhite.gfi_log.txt
   • ase_personalwhitelist.gfi_log.txt
   • ase_whitelist.gfi_log.txt

Reading the IP Whitelist Logs

1. Open the ase_ipwhitelist.gfi_log.txt file in a text editor. This debug log is for the IP Whitelist module and corresponds to the Configuration > Anti-Spam > Whitelist > IP Whitelist tab in the UI and the ipwhitelist table in the config.mdb configuration database.
2. Search for the Message-ID of the sample email
3. Look out for the entries similar to the bolded lines in the sample log extract below:

">> Init Message [<mysamplemessageid@domain.com>]"
"Context Refreshed: No"
"Licensing check: Licensed"
"<< Message Initialization"
">> Message Processing Block"
"Connecting IP: 192.3.158.73"
"CIPWhitelist::Execute()"
"Checking address [192.3.158.73]"
"Address [192.3.158.73] is not whitelisted"
"Message is not whitelisted ... "

• Connecting IP is the IP address of the sending server
• This IP was not in the whitelist
• If the sending server IP address matches, you will instead see log entries similar to this and you can, therefore, conclude that the email in question was Whitelisted by the IP Whitelist module:

"Checking address [192.168.4.134]"
"Address [192.168.4.134] is whitelisted"
"Message is whitelisted ... "
"Setting block report to [IP is in Whitelist]" 

• If no such entries are found for the Message-ID under review you can conclude that the email was not Whitelisted by this particular module and you can proceed to check the other Whitelist modules as described below.

Reading the Keyword Whitelist Logs

1. Open the ase_kwhite.gfi_log.txt file in a text editor. This is the debug log for the Keyword Whitelist. Emails whitelisted by this module will appear in the dashboard log as 'Keyword Whitelisted'. The debug log corresponds to Configuration > Anti-Spam > Whitelist > Keyword Whitelist in the UI and the kwhitebody and kwhitesubject tables in config.mdb.
2. Search for the Message-ID of the sample email
3. Look out for the entries similar to the bolded lines in the sample log extract below:

"Scanning subject ..."
"Scanning message body (TEXT)"
"Scanning body ..."
"Found 1 words: [access]"
"Setting actions data ..."
"Informing ASE of whitelisting [2]..."
"Whitelisted because of following keywords: 'access'"
"Setting block report to [Found word(s) 'access' in message body]"

• The check on the subject yielded no matches
• The check on the body yielded a single match
• The matched word was 'access'
• If a message is not whitelisted by the Keyword Whitelist, the logging ends with the following:

"<< Message Processing Block"
">> Message Uninitialization"
"<< Message Uninitialization"

Reading the Personal Whitelists Logs

Personal Whitelists can only be enabled when MailEssentials is installed on the Exchange Server in AD mode, otherwise, the ase_personalwhitelist.gfi_log.txt debug log file will show:

","ase_personalwhitelist","=================================================================================="
","ase_personalwhitelist",">> Message Initialization"
","ase_personalwhitelist","Init Message [<b99202b5439565bbd8053e6de39d9d07@EC2AMAZ-TEDQDCP>]"
","ase_personalwhitelist","Checking if PWLBL are enabled...."
","ase_personalwhitelist","Provider=Microsoft.Jet.OLEDB.4.0;User ID=Admin;Data Source=C:\Program Files (x86)\GFI\..
","ase_personalwhitelist","Personal Whitelist Enabled: False"
","ase_personalwhitelist","Licensing check: Licensed"
","ase_personalwhitelist","<< Message Initialization"
","ase_personalwhitelist",">> Message Processing Block"
","ase_personalwhitelist","Personal Whitelisting is disabled ..."
","ase_personalwhitelist","Message Uninitialization..."
","ase_personalwhitelist","=================================================================================="

1. Open the ase_personalwhitelist.gfi_log.txt  file in a text editor. This file contains information on the personal whitelists and is quickly overwritten. It corresponds to the Configuration > Anti-Spam > Whitelist > Personal Whitelist in the UI and the PWLBL.sdf table in config.mdb.
2. Search for the Message-ID of the sample email
3. You will see entries similar to ones below:

"Checking message against Personal Whitelist"
"SMTP Recipient [gfitest@gfi.com] does not care"

• The bolded line confirms that the sender was not on the personal Whitelist.

"Checking message against Personal Whitelist"
"SMTP Recipient [gfitest@gfi.com] ACCEPTS message"
"Injecting actioning data since some users blocked/accepted the message ..."
"All recipients allowed sender, setting GFI_ASEMSGPROPS_WHITELISTED property with updated details ..."

• The bolded line confirms that this sender was on gfitest@gfi.com's Personal Whitelist.

Reading the Autowhitelist and Email/Domain Whitelist Logs

1. Open the ase_whitelist.gfi_log.txt file using a text editor
2. This log contains the Autowhitelist as well as the Email/Domain Whitelist debug logs and is the most complicated to read from the four log files related to the Whitelist modules. It corresponds to the Configuration > Anti-Spam > Whitelist:: Whitelist and Auto Whitelist tabs and the antispam2_whitelist table in config.mdb. Autowhitelisted entries are saved at ..GFI\MailEssentials\Antispam\autowhitelist.mdb.
3. Search for the Message-ID of the sample email
4. The following log can be broken into two major parts, first the Whitelist then the Autowhitelist:

Whitelist:

• Each message can have up to 4 SQL checks run on them such as the one below:
  • SQL: SELECT TOP 1 id FROM antispam2_whitelist WHERE (type=0 OR type=4) AND entry IN ('test@gfi.com')
  • Each check will be followed by the following:

...was not found in db ...
Executing Wildcard check [1]...
Wildcards did not whitelist any entries ...

• This means the email address checked 'test@gfi.com' is not in the Whitelist
• The Wildcard check checks for domains, such as '*@gfi.com' which also did not match
• If any of the 4 SQL Checks match, the email is Whitelisted

• If a match is found, instead of ...was not found in db ... you will see the following:

Found match in db ...
Message is Whitelisted...Skipping NDR / Out-Of-Office Check

• This means you need to remove the address from the Whitelist.  In this case, test@gfi.com

• If none of the SQL Queries match, an additional check will be performed on the AutoWhiteList (AWL)

"Checking [test@gfi.com] against Autowhitelist ..."
"[test@gfi.com] is found in AWL"
"SETTING _bWhitelistMsg = true"
"MIME From (test@gfi.com) address is in AWL ..."

• This means the address 'test@gfi.com' was found in the AutoWhiteList, it will need to be removed from there
• If instead the address is not listed in the AutoWhiteList, you will see the following:

Checking [test@gfi.com] against Autowhitelist ..."
[test@gfi.com] is NOT found in AWL"

• The last few lines of any email check that found a match should end with the following if the message was Whitelisted:

"Setting block report to [Email address whitelisted]"
"GFI_ASEMSGPROPS_WHITELISTED = true"
"NDRSpamNewSenders = false"
'<< Message Processing Block"
">> Message Uninitialization"

• If you instead do not get a match on the Autowhitelist or the Whitelist, you will see the following as the last few lines:

"GFI_ASEMSGPROPS_WHITELISTED = false"
"NDRSpamNewSenders = false"
"<< Message Processing Block"
">> Message Uninitialization"
"<< Message Uninitialization"