User: Password:
Subscribe / Log in / New account

Backscatter increase clogs inboxes

Backscatter increase clogs inboxes

Posted Apr 10, 2008 13:37 UTC (Thu) by dwmw2 (subscriber, #2063)
Parent article: Backscatter increase clogs inboxes

It's not particularly difficult to avoid backscatter. I never send MAIL FROM:<>, and thus I never need to accept bounces to that address.

Instead of using my raw email address as the SMTP reverse-path of outgoing mail, my mailservers automatically rewrite it to include a timestamp (and an md5 hash to make it non-trivial to fake). Then they can recognise and accept only valid bounces to mail which I did actually send, while rejecting the backscatter from fakes.

As an added bonus, when I started doing this, people whose mailservers bother with sender verification callouts were also able to reject the mail faked to appear from too.

(Log in to post comments)

Backscatter increase clogs inboxes

Posted Apr 10, 2008 16:22 UTC (Thu) by eli (guest, #11265) [Link]

Interesting idea.  Do you have a link to the software you use for that, 
and configuration details?  What drawbacks have you run into with this 

Backscatter increase clogs inboxes

Posted Apr 10, 2008 16:34 UTC (Thu) by jake (editor, #205) [Link]

> Interesting idea.  Do you have a link to the software you use for that,
> and configuration details?  What drawbacks have you run into with this technique?

I probably should have referred to it in the article, but we had some information about Bounce
Address Verification in 

I think that is what David is referring to or is something similar.  The info in that article
may be getting out of date now, though.


Backscatter increase clogs inboxes

Posted Apr 11, 2008 11:20 UTC (Fri) by dwmw2 (subscriber, #2063) [Link]

Interesting idea. Do you have a link to the software you use for that, and configuration details? What drawbacks have you run into with this technique?
It was originally done in response to the brain-damage of SPF — an implementation of the 'Sender Rewriting Scheme' which the SPF nutters thought every existing forwarding host would end up implementing to conform to their retroactive redefinition of SMTP.

The idea was that in the Brave New World you weren't allowed to simply forward mail intact as we've been doing for decades. That's now called "forgery". So when forwarding a mail to a broken server which checks SPF, you have to mangle the source address to appear to be from one of your own domains instead. So you might rewrite it something like:

But that obviously isn't safe, because you want people to be able to receive bounces through this path — you have to relay those bounces on to the original user. If you were to just accept any old and forward that to user@domain then you'd effectively be an open relay.

So the scheme has to provide some kind of authentication on these made-up addresses, which we do with a crypto hash of the address with some local secret. Also we want to time-limit these signed addresses to prevent them being harvested and used for ever more. And add a prefix so we disambiguate from normal user addresses easily. We end up with something more like:

I implemented this and set it up so that it triggers only when forwarding mail from a domain with an SPF record, to a known SPF-afflicted recipient. Although it was mostly pointless because before adding such recipient domains to the list, I'd contact their postmaster and explain to them how broken SPF was and how it was causing them to reject valid mail — and they'd usually just stop rejecting for SPF failures. My 'spf-afflicted-domains' list has remained fairly much empty

But then I realised that the rewriting scheme itself could achieve most of what SPF set out to do, without the brokenness. I just set it to rewrite my own outgoing mail. So instead of sending MAIL FROM:<>, it's rewritten to something like <> — which is only in the SMTP transactions and the Return-Path: header of the mail; it's not visible in the From: header so most people never even notice.

I accept bounces (MAIL FROM:<>) only to the signed addresses, and — this is the important part — don't accept bounces to the normal address.

This has the knock-on effect that other people don't need to accept faked mail from the normal address either. Here's an attempt to feed fake mail from to sourceforge, for example:

220 ESMTP Exim 4.44 Fri, 11 Apr 2008 02:40:10 -0700
250 Hello []
250 OK
550-Verification failed for <>
550-Sent:     RCPT TO:<>
550-Response: 550-This address never sends messages directly, and should not accept bounces.
550-550-Please see or contact
550-550 for further information.
550 Sender verify failed
221 closing connection

It's done in Exim, which is versatile enough to do it all for itself without needing external software. My original write-up is at It's slightly out of date now — one of the things I've changed since then is to remove the full timestamp from the domain part, since it interacted badly with greylisting (as it's regenerated each time). The setup I'm actually using currently is here.

There are a couple of caveats that I've noticed, but nothing particularly problematic (for me, at least). The first is that it can interact badly with broken vacation messages or other autoresponses. If an autoresponse message is sent as a bounce, but to the From: address instead of to the SMTP reverse-path, then it obviously gets rejected. Some consider that a feature, though — and in fact most of the broken autoresponders out there are doubly-broken: not only are they sent to the From: address, but they're also not sent as a bounce. Which means they get through just fine, which is unfortunate when they are responding to faked mail, but thankfully there aren't so many of them that it negates the benefit overall.

The other problem I've seen was a mailing list which allows only senders to post, and does so by checking the SMTP reverse-path. Almost all mailing lists check the From: address, which works fine. I've encountered precisely one list which does it on the reverse-path, and ironically that was the one which was set up to discuss the whole 'Signed Envelope Sender' scheme. It's easy enough to work around — you just keep a list of such recipients and have your system use a special, fixed 'time' value when sending mail to those recipients. I never got round to implementing that; I just used a different address for that list, and have never seen the problem again.

Backscatter increase clogs inboxes

Posted Apr 11, 2008 15:41 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

I use a similar technique in my personal spam filter. All mail I send has my name in the "from:" RFC822 header. When I receive a bounce message, I look at the from: header of the bounced message and if it doesn't have my name, I know it's a bounce of something I didn't send. (Actually, I think I just do a string search of the entire bounce message for my name).

But I note that in the past two days, only 1 of the 900 spams addressed to my userid was a backscatter bounce. I know it used to be more.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds