Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

Julian,

The IESG will consider your appeal as soon as reasonably
possible.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
IETF Chair

Julian Mehnle wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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.1 (GNU/Linux)
> 
> iD8DBQFDDPiHwL7PKlBZWjsRApnbAKDFRk3VaEiPrXv7ulF2atjbW85w1QCeJUnS
> kj3OjXsjR1KEQiFTUNK0Y1M=
> =x3Lt
> -----END PGP SIGNATURE-----
>