Subject: Re: [EAI] Re: #1485: Choices

From: Harald Alvestrand <[email-masked]>
Date: Mon, 04 Jun 2007 00:48:16 +0200

Yuri Inglikov wrote:
> +1 for message/rfc822.
>
> I think that even if it leaks outside UTF8SMTP environment without downgrading (which /normally/ should not happen), it is better if older applications can at least partially interpret it / show most of the content than let them deal with unknown subtype of a message/ (which they certainly unable to) or deal with unstructured blob attachment (application/utf8smtp or anything like that). I don't quite understand the hesitation to extend the meaning of message/rfc822 to allow UTF8 content in UTF8SMTP environment. Isn't it very similar to allowing any other incompatible thing in such environment, like address headers with UTF8 local parts? Any such extensions likely will cause same problems if leaked outside UTF8SMTP environment.
And using message/rfc822 would offer an easy and convenient means of 
leakage.

Note that in the case of signed messages, you CANNOT downgrade on the 
border; in the case of encrypted messages, you can't even detect the 
MIME type of the inner part.

> On the other hand, most applications are robust enough to deal with unexpected / malformed MIME content and could be able to reasonably recover in most cases if faced with UTF8 embedded message.
>
> Yuri Inglikov
>
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ima
>
>   

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 04 Jun 2007 15:04:37 +0100

On Sun, 03 Jun 2007 23:48:16 +0100, Harald Alvestrand  
<[email-masked]> wrote:

> Yuri Inglikov wrote:
>> +1 for message/rfc822.
>>
>> I think that even if it leaks outside UTF8SMTP environment without  
>> downgrading (which /normally/ should not happen), it is better if older  
>> applications can at least partially interpret it / show most of the  
>> content than let them deal with unknown subtype of a message/ (which  
>> they certainly unable to) or deal with unstructured blob attachment  
>> (application/utf8smtp or anything like that). I don't quite understand  
>> the hesitation to extend the meaning of message/rfc822 to allow UTF8  
>> content in UTF8SMTP environment. Isn't it very similar to allowing any  
>> other incompatible thing in such environment, like address headers with  
>> UTF8 local parts? Any such extensions likely will cause same problems  
>> if leaked outside UTF8SMTP environment.

No more than using multipart/whatever with UTF-8 in Content-Description  
fields within its parts. Whilst all sorts of weird and wonderful  
departures from standards undoubtedly exist in the present network, if we  
cannot assume that implementors of a newly deployed feature such as  
UTF8SMTP will not follow our requirements, then there is not much hope for  
EAI. All that is required to prevent leakage is for MTAs that do  
downgrading to inspect all contained message/rfc822s to see if their  
headers contain 8bit (and so, recursively, for inner objects within the  
message/rfc822).
> MIME type of the inner part.

Apart from DKIM signatures, which are a separate can of worms, I don't  
think other existing signature schemes are supposed to hide or alter the  
MIME structure of a message.

-- 
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: John C Klensin <[email-masked]>
Date: Mon, 04 Jun 2007 12:56:03 -0400

--On Monday, June 04, 2007 3:04 PM +0100 Charles Lindsey 
<[email-masked]> wrote:

>...
>>> with   UTF8 local parts? Any such extensions likely will
>>> cause same problems   if leaked outside UTF8SMTP environment.
>> And using message/rfc822 would offer an easy and convenient
>> means of   leakage.
>
> No more than using multipart/whatever with UTF-8 in
> Content-Description fields within its parts. Whilst all sorts
> of weird and wonderful departures from standards undoubtedly
> exist in the present network, if we cannot assume that
> implementors of a newly deployed feature such as UTF8SMTP will
> not follow our requirements, then there is not much hope for
> EAI. All that is required to prevent leakage is for MTAs that
> do downgrading to inspect all contained message/rfc822s to see
> if their headers contain 8bit (and so, recursively, for inner
> objects within the message/rfc822).

Charles, having started out in favor of message/rfc822 and 
gradually changed my mind, I think the concern is that there are 
ways that things leak even in what is generally a conforming 
environment.  We've had experience with that over and over 
again, to the point that it is hard to pretend that leaks cannot 
(or will not) happen.  I fear that examples abound and that, 
while any one of them can be dismissed with an understanding of 
what can be done to prevent it, their number is such that we are 
very constrained if we want to be safe about these things in 
practice.

If one were willing to adopt an "ok, in that situation, 
just-send-8" position and some of its corollaries, then this 
would get a little easier.  I'm not, but that is just a personal 
opinion/ conviction/ preference.

    john

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 05 Jun 2007 12:15:18 +0100

On Mon, 04 Jun 2007 17:56:03 +0100, John C Klensin <[email-masked]> wrote:

> Charles, having started out in favor of message/rfc822 and gradually  
> changed my mind, I think the concern is that there are ways that things  
> leak even in what is generally a conforming environment.  We've had  
> experience with that over and over again, to the point that it is hard  
> to pretend that leaks cannot (or will not) happen.  I fear that examples  
> abound and that, while any one of them can be dismissed with an  
> understanding of what can be done to prevent it, their number is such  
> that we are very constrained if we want to be safe about these things in  
> practice.

I suspect that leaks of UTF8SMTP messages into message/rfc822 objects  
visible in the non-utf-8 environment will mostly arise from current MUAs  
that manage to acquire a UTF8SMTP message somehow (not supposed to happen,  
but it will) and then try to forward it as a message/rfc822 attachment  
(clearly, such MUAs will not be aware that the attachment should have been  
message/utf8smtp or application/utff8smtp). So there is absolutely nothing  
we can do to stop this from happening; the best thing we can hope to do it  
to arrange that any UTF8SMTP-capable MTA that detects such a beast can at  
least downgrade it to something legal (unless the onward path is  
UT8SMTP-capable, of course).

I doubt that such leaks are going to arise from MTAs that are truly  
UTF8SMTP-capable, which means that they are unlikely to arise in the  
course of DSNs that are simply returning the whole of the original  
UTF8SMTP message, since if they are smart enough to generate a DSN  
according to our documents, then they are probably smart enough to  
downgrade the returned message to something that is safe on the existing  
network (in cases where the return path is not UTF8SMTP).
>
> If one were willing to adopt an "ok, in that situation, just-send-8"  
> position and some of its corollaries, then this would get a little  
> easier.  I'm not, but that is just a personal opinion/ conviction/  
> preference.

The real problem with message/utf8smtp (as opposed to some  
application/utff8smtp) is that we know that some existing agents will just  
"send it as 8bit", and we do not know of ANY existing agent (and I keep  
asking for counter examples) that will attempt to encode it in Q-P or  
Base64, as the people in Prague seemed to envisage.

Basically, the message type in MIME was very badly designed. But there is  
not much that we can do about that except not to invent new message types.