|
See the list of signatories for the SPF Community Position.
|
|
The developers and users of the Sender Policy Framework ("SPF") welcome proposals that will truly help clean up the current problems with email forgery.
Email on the Internet has used primarily freely available software and open standards since the late 1970's and, even today, the vast majority of all mail servers run Free or "Open Source" software.
Many SPF developers and users consider that Microsoft's SenderID proposal is technically unsound and undermines the progress already begun by SPF. SPF development and deployment predate Microsoft's entry into the field and have achieved significant success to date. SenderID, in its most recent form, appears likely to interfere with the correct function and deployment of SPF.
Microsoft's patent license for SenderID does include royalty-free terms, but other terms of the license makes it difficult or impossible for many of these widely used mail servers to incorporate SenderID.
If SenderID were widely deployed, the license issue would create a barrier to open development of Internet infrastructure software that has not previously existed. SPF on the other hand has been made freely available to all, including Microsoft, with no restrictions whatsoever.
|
|
Using SenderID _REQUIRES_ SPF
SPF is an independent "domain based" authentication protocol and is the direct result of efforts exerted by an open group of independent developers. Sender-ID requires SPF in order to be implemented. Sender-ID is a superset, or a higher level protocol which attempts to address the "forwarding problem" where responsible domains no longer have an association with the sender IP address thus causing a potential for false positives.
Sender-ID shares scope with another superset or higher level protocol designed to solve the exact same problem, namely SRS (Sender Rewriting Scheme). SRS it should be noted is free of IPR claims and has been available since February of 2004. |
|
Microsoft's patent license for SenderID is incompatible with far too large a percentage of deployed MTAs for it to become a standard (de-jure or de-facto). Proof of this can be found by the public statements by The Apache Software Foundation and the Debian GNU/Linux Project.
|
|
"PRA" (Purported Responsible Address) as it is implemented within SenderID, has many technical problems that make it unsuitable for use in the real world. Whilst this technical aspect was not the sole contributor to the demise of the MARID working group it played a key role in acting as a major stumbling block for many. |
|
The PRA algorithm used in SenderID will not protect the From: header when phishing is going on. Phishers will certainly adapt to making the Resent-Sender: header pass PRA checks. When that happens, From:, Sender: and Resent-From: headers are left unverified by PRA and can still be forged. So, the PRA only protects From: when there is no need to protect it and fails to protect it when needed. (Note: "SPF Classic" has essentially the same weakness against phishing, but makes no claim that it provides superior phishing protection.) |
|
PRA gives incorrect results (false positives) on all the same things that SPF does, but also fails on mailing lists, moderated newsgroups, most MSAs enforcing submission rights (RFC 2476) without adding a corresponding "Sender:" header, and other MTAs adding incorrect "Sender:" headers. |
|
SenderID re-purposes the v=spf1 records. This will cause failures in cases where deployed SPF records currently work. In some cases, those failures can be fixed by changing records, in others (e.g. SES exists:), they can't. Where SenderID breaks the function of existing v=spf1 records, domain owners will only learn of it when legitimate mail is not delivered. SPF record publishers made their records public with the expectation that they would be used with the SPF algorithm. SenderID puts those records to a different, possibly incompatible use, without any consent from the publishers. |
|
PRA has had very limited deployment and testing, making it far riskier than "SPF Classic", which has been in testing in every major MTA (qmail, Sendmail, Postfix, Courier, Exim, and yes, even Exchange) since the beginning of this year.
From what information is available, the general consensus is that, since mail coming from mailing lists is far more common than mail coming from forwarders, this means that the PRA will have an error rate of at least 10 and maybe up to 1000 times as high as "SPF Classic". |
|
PRA requires a use of the Resent-* headers that many people believe is inconsistent with the use defined in RFC2822. Almost(?) no one currently uses these headers for either mailing lists or forwarding.
It appears that the only reason the Resent-* headers are used instead of a new PRA-specific header is that, if a new header were to be used, it would render obvious the fact that this is a significant change to the current email environment. |
|
|