[spf-discuss] IAB appeal draft

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

here's a carefully considered draft for the IAB appeal.  Sorry for the 
delay!  Please review it soon!

Julian.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD6hycwL7PKlBZWjsRAsqgAKCXswXq5nDEmyTE9qG/x0C0VHBgEwCg0NSK
cb25jRVSh7t1y03C5Kr9W7M=
=UpLI
-----END PGP SIGNATURE-----
> --- Begin Message ---
> 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 appeal[1] to the IESG 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.
>
> The Problem
> ===========
>
> The IESG decision is wrong in two ways:
>
> 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.  (Please review the IESG appeal[1] for the detailed explanation of the
> technical issue.)  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 as, even though the IESG
> has only approved the drafts for Experimental status, the experiments they
> are approving are still in conflict, which runs the risk of disrupting the
> e-mail operation of participants in at least one of the experiments despite
> their careful consideration of that experiment's rules.  The IESG,
> understandably, 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 Microsoft submitted draft-lyon-senderid-core-00[5]
> (which for the first time included the re-interpretation of "v=spf1"
> records for the PRA identity), and accepting such a submission despite the
> prior MARID WG consensus[6] that "v=spf1" should not be used for checking
> of PRA or other unexpected identities clearly violates the ultimate goal of
> producing reliable standards.
>
> On a practical level, SPF has been an ongoing experiment since late 2003.
> In the IESG's response to my appeal, they 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[7] 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[8].  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 should 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 gathered when at the same
> time draft-lyon-senderid-core redefines the semantics of "v=spf1" records
> for 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.  Nevertheless, 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://web.archive.org/web/20041117011615/http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-00.txt
>  6. http://www.ietf.org/proceedings/04aug/116.htm#cmr
>  7. http://article.gmane.org/gmane.mail.spam.spf.council/339
>  8. http://new.openspf.org/Specifications
>
>
> ---------------- My original appeal to the IESG ----------------
>
> From: Julian Mehnle <julian(_at_)mehnle(_dot_)net>
> To: Brian Carpenter <brc(_at_)zurich(_dot_)ibm(_dot_)com>
> CC: Ted Hardie <hardie(_at_)qualcomm(_dot_)com>, iesg(_at_)ietf(_dot_)org,
>     SPF Council <spf-council(_at_)v2(_dot_)listbox(_dot_)com>,
>     SPF Discussion <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>,
>     MARID <ietf-mxcomp(_at_)imc(_dot_)org>, ietf(_at_)ietf(_dot_)org
> 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(_at_)v2(_dot_)listbox(_dot_)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://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(_at_)v2(_dot_)listbox(_dot_)com/200409/0027.html
> 21. 
> http://archives.listbox.com/spf-help(_at_)v2(_dot_)listbox(_dot_)com/200410/0001.html
>
>
> --- End Message ---