Many spammers deliberately target a secondary mail-exchanger in the expectation that the security will be weaker there. Legitimate mail should only use a secondary if the primary is unavailable. Unfortunately this can legitimately appear so from the point of view of a sender even though the primary is in fact functional (e.g. due to DNS problems) hence there are possible false positives with this test. Since our secondary MX is adjacent to our primary the probability of this is low. Also some misguided mail systems, even some major ones, completely ignore the standards for MX priority. Selecting “reject” for this condition will result in SMTP temporary-reject responses, which should cause a legitimate sender to queue mail until it can access our primary. Also, if our secondary detects that the primary is offline, the test is disabled.
Verify Sender Domain Exists
This option enables testing that the alleged sender’s machine name is present in DNS (whether there is an “A” record for that name, giving an IP address). Some spam sources make up a sender machine name; if enabled such mails will be rejected.
Section 3.3 Mail Transactions
"the MAIL command.
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
This command tells the SMTP-receiver that a new mail transaction is
starting and to reset all its state tables and buffers, including any
recipients or mail data. The <reverse-path> portion of the first or
only argument contains the source mailbox (between "<" and ">"
brackets), which can be used to report errors"
Section 4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
"When an SMTP server returns a positive completion status (2yz code)
after the DATA command is completed with <CRLF>.<CRLF>, it accepts
responsibility for:
[...]
- if attempts to deliver the message fail due to permanent
conditions, or if repeated attempts to deliver the message fail
due to transient conditions, returning appropriate notification to
the sender of the original message (using the address in the SMTP
MAIL command)."
Obviously, we can’t return an “appropriate notification” to a sender who won’t accept mail!
Therefore we insist on that check for all the low-cost accounts, as part of the general reliability needs of email.
Full-service accounts can disable the check; we provide the knob to twiddle but it’s their decision to make. Preferably they should whitelist that particular sender, which bypasses the check only for that sender, rather than disabling it wholesale – but again, their policy choice not ours. Disabling the check will reduce the reliability of the email system, as a message could be dropped without the sender being notified of the situation.
Verify Sender
This option enables testing that the alleged sender exists (to the extent that the mail system would accept a bounce message to it). This is more expensive as it involves our mail server contacting theirs, and not perfect since some badly-configured servers (including major names such as AOL, and the usual configurations of Microsoft Exchange) always claim to accept mail for any name.
Some mail providers consider using this type of check abusive, as a spammer thereby imposes a load on an innocent third-party by using their name.
We’ve also seen at least one email provider running what we consider to be a broken greylisting system, which never got around to enabling MAIL FROM:<> mails (as used by bounces). Because of this our attempt to see if they will accept a bounce is rejected every time they (correctly) retry sending us a mail, until they time out. Obviously, we’d never be able to send them a real bounce either.
The comments above about the Sender Domain also apply here.
Validate HELO data
This option tests that the name given at the start of the SMTP session as identifying the sending machine exists in DNS (whether there is an “A” record for the name, and whether a reverse-lookup of resulting IP address results in the same name).
Many less-proficient system admins fail to either set up DNS properly for their systems, or configure their mail system to use a technically-illegal HELO name. Spammers are often included among this number, as are zombied PCs sending directly using Microsoft software. Unfortunately, so are (otherwise) legitimate individuals sending direct using Microsoft software (as opposed to sending via their ISP’s mail system). Microsoft, most unfortunately, encourage such misconfiguration in their software guidelines.
Mutating HELO data
This option checks whether the sending IP address has been seen to use more than one name to identify itself at the start of the SMTP session. This appears to be a characteristic of certain types of spammer. Unfortunately some major corporations also disregard standards in this respect (Ebay, Amazon have been noted doing this); if you expect mail from such you should either do no more than “warn” on this condition, or explicitly whitelist those senders.
Envelope Filters
2MX Arrival
Many spammers deliberately target a secondary mail-exchanger in the expectation that the security will be weaker there. Legitimate mail should only use a secondary if the primary is unavailable. Unfortunately this can legitimately appear so from the point of view of a sender even though the primary is in fact functional (e.g. due to DNS problems) hence there are possible false positives with this test. Since our secondary MX is adjacent to our primary the probability of this is low. Also some misguided mail systems, even some major ones, completely ignore the standards for MX priority. Selecting “reject” for this condition will result in SMTP temporary-reject responses, which should cause a legitimate sender to queue mail until it can access our primary. Also, if our secondary detects that the primary is offline, the test is disabled.
Verify Sender Domain Exists
This option enables testing that the alleged sender’s machine name is present in DNS (whether there is an “A” record for that name, giving an IP address). Some spam sources make up a sender machine name; if enabled such mails will be rejected.
The standard for SMTP says:
Section 3.3 Mail Transactions "the MAIL command. MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF> This command tells the SMTP-receiver that a new mail transaction is starting and to reset all its state tables and buffers, including any recipients or mail data. The <reverse-path> portion of the first or only argument contains the source mailbox (between "<" and ">" brackets), which can be used to report errors" Section 4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> "When an SMTP server returns a positive completion status (2yz code) after the DATA command is completed with <CRLF>.<CRLF>, it accepts responsibility for: [...] - if attempts to deliver the message fail due to permanent conditions, or if repeated attempts to deliver the message fail due to transient conditions, returning appropriate notification to the sender of the original message (using the address in the SMTP MAIL command)."Obviously, we can’t return an “appropriate notification” to a sender who won’t accept mail!
Therefore we insist on that check for all the low-cost accounts, as part of the general reliability needs of email.
Full-service accounts can disable the check; we provide the knob to twiddle but it’s their decision to make. Preferably they should whitelist that particular sender, which bypasses the check only for that sender, rather than disabling it wholesale – but again, their policy choice not ours. Disabling the check will reduce the reliability of the email system, as a message could be dropped without the sender being notified of the situation.
Verify Sender
This option enables testing that the alleged sender exists (to the extent that the mail system would accept a bounce message to it). This is more expensive as it involves our mail server contacting theirs, and not perfect since some badly-configured servers (including major names such as AOL, and the usual configurations of Microsoft Exchange) always claim to accept mail for any name.
Some mail providers consider using this type of check abusive, as a spammer thereby imposes a load on an innocent third-party by using their name.
We’ve also seen at least one email provider running what we consider to be a broken greylisting system, which never got around to enabling MAIL FROM:<> mails (as used by bounces). Because of this our attempt to see if they will accept a bounce is rejected every time they (correctly) retry sending us a mail, until they time out. Obviously, we’d never be able to send them a real bounce either.
The comments above about the Sender Domain also apply here.
Validate HELO data
This option tests that the name given at the start of the SMTP session as identifying the sending machine exists in DNS (whether there is an “A” record for the name, and whether a reverse-lookup of resulting IP address results in the same name).
Many less-proficient system admins fail to either set up DNS properly for their systems, or configure their mail system to use a technically-illegal HELO name. Spammers are often included among this number, as are zombied PCs sending directly using Microsoft software. Unfortunately, so are (otherwise) legitimate individuals sending direct using Microsoft software (as opposed to sending via their ISP’s mail system). Microsoft, most unfortunately, encourage such misconfiguration in their software guidelines.
Mutating HELO data
This option checks whether the sending IP address has been seen to use more than one name to identify itself at the start of the SMTP session. This appears to be a characteristic of certain types of spammer. Unfortunately some major corporations also disregard standards in this respect (Ebay, Amazon have been noted doing this); if you expect mail from such you should either do no more than “warn” on this condition, or explicitly whitelist those senders.