wayne wrote:
My conclusion: I'm not so sure that that a "HARD PASS" is that useful.
ACK, in the draft I put it that way:
| Please note that the "auth" property has no technical effect. It is
| arguably better to use a "Neutral" mechanism for any shared smart
| host, and to use "Pass" only if the MSA enforces submission rights.
Updates welcome, I want to get rid of this beast at some point in time.
At the moment it's waiting for some interesting addition for DKIM, and
of course for implementations. The op=pra is by far the hottest at
this time, and op=auth should at least cause no harm.
My conclusion: An appropriate "I really mean FAIL" policy could be
useful.
This is a fatally flawed incorrect conclusion. Adding "I really mean
FAIL" is a sure killer for the complete project:
Obviously senders are prepared that failing mail is rejected, that's
noted right in the intro, section 1. And they know that checks won't
work behind the border of the receiver. At best FAILS can be still
correctly identified, and deleted. Most chances to fix problems with
erroneous policies or odd forwarding scenarios are gone if the mail
is deleted. Not so if failing mail is rejected a.s.a.p., as it should.
That is obvious. There's even a SHOULD about where to check SPF, and
at this _recommended_ place, the border MX, anybody who considers to
accept FAIL tagged as "suspicious" is a psychopath. The hapless users
will of course delete all mails tagged as "suspicious", they have no
time to check thousands of "suspicious" mails per day manually.
Only reject is save for the rare "false positives", senders screwed up
with their policy, or receivers arranged forwarding from SPF-ignorant
to SPF-checker.
Millions of policies are published under that obvious assumption. It
won't do to devaluate all existing FAIL policies, and all receivers
doing the right thing today (= reject FAIL) by the introduction of a
new HARDFAIL. Harmful. Potentially worse than the PRA abuse.
Now, for fun, you might want to ponder whether "SoftFail", something I
lobbied Meng to get put back into SPF, actually passes the above three
criteria.
It doesn't. For receivers it's unclear what the sender actually wants
in cases like PayPal, where any reasonable period for SOFTFAIL-testing
ended years ago. For senders it's an illusion that they can test the
water with SOFTFAIL. Actually most receivers won't care how senders
test the water, maybe they accept SOFTFAIL tagged as "suspicious".
Same reasoning as above, accept as "suspicious" is more dangerous than
a clear reject, potentially causing losses of legit mails. We're all
lazy and cowards and want somebody else to eat shit. Without clean
decisions (publish FAIL, not SOFTFAIL - reject FAIL, don't tag it) SPF
won't work as expected in the long run.
Finishing another episode in "the last years of SMTP": Frank
-------
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