Re: Appeal of the IESG decision to publish draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

Dear Mr. Mehnle,

This is to acknowledge receipt of your message.  The IAB will
review the material and provide you a response.

Best regards,
Leslie,
IAB Chair.

Julian Mehnle wrote:
> -----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 <[email protected]>
> To: Brian Carpenter <[email protected]>
> CC: Ted Hardie <[email protected]>, [email protected],
>     SPF Council <[email protected]>,
>     SPF Discussion <[email protected]>,
>     MARID <[email protected]>, [email protected]
> 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/[email protected]/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/[email protected]/200409/0027.html
> 21. http://archives.listbox.com/[email protected]/200410/0001.html
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> 
> iD8DBQFD6mzYwL7PKlBZWjsRAoH3AJsHvn4nSLE24J18Wf6gQRVfTMuhigCgpsiu
> qLiATbaNBNdhXDTiRkz7cn4=
> =pFJK
> -----END PGP SIGNATURE-----
>