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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf