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

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

Wed, 16 Jul 2008 01:21:57 GMT

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/

FastMail backscatter filter does similar to this...

Rob Mueller — Thu, 17 Jul 2008 06:50:07 GMT

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.

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

Frank — Fri, 18 Jul 2008 10:04:12 GMT

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.

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

Lee Maguire — Sat, 19 Jul 2008 00:42:53 GMT

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

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

Justin Mason — Sat, 19 Jul 2008 23:16:18 GMT

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.

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

Justin Mason — Mon, 21 Jul 2008 01:19:00 GMT

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

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

Manoj — Sun, 27 Jul 2008 20:24:33 GMT

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

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

Justin Mason — Thu, 07 Aug 2008 23:21:02 GMT

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

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

DWalker59 — Wed, 01 Oct 2008 01:36:59 GMT

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.

Postini's new features

Terry Zink's Anti-spam Blog — Sat, 08 Nov 2008 02:16:02 GMT

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