On Sat, 5 Jan 2008, Allesandro Vesely wrote:
A "Fail" result is an explicit statement that the client is not
authorized to use the domain in the given identity. The checking
software MUST reject the mail outright.
Marking may allow messages with abused names to hit users. SPF should
avoid exactly that. There are no false positives, since the domain
owner is the direct origin of such "explicit statement". (Yes, there
may be errors in the SPF setup, that's why SOFTFAIL exists. See next
post.)
I strongly disagree with this. It effectively forbids the client from
taking measures to mitigate traditional-forwarding false positives.
This relates to the key issue I tried to bring up during the last SPF
election. Many SPF partisans seem to want to rush receiverside SPF
deployment, getting entire ISPs to move to a reject-on-SPF-fail-policy
all at once, disregarding the FP risk caused by traditional forwarders.
They hope that, confronted with a unified wall of SPF-implementing
recipients, forwarders will give up the simple traditional forwarding
methods and adopt SRS.
I think this is folly. It's a chicken game, with four states:
1A - forwarders use SRS, recipients do not enforce SPF
1B - forwarders use SRS, recipients enforce SPF
2A - forwarders operate traditionally, recipients do not enforce SPF
2B - forwarders operate traditionally, recipients enforce SPF
We are presently in state 2A, and would like to reach 1B. The forwarders
generally aren't willing to move to 1A, so we can only either remain in 2A
or move to 2B. 2B is the state where the false positives occur.
True, the forwarders have less to lose by moving to SRS than recipients
have to gain by deploying SPF (after the forwarders give up). But it's
the forwarders, not the recipients who have the *power* here. They'll
probably just tough out state 2B until the recipients give up and roll
back to state 2A.
But that's not the real problem, for there is a third party -- the
ultimate sender. The sender only cares about avoiding state 2B, and can
unilaterally force a rollback to state 2A by simply *not publishing a -all
SPF record*.
It's very bad if the sender does this. If an individual recipient gives
up, only he is affected. But there's also an elite class of recipients
who can get the benefits of state 1B by enumerating all forwarders and
exempting them from local SPF checking. If the sender gives up, these
innocent elite users *also* get knocked back into a virtual state 2A.
Your statement -- ``There are no false positives, since the domain owner
is the direct origin of such "explicit statement".'' is basically saying
that it's the duty of the sender to retreat from SPF unless he wants to
accept responsiblity for forwarding false positives.
Since sender-SPF deployment is far more critical than receiverside-SPF
deployment, I call that a destructive stand.
(I think the way forward is to make forwarder-whitelisting easier, so
that eventually everyone can join the elite class who can deploy
receiverside-SPF safely.)
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=82140043-fae172
Powered by Listbox: http://www.listbox.com