I also received the answer to my appeal. IESG basicly agrees that use
of Resent fields is not compatible with standards but considers that
is not enough to not publish the draft for EXPERIMENTAL status and
instead chooses to add [yet another] note about it:
"Participants in the Sender-ID experiment need to be aware
that the way Resent-* header fields are used will result in
failure to receive legitimate email when interacting with
standards-compliant systems (specifically automatic forwarders
which comply with the standards by not adding Resent-* headers,
and systems which comply with RFC 822 but have not yet implemented
RFC 2822 Resent-* semantics). It would be inappropriate to advance
Sender-ID on the standards track without resolving this
interoperability problem."
All together this looking to become the longest IESG notes ever
to be added to any drafts by IESG...
---------- Forwarded message ----------
Date: Thu, 08 Dec 2005 11:49:55 +0100
From: Brian E Carpenter <brc(_at_)zurich(_dot_)ibm(_dot_)com>
To: "william(at)elan.net" <william(_at_)elan(_dot_)net>
Subject: Re: Additional appeal against publication of draft-lyon-senderid-* in
regards to its recommended use of Resent- header fields in the way that is
inconsistant with RFC2822
William,
The attached response is on its way through the formal channel.
This ends the IESG appeal process.
Sorry this took so long.
Brian
william(at)elan.net wrote:
Hello Brian,
With IESG already considering other issues with publication of
draft-lyon-senderid-core as experimental RFC, I'd like to request it
also formerly consider and make determination in regards to issues
raised at the very end of MARID regarding use of Resent- header fields
by draft-lyon-senderid-core and draft-lyon-senderid-pra which appears
to be in violation of the RFC2822 intended use of those fields.
The more fundamental problem in regards to this issue and the issue
raised by Julian Mehnle is that it appears that so-called SenderID
experiment is not limited to only those who wish to participate it,
but has effects on other internet users, in particular those who want
to use only SPF (Classic SPF) as well as those who interpret and use Resent-
fields (they can not be certain when looking at received email
if fields had been added by user action at MUA in according with RFC2822 or
in automated manner by forwarding entity as required by senderid)
and this problem must be addressed before such publication is approved
by IESG as official IETF experiment.
The details of the appeal listed below are largely copy of my previous
message to IESG on this subject, those interested can also see:
http://www.imc.org/ietf-mxcomp/mail-archive/msg04713.html
http://www.imc.org/ietf-822/mail-archive/msg05670.html
http://www.imc.org/ietf-mxcomp/mail-archive/msg05774.html
Details of the objection in regards to RFC2822 specified Resent fields:
1. Recommendations for forwarders incompatible with RFC2822
Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt
| 7.2 E-Mail Forwarders
|
| In order to pass the PRA variant of the test, a program that forwards
| received mail to other addresses MUST add an appropriate header that
| contains an e-mail address that it is authorized to use. Such
| programs SHOULD use the Resent-From header for this purpose.
The above is is incompatible with the section 3.6.6 of RFC2822:
Ref: http://www.ietf.org/rfc/rfc2822.txt
| Note: Reintroducing a message into the transport system and using
| resent fields is a different operation from "forwarding".
| "Forwarding" has two meanings: One sense of forwarding is that a mail
| reading program can be told by a user to forward a copy of a message
| to another person, making the forwarded message the body of the new
| message. A forwarded message in this sense does not appear to have
| come from the original sender, but is an entirely new message from
| the forwarder of the message. On the other hand, forwarding is also
| used to mean when a mail transport program gets a message and
| forwards it on to a different destination for final delivery. Resent
| header fields are not intended for use with either type of
| forwarding.
This objection was discussed at MARID [1] and was found to be valid based on
the answer by Pete Resnick [2] and in subsequent discussion in jabber
conference [3].
Note: Same objection applies to section 7.3 of senderid-core document
which requires use of Resent- fields by mail lists
References:
[1] http://www.imc.org/ietf-mxcomp/mail-archive/msg04713.html
[2] http://www.imc.org/ietf-mxcomp/mail-archive/msg04972.html
[3]
http://www.xmpp.org/ietf-logs/marid(_at_)ietf(_dot_)xmpp(_dot_)org/2004-09-20.html
2. Use Resent-* headers for automatic action, which is incompatible
with RFC2822
Ref: http://www.ietf.org/rfc/rfc2822.txt (section 3.6.6):
| Resent fields are
| strictly informational. They MUST NOT be used in the normal
| processing of replies or other such automatic actions on messages.
I take "automatic action" to include rejection and bouncing of messages and
draft-lyon-senderid-core-01 recommends when PRA address derived from Resent-
header is not authorized based on corresponding SPF record check, then
message is to be rejected by mail system in automated manner.
3. PRA algorithm fails when message is RFC822 compliant,
but not RFC2822 compliant
Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-pra-01.txt
| Where messages conform to RFC822 rather than RFC2822, it is possible
| for the algorithm to give unexpected results. An RFC822 message
| should not normally contain more than one set of resent headers;
| however the placement of those headers is not specified, nor are they
| required to be contiguous. It is hence possible that the Resent-From
| header will be selected even though a Resent-Sender header is present.
| Such cases are expected to be rare or non-existent in practice
The problem is acknowledged in the draft, however I disagree that it
should be ignored quite so easily because RFC822 is still listed as
Internet Standard where as RFC2822 is just Proposed Standard.
4. Resent-From can not be used without Resent-Date
Ref: http://www.ietf.org/rfc/rfc2822.txt (section 3.6.6):
| When resent fields are used, the "Resent-From:" and "Resent-Date:"
| fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent.
| Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
| identical to "Resent-From:".
While not specifically mentioned, I believe draft-lyon-senderid-core
document implies that only Resent-From is to be added by those forwarding
systems that participate in the experiment (this is difficult to confirm
because so far I've not found ANY forwarding system that is actually adding
Resent- as per senderid-core draft).
-------
Sender Policy Framework: http://www.openspf.org/
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_)comThe IESG has reviewed William Leibzon's appeal against the
approval of draft-lyon-senderid-core-01 (see
http://www.ietf.org/IESG/APPEALS/appeal2-draft-lyon-senderid.txt
for the full text of the appeal).
Firstly we recall that the Sender ID drafts, and the SPF draft,
were approved for publication as Experimental RFCs and not approved
for the Standards track. The bar is lower for Experimental RFCs.
To avoid confusion, we repeat here the text of the IESG Note
to be included in each of the resulting RFCs:
"The following documents (draft-schlitt-spf-classic, draft-katz-submitter,
draft-lyon-senderid-core, draft-lyon-senderid-pra) are published
simultaneously as Experimental RFCs, although there is no general technical
consensus and efforts to reconcile the two approaches have failed. As such
these documents have not received full IETF review and are published "AS-IS"
to document the different approaches as they were considered in the MARID
working group.
"The IESG takes no position about which approach is to be preferred and
cautions the reader that there are serious open issues for each approach and
concerns about using them in tandem. The IESG believes that documenting the
different approaches does less harm than not documenting them.
"The community is invited to observe the success or failure of the two
approaches during the two years following publication, in order that a
community consensus can be reached in the future."
We have reviewed the content of the appeal and subsequent
email discussion. The appeal asserts that Sender-ID makes
non-standard use of Resent- headers in a way that may affect
their interpretation by both participants and non-participants in
the Sender-ID experiment. The appeal requests the IESG to
address this, without suggesting a specific remedy.
After receiving expert advice from Chris Newman, the IESG has
decided it is sufficient to add the following text to the IESG
Note to be added to the four documents listed above:
"Participants in the Sender-ID experiment need to be aware
that the way Resent-* header fields are used will result in
failure to receive legitimate email when interacting with
standards-compliant systems (specifically automatic forwarders
which comply with the standards by not adding Resent-* headers,
and systems which comply with RFC 822 but have not yet implemented
RFC 2822 Resent-* semantics). It would be inappropriate to advance
Sender-ID on the standards track without resolving this
interoperability problem."
We thank William Leibzon for bringing this issue to our attention, and we hope
that the augmented IESG note will address his concerns.
-------
Sender Policy Framework: http://www.openspf.org/
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