Subject: [EAI] Test data: 8-bit attachments

From: Harald Alvestrand <[email-masked]>
Date: Tue, 27 Mar 2007 16:29:35 +0200

Attached is what started out as the following:

- A message with an attached message/utf-8-or-something-like-that (this 
type is almost guaranteed to be unknown to the MTAs on the way), encoded 
in quoted-printable
- A nearly identical message, encoded in 8-bit.

The quoted-printable version at the time it started out:

From: [email-masked]
To: [email-masked]
Subject: Fake test UTF-8 message
MIME-version: 1.0
Content-type: multipart/mixed; boundary="tigerlily"

--tigerlily
Content-type: message/utf-8-or-something-like-that
Content-transfer-encoding: Quoted-printable

From: s=C3=[email-masked]
To: [email-masked]

H=C3=A5rete
The word above is the word "hairy" in Norwegian
--tigerlily--

The downgrading MTA seems to have been Postfix.
I guess we've proved that Postfix doesn't let 8-bit encoded 
message/whatever body parts through undamaged, but quoted-printable ones 
are preserved perfectly.

                            Harald

Subject: Fake test UTF-8 message
From: [email-masked]
To: [email-masked]
Date: Tue, 27 Mar 2007 15:59:05 +0200 (CEST)

From: s=C3=[email-masked]
To: [email-masked]

H=C3=A5rete
The word above is the word "hairy" in Norwegian

Subject: Fake test 8-bit UTF-8 message
From: [email-masked]
To: [email-masked]
Date: Tue, 27 Mar 2007 15:59:46 +0200 (CEST)

From: [email-masked]
To: [email-masked]

HC%rete
The word above is the word "hairy" in Norwegian

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

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 27 Mar 2007 19:41:53 +0200

Harald Alvestrand wrote:

> - A message with an attached message/utf-8-or-something-like-that
> (this type is almost guaranteed to be unknown to the MTAs on the
> way), encoded in quoted-printable

All-ASCII reply, what arrived at GMaNe is this:
http://article.gmane.org/gmane.ietf.ima/1647/raw

Your article is a multipart/mixed MIME version 1.0 with four parts:

= 1 =
A 7bit UTF-8 intro (encoded as QP) mentioning the words H=C3=A5rete
and s=C3=[email-masked]

= 2 =
The 2nd part is the first forwarded test message/rfc822 (CTE 7bit),
it was sent "from" (2821 + 2822, SPF + PRA) <[email-masked]>
and "to" [email-masked] via spaceape10.eur.corp.google.com

= 2.1 (tigerlily) =
The content of this message was a multipart/mixed with one part
(overall 2.1), a message/utf-8-or-something-like-that with CTE QP.

It contains exactly the same two words as quoted in the intro.

= 3 =
The third part is the second forwarded test message/rfc822, also
CTE 7bit, now via spaceape11 instead spaceape10.

= 3.1 (tigerlily) =
The content of this message was a multipart/mixed with one part
(overall 3.1), a message/utf-8-or-something-like-that with CTE
7bit (instead of QP in 2.1)

It contains [email-masked] instead of s=C3=[email-masked]
and HC%rete instead of H=C3=A5rete

= 4 =

Some spam added by an entity claiming to be the EAI mailing-list.

===

The "damage" in the third part might have been introduced by GMaNe
or the mailing list.  IMO it can't work if you forward an 8bit
message (did you ?) as message/rfc822 with CTE 7bit, the "damage"
could be actually an attempted "fix".

Otherwise the damage already happened in the test, and how you
forwarded it to the mailing list doesn't matter.  In the intro you
said that the second test was sent using CTE 8bit for the tigerlily
part.  What I see is CTE 7bit for this part (3.1).

If you sent it as 8bit I'd also expect to see a CTE in the header
(i.e. part 3), but that header only says multipart/mixed defining
the tigerlily boudary exactly as in the first test.

I can't check the Google hops, but eikenes.alvestrand.no offers
8BITMIME.  Do your logs confirm that 8BITMIME was actually used
when smtp-out.google.com sent the second test mail to you ?

For us to see what really happpened with the second test mail (8bit)
I think you've to send it as ZIP.  So far I only see that "CTE QP"
for the unknown message subtype in the first test apparently worked.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 28 Mar 2007 20:38:17 +0100

> type is almost guaranteed to be unknown to the MTAs on the way), encoded

But it would not surprise me in the least if lots of existing software  
does the "right thing" in that case. But if you pointd out to their  
implementors that it was "EXPRESSLY FORBIDDEN" by RFC 2045, they they  
would just reply that they were being "liberal" (whether intentionally so,  
or because they had not read RCC 2045 properly).

But that is not to say that you can RELY on the fact that every  
implementor has misread RFC 2045 in the same way. That wording in RFC 2045  
is pretty strong.

And since AFAICS we can do what we need without inventing new  
message/types that break that rule, then we should do so.

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