"It is the opinion of the co-chairs at this time (before the end of last call) that the MARID working group has no consensus regarding the deployment of Sender ID. This lack of consensus centers around the IPR associated with the PRA algorithm."

I asked Yakov Shafranovich what it means that they can't reach consensus, and here is his explanation:

"Sender-ID appears to be probably dead in its current form. It remains to be seen whether Microsoft will continue pushing the current form of Sender ID or agree to the compromise proposed by the MARID co-chair."

It appears that Sender-ID cannot be approved because of IPR issues, due to the lack of consensus. Of course, if Microsoft were to change their license, the story could change.

Of course, some say they'll just barrel ahead with their corporate cronies:

"Despite the controversy, the ESPC remains hopeful about Sender ID's fate.

"'The broadest adoption possible and the most consistent standards are in the interests of not just senders, not just ISPs, but of consumers,' said Trevor Hughes, executive director of the ESPC.

"Hughes also points out that even if it doesn't become a standard, Sender ID will still be a factor if the major ISPs adopt it.

"'Where we stand is that Sender ID is going to be a reality for large senders,' he said. 'We don't question the sincerity of the folks who are raising concerns over open source compatibility. We just haven't come up with the same concerns.'"

Hmm. Did he just say the ESPC doesn't care about compatibility in a standard? Yes. I believe he did. And the only consumers that will benefit are those with domains, from what I understand. The ESPC is the EMail Service Providers Coalition. You can see by the list of their members -- like DoubleClick and Real 24/7 Media -- that their concerns are marketing-related, and they probably don't much care what anybody else wants. At least, that's been my experience with DoubleClick. It's not saying much that's good about Microsoft that they intend to do what they do exclusively in their email space, if necessary.

Anyway, the biggest-gorilla-in-the-room response might not work , because Microsoft isn't the biggest gorilla here:

"Open source endorsement is essential for widespread, worldwide adoption of Sender ID. Although major e-mail service providers like Microsoft and AOL say they will be incorporating Sender ID as it stands, and many software vendors are already moving forward with implementations of their own. The vast majority of administrators around the world use open source Message Transfer Agents like Sendmail, QMail, Postfix or Exim.

"Yakov Shafranovich, a former co-chair of the Anti-Spam Research Group (ASRG) and one of the more vocal critics of Microsoft's patent claims, was initially receptive to Newton's proposal, which puts the decision of which extension to use in the hands of network administrators.

"'A proposal that allows Sender ID to be used with multiple identities would sidestep that problem by letting end users pick if they want to use PRA and handle the IPR issues themselves,' he said in an e-mail interview. 'Others are free to choose "mailfrom" or any other extensions that will probably be developed. This way the IETF will sidestep IPR issues and can approve the standard.'"

Here is the complete email.

-------- Original Message --------

Subject: consensus call on pra/mailfrom deployment and versioning/scope
Date: Wed, 8 Sep 2004 09:37:18 -0400
From: Andrew Newton
To: IETF MARID WG

It is the opinion of the co-chairs at this time (before the end of last call) that the MARID working group has no consensus regarding the deployment of Sender ID. This lack of consensus centers around the IPR associated with the PRA algorithm. Since predicting deployment is a subjective matter and not strictly a technical concern, we would like to offer the working group a proposal for modifying Sender ID that would take the issue of deployment out of the hands of the IETF and place it in the hands of the ultimate decision-makers, the systems and network administrators of the Internet. We feel that this is where decisions of deployment should really be made.

It is also the opinion of the co-chairs that many in the working group are willing to deploy MAIL FROM checking as specified in draft-mengwong-spf. Therefore, we ask for consideration of the following proposal:

The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne)

version = "spf2." ver-minor "/" ver-scope *( "," ver-scope )
ver-minor = 1*DIGIT
ver-scope = "pra" / "mailfrom" / name
name = alpha *( alpha / digit / "-" / "_" / "." )

And the following stipulations:

1) "mailfrom" checking will be defined in a new draft
2) multiple records are allowed
3) a scope (e.g. "pra") can only appear in one record of one type for validity purposes

The question before the working group: assuming no technical errors with the above, is there anybody who vehemently objects with this proposal?

-andy