Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
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)
> 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.
Posted Apr 11, 2008 11:20 UTC (Fri) by dwmw2 (subscriber, #2063)
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?
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:
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:
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds