Subject: [EAI] New text for SMTPEXT, section 2.5.2

From: John C Klensin <[email-masked]>
Date: Mon, 05 Jun 2006 03:42:17 -0400

Section 2.5.2 of eai-smtpext-00 now reads

> 2.5.2.  Trace Fields
>
> Internationalized domain names in Received fields must be
> transmitted in the punycode form.  Addresses in "for"
> clauses need further examination and might be treated
> differently depending on [IMA- utf8header].  The reasoning
> in the introductory portion of [IMA- overview] strongly
> suggests that these addresses be in UTF-8 form, rather than
> some specialized encoding.

As a consequence of discussion at the interim meeting about 
difficulties associated with having to modify earlier Received 
fields on downgrade, it should read something like...

2.5.2.  Trace Fields

Internationalized domain names in Received fields must be
transmitted in the punycode form.  "For" fields containing
internationalized addresses are prohibited, since subsequent
downgrading would force violating rules in RFC 2821
prohibiting altering existing Received fields.  With these
two restrictions, there should be no need for UTF-8
information in Received fields and such information is
prohibited to preserve the integrity of those fields.
More generally, UTF-8 information of any sort MUST NOT
appear in Received fields, even in comments within those
fields.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 05 Jun 2006 12:56:17 +0100

> appear in Received fields, even in comments within those

I think you shold adopt Chris Newmsn's suggestion that any For field  
containing an internationalized addresse should be written inside a  
comment (For fields are too useful to abandon them entriely).

And I see no harm in UTF-8 inside comments (since the downgrade mechanism  
is clear, and Chris Newman's suggestion requires it).

It might be a kinder to use RFC 2047 inside such comments, but I would not  
make that stronger than a "SHOULD".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Jun 2006 20:08:05 -0400

--On Monday, June 05, 2006 12:56 +0100 Charles Lindsey 
<[email-masked]> wrote:

> I think you shold adopt Chris Newmsn's suggestion that any For
> field  containing an internationalized addresse should be
> written inside a  comment (For fields are too useful to
> abandon them entriely).
>
> And I see no harm in UTF-8 inside comments (since the
> downgrade mechanism  is clear, and Chris Newman's suggestion
> requires it).
>
> It might be a kinder to use RFC 2047 inside such comments, but
> I would not  make that stronger than a "SHOULD".

Charles, there are important historical reasons for not changing 
the rule that MTAs never earlier Received fields.  You may feel 
that UTF-8 in Received comments are so important that the "no 
modifications" principle should be overridden, but it certainly 
is not so obvious as to constitute "no harm".

As far as the utility of "for" fields, my recollection was that 
the topic was discussed during the DRUMS work because of the 
potential security issues if there were more than one recipient 
(and even more so if any of the envelope recipients did not 
appear in the headers).  My memory could be wrong, but I believe 
the decision to retain "for" at all in 2821 (other than as a 
legacy "MAY") was a compromise between those who thought it was 
sometimes useful and those who were concerned about the security 
issues.  If that recollection is even partially correct, I infer 
that there isn't strong community consensus that "for" fields 
are too useful to abandon.

     john

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 06 Jun 2006 11:11:02 +0100

On Tue, 06 Jun 2006 01:08:05 +0100, John C Klensin <[email-masked]> wrote:

> Charles, there are important historical reasons for not changing the  
> rule that MTAs never earlier Received fields.  You may feel that UTF-8  
> in Received comments are so important that the "no modifications"  
> principle should be overridden, but it certainly is not so obvious as to  
> constitute "no harm".

Well I have certainly seen suggestions on this list (Chris Newman IIRC)  
that the principle in question might be relaxed in cases such as this.

But the possibility of requiring, in the smtp document, that any UTF-8 in  
comments within Received headers should be generated in downgraded form  
(i.e. MUST be encoded as per RFC 2047) would cover the situation whilst  
still retaining the 'no changes' rule.
>
> As far as the utility of "for" fields, my recollection was that the  
> topic was discussed during the DRUMS work because of the potential  
> security issues if there were more than one recipient (and even more so  
> if any of the envelope recipients did not appear in the headers).  My  
> memory could be wrong, but I believe the decision to retain "for" at all  
> in 2821 (other than as a legacy "MAY") was a compromise between those  
> who thought it was sometimes useful and those who were concerned about  
> the security issues.  If that recollection is even partially correct, I  
> infer that there isn't strong community consensus that "for" fields are  
> too useful to abandon.

I can only speak for my own experience, which is that I have often found  
"for" fields to be helpful when poking around in Received headers.

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Jun 2006 18:09:13 +0100

On Tue, 6 Jun 2006, Charles Lindsey wrote:
> > security issues if there were more than one recipient (and even more
> > so if any of the envelope recipients did not appear in the headers).
> > My memory could be wrong, but I believe the decision to retain "for"
> > at all in 2821 (other than as a legacy "MAY") was a compromise between
> > those who thought it was sometimes useful and those who were concerned
> > about the security issues.  If that recollection is even partially
> > correct, I infer that there isn't strong community consensus that
> > "for" fields are too useful to abandon.
>

Speaking as a postmaster, I agree, because it's usually more convenient
than digging the same information out of the logs. My servers also record
the return path in a comment in their Received: lines to help with tracing
messages through mailing lists; this is also a popular way of passing the
return path to content scanners.

So I think we need an official way to record utf8 email addresses in
Received: lines, even if the "for" field can only appear some of the time.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL: SOUTH BAILEY SOUTH OR SOUTHWEST 4 OR 5 VEERING NORTH 3 OR 4, THEN
BECOMING VARIABLE. OCCASIONAL RAIN. MODERATE WITH FOG PATCHES.