I have found the documentation around SmarterMail's anti-spam features to be difficult to parse. After studying the options in some detail, I constructed this document, which I have decided to share.
Overview
The AntiSpam logic can produce any of these dispositions:
- Accept without changes.
- Add a custom header to the message (content filtering rules only).
- Tag the subject with a warning such as “[SPAM?]”
- Direct the message to the recipient’s Junk folder.
- Direct the message to the recipient’s Deleted folder (User spam rules only).
- Quarantine the message (virus detection only).
- Delete the message (silent discard)
- Bounce the message (generate a non-delivery report (hereafter “NDR” for brevity).
- Close the SMTP session with a 4xx code (greylisting)
- Close the SMTP session with a 5xx code (reject)
Spam Processing Phases
SPAM processing is broken into these phases: Inbound SMTP including Recipient Verification and DMARC, Declude (Spool\Proc) processing, Spam Filtering, Antivirus Filtering, and Outbound SMTP blocking.
Inbound SMTP Blocking
If the message is received by authenticated or unauthenticated SMTP, all tests configured for “Inbound SMTP” are checked. Most tests can either cause an immediate reject decision or contribute a spam weight used for a disposition decision after all tests are completed.
[THEORY:] If a message is accepted, the spam weight from this phase is discarded, so that downstream phases start from a weight of zero. (Or does the spam weight move forward via the .HDR file?) ]
Disposition options in this phase are:
- Reject with 5xx code if a specific test causes that result.
- Reject with 5xx code if total spam weight exceeds the AntiSpam option for “Incoming Spam Block” threshold
- Reject with 4xx code if total spam weight exceeds the AntiSpam option for Greylist spam weight (and the sender is not exempted from greylisting).
- Accept the message for additional processing.
Recipient Verification
After the initial HELO/EHLO is accepted, the sender submits recipient names. On a mail store server, recipient checking is always performed, and the recipient will be rejected if the account is non-existent, disabled without mail, or over quota. On an incoming gateway, recipient verification will only occur if recipient verification is configured and enabled using either LDAP or SmarterMail gateway mode. (Not that LDAP tests only for account existence.) Honeypot addresses may trigger a disposition decision, or may increase the Incoming SMTP spam weight above the configured threshold. If either occurs, then subsequent “Rcpt To” entries will be rejected as if the recipient was invalid, whether or not that is actually the case.
DMARC
After the whole message has been received via SMTP, DMARC processing is performed. Fail with Reject policy causes the message to be rejected. Fail with Quarantine policy causes the message to be quarantined. DMARC is the only test within Inbound SMTP processing which can produce a Quarantine result.
Phase Transiton
Upon completion of the SMTP session, or upon initial entry by any other method, the message is delivered to one of two places. either the Spool\Proc folder for Declude processing, if that option is enabled, or directly to the \Spool folder for processing by the Delivery process.
Declude Processing
Declude has separate configurations for inbound and outbound messages. One or the other configuration is activated based on the Recipient domain(s) found in the .HDR file. Two files are used to communicate with the external process: the .EML file contains the actual message, and the .HDR file contains message metadata. Message metadata provides the SMTP attributes which are not available in the message itself, including: Source IP, Helo/Ehlo Name, Reverse DNS name, Mail From address, and Rcpt To addresses.
Completion of Declude processing is indicated by delivering these two files to the Spool folder. The external process has freedom to alter the message in any way desired. If the message never returns to that folder, SmarterMail processing ends. Declude supports any of these actions:
- Delete the message files (silent discard).
- Drop the message file into a HOLD location (non-SmarterMail quarantine).
- Add headers to the message.
- Add a warning tag to the subject.
- Add a warning block to the body of the message.
- Trigger a bounce by adding an indicator to the .HDR file (Note that SMTP reject is no longer possible because the SMTP session is closed before external processing starts, and because the message may not have been received by SMTP.)
- Indicate a spam weight by adding a token to the .HDR file
SPAM Filtering
When the message arrives in the Spool folder, the Delivery phase starts and that phase promptly invokes the Spam Checks sub-phase. This phase is logged in the SpamChecks log file and it applies all tests configured for “Spool Filtering.” Anti-Spam rules can be configured at the System, Domain, or User level. [How these three levels interact needs clarification. At one point we were told that only one set of rules is used, with “User” rules taking precedence over Domain and System.]
Most spam filtering rules only contribute to the total spam weight, which then triggers action if one of the three anti-spam thresholds are exceeded. Content Filtering tests are an exception, because they can trigger Bounce, Delete, or folder redirection based on a single test. Content filtering rules can also be used to add a custom header to the message, presumably for audit use only.
Content filtering rules can only be configured at the domain or user levels. Consequently, content filtering cannot be usefully configured on an Incoming Gateway server.
AntiVirus Checks
Antivirus processing is configured at the system level only. When a virus is detected, the message can be deleted silently, quarantined, or the virus can be ignored. If virus detections are ignored, presumably to monitor the accuracy of the antivirus tool, the system administrator should monitor log files closely to detect whether actual attacks have been allowed.
[THEORY: Do Antivirus checks occur before or after the “Spool Filtering” checks?
Delivery processing
Inbound messages: For message destined for a hosted account, delivery is now performed. Under unusual circumstances, an account problem may be detected here which was not detected during Recipient Verification. If a delivery failure occurs, a bounce event is triggered.
Outbound SMTP Blocking
If the destination address is not locally hosted, the message must be transmitted via SMTP. If an Outbound SMTP Blocking threshold is configured, any spam checks configured for “Outbound SMTP” are performed with each test contributing to a spam weight. If the Outbound SMTP block threshold is reached, the configured action is applied, which can be:
- Quarantine
- Block with bounce message to sender
- Block without bounce message.
For an Inbound Gateway server, “Outbound SMTP” applies to messages being forwarded inward to the mail store server. As a result, an Inbound Gateway system may have quarantined items.
Spam Processing Exceptions
Trusted Senders and Domains
Trusted senders are exempted from “Spam Filtering” rules. Trust is based on the message From address, not the SMTP Mail From address, so trusted sender exemptions do not apply to Inbound SMTP blocking.
[THEORY: Trusted Sender exemptions seem inapplicable to outbound processing, but the documentation is not clear on this point.]
These rules are used to determine if a sender can be trusted:
- SPF/DKIM/DMARC tests are performed for any that are enabled. If any produce SPF_Fail, SPF_Softfail, SPF_PermError, DKIM_Fail, or DMARC FAIL, the sender is not trusted.
- [THEORY: SmarterMail provides some fallback for senders that do not have a DMARC policy. The specifics need to be clarified.]
- If a verification failure is not detected, and the From address is in the Trusted Senders list, then the message is exempted from all Spam Checks (THEORY: And anti-virus checks?)
- For configurations with incoming gateways, Trusted Senders will need to be configured on both the gateway server and the mail store server, for the exemption to be fully effective. Remember that on an incoming gateway, only system-level trust rules are applied.
[THEORY: Does SmarterMail gateway mode provide a workaround to this limitation, so that user and domain filter rules can be retrieved and applied on the incoming gateway?]