2.7. Blocking Collateral Spam

Collateral Spam is more difficult to block with the techniques described so far, because it normally arrives from legitimate sites using standard mail transport software (such as Sendmail, Postfix, or Exim). The challenge is to distinguish these messages from valid Delivery Status Notifications returned in response to mail sent from your own users. Here are some ways that people do this:

2.7.1. Bogus Virus Warning Filter

Most of the time, collateral spam is virus warnings generated by anti-virus scanners[1]. In turn, the wording in the Subject: line of these virus warnings, and/or other characteristics, is usually provided by the anti-virus software itself. As such, you could create a list of the more common characteristics, and filter out such bogus virus warnings.

Well, aren't you in luck - someone already did this for you. :-)

Tim Jackson maintains a list of bogus virus warnings for use with SpamAssassin. This list is available at: http://www.timj.co.uk/linux/bogus-virus-warnings.cf.

2.7.2. Publish SPF info for your domain

The purpose of the Sender Policy Framework is precisely to protect against Joe Jobs; i.e. to prevent forgeries of valid e-mail addresses.

If you publish SPF records in the DNS zone for your domain, then recipient hosts that incorporate SPF checks would not have accepted the forged message in the first place. As such, they would not be sending a Delivery Status Notification to your site.

2.7.3. Enveloper Sender Signature

A different approach that I am currently experimenting with myself is to add a signature in the local part of the Envelope Sender address in outgoing mail, then check for this signature in the Envelope Recipient address before accepting incoming Delivery Status Notifications. For instance, the generated sender address might be of the following format:
localpart=signature@domain

Normal message replies are unaffected. These replies go to the address in the From: or Reply-To: field of the message, which are left intact.

Sounds easy, doesn't it? Unfortunately, generating a signature that is suitable for this purpose is a bit more complex than it sounds. There are a couple of conflicting considerations to take into account:

At this point, this approach starts losing some of its edge. Moreover, even legitimate DSNs are rejected unless the original mail has been sent via your server. Thus, you should only consider doing this if for those of your users that do not roam, or otherwise send their outgoing mail via servers outside your control.

That said, in situations where none of the above concerns apply to you, this method gives you a good way to not only eliminate collateral spam, but also a way to educate the owners of the sites that (presumably unwittingly) generate it. Moreover, as a side benefit, sites that perform Sender Callout Verification will only get a positive response from you if the original mail was, indeed, sent from your site. In essence, you are reducing your exposure to sender address forgeries by spammers.

You could perhaps allow your users to specify whether to sign outgoing mails, and if so, specify which hosts should be allowed to return mails to the unsigned version of their address. For instance, if they have system accounts on your mail server, you could check for the existence and content, respectively, of a given file in their home directory.

2.7.4. Accept Bounces Only for Real Users

Even if you check for envelope sender signatures, there may be a loophole that allows bogus bounces to be accepted. Specifically, if your users have to opt in to the scheme, you are probably not checking for this signature in mails sent to system aliases, such as postmaster or mailer-daemon. Moreover, since these users do not generate outgoing mail, they should not receive any bounces.

You can reject mail if it is sent to such system aliases, or alternatively, if there is no mailbox for the provided recipient address.

Notes

[1]

Why on earth the authors of anti-virus software are stupid enough to trust the sender address in an e-mail containing a virus is perhaps a topic for a closer psychoanalytic study.

mirror server hosted at Truenetwork, Russian Federation.