On Fri, 2004-02-27 at 16:49 -0500, Meng Weng Wong wrote:
So forwarders have to adapt.
This is easier to say if there's actually something concrete to adapt
_to_. But that isn't currently the case; the strategies are still being
debated.
If there's a different technology that has a better adoption dynamic,
I'm all ears. It's never too late to find a better way.
I don't know.
I'm currently experimenting, as I believe I already mentioned, with SRS
on my _own_ outgoing mail, coupled with rejecting bounces to my 'raw'
email address.
It's only been in place a few days, so I haven't actually started
rejecting bounces yet. I've been monitoring though, and the only mails
with empty reverse-path that have arrived to the 'raw' address have been
joe-joe bounces. I'll roll out the actual rejection of bounces over the
weekend (although I've already been doing that for some time for other
old addresses which are forwarded to my current address).
The idea is that there is never valid MAIL
FROM:<dwmw2(_at_)infradead(_dot_)org>;
only MAIL
FROM:<SRS0+HHH+TTT+dwmw2+infradead(_dot_)org(_at_)srs(_dot_)infradead(_dot_)org>
Therefore, I can reject anything with empty reverse-path to the 'raw'
address dwmw2(_at_)infradead(_dot_)org(_dot_)
Since I do this, any third party who implements sender callouts will
observe that I'm not accepting bounces, and can correctly determine that
it should reject the mail it was trying to verify the sender of.
In this way, my email address is protected from joe-jobbing -- at least
in that _I_ won't receive bounces and third parties implementing some
fairly basic checks won't receive the faked mail. That's all we can hope
for, right?
It's obviously not a _perfect_ scheme, but it seems to work --
admittedly for all of a few days to far on a somewhat limited test set
of one address. I've noted one or two minor problems so far, but nothing
serious. They are:
- Some sites do callouts with postmaster@ rather than MAIL FROM:<>.
It was necessary to make the valid SRS addresses accept such mail in
order to let me send mail to, for example, pobox.com. That's not really
a problem, except that I didn't think do to so originally. In fact I
think mail from postmaster@ probably ought to be accepted to those
addresses anyway. Since they're limited-lifetime, hash-signed addresses
it doesn't hurt to be a bit permissive.
- Some sites do callouts with postmaster@ rather than MAIL FROM:<>.
Yes I did just say that twice. Sites who call out with postmaster@
rather than the empty SMTP reverse-path don't get the benefit of
rejecting mail with my address faked. Not a _fundamental_ problem, since
this just lumps them in with sites who don't do callouts at all. It
didn't break; it just didn't help them. Still helps _me_ -- since if
they later have to bounce the joe-job for other reasons I won't accept
it because they _will_ be using MAIL FROM:<> at _that_ time.
I'm trying to think back now to what else I've changed since the first
version. I implemented case sensitive hash signing because the localpart
is sometimes forced to lower case elsewhere before it gets back to you.
I think that's about it.
Doing the rewriting in the MTA at SMTP time means it _doesn't_ end up in
the Sender: header, so I don't believe Outlook users see the horrid:
'SRS0+noisynoisynoisynoisynoisy(_at_)srs(_dot_)infradead(_dot_)org on behalf of
David
Woodhouse' which was originally a potential concern.
The only other potential 'problem' I can think of off-hand is with
broken autoresponders. And by 'broken' I mean those which are _already_
considered broken in the Old World, before taking anything above into
account and without changing the rules.
There are two forms of breakage you occasionally see from
autoresponders. Firstly they may reply to the From: address rather than
the SMTP reverse-path, and secondly they may reply with a non-empty
reverse-path in their _own_ mail.
Either of these problems will cause the autoreply to be bounced -- it'll
either be a bounce to the 'raw' address or a 'real' mail to the SRS
address respectively. Of course, if the autoresponder commits _both_ of
the above sins then its mail will get through; more by luck than
judgement. There is a correlation between both forms of brokenness, so
some autoreplies may well get through that way, but some will inevitably
be lost.
I'm happy with that loss -- I'd probably have been reporting such
autoresponders to the abuse contact at the upstream network provider
_anyway_, and the value out-of-office replies is generally low.
To accept that loss is a policy decision which I'm happy enough to make,
but which others may be less happy about. Certainly it's less of a
problem than the false bounces I'd get with a strict implementation of
SPF, and it's fixable by getting people to apply what is _already_
considered common sense, rather than a new form of same.
On the receiving side, you obviously need to do callouts to get the
benefit. Some people consider callouts to be impractically expensive;
that's a matter of opinion and I disagree.
More importantly: as mentioned above, in order to get the benefit of
this you need to do callouts with MAIL FROM:<>. This is a _real_ problem
for some people, if they have to accept mail from sites in
dsn.rbl-ignorant.org. However, I believe (and this is untested) that it
should be possible to do a callout with MAIL FROM:<> but if the MAIL
command is rejected, then try MAIL FROM:<postmaster@<domain>> instead.
That way if the target accepts MAIL FROM:<> you get the real benefit of
checking whether they accept _bounces_, not just real mail -- but if
they don't like that you can still verify the address receives mail from
postmaster(_at_)(_dot_) As I said; that's untested since I do all callouts with
empty reverse-path anyway.
The opposite applies to _recipient_ verification callouts. These must be
done with a _real_ reverse-path. But doing r-v callouts to _unknown_
sites, rather than just between a backup MX and the hosts it's relaying
for, is I think fairly rare. And already breaks if you do it with empty
reverse-path to things like mailing lists, which are increasingly
nowadays starting to reject bounces to the list-submission address.
So in general, it looks promising.
--
dwmw2