Backscatter increase clogs inboxes
Posted Apr 11, 2008 11:20 UTC (Fri) by dwmw2
In reply to: Backscatter increase clogs inboxes
Parent article: Backscatter increase clogs inboxes
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 email@example.com
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:<firstname.lastname@example.org>, it's rewritten to something like <SRS0email@example.com>
— 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 firstname.lastname@example.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
250 mail.sourceforge.net Hello pmac.infradead.org [22.214.171.124]
550-Verification failed for <email@example.com>
550-Sent: RCPT TO:<firstname.lastname@example.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 email@example.com for further information.
550 Sender verify failed
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.
to post comments)