Subject: Re: [EAI] Re: for8

From: Randall Gellens <[email-masked]>
Date: Fri, 2 Feb 2007 00:40:11 -0800

At 9:27 PM -0800 1/25/07, Chris Newman wrote:

>  John C Klensin wrote on 1/22/07 20:07 -0500:
>>  (i) It might be better to just drop "for" clauses that contain
>>  non-ASCII material rather than figure out some creative way to
>>  encode them.... possibly replacing them with a comment whose
>>  semantics are closer to "non-ASCII for clause dropped on
>>  downgrading" than to an attempted encoding of the prior address.
>>
>>  (ii) we might want to require the MTA that does the downgrading
>>  to insert a very specific trace header that explains the damage
>>  it did.  Any comments that contain encodings of prior addresses
>>  should probably be on that trace header, not retrofitted into
>>  headers that did not contain information in that form.
>
>  The robustness gained by never altering Received headers greatly 
> exceeds the value of the "for" clause (for is a convenience -- the 
> relevant MTA logs are the only place where the canonical data can 
> be found).

To an MTA administrator, perhaps so.  To end users, especially those 
debugging scripts, the "for" clause can be very helpful, since such 
people usually don't have access to the server logs.

>   However, regardless of what the specification says, we can't 
> usefully stop email originators from putting a UTF-8 address in the 
> "for" clause of Received.  A robust MTA has to deal with that case 
> anyway.  So I'd say three things about this issue:
>
>  1. SHOULD NOT generate for clause with UTF-8 address: forcing 
> systems to alter
>     received headers is bad

Yes, it is bad.  But it is also temporary: we're planning for a world 
where UTF8SMTP has seen wide deployment and downgrades are rare.  In 
such a world, "for" clauses can continue to be very useful.

>  2. MUST remove a Received for clause with a UTF-8 address on 
> downgrade: to avoid
>     breaking systems further down the line

Yes, I agree.

>  3. MUST NOT include an encoded version of the UTF-8 address in the
>     existing Received header but MAY include it in a Downgraded-details trace
>     field to minimize risk of damage to Received headers.

Yes, I agree.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Eggheads unite!  You have nothing to lose but your yolks.
        --Adlai Stevenson

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 05 Feb 2007 19:01:49 -0000

On Mon, 22 Jan 2007 20:41:36 -0000, Randall Gellens <[email-masked]>  
wrote:

> It seems we have two unpleasant choices:
>
> 1: Prohibit "for" clauses when the address is non-ASCII.
> 2: Alter trace headers when downgrading.
>
> The basic direction of the group, as I understand it, assumes that mail  
> systems will fairly rapidly be upgraded to handle UTF8, and tries to  
> avoid creating short-term kludges which will inevitably live on long  
> after everyone has upgraded.
>
> We may be better off with choice 2.  Choice 1 means that as systems are  
> upgraded, "for" clauses vanish.  I've found these clauses to be very  
> helpful when debugging things.

+1

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   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: Kari Hurtta <[email-masked]>
Date: 06 Feb 2007 20:36:54 +0200

"Charles Lindsey" <[email-masked]> writes in gmane.ietf.ima:

> On Mon, 22 Jan 2007 20:41:36 -0000, Randall Gellens
> <[email-masked]>  wrote:
> 
> > The basic direction of the group, as I understand it, assumes that
> > mail  systems will fairly rapidly be upgraded to handle UTF8, and
> > tries to  avoid creating short-term kludges which will inevitably
> > live on long  after everyone has upgraded.
> >
> > We may be better off with choice 2.  Choice 1 means that as systems
> > are  upgraded, "for" clauses vanish.  I've found these clauses to be
> > very  helpful when debugging things.
> 
> +1
 
I assume that Downgraded: -header field is not trace header.

If trace headers is modified, is there also need for correspond
downgraded header filed?  

That makes Trace-Downgraded: -header field.

Also for MIME structure there is need to downgraded header field.
Because only Content-* is supported on MIME structure, is there
need correspond downgraded header filed?  

That makes Content-Hdr-Downgraded: -header field.

/ Kari Hurtta

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 Feb 2007 14:39:25 -0500

--On Tuesday, 06 February, 2007 20:36 +0200 Kari Hurtta
<[email-masked]> wrote:

>> > We may be better off with choice 2.  Choice 1 means that as
>> > systems are  upgraded, "for" clauses vanish.  I've found
>> > these clauses to be very  helpful when debugging things.
>> 
>> +1
>  

One could do it that way, but it really adds a lot of clutter
with little payoff.  I would think that we would do something
closer to what has been preferred for gateways.  In other words,
the downgrading machine inserts one or more standard Received
fields that contain the relevant information.  For example, one
might have

Received: from mumble.xyz by mumble.xyz with esmtp
    id 1HED2M-000I6F-JH for alt-address@alt-domain;
    Mon, 31 Feb 2008 18:14:35 -0200
    (downgraded from utf8address, previous 'for' clauses 
     deleted)
Received: from foo.bar.baz by mumble.xyz with UTF8SMTP
   id 1HED2M-000I6F-JH; Mon, 31 Feb 2008 18:14:15 -0200

I don't think there is an problem figuring out what happened
there.  And there is zero new syntax to deal with, pin down, and
worry about.

Design suggestion (personal opinion):  every new header and new
variation on a header, has costs and introduces more risks of
interoperability problems and general bad behavior.   If we need
new headers, let's design them carefully and do it.  But "new
header" should be the last resort, not the default answer to
almost any question.  That principle is particularly important
when downgrading is involved because we need to understand that,
regardless of whether we get information through a new header or
field as documentation for the receiving user, the chances are
high that a legacy MUA or MTA that knows nothing about our
extensions will, at best, ignore and possibly delete or trash
precisely the headers we are trying to invent to help people out.

     john

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 07 Feb 2007 12:06:26 -0000

> I assume that Downgraded: -header field is not trace header.

It was not planned as such, and newly invented trace headers are unlikely  
to be widely recognized for years to come (DKIM have tried it, but with  
not much expectation that it will work). The Downgraded header is provided  
primarly so that the opriginal header is preserved and can even be  
restored if/when the message is upgraded. It is also available for tracing  
purposes by those who can be bothered to look for it. But it is not the  
end of the world even if it gets thrown away by some over-zealous  
intermediate agent.

But I like John's suggestion that downgraders should be encouraged to  
record the fact within a Received header (and the Downgrade draft should  
recommend this). But the Downgraded headers will still be needed for their  
original purpose.

> need correspond downgraded header filed?

I doubt that many existing agents actually worry if they see a  
non-Content-* header in these positions, and as I already said, it is not  
the end of the world if one of these occasionally gets lost.

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Feb 2007 08:10:49 -0500

--On Wednesday, 07 February, 2007 12:06 +0000 Charles Lindsey
<[email-masked]> wrote:

>...
> But I like John's suggestion that downgraders should be
> encouraged to record the fact within a Received header (and
> the Downgrade draft should recommend this). But the Downgraded
> headers will still be needed for their original purpose.

To be sure we are clear about the suggestion, the Downgraded
headers are either needed or they are not (no comment in this
note).  The Received header change is built upon another
principle, which is that systems that change messages in transit
should record that fact.

The two suggestions are largely independent of each other.

    john