Terry Zink's Cyber Security Blog

Discussing Internet security in (mostly) plain English

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

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

  • Comments 11

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.

Leave a Comment
  • Please add 4 and 6 and type the answer here:
  • Post
  • PingBack from http://blog.a-foton.ru/2008/07/the-problem-of-backscatter-part-11-check-to-see-if-you-sent-it-in-the-first-place/

  • As an FYI, I implemented a backscatter filter in FastMail (http://www.fastmail.fm) a while back that does content analysis similar to this (http://blog.fastmail.fm/2006/04/21/new-backscatter-spam-protection/).

    For bounce emails, we analyse the Received: headers it finds for the "original" email in the bounce, and builds a list of hosts the original email came from. By default, it then checks against our outbound hosts, but also allows the user to configure custom hosts (eg they send email via an SMTP server that's not us, with a MAIL FROM address that's handled/forwarded to our servers)

    It took a bit of tweaking, but it's now quite effective (>95%). Not only does it catch standard "message/delivery-status" type notifications, but lots of other bounce style messages as well (eg "Below this line is a copy of the message", etc).

    Strangely hotmail.com was one of the most annoying. In some cases the bounced email isn't bounced at SMTP time. Of course for those cases hotmail generates the NDN "bounce" email. The annoying part is it includes a "text/rfc822-headers" MIME section, but the headers it includes have all the Received: headers stripped out. Grrrr.

  • A more sophisticated way to figure out which bounces are good bounces is "BATV" described in an Internet Draft. Roughly it changes the envelope sender address to a magic crypto-timestamp cookie at the outbound servers (or before). Any bounce not sent to a (still) valid magic cookie address can't be a good bounce, the inbound servers can reject it. The inbound servers (or something behind them) would also change the magic cookie back to the original envelope sender address, and BATV can work transparently form a user's POV. There are several caveats wrt RFC 3834 (e.g., vacation mail) among others. Any sender who can't publish a SPF FAIL policy for some reason also can't use BATV, as BATV requires some coordination between outbound and inbound servers.

  • Regarding hotmail.com bounces - I believe hotmail can generate non-deliverable style messages in response to user actions ("fake" bounces, if you will).

  • hi Terry --

    worth noting for SpamAssassin users that the VBounce ruleset does this, as well as applying content filtering to detect non-obvious bounces:  I've written a few posts over at my blog.  <a href="http://taint.org/2008/04/12/235407a.html">this one</a> is a good starting point.

  • oops.  wasn't expecting that ;) -- here's that URL: http://taint.org/2008/04/12/235407a.html

  • Hi Terry,

    Will the "Received headers" is a good choice to check backscatter?

    Consider a case where a user subscribed to a newsletter or greetings site. Now if he wants to send a greeting to xyz@mail.com, but a typo occurred and it was sent to cyz@mail.com. Obviously the user should get a bounce back that he has sent the greeting to a wrong address. Now here you'll mark, a legitimate bounce, as spam since you won't find your servers in Received header?????

    (It happened to me lot many times).

  • Manoj: exactly.  that's what the SA ruleset looks for.

  • Some sort of a GUID in mail that you SEND, which should be included in the header of any mail that comes back with an NDR, can fix the problem.  The tradeoff is that you (the sender) has to keep a database of GUIDs of mail he has sent (for some length of time).

    I think this (or something like it) is part of some of the proposals that are out there...  I haven't read the whole series yet, either.

  • Over on the Google Enterprise Blog, they recently posted the following with regards to some new features:

  • This blog has been created to share useful information. Thanks and greetings!

Page 1 of 1 (11 items)