-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To the Internet Architecture Board, as per the Internet Standards Process, section 6.5, and on behalf of the SPF project, I am hereby appealing the IESG's decision[2] on 2005-12-08 to publish the draft-lyon-senderid-core-01 I-D[3] as an Experimental RFC as-is. I am attaching my initial IESG appeal[1] and will try not to rehash all the arguments contained therein. I will merely point out the larger issues and the negative implications of the IESG's decision here. Please review the IESG appeal and the referenced documents first. The Problem =========== The IESG decision is wrong in two ways: 1. On a technical level, draft-lyon-senderid-core-01[3], by implicitly redefining the semantics of "v=spf1" DNS records, significantly conflicts with draft-schlitt-spf-classic-02[4], on which the former depends, and which has also been approved by the IESG to be published as an Experimental RFC. The IESG has conceded this fact in their response[2] to my appeal, yet they argue that "the IESG did consider this conflict in its original discussions, and that is one of the reasons why we crafted the original IESG note to be included in these documents, which highlights that there are concerns about using these mechanisms in tandem". No such note can sufficiently mitigate the technical conflict. Even though the IESG has only approved the drafts for Experimental status, the experiments they are approving are still in conflict. This conflict bears the potential of disrupting the e-mail operation of domain owners participating in either of the experiments despite their careful consideration of the experiments' rules. The IESG, under- standably, does not want to take sides for political reasons, but difficult political situations should not bar the internet standards process from producing technically sound results. The conflict arose only after the IESG asked for individual draft submissions from the SPF and Sender ID authors and draft-lyon-senderid- core-00 was submitted (which for the first time included the re-inter- pretation of "v=spf1" records for the PRA identity). Accepting such a submission despite the prior consensus of the MARID WG[5] (which was closed afterwards) that "v=spf1" should not be used for checking of PRA clearly violates the ultimate goal of producing reliable standards. 2. On an operational level, SPF has been an ongoing experiment since late 2003. In their response to my appeal, the IESG explained that the SPF and Sender ID drafts "were approved for publication as Experimental RFCs and not approved for the Standards track", and that "the bar is lower for Experimental RFCs". Ted Hardie, the IETF AD responsible for these drafts, explained[6] that "the conflicts between the two [drafts] on this and other points are part of why the IESG is publishing them 'AS IS'". This reasoning disregards the substantial history the "v=spf1" record definition has had outside the IETF since late 2003[7]. The SPF project, which I am representing in this case, believes that the decision to ignore the prior experience with SPFv1 and to lodge draft-schlitt-spf-classic for Experimental instead of Proposed Standard status was unjustified, but has accepted the IESG's decision that additional experience be gathered before standardizing the proposal. However the IESG's decision to equally publish a draft-lyon-senderid- core that, without technical reason, conflicts with the historical use of "v=spf1" records, unnecessarily compromises at least one of the two experiments. Meaningful and reliable experience about the practicability and effectiveness of draft-schlitt-spf-classic cannot be reasonably expected to be collected when at the same time draft-lyon-senderid-core misinterprets the semantics of "v=spf1" records in a significant number of cases. Requiring participants in the SPFv1 experiment to "opt out" from also participating in the Sender ID experiment by publishing an empty "spf2.0" record cannot be considered an acceptable solution either, both based on principle and given the large number of existing "v=spf1" records that were published before Sender ID was conceived[8]. Finally, the IESG's approval of conflicting experiments could be seen as a failure in following the standards process[9], which in section 4.2.1, "Experimental", requires "verification that there has been adequate coordination with the standards process", which would by analogy not only mean coordination with standards track RFCs but also with other experimental RFCs. Both SPFv1 and Sender ID could certainly be used productively in tandem if the redefinition of "v=spf1" records was omitted from the Sender ID specification. Proposed Remedy =============== The relevant part of draft-lyon-senderid-core-01, section 3.4 "Compatibility", could be changed 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. draft-lyon-senderid-core should not be published unless this conflict is resolved. Kind regards, Julian Mehnle. References: 1. http://www.ietf.org/IESG/APPEALS/appeal-draft-lyon-senderid-core.txt 2. http://www.ietf.org/IESG/APPEALS/appeal-response-julian-mehnle.txt 3. http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt 4. http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-02.txt 5. http://www.ietf.org/proceedings/04aug/116.htm#cmr 6. http://article.gmane.org/gmane.mail.spam.spf.council/339 7. http://new.openspf.org/Specifications 8. http://www.imc.org/ietf-mxcomp/mail-archive/msg05105.html 9. http://www.rfc-editor.org/rfc/rfc2026.txt - ---------------- My original appeal to the IESG ---------------- From: Julian Mehnle <julian@xxxxxxxxxx> To: Brian Carpenter <brc@xxxxxxxxxxxxxx> CC: Ted Hardie <hardie@xxxxxxxxxxxx>, iesg@xxxxxxxx, SPF Council <spf-council@xxxxxxxxxxxxxx>, SPF Discussion <spf-discuss@xxxxxxxxxxxxxx>, MARID <ietf-mxcomp@xxxxxxx>, ietf@xxxxxxxx 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 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" <draft-schlitt-spf-classic-02> I-D and the "Sender-ID" <draft- lyon-senderid-core-01, draft-lyon-senderid-pra-01, draft-katz-submitter- 01> 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@xxxxxxxxxxxxxx/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://web.archive.org/web/20041115043332/http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-03.txt 19. http://web.archive.org/web/20041117011615/http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-00.txt 20. http://archives.listbox.com/spf-discuss@xxxxxxxxxxxxxx/200409/0027.html 21. http://archives.listbox.com/spf-help@xxxxxxxxxxxxxx/200410/0001.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD6mzYwL7PKlBZWjsRAoH3AJsHvn4nSLE24J18Wf6gQRVfTMuhigCgpsiu qLiATbaNBNdhXDTiRkz7cn4= =pFJK -----END PGP SIGNATURE----- _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf