Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02
Brian E Carpenter <brc@zurich.ibm.com> Mon, 29 August 2005 13:04 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9jJ9-0004jS-Nv; Mon, 29 Aug 2005 09:04:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9jJ3-0004ik-BD; Mon, 29 Aug 2005 09:04:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06399; Mon, 29 Aug 2005 09:04:08 -0400 (EDT)
Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9jKM-00077W-UQ; Mon, 29 Aug 2005 09:05:33 -0400
Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j7TD4SFi336270; Mon, 29 Aug 2005 14:04:28 +0100
Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7TD3vOk247720; Mon, 29 Aug 2005 14:03:57 +0100
Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j7TD3vd0029397; Mon, 29 Aug 2005 14:03:57 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j7TD3u0L029386; Mon, 29 Aug 2005 14:03:56 +0100
Received: from zurich.ibm.com (sig-9-145-129-58.de.ibm.com [9.145.129.58]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA63070; Mon, 29 Aug 2005 15:03:55 +0200
Message-ID: <431307B8.70700@zurich.ibm.com>
Date: Mon, 29 Aug 2005 15:03:52 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Julian Mehnle <julian@mehnle.net>
References: <200508250045.27704.julian@mehnle.net>
In-Reply-To: <200508250045.27704.julian@mehnle.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0
Content-Transfer-Encoding: 7bit
Cc: Ted Hardie <hardie@qualcomm.com>, ietf@ietf.org, SPF Council <spf-council@v2.listbox.com>, MARID <ietf-mxcomp@imc.org>, SPF Discussion <spf-discuss@v2.listbox.com>, iesg@ietf.org
Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
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/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://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@v2.listbox.com/200409/0027.html > 21. http://archives.listbox.com/spf-help@v2.listbox.com/200410/0001.html > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFDDPiHwL7PKlBZWjsRApnbAKDFRk3VaEiPrXv7ulF2atjbW85w1QCeJUnS > kj3OjXsjR1KEQiFTUNK0Y1M= > =x3Lt > -----END PGP SIGNATURE----- > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Appeal: Publication of draft-lyon-senderid-core-0… Julian Mehnle
- Re: Appeal: Publication of draft-lyon-senderid-co… Harald Tveit Alvestrand
- Re: Appeal: Publication of draft-lyon-senderid-co… Bill Sommerfeld
- Re: Appeal: Publication of draft-lyon-senderid-co… Ned Freed
- Re: Appeal: Publication of draft-lyon-senderid-co… Bill Sommerfeld
- Re: Appeal: Publication of draft-lyon-senderid-co… Dave Crocker
- Re: Appeal: Publication of draft-lyon-senderid-co… Spencer Dawkins
- Re: Appeal: Publication of draft-lyon-senderid-co… Stephane Bortzmeyer
- Re: Appeal: Publication of draft-lyon-senderid-co… Theodore Ts'o
- Re: Appeal: Publication of draft-lyon-senderid-co… Douglas Otis
- Re: Appeal: Publication of draft-lyon-senderid-co… Julian Mehnle
- Re: Appeal: Publication of draft-lyon-senderid-co… Julian Mehnle
- Re: Appeal: Publication of draft-lyon-senderid-co… Andrew Newton
- Re: Appeal: Publication of draft-lyon-senderid-co… Stephane Bortzmeyer
- Re: Appeal: Publication of draft-lyon-senderid-co… Andrew Newton
- Re: Appeal: Publication of draft-lyon-senderid-co… Andrew Newton
- RE: [spf-discuss] Re: Appeal: Publication of draf… Hallam-Baker, Phillip
- Re: [spf-discuss] Re: Appeal: Publication of draf… Sam Hartman
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Julian Mehnle
- Re: [spf-discuss] Re: Appeal: Publication of draf… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Julian Mehnle
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: [spf-discuss] Re: Appeal: Publication of draf… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- RE: Appeal: Publication of draft-lyon-senderid-co… Thomas Gal
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Bruce Lilly
- Is it necessary to go through Standards Track to … C. M. Heard
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Scott W Brim
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… Douglas Otis
- Re: [spf-discuss] Re: Appeal: Publication of draf… Dotzero
- RE: [spf-discuss] Re: Appeal: Publication of draf… Jeff Macdonald
- Re: [spf-discuss] Re: Appeal: Publication of draf… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… Douglas Otis
- Re: Appeal: Publication of draft-lyon-senderid-co… Brian E Carpenter
- Re: Appeal: Publication of draft-lyon-senderid-co… Brian E Carpenter
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Pekka Savola
- Re: Appeal: Publication of draft-lyon-senderid-co… william(at)elan.net
- Re: Appeal: Publication of draft-lyon-senderid-co… Julian Mehnle
- Re: [spf-discuss] Re: Appeal: Publication of draf… Dick St.Peters
- Re: [spf-discuss] Re: Appeal: Publication of draf… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Julian Mehnle
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… Dick St.Peters
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: [spf-discuss] Re: Appeal: Publication of draf… william(at)elan.net
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… Sam Hartman
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… william(at)elan.net
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Bob Braden
- Re declare SPF and Sender-ID to be Informational John Levine
- Re: Re declare SPF and Sender-ID to be Informatio… Dave Crocker
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Re declare SPF and Sender-ID to be Informatio… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: Re declare SPF and Sender-ID to be Informatio… John Levine
- Re: Re declare SPF and Sender-ID to be Informatio… Brian E Carpenter
- Re: declare SPF and Sender-ID to be Informational Frank Ellermann
- Individual submissions and Informational RFCs wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Sam Hartman
- Re: Individual submissions and Informational RFCs John C Klensin
- Re: Individual submissions and Informational RFCs Harald Tveit Alvestrand
- Re: Individual submissions and Informational RFCs wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Sam Hartman
- Last call IETF experiments (was: Appeal ....) Frank Ellermann
- Re: Last call IETF experiments Frank Ellermann
- Re: Last call IETF experiments (was: Appeal ....) John C Klensin
- Re: Last call IETF experiments Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Douglas Otis
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Keith Moore
- Re: Appeal: Publication of draft-lyon-senderid-co… Douglas Otis
- Re: Appeal: Publication of draft-lyon-senderid-co… william(at)elan.net
- Re: Appeal: Publication of draft-lyon-senderid-co… Douglas Otis
- Re: Appeal: Publication of draft-lyon-senderid-co… william(at)elan.net
- SES or BATV (was: Publication of draft-lyon-sende… Frank Ellermann
- SES vs BATV Douglas Otis
- Re: Last call IETF experiments Sam Hartman
- Re: Publication of draft-lyon-senderid-core-01 in… Douglas Otis
- Re: Last call IETF experiments Frank Ellermann
- Re: Publication of draft-lyon-senderid-core-01 in… Frank Ellermann