On Tue, 2005-05-24 at 10:57 +0100, Chris Webb wrote:
> Gosh, you've implemented SRS-style rewriting entirely in Exim string
> expansion! Does this have any advantages over the libsrs_alt support now
> integrated into Exim 4.50 as part of the exiscan-acl patch?
Not really that I'm aware of. It's just that I did it long before the
libsrs_alt support was working. I don't really even use it for SRS per
se -- my 'spf_afflicted_domains' list of recipient domains for which I
should rewrite is almost empty. I really only use it for rewriting my
_own_ users' outgoing mail, so that I can authenticate bounces.
> It's certainly a very impressive of the power of the string expansion
> system!
It's also a very impressive demonstration of how silly I can get when
I'm bored. Although I'm not in Tony's league.
> > You don't have to do it unconditionally. You could do it only for mail
> > which originates from SPF-afflicted domains, and which is also destined
> > to servers which you know are rejecting mail for an SPF failure.
>
> As you say, the former ought to be relatively straightforward to test,
> although I'd like to be able to be more specific than just testing for an
> SPF-affected domain. There may be SPF domains that allow a (perhaps very
> wide) subset of hosts including our machines (especially people we've
> complained to in the past, who've just added our mail servers to their SPF
> host list!), and we don't want to rewrite for that case if we can help it.
True.
> The SPF checking code is already in Exim 4.50 for the spf ACL condition,
> it's just getting at it and applying it to the MAIL FROM address from within
> a router condition that's the tricky bit!
You also need to run the check against your own outgoing IP address,
which you won't necessarily have until you get to the transport.
> (I'd like to avoid the extra admin work of having to maintain a list of
> hosts that reject on SPF mismatch, so
Don't just rewrite across the board. The reverse-path contains useful
information -- it's the only 100% reliable way to filter mailing list
traffic, for example. And if every hop were to rewrite unconditionally
the reverse-path would very quickly get silly.
I'd suggest you try it. I expected a certain amount of 'extra admin
work' from doing it this way, but in fact it turns out that I
drastically overestimated the amount of work it would take. It's
actually quite rare for people to be dim enough to really reject for SPF
failure, and on the rare occasion that it's happened, a simple
explanation or reference to something like
http://david.woodhou.se/why-not-spf.html has usually persuaded them to
actually think about what they're doing rather than just listening to
the hype, at which point they've fixed their problem and I haven't
needed to add them to the list.
You can always fall back to doing it for all recipients if you really
_do_ find that it's more work than you wanted.
> I'm inclined just to never generate mail that could provoke such a
> failure, despite this going somewhat against the grain.)
I see your point, but this really isn't your fault. If other people out
there want to invent new rules about how SMTP works, it isn't your
responsibility to 'keep up' with them. If I declared that I would no
longer accept mail from you if it didn't have a GPG signature, would you
rush to comply?
One option I'm seriously considering is just to reject all _incoming_
mail if an SPF record says I wouldn't be able to send it on, regardless
of whether the ultimate recipient is actually at a domain which checks
SPF -- and in fact regardless even of whether I'd end up forwarding the
mail at all, or whether it's a local delivery.
By implementing SRS unconditionally, you're only pandering to the
stupidity and helping to make the problem worse. Please don't do that --
if you have to make an exception for a limited number of sites who
refuse to correct their behaviour, that's sane enough, but don't do it
unconditionally.
--
dwmw2
