On Sat, 2004-03-20 at 13:39 -0600, J Yunke wrote:
> For those that don't know much about SPF (http://spf.pobox.com) I will
> briefly state the problem. THIS PROBLEM MAY AFFECT YOU whether you adopt
> SPF or not, since SPF is currently being adopted by thousands of server
> administrators.
Those administrators are deliberately breaking their own systems and
deciding to be incompatible with the way that SMTP has worked for
decades. That is _their_ problem, and I recommend that sane
administrators do _not_ work around this brain damage except when it's
absolutely necessary.
> Now, there are solutions to mangle the addresses into the old-school
> SMTP # notation, but I think that's ugly.
Nevertheless, it does actually achieve the desired effect, as long as
you don't think too hard about the 64-character limit on localparts.
An Exim implementation can be found at
http://www.infradead.org/rpr.html
> Here's what I'd like to do:
Before I pick your suggestion apart -- seriously, please don't implement
SPF, and please work around its fundamental brokenness _only_ to the
extent you really need to. If you _must_ do some rewriting for the
benefit of users forwarding to SPF-afflicted servers, then do so _only_
for those servers known to be broken.
SPF does not claim to be a one-stop solution to end all spam. Don't
balance the weight of the 'spam problem' against the 'forwarding
problem'. Consider the actual _benefit_ of SPF against its problems.
SPF offers you a way to validate the _envelope_ sender (not the From:
header) of mail. It prevents you from receiving faked mail claiming to
have a reverse-path in a domain which has published strict SPF records,
and it can help to prevent you from receiving bounces to such faked mail
from domains which are strictly implementing SPF on receipt.
That's all it does.
If you want to avoid the problem of your users receiving bounces to mail
they did not send, the page at
http://www.infradead.org/rpr.html has an
example of how to do that _without_ needing to change the way the world
works. Basically you do rewriting only on your _own_ outgoing addresses,
so the 'raw' address (e.g. dwmw2@???) is never used in valid
MAIL FROM:. Then you can reject bounces to that address -- and anyone
doing sender verification callouts will hence also reject faked mail
_from_ that address.
That's the problem that SPF tries to solve -- but with a solution which
works _now_ without the breakage of SPF. You _instantly_ stop getting
bounces to fake mail, without anyone else having to do _anything_. And
many people also stop receiving the fake mail claiming to be from you,
if they're doing callouts.
> #1. I specify bob@??? as an exception that needs to go through
> a special header rewrite process. It isn't applied to all at
> mydomain.com, just bob@???.
Why not apply to all mail forwarded to @brokenfreemailprovider.com ?
That way, it's easier to handle keeping your database up to date. You
can add brokenfreemailprovider.com to the database only when they've
answered your email to postmaster@ explaining their misconfiguration,
and perhaps remove them when they fix it by no longer using SPF.
If the entries in your database are the _local_ user who's affected by
such breakage, that's less easy to track.
> #2. When a message comes in for bob@???, I want the From:
> header to be forced to super-postmaster@???.
This is irrelevant. It's MAIL FROM:<> that SPF looks at. You don't need
to change _anything_ in the mail itself (including its headers) to mail
SPF tests pass.
All you need to do is change the MAIL FROM:<>, and you need to do it in
such a way that bounces will get back to the original address given
there when the mail was delivered to _you_.
> #3a. If there's a Reply-to: header, I want the original From: header to
> be placed in X-Original-From (or something like that).
This gets lost. Too many broken mailers don't include headers from the
mail they're bouncing. You can't put the original address anywhere in
the headers -- it has to be encoded in the MAIL FROM: address you use
when sending the mail on, because that's the _only_ thing you can rely
on to be preserved in the bounce.
If you want to make your mailer compatible with SPF's Brave New World,
you _must_ encode the original reverse-path in the reverse-path you use
in forwarding. You can either encode it in the address directly, or use
it as a database key. Those are the only two options.
--
dwmw2
