-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wayne Schlitt wrote:
William Leibzon wrote:
Now I note that since Wayne said that SPF Council made a resolution to
go with appealing the decision it is COUNCIL'S responsibility to
follow up on this resolution (and QUICKLY!). That means you either
decide who of the SPF Council members would be making an appeal next
week or you deligate to to somebody else, but you can't just leave it
up in the air as time to will run out very very soon.
The SPF council resolution said that *someone* should prepare an
appeal, not *a council member*.
True. The resolution says:
| Someone should prepare an appeal to the IETF in case we cannot get MS to
| stop re-using v=spf1 records for PRA checking. The appeal shall be
| submitted to the IETF if there are no clear indications that MS is
| willing to open serious discussions about this within 7 days [as of
| 2005-07-19]. Julian will prepare the appeal it if nobody else will.
Julian said he would do it, but Julian has also explained to me on IRC
that he has been very busying doing work that he gets paid for right
now. Unless something changes, I think you should probably not expect
him to have the time to file the appeal.
Not exactly true. Yes, I am busy, but I also said that I would prepare the
appeal if nobody else would. It seems that nobody else has prepared one,
so I went ahead and did it, making use of Frank's write-up (thanks!).
William is right about running out of time. To be quite honest, I
thought time had already run out.
The IESG announced the publication of draft-lyon-senderid-core-01 as an
Experimental RFC on 2005-06-29[1]. That sets the appeal deadline for
Monday, 2005-08-29.
I have attached my draft for the appeal. Please comment on it.
Julian.
References:
1. http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01356.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDCj5XwL7PKlBZWjsRAoq9AJ9+58icxgGPjHZjHiU0E7n3D7ciiQCeON7C
NhOuIEY3aJPFpoHZDWGsCIs=
=Uv3o
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
--- Begin Message ---
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 had outside the IETF. And
even though the IESG intends to run both of these 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[4].
However, this is in direct conflict with draft-schlitt-spf-classic-02[5],
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
negatives, 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.
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.[6,7,8]
It should be noted that at the time of the dissolution of the MARID working
group in September 2004[9], there had been at least 650,000 domains with
"v=spf1" policies published in the com/net/org TLDs alone.[10] It can be
safely assumed that practically all of these policies were published based
on draft-mengwong-spf.02.9.4[6], draft-mengwong-spf-00[7], or draft-
mengwong-spf-01[8], 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 compatibili-
ty 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.
This view seems to have prevailed at the 60th IETF meeting in June 2004,
too, where among other things MARID was discussed[11]:
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[12] the version identifier to "spf2.0" in
draft-ietf-marid-protocol-01 in the aftermath[13,14] of IETF-60, a major
motivation was clearly to avoid the use of "v=spf1" records for checking of
PRA or other unexpected identities.
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.
* MAIL FROM signature schemes such as BATV, SES, SRS, or VERP employ
unique tokens in the MAIL FROM identity, but inherently do not change
the PRA identities. These schemes make deliberate use of the protocol
layer separation in internet mail, i.e. of the fact that the header
identities are conceptually independent from the envelope identities.
* 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 then the PRA identity is usually unpredictable.
Now, the entire point of Sender ID is to add PRA checking over SPF, and the
motivation for Sender ID specifying the applicability of "v=spf1" policies
to PRA checking is to make use of the hundreds of thousands of "v=spf1"
records already out there. There would be nothing wrong with this if there
weren't the issues described above. However, if due to a change in
semantics all publishers have to rethink their policies and possibly
re-publish, then the benefit of re-using the deployed base is lost, at the
additional cost of irritating publishers.
Sender ID and SPF 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 semantical conflict is currently
still a field of research, and 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://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt
4. http://www.ietf.org/internet-drafts/draft-lyon-senderid-pra-01.txt
5. http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-02.txt
6. http://spf.pobox.com/draft-mengwong-spf.02.9.4.txt
7. http://spf.pobox.com/draft-mengwong-spf-00.txt
8. http://spf.pobox.com/draft-mengwong-spf-01.txt
9. http://www.imc.org/ietf-mxcomp/mail-archive/msg05054.html
10. http://www.imc.org/ietf-mxcomp/mail-archive/msg05105.html
11. http://www.ietf.org/proceedings/04aug/116.htm#cmr
12. http://www.imc.org/ietf-mxcomp/mail-archive/msg03282.html
13. http://www.imc.org/ietf-mxcomp/mail-archive/msg03164.html
14. http://www.imc.org/ietf-mxcomp/mail-archive/msg03081.html
--- End Message ---