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. 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.
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:
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 |
Although this address does not expire, if you start seeing
junk mail to it, you will at least know the source of the
leak - it is incorported in the recipient address.
Moreover, you can easily block specific recipient address
signatures, without affecting normal mail delivery to that
same recipient.
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.
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.
|
|