Subject: Re: [EAI] downgrading and Received header changing

From: [email-masked]
Date: Mon, 08 May 2006 17:12:10 +0900 (JST)

Dear John,

> From: John C Klensin <[email-masked]>
> Fujiwara-san,
> 
> If the interim meeting comes together, I hope we can work 
> through these cases with a whiteboard.

I'm planning to participate.

> My own -- tentative -- position is that breaking section 4.4 of 
> 2821 would be a very bad idea, at least if there are 
> alternatives.  That is one of the rules that was established 
> after long, bad, experience and I'd be hesitant to abandon it.

Agree.

for example, removing received header (and save it to another place)
may break mail loop detection. rewriting "for" clause may be one
of possible solutions.

> I see at least two alternatives you didn't list.  I'm not 
> proposing either, but we should know they are alternatives. One 
> is simply to not use "for" when the address is non-ASCII.  As I 
> mentioned in my note to Charles, because of the security issues, 
> its value may be somewhat overrated.   The other possibility is 
> to decide that, if an i18n "for" is present, the downgrading 
> system must go into full conversion-gateway mode, encapsulating 
> the old message (trace headers and all) and putting _only_ the 
> gateway headers in the outbound message.

full conversion-gateway mode may be MIME encapsulation downgrading
method, I think.

--
Kazunori Fujiwara, JPRS

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 08 May 2006 03:34:14 -0400

Fujiwara-san,

     john

--On Monday, May 08, 2006 15:01 +0900 [email-masked] wrote:

> I'm afraid that downgrading changes Received header.
>
> There are three possible header downgrading idea.
>
> draft-yoneya-ima-downgrade-01.txt describes 1 and 3.
>
> idea 1. Header by header conversion
>
>   Rewrite all headers to be US-ASCII.
>
>     Received: from ... by ... for <IMA>
>       -> Received: from ... by ... for <__RFC2047__(IMA)>
>
> idea 2. Header encapsulation
>
>   define new encapsulated header and replace original header
> with   encapsulated header.
>
>     Received: from ... by ... for IMA
>       -> IMA-Encapsulated: Received: encapsulate(from ... by
> ... for IMA)       or
>       -> IMA-Encapsulated: Received: from ... by ... for
> encapsulate(IMA)
>
> idea 3. MIME encapsulation
>
>   generate new MIME part Message/EAI.
>   Received field is preserved in MIME part.
>
> RFC 2821 Section 4.4 Trace Information says:
>     An Internet mail program MUST NOT change a Received: line
> that was     previously added to the message header.
>
> idea 1:
>
>      Received header's for clause is modified to be equivalent
>      US-ASCII form, other clauses are visible, Received header
> line      number is preserved.
>
> idea 2:
>
>      Received header information is preserved, Received header
> line      number is initialized to be zero in downgraded
> header.
>
> idea 3:
>
>      Received header information is preserved, Received header
> line      number is initialized to be zero in downgraded
> (outer) header.
>
> All three may break RFC 2821 Section 4.4.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 08 May 2006 12:38:30 +0200

[email-masked] wrote:

>>   The other possibility is 
I am still doubtful that a MIME-encapsulated downgrade message will have 
an acceptable value when it is delivered to an ASCII-only recipient. I'd 
be hesitant to require encapsulation because of Received: headers.

So far, there has been no response to the call for a scenario where the 
encapsulation is useful/needed for inclusion in the scenarios document. 
Until that arrives, I can't conclude that the WG has consensus it's needed.

                     Harald

---

From: [email-masked]
Date: Tue, 09 May 2006 15:08:36 +0900 (JST)

> From: Harald Alvestrand <[email-masked]>

Received header problem exists on both header conversion method and
MIME encapsulation method. (problem seriousness is different depending
on the methods.)

We need to compare downgrading methods on requirements, advantages and
disadvantages, permited or not on the previours standards.

> Until that arrives, I can't conclude that the WG has consensus it's needed.

I try to write 'downgrading' scenario with two downgrading methods,
and write implementation idea/memo/requirements for each entity.

--
Kazunori Fujiwara, JPRS

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 09 May 2006 17:55:03 +0100

> MIME encapsulation method. (problem seriousness is different depending

But in either event is it some human reader who is going to have to  
disentangle it. So for a human, seeing something like

    Downngraded: Received .....

where otherwise he would have expected Received:, should not be too  
difficult to decipher (especially if his MUA has kindly translated any  
RF2047 encoded-words inside it).

OTOH, ordinary readers, not particularly interested in inspecting the  
Received headers, are unlikely to be impressed at receiving a message with  
no body and the real message as an attachment of type message/rfc2822  
(even if it IS displayed inline, which cannot be guaranteed).
> disadvantages, permited or not on the previours standards.

Yes. I think it would be nice to see complete examples using both methods.

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