-----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-----