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:
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 <tim (at) timj.co.uk> 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.
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.
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:
To gain any benefit from this method, the signed envelope sender address that you generate should be useless in the hands of spammers. Typically, this would imply that the signature incorporates a time stamp that would eventually expire:
sender=timestamp=hash@domain |
If you send mail to a site that incorporates Greylisting, your envelope sender address should remain constant for that particular recipient. Otherwise, your mail will continuously be greylisted.
With this in mind, you could generate a Envelope Sender based on the Envelope Recipient address:
sender=recipient=recipient.domain=hash@domain |
Two more issues occur with mailing list servers. Usually, replies to request mails (such as "subscribe"/"unsubscribe") are sent with no envelope sender.
The first issue pertains to servers that send responses back to the Envelope Sender address of the request mail (as in the case of <discuss@en.tldp.org>). The problem is that commands for the mailing list server (such as subscribe or unsubscribe) are typically sent to one or more different addresses (e.g. <discuss-subscribe@en.tldp.org> and <discuss-unsubscribe@en.tldp.org>, respectively) than the address used for list mail. Hence, the subscriber address will be different from the sender address in messages sent to the list itself -- and in this example, also different from the address that will be generated for unsubscription requests. As a result, you may not be able to post to the list, or unsubscribe.
The compromise would be to incorporate only the recipient domain in the sender signature. The sender address might then look like:
subscribername=en.tldp.org=hash@subscriber.domain |
The second issue pertains to those that send responses back to the reply address in the message header of the request mail (such as <spam-l-request@peach.ease.lsoft.com>). Since this address is not signed, the response from the list server would be blocked by your server.
There is not much you can do about this, other than to "whitelist" these particular servers in such a way that they are allowed to return mail to unsigned recipient addresses.
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.
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.
| [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. |