Subject: [EAI] Example of body part headers

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 22 Jun 2006 16:52:35 +0100

I have mentioned this issue several times, but I thought it better to  
provide an example to illustrate the problem.

Here is a message that should be valid under Utf8smtp. Observe that there  
is no utf8 at all in the headers, but there is plenty of it in the  
attachments, and some of it is not within the protection of any  
Content-Transfer-Encoding (see the Content-Disposition in the first  
attachment, and the From, To and Subject headers in the second  
attachment). And pardon my French if I have used accute and grave accents  
in places where they should not be, and if I have got some genders wrong  
:-( .

Let us suppose that this message passes through several MTA, where the  
first offers full UTF8SMTP, the second does not offer that, but offers  
8BITMIME, and the third does not even offer 8BITMIME. The envelope  
involves no UTF8, but the MAIL FROM: MUST contain a BODY=8BITMIME  
parameter.

Date: Thu, 22 Jun 2006 15:24:33 +0100 (BST)
From: ascii@ascii
To: another-ascii@another-ascii
Subject: Example of utf8 body headers
Header-Content: (or whatever we call this header)
                 Utf8smtp
                 (even though there is no utf8 in the headers or envelope)
Mime-Version: 1.0
Content-Type: MULTIPART/mixed; BOUNDARY=boundary

--boundary
Content-Disposition: attachment; filename="éxample.txt"
Content-Transfer-Encoding: 8bit
Content-Type: TEXT/plain; charset=utf-8

Ici un Éxample d'une accent aigue.
--boundary
Content-Type: MESSAGE/rfc822;

Date: Thu, 22 Jun 2006 15:13:10 +0100
From: [email-masked]
To: another-utf8@another-utf8
Subject: Éxample_d'une_message/rfc822
Header-Content: Utf8smtp
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Ici un deuxième éxample d'une accent aigue.
--boundary--

So what happens? The first MTA is perfectly happy to accept it from the  
MUA. It then observes that the 2nd MTA does not accept Utf8smtp (and it  
has been warned by the Header-Content that this is a Utf8smtp message) so  
it has to consider what downgrades it needs to perform.

Now, it it does nothing, it will be forwarding a message that does not  
conform to existing standards (but if all the subsequent MTAs advertise  
8BITMIME, then it would in fact be delivered intact).

Suppose it does nothing, and then MTA #2 tries to be deliver it to the  
non-8BITMIME MTA #3. Read RFC 1652. MTA #2 has the option of bouncing it,  
or trying to downgrade it (but RFC 1652 gives no clue about downgrade  
rules - it just tells you to ensure it goes forward as a valid 7bit  
message). Observe that MTA #2 still sees that BODY=8BITMIME parameter in  
the MAIL FROM:, so it knows that downgrading is needed. If it is smart  
enough (are actual 8BITMIME MTAs that smart?) it will observe the  
multipart mixed and examine the Content-Transfer-Encodings in each  
multipart. Seeing that they are 8bit, it will do the necessary conversions  
and change those CTEs to Quoted-Printable. But, not being Utf8smtp-aware,  
it will do nothing about the utf8 in the Content-Disposition header or the  
headers of the message/rfc822.

So it is clear that it is the responsibility of MTA #1 to deal with those  
before passing it on to MTA #2 (I already mentioned that in my comments on  
the downgrade draft). Moreover, it is quite clear how to dongrade those  
headers (RFC 2231 for the Content-Disposition and RFC 2047 for the rest,  
so all the downgrade draft needs to do it to draw attention to the need to  
dongrade those headers.

There are also some repercussions for the utf8headers draft. Clearly, it  
needs to state that it updates RFCs 2045 and 2183 (allowing utf8 in  
<parameter>s) and RFC 2046 (allowing Utf8smtp messages within a   
message/rfc822).

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

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