Subject: 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

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 29 Aug 2005 08:28:52 -0700 (PDT)

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-masked]/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).

-- 
William Leibzon
Elan Networks
[email-masked]

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 29 Aug 2005 20:06:40 +0200

william(at)elan.net wrote:

[...]
>   http://www.imc.org/ietf-mxcomp/mail-archive/msg05774.html

Yes, that was a very good article.

> incompatible with RFC2822

I'm still a bit lost how this could actually _break_ something.
For obvious reasons the author can't say "updates 2822", how
should he fix it ?  As you said the 822 issue is mentioned in
the senderid-pra draft.

Do you want more "security considerations", something along
the line of "PRA-participants agree to break an explicit MUST
in 2822" ?

> 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.

Touché.  OTOH the author isn't responsible for this "detail" -
in the spirit of TINW (for an IETF-we) it's "our" fault.  Bye.

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 29 Aug 2005 13:55:51 -0700 (PDT)

> the line of "PRA-participants agree to break an explicit MUST

Its not that easy because participants are not the only ones who
see messages from such forwarders (if they ever come into existence)
and so as I mentioned the draft actions are not limited to those who
agree to participate in the experiment (but at least and unlike 
re-purposing of v=spf1 records this action would not cause failures
as you correctly note).

And since this actually breaks standard, this would seem to require
explicit action and consent from IESG with understanding about it
and update to RFC2822 with consensus and last call if properly done
(and there has not been even an attempt by draft authors to ask for
review at ietf-smtp or ietf-822 and do last-call like SPF draft 
author has done voluntarily). I guess its also fundamental question
on how seriously does IETF really protect its own standards and 
follows its own procedures on how they are to be changed.

As far as fixing it there are two ways to go about it (and you're
correct that I should have mentioned considering its an appeal and
there I have to say, not only what I believe is wrong but how it
can be fixed):

1. As I already mentioned, IETF can do separate draft that updates
RFC2822 and illuminates ambiguities allowing for reuse of Resent-
header fields by forwarders. This new draft (and only that draft)
would have to go to standard track as proposed standard with appropriate 
review and last call same as RFC2822.

2. Without changing standard, SID for its experiment (and since
none of the systems adding Resent are adding it the way they want
right now anyway, so no changes to running systems) can just create
new header field and use that - this possibility has been mentioned
at MARID btw.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Aug 2005 11:12:12 +0200

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:
> 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].
> 
> Resent- header is not authorized based on corresponding SPF record 
> check, then message is to be rejected by mail system in automated manner.
> 
> 
> 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).
>

---

From: Tony Finch <[email-masked]>
Date: Wed, 31 Aug 2005 18:37:16 +0100

> should he fix it ?  As you said the 822 issue is mentioned in

Regarding RFC 822, the S-ID draft doesn't mention the fact that a large
proportion of software which does something useful with Resent- headers
still implements the 822 syntax, not the 2822 syntax.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.