CircleID

While several news stories are reporting that Sender-ID has been killed, that is not entirely true. While Sender-ID in its current form is dead because of Purported Responsible Address (PRA), the compromise version with MAILFROM and PRA scopes is not. Also, the co-chairs want to stay away from any other alternative algorithms that do RFC2822 checking because of possible Intellectual Property Rights (IPR) claims by Microsoft on that as well.

Andrew Newton, one of two co-chairs of the working group, wrote in an email today to the group's discussion forum:

"Due to the fact that we released statements in two separate messages, there seems to be some confusion on how we intend this working group to proceed on Sender ID.

First, the PRA document is not being dropped. Instead, we are proceeding with a document set that includes a non-encumbered (as far as we know) scope, "mailfrom", in addition to the "pra" scope. As we stated before, the objection to PRA is based on questions of deployment caused by incompatibilities with open source licenses. However, there were also a significant number for responses from participants stating that they had no such deployment issues.

Second, it does not make sense to discuss alternatives to PRA if those alternatives may be reasonably inferred to be covered by the patent application (though not necessarily the license) since this working group does not wish to discount Microsoft's patent application. And since we do not know the specific claims of the patent application, construction of such an alternative would need to take into account a few things we do know:

1. The patent application covers at least -core and -pra in combination. There is no reason to think that Microsoft's application is limited to the technology in these two drafts.

2. It does not cover MAIL FROM because this question has been specifically asked of Microsoft.

3. The algorithm in -pra has changed through multiple revisions of the draft(s). This would seem to at least exclude any scopes that use 2822 headers to identify the party most recently responsible for injecting the message.

We hope to have a schedule as soon as possible."

For a good explanation of the IPR issue, read Andrew Newton's follow up posts below:

http://article.gmane.org/gmane.ietf.mxcomp/4945
http://article.gmane.org/gmane.ietf.mxcomp/4946

By Yakov Shafranovich, Software Architect & Consultant. Visit the blog maintained by Yakov Shafranovich here.

Related topics: Email, Spam