Overview
SpamRazer is an Anti-Spam engine that determines whether an email is spam or not through the use of email fingerprints, email reputation, content analysis, and heuristics.
In this article, you will learn how to determine why the SpamRazer engine blocked or allowed a message as part of the troubleshooting process.
Introduction
SpamRazer is a complete Anti-Spam engine that makes use of various technologies to identify and block spam including Email Reputation, message fingerprinting, and heuristics. The engine needs to be updated often to keep up to date with the latest spam trends.
There will be scenarios where customers open support requests wanting to understand why the engine blocked or allowed specific messages against their expectations. The next section outlines the troubleshooting process to determine the reason behind the actions taken by the SpamRazer engine.
Description
If you are questioning why an email was blocked or allowed by the SpamRazer Anti-Spam filter and would like more information, you can find further details in the SpamRazer debug log file.
Follow the below procedure to find the log file and information regarding the email message under review, and thereafter use the examples below to interpret and determine why the message was either blocked or allowed:
- Find the Message-ID of the email in question by either gathering 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\EmailSecurity\DebugLogs\ and locate the debug log file for the Keyword Filtering module. The log file name is ase_spamrazer.gfi_log.txt
- This is the debug log for the Keyword Filtering Module and corresponds to the GFI MailEssentials > > Anti-Spam > Anti Spam Filters > SpamRazer 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 SpamRazer engine. Pay close attention to the lines in bold to understand what happened and why.
- Note: Message-IDs have been redacted from the example log files below.
Scenario 1: Email was allowed by the module
>> Message Processing Block
Stream Retrieved [size: 24419]
(IPRep) Executing IPcheck ...
(IPRep) [0x1330CFD0] IPcheck succeeded [Score: 50, Threshold: 90]
(IPRep) Executing DOMAINcheck ...
(IPRep) [0x1330CFD0] DOMAINcheck succeeded [Score: 50, Threshold: 90]
(IPRep) IP reputation did not determine if msg is spam
(Score) [0x1330CFD0] Smtp Envelop: [HELO mx137.gfi.com MAIL FROM: gfitest@gfitest.com RCPT TO: gfitest@gfitest.com]
(Score) [0x1330CFD0] Connecting IP: [209.162.194.137]
(Score) [0x1330CFD0] Trying to read [20000] bytes of message
(Score) [0x1330CFD0] # bytes read: 20000
(Score) [0x1330CFD0] Message scanned [score: 1]
(Score) [0x1330CFD0] SPF Status: fp
(Score) [0x1330CFD0] 1,0,0,,d41d8cd98f00b204,sender@gfi.comt,gfitest@gfitest.com:gfitest@gfitest.com,RULES_HIT:53:2539:4310,0,RBL:209.162.194.137:@gfitest@gfitest.com:gfitest@gfitest.com.lbl8.mailshell.net-62.18.0.100 64.95.201.95,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0
(Score) [0x1330CFD0] (-100%) Sender has hammy reputation
Note: The SpamRazer engine is not highly configurable beyond the ability to enable or disable the entire engine. The only exception to this is the ability to Enable SpamRazer to perform a Sender Policy Framework check as part of its checks.
Scenario 2: Email was blocked by the module
>> Message Processing Block
Stream Retrieved [size: 28851]
(IPRep) Executing IPcheck ...
(IPRep) [0x1330CFD0] IPcheck succeeded [Score: 50, Threshold: 90]
(IPRep) Executing DOMAINcheck ...
(IPRep) [0x1330CFD0] DOMAINcheck succeeded [Score: 50, Threshold: 90]
(IPRep) IP reputation did not determine if msg is spam
(Score) [0x1330CFD0] Smtp Envelop: [HELO gfitest@gfitest.com MAIL FROM: spammer@gfi.com RCPT TO: gfitest@gfitest.com]
(Score) [0x1330CFD0] Connecting IP: [192.158.226.130]
(Score) [0x1330CFD0] Trying to read [20000] bytes of message
(Score) [0x1330CFD0] # bytes read: 20000
(Score) [0x1330CFD0] Message scanned [score: 92]
(Score) [0x1330CFD0] SPF Status: fp
(Score) [0x1330CFD0] 92,0,0,,d41d8cd98f00b204,spammer@gfi.com,gfitest@gfitest.comgfitest@gfitest.com,RULES_HIT:4310,0,RBL:192.158.226.130:@gfitest.com:gfitest@gfitest.com.lbl8.mailshell.net-62.2.0.100 64.100.201.201,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:gfitest.com-dnsbl7.mailshell.net-127.0.0.192,Custom_rules:0:0:0
(Score) [0x1330CFD0] (100%) URL is in DNSBL
Setting actions data ...
Informing ASE [2]...
Setting block report to: 'Message was found to be spam: (100%) URL is in DNSBL,'
Notes:
- SpamRazer can block for a number of reasons that will begin with "Message was found to be spam:"
- "IP is in RBL"
- "URL is in DNSBL"
- "URL is in MSBL"
- "IP has spammy reputation"
- "Sender has spammy reputation"
- "Contains spammy domain"
- "Failed SPF check" - Turn off the SPF Check
- Aside from the SPF check, SpamRazer cannot be altered and affected legitimate senders must be whitelisted.
- Alternatively, the senders failing the SPF check should be advised to ensure their email server passes the SPF checks.