Nico Kadel-Garcia wrote:
Julian Mehnle wrote:
Foremost, a "Received-SPF:" header should not be added as a result of
an _outbound_ SPF check. The header name kind of implies that.
Sure it can. The outgoing mail should be checked for forged webmail or
spam traffic, since often people can accidentally get their laptops
zombi-loaded or virus-laden when they travel or take it home.
No. Of course outbound SPF checking is useful (I never disputed that, and
I'm doing it myself), but a "Received-SPF:" header should _not_ be added
as a result of an outbound SPF check.
[The "R-SPF:" header] will get replaced at the next SPF compliant SMTP
server.
A "R-SPF:" header that results from an outbound SPF check is useless. All
software that cares about "R-SPF:" headers in messages should only use
_trusted_ "R-SPF:" headers, and a "R-SPF:" header that has been created by
a 3rd-party sending MTA as a result of an outbound check (or as a result
of anything else, it doesn't matter) is generally _not_ trustworthy.
Receivers need to do their own SPF checks. The point of doing outbound
SPF checks is to protect one's own network against forgers (including
viruses/zombies), not to provide others with untrustworthy "R-SPF:"
headers.
Distinguishing between the filtering inbound and the filtering outbound
is often adding complexity and debugging confusion, since mail that
works from inside will work outside or vice versa.
In general I agree. But SPF is a special case because outbound SPF
checking works significantly differently from inbound SPF checking. On
inbound checking I evaluate spf(sender_address, caller_ip), while on
outbound checking I evaluate spf(sender_address, my_own_ip). Thus I
_have_ to distinguish.