The problem of backscatter, part 11 - Check to see if you sent it in the first place

Other than content filtering and SPF, there's 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 we sent the message in the first place.  BTW, most of this post is based upon information found at the Postfix How-To.

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

HELO: mail.example.com
MAIL FROM: tzink@example.com
RCPT TO: someguy@example.org
DATA
<etc>
.
QUIT

If someguy@example.org 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 say 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.

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).

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

I also don't HELO with a 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. 

Thus, this way to fight backscatter is to do it when it hits your inbound server and handle it in a special way different from the regular inbound filtering.   Verify first that it is a bounce message (it contains postmaster@, a null sender <>, Undeliverable in the subject line, etc).  Next, look for some tell-tale characteristics that say the message came from you.  What do the Received headers look like?  Can you grab something from there?  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 (ie, 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 features into your outbound mailer that you can distinctively 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 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, the recipient MTA just did a lousy job of letting you know.