Subject: Re: [EAI] Minutes from Prague (fwd)

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 26 Apr 2007 23:18:18 +0200

Since Charles forwarded his comment to the list, I'm assuming that he did 
not consider my comment below convincing.

           Harald

------------ Forwarded Message ------------
Date: 23. april 2007 12:47 +0200
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Subject: Re: [EAI] Minutes from Prague

Charles Lindsey wrote:
> On Fri, 20 Apr 2007 21:48:57 +0100, Harald Tveit Alvestrand
> <[email-masked]> wrote:
>
>> Due to my inattention, I have let this slip right until the submission
>> deadline.
>> So the attached file has been submitted as minutes without review
>> from the
>> WG.
>
> And from the minutes:
>
> ..................
> DSN
> draft-ietf-eai-dsn-00
> ---------------------
>
> Issue: Should message encoding be application/utf8smtp or
> message/utf8smtp
> Discussion: MIME allows 8-bit types, but explicitly prohibits 8-bit
> message
> types for message/*
> Argument in favor of message/utf8smtp: the object is a message.
> Argument against message/utf8smtp: may break 7-bit implementations
> Argument for application/utf8smtp: will work with everything, since
> application/<unknown> is supposed to be treated as
> application/octet-stream
> Argument against application/utf8smtp: automated DSN processors might
> barf
> on 8-bit content
> Argument against (soft) message/utf8smtp: the use will leak out, e.g.,
> multipart/digest
> Resolution: do message/utf8smtp; fix broken implementations (if any)
> ...................
>
> I don't understand the proposed resolution here. It violates a very
> explicit "EXPRESSLY FORBIDDEN" in RFC 2045, so you can hardly describe
> an implementation that does not expect to see 8bit where 8bit is
> expressly forbidden as "broken" and "to be fixed". So what am I missing?
The fact that some of us considered the prohibition from RFC 2045 stupid?
>
> And the dicussion completely failed to consider the third possibility
> of using message/rfc822, downgraded as necessary before it is allowed
> to be seen in the non-UTF8SMTP universe (but presumably upgraded again
> for display by recipients so capable).
Yes, it failed to consider this possibility. Rather, there was nobody in
the room who had taken leave of his senses enough to seriously want to
advance such a suggestion.

Your suggestion has NOT seen any support on the list. And for good reason.
>
> Moreover, since we seemed to have abandoned any HDR=UFT8SMTP parameter
> in SMTP, downgraders are going to have to recognize and deal with any
> 8bit headers contained within a message/rfc822, just as they are going
> to have to recognize and deal with them within mime body headerts
> within any multipart.
I don't see a connection here.

---------- End Forwarded Message ----------

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 27 Apr 2007 13:59:57 +0100

On Thu, 26 Apr 2007 22:18:18 +0100, Harald Tveit Alvestrand  
<[email-masked]> wrote:

> Since Charles forwarded his comment to the list, I'm assuming that he  
> did not consider my comment below convincing.

> The fact that some of us considered the prohibition from RFC 2045 stupid?

Yes, we all agree that it is stupid, but RFC 2045 is a Draft Standard;  
that is what it says, so you cannot complain if that is what people have  
implemented.

The scenario we are considering is where a UTF8SMTP-aware MTA has  
generated a DSN which includes the whole of the original message, and it  
finds that it has to send it via some non-UTF8SMTP server. Moreover, the  
next hop beyond that one may not even support 8BITMIME.

Now I can only speak for sendmail, because I have studied its relevant  
source code. It the DSN includes a message/utf8smtp with C_T_E: 8bit  
(which is allowed) and the next hop does not do 8BITMIME, then sendmail  
WILL NOT attempt to change it to C_T_E: Q-P (or Base64) - it will just  
send the 8bits and hope for the best.

I don't know what other servers do, but it would not surprise me if they  
behaved similarly. But, in any case, sendmail is a significant part of the  
currently installed server-base, and it was my understanding that EAI is  
intended to interoperate with that existing base.

OTOH if the returned message in the DSN is sent as an  
application/utf8smtp, or as a properly downgraded message/rfc822, then  
sendmail (and I presume all other servers) will then downgrade it  
correctly if asked to forward it to a non-8BITMIME system.

Now you might well be able to persuade the implementors of sendmail that  
it is "broken" and should be "fixed". But even then there would still be a  
large installed base of earlier implemenations. The efforts of the  
sendmail implementors would be better spent on doing a decent  
implementation of full UTF8SMTP.
>> of using message/rfc822, downgraded ...
>

Such as "it would actually work"?

-- 
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: 27 Apr 2007 21:53:50 +0300

> Your suggestion has NOT seen any support on the list. And for good reason.

Well at least I have mentioned that possibility:
   "message/utf-8   can be downgraded to message/rfc822 or converted to
    multipart/utf8-encapsulated."

So I do not think that your claim is completely true.

( There is perhaps some other messages, but that I least found. )

/ Kari Hurtta

--------------------------------------------------------------------
From: Kari Hurtta <[email-masked]>
Subject: Re: [EAI] Re: 8to7 downgrade and message/*
Newsgroups: gmane.ietf.ima
To: [email-masked]
Date: 03 Feb 2007 23:42:01 +0200

Frank Ellermann <[email-masked]> writes in gmane.ietf.ima:

> > Effectively gateways are required bounce unknown message/* types
> > if they include 8-bit.
> 
> Okay, so we should offer a better solution for message/utf-8 and
> family for the purpose of 8BITMIME to 7bit gateways - nobody else
> needs this.  While we're at it let's support any message subtype,
> including invalid message/rfc822 headers with UNKNOWN-8BIT octets.

Yes.

Note that providers of that solution are UTF8SMTP to rfc(2)822 gateways.

They must do that munging so that there is not these message/utf-8,
message/utf-8-headers and so on types.   

> How about an application/message-munged with a mandatory parameter
> indicating the original message subtype ?  Where "munged" could be
> defined as a very radical procedure:  Take the complete unknown
> message part (or a complete invalid message/rfc822 part), gzip it,
> B64 it, ready.  Maybe gzip is overkill.

message/utf-8   can be downgraded to message/rfc822 or converted to
multipart/utf8-encapsulated.

message/utf-8-headers is better replaced with text/utf8-header 

Then there is left   message/utf-8-delivery-status and 
message/utf-8-disposition-notification

There is some details which need to be figured out.

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 28 Apr 2007 08:26:24 +0200

> The fact that some of us considered the prohibition from RFC 2045 stupid?

Now I'm confused.  It's no stupid prohibition.  It's based on three
assumptions:  (1) Messages consist of an ASCII header and a body.
(2) The body can be structured and/or encoded as specified in the
header of the message.  (3) Eveybody knows how a message/rfc822 is
structured, and how it specifies the encoding of its body, because
the message/rfc822 structure is what MIME and RFC 2045 are about.

So if you put a message/rfc822 as part (or as part of a part, etc.)
into a MIME message, which is by definition also a message/rfc822,
then it makes no sense to specify a CTE like base64 for this part,
it would encode the complete message, header, body, any parts the
embedded message has, all.

However a CTE like 8bit in the MIME part header of the embedded
message protects the visible message structure, its ASCII header
is still directly visible, its ASCII MIME part headers (if it's
also structured) are still directly visible, and any part of the
embedded message that is neither a message nor a multipart has
its own header that can use its own CTE (including base64 or QP).

You can also put the 8BITMIME message into a 7bit message: Keep
its ASCII header and its ASCII MIME part headers as they are,
and flip any CTE 8bit (or binary, but my example is 8bit) you
find in non-composite parts of this message to base64.  And of
course encode those parts using B64.

The complete structure is still visible, any embedded parts
that were already 7bit are directly readable for MIME unaware
user agents.  And actually you do that recursively depth first,
flip CTE to B64 or QP as needed for non-composite parts, keep
the MIME structure including all MIME part headers as is, and
replace any composite 8bit CTE by 7bit for this procedure.

A message containing among other parts a message, the embedded
message containing among other parts a message, no problem, you
can freely flip them from 8bit to 7bit while still preserving
their visible ASCII structure + all visible ASCII parts,  And
of course all ASCII message and MIME part headers are visible.

Without that prohibition parts of the MIME structure (complete
messages or complete multiparts) would be "hidden" in the form
of base64 garbage, that's not nice to MIME-unaware user agents.

MIME has builtin maximum backwards compatibility, that's not
stupid, it's brilliant.  I'd wish all protocols were designed
that way.

Of course we now have a "minor" problem here for EAI, one of
the three assumptions mentioned above is wrong, and conclusions
based on these three assumptions are suddenly utter dubious.

But that doesn't force us to violate the EXPRESSLY FORBIDDEN
rule.  If we can't have CTE b64 for message subtypes, we just
roll our own application/message where we can use B64 as it
pleases us.  After all it's just a name, the "desired" effect
of completely encoding an embedded 8bit message/xyz (thereby
hiding its header + structure for MIME unaware UAs) is the
same, no matter if we say "application/message" following the
rules, or if we force B64 at a place where it's not allowed.

And IMO all these 8bit to 7bit considerations are not really
the job of EAI.  We can do that based on Kari's draft, or on
a hypothetical draft defining application/message, but it's
not required for the EAI experiment:  As far as UTF8SMTP is
concerned the whole world uses 8BITMIME.  If somebody still
uses 7bit his 8BITMIME to 7bit problems are no EAI problems.

Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 30 Apr 2007 16:17:41 +0200

> the message/rfc822 structure is what MIME and RFC 2045 are about.
The thing that is (possibly) stupid is extending this restriction across 
every future MIME type that starts with the letters "message/". See RFC 
2046 section 5.2.2 for the rather specific restrictions on encoding for 
message/partial.

The content of a message/partial doesn't consist of an ASCII header and 
a body, so I lost you at (1).

                     Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 30 Apr 2007 16:22:13 +0200

> So I do not think that your claim is completely true.
Downgrading to message/rfc822 is not completely beyond the realm of the 
reasonable (imho).

The "unsupported" I was pointing out was the idea of transporting 
UTF8SMTP messages inside the UTF8SMTP cloud with a MIME type of 
message/rfc822.

                        Harald