John Glube wrote in mxcomp:
I should have written:
|The underlying benefit of e-mail authentication for senders
|interested in e-mail delivery is to establish a framework that
|supports certification and reputation services, both external
|and internal to facilitate the delivery of ham, while rejecting
|spam [1]
That was not the main purpose of SPF. "SHOULD check HELO" was
added in 2005, because it was always allowed and possible, and
it makes sense for the reasons you have stated.
But the main idea of SPF is to get rid of backscatter, numerous
bogus bounces / challenges / other auto-responses to forged
Return-Paths. With side effects, some hard, others desirable.
Above all _save_ good bounces because SMTP without any bounces
won't work. To save the good bounces and other auto responses
it is essential to get rid of the bad backscatter a.s.a.p.
How fast it's adopted by senders or receivers is less important
- that "smart" spammers stay away from FAIL-protected addresses
is the point.
SPF is designed to offer an immediate benefit for participants,
especially spoofed "senders".
receivers can use their sender policy records for what ever
purpose they want, irrespective of the stipulated protocols
is not acceptable.
Of course, receivers could decide to block everybody with(out)
sender policy, count characters in a sender policy, or "check"
a Message-ID, etc. Their server, their rules.
Nevertheless those interested to avoid backscatter will try to
follow the rules as defined in the SPF RfC. Or they use a
proper subset, e.g. "without FAIL-chance I won't waste time",
or "let's only use PASS + white lists", or "MAIL FROM stuff is
tricky, forget it, but the HELO tests are nice".
Other checks (PRA, Message-ID, policy length in characters)
are NOT RECOMMENDED, because that's not what the publisher of
a v=spf1 policy intended.
And as William pointed out, it would be also FUBAR to try a
HELO-test with a spf2.0/pra policy. A PRA-policy is not for
HELO tests. Receivers are free to try it anyway, but they are
far beyond anything specified in the senderid drafts if they
do this.
And of course this won't work, any "FAIL" they'd get would be
a fantasy-FAIL, not a senderid-FAIL, let alone a SPF-HELO-FAIL.
SID like SPF is a protocol, it works as designed, receivers
are on their own if they break or twist it. One thing that
is erroneously specified in SID (= _not_ working as designed)
is to check PRA against v=spf1.
That's the point of the appeal. No amount of weasel words can
change this, it is a serious security bug and has to be fixed.
it seems SPF folks supporting the appeal are not interested
in pushing back on Microsoft as it relates to the IPR
Why should we ? It's none of our business, that's something
SID-implementors would discuss with MS. I'm confident that
MS can handle all IPR questions about SID without any "help"
from the SPF community.
simply want to fully sever the relationship between spfv1 and
spf2.0.
That's not the case, it's okay to share the same DNS RR, it's
okay to use v=spf1 as spf2.0/mfrom, it's okay to use the same
result codes, the same error handling, an almost identical
syntax, and the same processing limits.
So why should they reinvent the wheel, "build on the work of
others". I've seen statements from Wayne where he offers to
help with spf2.0. I'm sure that Meng would also help. I've
offered op=pra as a way to get an "spf2.0/mfrom,pra" effect
in a "v=spf1 op=pra" record for those who explicitly want it:
http://purl.net/xyzzy/home/test/draft-spf-6-3-options-08.txt
So far they didn't react and want any help - no big surprise,
from a technical POV neither SPF nor SID are rocket science.
In that case, I presume the SPF Community has no problem
with these potential developments:
I skip this, ex falso quodlibet.
there is every possibility that those supporting "technical
purity" within the SPF Community are in for a rude awakening
The "rude awakening" when an SDO like the IETF intentionally
allows conflicting standards ("experiments") only to please MS
would be far worse.
Bye, Frank (please fup2 general list)
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf