Overview
Greylisting is a simple but very effective anti-spam mechanism that works at SMTP level and based on the premise that spammers continuously send emails without checking for error messages. The Greylist Anti-Spam filter is designed to block spam originating from spammers and bulk mailers that do not resend emails on delivery failure.
In this article, you will learn how to determine why the Greylist filter blocked or allowed a message as part of the troubleshooting process involving this Anti-Spam plug-in.
Introduction
The Greylist Anti-Spam filter works by temporarily blocking incoming emails received from unknown senders. Legitimate mail systems typically try to send the email after a few minutes; spammers simply ignore such error messages.
There will be scenarios where customers open support requests wanting to understand why the Greylist filter blocked or allowed specific messages against their expectations. The next section outlines the troubleshooting process to determine the reason behind the actions taken by this filter.
Description
If you are questioning why an email was blocked or allowed by the Greylist spam filter and would like more information, the best place to start the troubleshooting process is to examine the debug logs.
Follow the below procedure to find the log file and information regarding the email message under review, and thereafter use the examples provided to interpret and determine why the message was either blocked or allowed:
- Find the Message-ID of the email in question by either obtaining it from the headers of the message itself or by looking for it in the MailEssentials Dashboard > Logs > Details tab. Refer to this linked article for more information on Reading Email Headers to extract the Message-ID.
- Navigate to ..\GFI\MailEssentials\AntiSpam\DebugLogs and locate the log file for the Greylist Anti-Spam module. The debug log filename is ase_greylisting.gfi_log.txt
- This debug log file for the module corresponds to GFI MailEssentials > Anti-Spam > Anti-Spam Filters > Greylist on the configuration UI.
- Open the debug log file in a text editor and search for the Message-ID obtained in step 1.
- Refer to the scenarios below to determine the reasons behind the action taken by the module. Pay close attention to the lines in bold to understand what happened and why.
The debug log file will indicate whether Greylist protection is enabled and any actions taken by the filter while scanning emails. If the module is disabled the log file will simply show:
","ase_greylisting","----------------------------------------------------------"
","ase_greylisting",">> Message Initialization"
","ase_greylisting","Context Refreshed: No"
","ase_greylisting","Licensing check: Licensed"
","ase_greylisting","Message ID, [<7E47AC143842434400000021@EC2AMAZ-TEDQDCP>]."
","ase_greylisting","<< Message Initialization"
","ase_greylisting",">> Message Processing Block"
","ase_greylisting",">> CModuleContext::ProcessMessage()"
","ase_greylisting","Greylisting is disabled."
","ase_greylisting","<< CModuleContext::ProcessMessage()"
","ase_greylisting","<< Message Processing Block"
","ase_greylisting",">> Message Uninitialization"
","ase_greylisting","<< Message Uninitialization"
","ase_greylisting","----------------------------------------------------------"
Scenario 1: Email was allowed by the module
Message recipients are local - process; GFI_MTASMTP_MC_Recipients - [1].
Checking connecting IP against whitelist exclusion...
Connecting IP: [x.x.x.x].
CIPWhitelist::Execute()
Checking address [x.x.x.x]
Address [x.x.x.x] is not whitelisted
Checking connecting IP against whitelist exclusion...ready
Checking email addresses against whitelist exclusion...
Checking [gfitest@gfitest.com] against Autowhitelist ...
Checking against manual whitelists ...
[MIMEToWhitelist] Processing [1] items
SQL: SELECT id FROM antispam2_whitelist WHERE type=0 AND entry IN ('gfitest@gfitest.com')
[MIMEToWhitelist] Executing Wildcard check [1]...
[MIMEToWhitelist] Wildcards did not whitelist any entries ...
[MIMEFromWhitelist] Processing [1] items
SQL: SELECT id FROM antispam2_whitelist WHERE type=1 AND entry IN ('recipient@gfitest.com')
[MIMEFromWhitelist] Found match in db ...
Email found in whitelist exclusion list, Bypass greylist.
Note: You may find any of the following messages depending on why the email was allowed. The actions to have the sender blocked if desired for each of the bypass reasons are also indicated:
- Email found in whitelist exclusion list, Bypass greylist - Remove from the Auto Whitelist, manual Whitelist, or IP Whitelist
- Email found in greylist exclusion list, Bypass greylist - Remove from the Greylist Exclusions tab
- Connecting IP is a perimeter SMTP Server forwarding emails to this server, Bypass greylist - Remove from the perimeter servers list
- Interval larger than Block period - Authorize triple - This cannot be altered
- Triplet found in Temporary table - This cannot be altered
Scenario 2: Email was blocked by the module
Register triplet - [x.x.x.x, gfitest@gfitest.com, recipient@gfitest.com]
>> CGreyListing::RegisterTriplet()
Insert Query - LogTime=[11 02 2013 06:40:00 518] IP=[x.x.x.x] Sender=[gfitest@gfitest.com] Recipient=[recipient@gfitest.com]
<< CGreyListing::RegisterTriplet()
Processing complete: : <25>ms
Inform ASE to send retry code after DATA command.
Setting actions data ...
Informing ASE [2]...
Setting block report to: 'Triplet not confirmed' - Either this is the first time the email has come in or a different server is replying to the RFC Compliance request.
Note: You may also see the following:
- Interval [0] smaller than Block period - Send retry code- The sending server replied too quickly. It should attempt again in a few minutes and allow the message through.