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,

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/[email protected]/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).
>