The problem of backscatter – part 2

Last month, we introduced the problem of backscatter spam, describing what it is and why it is such a problem. We also looked at why it is so difficult to stop. Fortunately, the situation is not hopeless and this month we will look at some of the methods we have at our disposal to help combat this irritating type of spam.

One technique we can use to help combat backscatter is to block all NDR messages, or at least tag the phrases and characteristics that commonly occur in NDR backscatter as inputs to a spam filter decision. The Spamnation website [1] recommends some fields to examine, in order of usefulness:

If a spam filter were to look for the above characteristics and block mail based on them, there’s a good chance that it would block a very healthy portion of NDR backscatter. The problem is that it would also block a lot of legitimate NDR mail.

Another, riskier, blocking strategy would be to block all mail with a null sender, <>, in the SMTP MAIL FROM field. As many MTAs will send bounces with null senders (so as not to receive a bounce back if the NDR cannot be delivered), blocking all mail with a null sender will succeed in blocking the bulk of NDRs. However, there are some drawbacks to this:

There are some mail delivery systems that already refuse to route mail with an empty sender due to the excessive abuse of backscatter. These systems are prone to the false positive problems described above. You can get around this by setting inbound ‘allow’ policy rules for other characteristics, for example, you could have ‘allow’ rules for certain IPs and ‘reject’ rules for null MAIL FROMs. The inbound ‘allow’ rule could supersede the ‘reject’ rule. The drawback of this strategy is that it creates large numbers of ‘allow’ rules that become impossible to manage because of all the exceptions to the rule.

So, content filtering based upon From/Subject/Body examination is one way to fight backscatter, albeit with false positive problems. If you have a handle on who you want to accept mail from (no pun intended) then you can create exceptions. But remember, managing exceptions can become a real pain after a while.

Another trick for combating backscatter is to use SPF records. SPF records are designed to help combat backscatter on the theory that the recipient mail server will be able to figure out that your server didn’t send it. Here’s how it works:

However, my mail server is smarter than that. When it accepts the message, it does some spam filtering. It sees that the sending IP for the message is 288.41.18.19. It then looks up the SPF record for example.com and sees it is 256.18.19.0/24. It determines that the sending IP is not in the SPF range for the domain in the MAIL FROM. My mail server sees that any mail coming from example.org that fails the SPF check has a hard fail, '-all'. It assumes that the message is spoofed/forged and decides not to send an NDR back to [email protected], the purported sender. Instead, it simply drops the message. No backscatter is sent back to me.

The use of SPF records is a way to avoid contributing to the backscatter problem, but this technique is entirely dependent upon the recipient MTA. The recipient MTA must perform an SPF check on the message and then decide not to take its normal course of action on non-deliverable mail. Thus, logic must be built into the MTA to perform custom actions depending on the authentication results.

Not every MTA will do this. SPF checks require DNS queries which are somewhat computationally expensive. It is quicker and easier simply to check to see if the message can be delivered and then take action, rather than check, verify, and then take action. Still, using an SPF record with ‘-all’ in it means that you have given receiving MTAs the help they need in order to determine whether you actually sent the message. Whether or not they use this information is up to them.

There is another way to combat backscatter – check to see if you sent the message in the first place. We have already seen that NDR messages and backscatter contain a notice from the bouncing email server as well as all, or part, of the original message. We can use this bounce message to figure out whether or not you sent the message in the first place.

Suppose that my email address is , and my mail server is mail.example.com. My mail server always sends mail like this:

HELO: mail.example.com
MAIL FROM: [email protected]
RCPT TO: [email protected]
DATA
<etc>
.
QUIT

If [email protected] were to see this message in his inbox and look at the message headers, he would see a line something like the following:

Received: from mail.example.com (mail.example.com [188.24.229.80])

Properly interpreted, the part in parentheses says that this SMTP transaction came from 188.24.229.80 and the mail server HELO’ed as mail.example.com. The recipient mail server did a reverse DNS lookup of 188.24.229.80 and it said mail.example.com. Thus, mail coming from me has Forward-Confirmed Reverse DNS set up.

Suppose the message headers said the following:

Received: from host.example.com (unknown [188.24.229.80] helo=example.com)
...

My mail servers don’t do it that way. They don’t HELO with nothing (that’s what unknown means).

Received: from [188.24.229.80] (port=12345 helo=example.com)...

My mail servers don’t HELO with example.com or with a port in the HELO. My reverse DNS is not the IP that I sent it from. Suppose it said the following in the bounced body content Received headers:

Received: from mail.example.com (HELO mail.example.com)
[123.123.122.101]...

This one comes close, but notice that the IP it came from is not one of my IPs. I can see that the IP should have failed an SPF check (and the recipient mail server should have detected this and not bounced it... tsk, tsk). What if the body contents had said this:

Received: from host.example.com (EHLO example.com) ...

I also don’t HELO with an EHLO. These are all examples of anomalies in the way that my mail servers send mail. You could spot similar abnormalities in the Message-ID tag. If it doesn’t conform to the way I generate them, then I know that I didn’t send it and that the bounce message did not originate from me.

This method of fighting backscatter is to do it when it hits your inbound server and handle it in a different way from the regular inbound filtering. Verify first that it is a bounce message, for example by looking for the Content-Type: multipart/report; report-type=delivery-status; header.

Next, look for some tell-tale characteristics that say the message came from you. What do the Received headers look like? The HELO line is usually pretty distinctive, and so is the Message-ID. Do you sometimes insert a special X-Header into your outbound messages?

If the message is a bounce message and lacks some of these distinctive features, you can be fairly certain that the message is backscatter (i.e. bounce-back spam that did not originate from you). The advantage of this feature is that you don’t have to rely on someone else to do the spam filtering as in the SPF model. Messages that are uniquely yours are difficult to spoof and it is unlikely (though possible) that a spammer would spoof something unique to you in order to spam you. Of course, you wouldn’t actually accept a message simply because it looks like it comes from you, you would only not reject it. You would need a stronger method of authentication.

The downside is that you have to insert special distinctive features into your outbound mailer that you can recognize, and you need to have special handling for NDRs that implement custom logic that you wouldn’t normally perform on inbound messages. Rejecting mail in this way again imports additional risk because some MTAs will bounce messages back to you and won’t conform to the Pirates’ Code (see part 1 of this article, VB September 2008, p.S2) of sending DSNs; they may not send back all of the headers or they may modify some of them. In this case you could end up rejecting messages that legitimately came from you, when the recipient MTA just did a lousy job of letting you know.

It would be remiss of me not to include a section on how mail administrators can make sure they do not contribute further to the problem of backscatter [3].

Even if we all can’t stop backscatter, let’s not make it worse by contributing to it. Don’t send mail automatically if you can’t deliver it or without verifying that whoever sent the message actually sent it.

There are a number of competing mail transfer agents out there, including Microsoft Exchange, Postfix, Sendmail, qmail, Exim, and so forth. I am not an expert on MTAs but I know a few things about them.

Qmail is a mail transfer agent that runs on Unix. It was written by Daniel J. Bernstein [4] as a more secure replacement for the popular Sendmail program. When first published, qmail was the first mail transport agent that was written with security in mind. Other MTAs with security concerns addressed have been written since then.

Qmail is designed to accept mail for all of its domains and not perform any recipient validation. If the recipient doesn’t exist, it generates an NDR. In other words, it accepts, then bounces. This, of course, can generate backscatter.

Another thing about some older versions of qmail is that it doesn’t put in the following header in a bounce:

Content-Type: multipart/report; report-type=delivery-status;

I know this because recently I had to investigate a customer complaint. They claimed that because the bounce message did not have that header (which is required by the Pirates’ Code), the message was not backscatter; rather, it was a spammer spoofing backscatter and getting through the filters. While it’s certainly possible that a spammer would do this, it turned out to be a qmail-generated bounce message that did not include the header.

Qmail does put this in the bounce message, however:

Hi. This is the qmail-send program at mail.someorganization.com.

I’m afraid I wasn’t able to deliver your message to the following
addresses.

This is a permanent error; I’ve given up. Sorry it didn’t work out.

It also inserts the following header:

Received: (qmail 9999 invoked for bounce);

So, it is quite interesting that some qmail implementations do not include the Content-Type header but do include the above bounce message. It does not quite comply with the RFC (or Pirates’ Code), but it’s part way there.

The moral of the story is: if you are running qmail, don’t just use the default implementation. There are some patches out there [5] that will fix the accept-then-bounce behaviour.

In this article we have seen some techniques for minimizing the backscatter issue. In the next article, we will examine a technique that has a much greater success rate at blocking backscatter – Bounce Address Tag Validation.