| |||||||||||||
Backscatter increase clogs inboxesBackscatter increase clogs inboxesPosted 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:<dwmw2@infradead.org>, 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 dwmw2@infradead.org 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 technique?
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 http://lwn.net/Articles/189531/ 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. jake
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: <originaldomain>+<originaluser>@example.orgBut 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 domain+user@example.org 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: SRS0+<hash>+<timestamp>+<domain>+<user>@example.orgI 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:<dwmw2@infradead.org>, it's rewritten to something like <SRS0+d6ac8e5b21d8f29d40b9+1675+infradead.org+dwmw2@pentafluge.srs.infradead.org> — 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 dwmw2@infradead.org to sourceforge, for example: 220 mail.sourceforge.net ESMTP Exim 4.44 Fri, 11 Apr 2008 02:40:10 -0700 sc8-sf-mx1.sourceforge.net HELO pmac.infradead.org 250 mail.sourceforge.net Hello pmac.infradead.org [90.155.92.200] MAIL FROM:<dwmw2@infradead.org> 250 OK RCPT TO:<bluez-devel@lists.sourceforge.net> 550-Verification failed for <dwmw2@infradead.org> 550-Called: 213.146.154.40 550-Sent: RCPT TO:<dwmw2@infradead.org> 550-Response: 550-This address never sends messages directly, and should not accept bounces. 550-550-Please see http://www.infradead.org/rpr.html or contact 550-550 postmaster@infradead.org for further information. 550 Sender verify failed QUIT 221 mail.sourceforge.net 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 http://www.infradead.org/rpr.html. 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.
|
|||||||||||||