I think the approach to dealing with forwarders needs to change. In
particular, I think we should sideline SRS and work on some kind of SMTP
extension to make forwarder whitelisting easier.
Specifically, I'd like to see an ESMTP extension where a sender can say
"I'm a forwarder, the recipient knows me as X and trusts me, so don't
SPF-check this message". X would be an identity that the recipient MTA
would check against a whitelist, and it would contain a domain so the
sender IP's right to claim that identity could be verified using SPF-like
DNS records.
Unlike SRS, which places significant burdens on the forwarder, this would
only require a software upgrade. Also, if the feature were available,
forwarders would have incentive to use it even if there was no SPF.
Consider what happens when spam makes it past a forwarder's own defenses.
Two bad things can happen:
* First, the recipient mailbox might have more sensitive content-filter
defenses, and reject the message at DATA. This leaves the forwarder
holding the hot potato -- they have to either risk silently dropping mail,
or risk emitting backscatter.
* The end-user might have a "This is spam!" button which trains an IP
blacklist, and be unaware of the implications of so tagging the forwarded
spam. Eventually the forwarder would develop a black reputation and be
unable to pass any mail to that mailbox, even though they aren't
themselves spam supporters.
The hypothetical extension would solve both of these problems in passing.
If the recipient trusts a forwarder enough to stand down SPF, they can
easily also stand down the IP-blacklist training and content filtering. By
solving these pre-existing problems, we can perhaps make the effective
deployment burden for the forwarder negative, and thus actually see some
uptake.
(SRS, in contrast, doesn't help with the IP training problem, and it makes
the hot-potato problem worse, since the forwarder assumes responsibility
for relaying the recipient's backscatter.)
This approach places a greater burden on the recipient than in the
original plan -- where all forwarders switched to SRS, and all recipients
applied a universal reject-on-SPF-fail policy. But it's an improvement on
the status quo, where nobody uses SRS and manual, unreliable whitelisting
of forwarder IP addresses is a prerequisite to acting on SPF "fail" or
"softfail" results.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735