Overview
The Header Checking Anti-Spam filter works by analyzing the email header to identify spam emails.
In this article, you will learn how to determine why the Header Checking filter blocked or allowed a message as part of the troubleshooting process involving this Anti-Spam plug-in.
Introduction
The Header Checking Anti-Spam filter allows an administrator to specify which checks should be performed on email headers in order to identify spam by detecting particular groups of inconsistencies in MIME/SMTP header values.
There will be scenarios where customers open support requests wanting to understand why the Header Checking 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 Header Checking 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 Header Checking Anti-Spam module. The debug log filename is ase_header_check.gfi_log.txt
- This debug log file for the module corresponds to GFI MailEssentials > Anti-Spam > Anti-Spam Filters > Header Checking on the configuration UI as well as a number of the antispam2 tables in the config.mdb database.
- 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 Header Checking protection is enabled by specifying and logging which checks are performed on email headers. If the no checks are specified, Header Checking is effectively disabled the log file will simply show:
","ase_header_check","--------------------------------------------------------"
","ase_header_check","<< Load Config"
","ase_header_check","<< Init Message"
","ase_header_check",">> Process Message"
","ase_header_check","<< Process Message"
","ase_header_check",">> Message Uninitialization"
","ase_header_check","<< Message Uninitialization"
Note: There is no disabled message, simply no checks are done.
Scenario 1: Email was allowed by the module
Context Refreshed: No
Licensing check: Licensed
<< Init Message
>> Process Message
Executing processing ...
>> Rcpt Count
Checking for maximum number of recipients: 40
Recipients in this email: 1
<< Rcpt Count [Ham]
>> Empty FROM
Number of MIME Senders: 1
Valid MIME Sender found
<< Empty FROM [Ham]
>> Malformed Email
Checking for malformed email format: gfitest@gfi.com
gfitest@gfi.com is a valid email address
<< Malformed Email [Ham]
>> Digits in Email
Checking email for numeric characters: gfitest@gfi.com
Digits found in email address: 0
<< Digits in Email [Ham]
>> Rcpt in Subject
<< Rcpt in Subject [Ham]
>> Encoded IP
>> PDF Spam
>> Charset
>> File Spam
Email body length: 168
Searching through attachments for '.pdf' files
Number of children [0]
HTML charset [us-ascii]: Codepage [1252]
No '.pdf' files found in email
<< Charset [Ham]
Number of attachments in email: 0
<< PDF Spam [Ham]
Check valid only for one attachment. Skipping
<< File Spam [Ham]
Urls extracted from body: 26
<< Encoded IP [Ham]
<< Process Message
Note: If a spam email is allowed through, make sure all the checks were performed.
Scenario 2: Email was blocked by the module
Due to the extensive number of mini checks performed by this module, you may get any of the below messages in the debug logs when a message is blocked by any of the checks, the reason for blocking starts with "Setting block report to:"
The reasons below are listed in the same order as the checks in the configuration UI:
"From field empty"
"Email header contains a malformed MIME From: field"
"Recipient list exceeds maximum threshold"
"Email has different SMTP TO: and MIME TO: fields in the email addresses"
"Domain does not exist - invalid domain passed" OR "Domain does not exist
"Number of numbers in MIME From exceeds maximum threshold"
"Encoded IP"
"Email contains remote images"
"Embedded GIF"
"Email contains attachment spam"
"Email found in subject"
"Character set not allowed" - This is set in the Character Sets tab
Note: If any of the checks are blocking valid emails, the only option on the recipient end is to whitelist the sender or disable that check since these issues can only be resolved by the sender.
Priyanka Bhotika
Comments