On Tue, 2004-03-23 at 15:33 +0100, Alain Knaff wrote:
begin Tuesday 23 March 2004 14:30, David Woodhouse quote:
You can be more specific than that. The purpose and intent of SRS is to
fix the broken assumptions of SPF
Not necessarily the only use. SPF works wonders with other
sender-validation schemes as well. Here in Luxembourg, one large
ISP (pt.lu) is doing a very simple algorithm: if Envelope From is
pt.lu, but the IP is not one of pt.lu's it rejects.
Yep. This is one of the "recipient is known to pull a list of
'acceptable' IP addresses out if its wossname" cases which I had
actually addressed in my implementation and had already mentioned, but
which I neglected to repeat in the interest of simplicity.
This would be handled in my case by the following:
echo "pt.lu: all" >> /etc/exim/conf/spf-afflicted-domains
I should perhaps add an 'own' type to go with 'spf' and 'all', for those
who reject only their _own_ addresses coming from elsewhere, rather than
inventing bogus 'acceptable IP' lists for other domains, like gmx.de
apparently do.
Not valid if domain is "protected" by a different sender validation
system such MS caller-id for email, DMP, or just a manual access list
at the receiver...
True. OK.. more generally I should say "You don't need to rewrite unless
the recipient happens to think you're not an acceptable sender for the
source address in question".
In fact, I'll further qualify that by appending "_AND_ you care about
their choice to throw away valid mail."
And you don't need to rewrite when sending to a recipient who isn't
going to check SPF.
Dangerous. The recipient system may not be checking today, but he
might tomorrow. Also, it might be hard to find out dynamically whether
any checking occurs
True. But I didn't say it was easy to check. You don't _need_ to rewrite
unless the mail is going to be discarded (and perhaps not even then).
You might _choose_ to rewrite if you can't actually work out whether or
not it'll be discarded, but that's your decision.
My local policy is that if I find people rejecting forwarded mail due to
SPF or other similar reasons, I report that as a misconfiguration and
request that they stop. Only if they refuse to fix it and if I _really_
need my system to be able to forward to the domain in question, do I add
them manually to the 'spf-afflicted-domains' list.
Others may want to err more on the side of permissiveness at the cost of
performing far more rewriting than is absolutely necessary. I prefer to
abide by the principle of minimal munging.
Basically, the question you need to ask is "Is the flawed assumption of
SPF going to cause this message to be rejected because I'm sending it
from this particular IP address". And that question _is_ one that can be
answered in the output stage of your MTA.
Indeed. Except I would state it as "Is there _a_possibility_ that the
flawed assumption of SPF is going to cause this message to be rejected
because..."
That is a difference of local policy. You choose to mangle sender
addresses to work around _potential_ errors at the receiving end.
I choose to work around such errors _only_ if I know they exist, if the
offending party won't fix them, _and_ I actually need to get the mail
through.
That last condition, in particular, happens only if the recipient whose
forwarded mail is being rejected _cannot_ change service providers and
use a more sanely run domain as the target for the forwarding from my
systems.
But my point was that it _is_ a decision which can be made during your
output stage. After all, it's directly related to your second-guess of a
decision which the recipient is likely to make at _its_ 'receipt stage'.
Here is how we do it (at lll.lu and linux.lu): we apply SRS by default
as soon as we forward mails to destinations outside our administrative
realm (assuming From is not local, of course).
/me shudders... sendmail.cf. Now it's only fair that you have to read
the Exim one at http://www.infradead.org/rpr.html to make your eyes hurt
as much as mine now do. :)
--
dwmw2