William,
We will consider this together with the other appeal.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
IETF Chair
Distinguished Engineer, Internet Standards & Technology, IBM
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@xxxxxxxxxxxxx/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).
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf