-----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@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.1 (GNU/Linux)
iD8DBQFDDPiHwL7PKlBZWjsRApnbAKDFRk3VaEiPrXv7ulF2atjbW85w1QCeJUnS
kj3OjXsjR1KEQiFTUNK0Y1M=
=x3Lt
-----END PGP SIGNATURE-----
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf