Subject: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Thu, 25 Aug 2005 00:45:26 +0200 From: Julian Mehnle To: Brian Carpenter CC: Ted Hardie , iesg@ietf.org, SPF Council , SPF Discussion , MARID , ietf@ietf.org IESG Chair Brian Carpenter, as per the Internet Standards Process, section 6.5, and on behalf of the SPF project, I am filing a formal appeal on the IESG's approval on 2005-06-29[1] to publish the draft-lyon-senderid-core-01 I-D[3] as an Experimental RFC as-is. I believe that draft-lyon-senderid-core-01 conflicts in a significant aspect with draft-schlitt-spf-classic-02, on which the former depends, and which has also been approved by the IESG to be published as an Experimental RFC.[2] The conflicting part of the Sender-ID specification disrespects the substantial history the SPF specification has outside the IETF. Through its decision, the IESG also ignores SPF's deployed base.[3] And even if the IESG intends to run both of the specifications as an experiment before deciding any further on how to proceed with them, the publication of conflicting specifications is bound to disrupt these experiments. Please find the full appeal included below. Regards, Julian Mehnle. The Problem =========== draft-lyon-senderid-core-01, section 3.4 "Compatibility", says: [...] Sender ID implementations SHOULD interpret the version prefix "v=spf1" as equivalent to "spf2.0/mfrom,pra", provided no record starting with "spf2.0" exists. This means that the I-D recommends that "v=spf1" records be used for checking the PRA identity defined in draft-lyon-senderid-pra-01[5]. However, this is in direct conflict with draft-schlitt-spf-classic-02[6], section 2.4 "Checking Authorization", which says: [...] At least the "MAIL FROM" identity MUST be checked, but it is RECOMMENDED that the "HELO" identity also be checked beforehand. Without explicit approval of the domain owner, checking other identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results. [...] "v=spf1" records have always been published by domain owners with only the MAIL FROM and HELO identities in mind. Checking them against other identities will most likely not only produce non-trivial amounts of false results, but also distort the results of any intended experiments. Proposed Remedy =============== Change the relevant part of draft-lyon-senderid-core-01, section 3.4 "Compatibility", to read: Sender ID implementations MUST interpret the version prefix "v=spf1" as equivalent to "spf2.0/mfrom", provided no record starting with "spf2.0" exists. In any case, draft-lyon-senderid-core should not be published until this conflict is resolved. Justification ============= On 2005-06-29, the IESG announced the decision to publish both the "SPF, version 1" I-D and the "Sender-ID" I-Ds as Experimental RFCs. The re-interpretation of SPFv1's "v=spf1" records by draft-lyon-senderid- core-01 to be equivalent to "spf2.0/mfrom,pra", and thus to be applicable for checking against the PRA identity defined in draft-lyon-senderid- pra-01, conflicts with the substantial history of SPF outside the IETF standards process. Ever since late 2003, SPF has been defined to apply only to the MAIL FROM and HELO identities.[7,8,9] It should be noted that at the time of the dissolution of the MARID working group in September 2004[10], there had been at least 650,000 domains with "v=spf1" policies published in the com/net/org TLDs alone.[11] It can be safely assumed that the vast majority of these policies was published based on draft-mengwong-spf.02.9.4[7], draft-mengwong-spf-00[8], or draft- mengwong-spf-01[9], and thus with only the MAIL FROM and HELO identities in mind. Even though the SPF specification has undergone quite some changes since late 2003, the focus has always been on maintaining backwards compatibility and protecting the meaning of existing sender policies. The different interpretation by the Sender ID specification however has significant implications of which many domain owners were not, and could not be, aware when they defined and published their "v=spf1" policies. The PRA and MAIL FROM / HELO identities are not generally interchangeable, and as a matter of fact there are prominent cases where they differ from each other: * Many mailing lists rewrite the MAIL FROM identity when distributing messages, but do not change the header (PRA) identities. And they are not required to do so by RFCs 2821 or 1123 or any other current IETF standards. * Many organizations with their own domains outsource their bulk message sending (newsletters, etc.) to ESPs, who use their own domain in the MAIL FROM identity and the organization's domain in the From: header, but do not add a Sender: header.[12] * If the MAIL FROM is empty ("MAIL FROM:<>"), the MAIL FROM identity, as defined by the SPF specification, falls back to HELO identity[5, section 2.2], while the PRA identity is usually unpredictable. The bottom line of all these cases is that even though it might be desirable in the long run to enforce congruence between the envelope and header identities, this is still far from reality. And the often atypical but otherwise perfectly standards compliant configurations in which "v=spf1" records have been deployed over the past 1.5 years should not be ignored just because the IESG chooses[13,1,2] to see SPF as a simple offshoot of the failed standardization attempt in the MARID working group. This view seems to have prevailed at the 60th IETF meeting in June 2004, too, where among other things MARID was discussed[14]: 3) draft-ietf-marid-protocol-00 [...] The room discussed the version identifier in the TXT record. Mark introduced the subject by explaining that most people today publish "v=SPF1" with the intention that receivers will be checking MAIL FROM and not PRA. Many participants expressed concern over the semantic meaning and suggested the version number would change. Marshall asked if anybody in the room had any serious objections to changing the version identifier; none were given. Andy directed Mark to send suggestions for the new version identifier to the list where this would be discussed. So when Mark Lentczner changed[15] the version identifier to "spf2.0" in draft-ietf-marid-protocol-01 in the aftermath[16,17] of IETF-60, there was clearly a consensus to avoid the use of "v=spf1" records for checking of PRA or other unexpected identities. It is also worth noting that at the time the MARID WG was closed, the then-current Sender ID specification draft-ietf-marid-protocol-03[18] did not include the re-use of "v=spf1" records for PRA checking. This was only introduced in the individual submission draft-lyon-senderid-core-00 [19] in October 2004. Also did Microsoft's record generation wizards generate only "v=spf2.0/pra" records until the end of October[20,21], when they began generating only "v=spf1" records. SPF and Sender ID are potentially complementary but generally separate. Not only should domain owners, who are the primary target audience of all domain-based sender authentication schemes, have a choice in which experiments they participate and in which they don't, but also should they be able to feel confident that the experiments in which they participate will not unnecessarily be tampered with. In any case, the practical impact of the semantic conflict is currently still a field of research, and even if the IETF intends to publish the Sender ID and SPF specifications as Experimental RFCs in order to gain more experience and reach community consensus in the future[1,2], then setting up conflicting experiments is certainly going to prove counter-productive. References: 1. http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01356.html 2. http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01357.html 3. http://article.gmane.org/gmane.mail.spam.spf.council/340 4. http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt 5. http://www.ietf.org/internet-drafts/draft-lyon-senderid-pra-01.txt 6. http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-02.txt 7. http://spf.pobox.com/draft-mengwong-spf.02.9.4.txt 8. http://spf.pobox.com/draft-mengwong-spf-00.txt 9. http://spf.pobox.com/draft-mengwong-spf-01.txt 10. http://www.imc.org/ietf-mxcomp/mail-archive/msg05054.html 11. http://www.imc.org/ietf-mxcomp/mail-archive/msg05105.html 12. http://archives.listbox.com/spf-discuss@v2.listbox.com/200408/0122.html 13. http://article.gmane.org/gmane.mail.spam.spf.council/339 14. http://www.ietf.org/proceedings/04aug/116.htm#cmr 15. http://www.imc.org/ietf-mxcomp/mail-archive/msg03282.html 16. http://www.imc.org/ietf-mxcomp/mail-archive/msg03164.html 17. http://www.imc.org/ietf-mxcomp/mail-archive/msg03081.html 18. http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-03.txt 19. http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-00.txt 20. http://archives.listbox.com/spf-discuss@v2.listbox.com/200409/0027.html 21. http://archives.listbox.com/spf-help@v2.listbox.com/200410/0001.html