Subject: [EAI] I-D Action:draft-ietf-eai-rfc5336bis-08.txt

From: [email-masked]
Date: Mon, 07 Mar 2011 01:30:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Email Address Internationalization Working Group of the IETF.

	Title           : SMTP Extension for Internationalized Email Address
	Author(s)       : J. Yao, W. MAO
	Filename        : draft-ietf-eai-rfc5336bis-08.txt
	Pages           : 22
	Date            : 2011-03-07

This document specifies an SMTP extension for transport and delivery
of email messages with internationalized email addresses or header
information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5336bis-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: John Levine <[email-masked]>
Date: 8 Mar 2011 01:12:56 -0000

>	Filename        : draft-ietf-eai-rfc5336bis-08.txt

I hope someone can point me at archived messages that resolve this,
but what's the reason that section 3.2 says that you need to have
a UTF8SMTPbis session to pass a message/global as a MIME part?  I
understand why it'd be a problem if sent as 8bit, but if it's
QP or base64, what's the difference between that and any random
application/x.somethingyouneverheardof that people send all the time?

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Mar 2011 03:49:07 -0500

--On Tuesday, March 08, 2011 01:12 +0000 John Levine
<[email-masked]> wrote:

> I hope someone can point me at archived messages that resolve
> this, but what's the reason that section 3.2 says that you
> need to have a UTF8SMTPbis session to pass a message/global as
> a MIME part?  I understand why it'd be a problem if sent as
> 8bit, but if it's QP or base64, what's the difference between
> that and any random application/x.somethingyouneverheardof
> that people send all the time?

Nothing in any of the base MIME or message header specs permits
encoding headers (other than the parts that can be turned into
encoded words( in other than ASCII text.  And the definition of
message/rfc822 requires conformance to 822 / 5322, including the
"all header information is either ASCII or encoded into ASCII"
requirement.

So, assume we start out with an incoming message structured as

#  From: [email-masked]
#  To: SomeNonASCII <[email-masked]>
#  Date: Saturday, February 30, 2011 00:01 +0100
#  MIME-Version: 1.0
#  Content-type: text/plain; charset=UTF-8
#  Content-transfer-encoding: 8bit
#  
#  Some message text containing characters outside the ASCII
range

It is received at example.net with SMTP extensions 8BITMIME and
UTF8SMTPbis.  So far, so good.  The recipient there now wants to
encapsulate it, headers and all, and forward the result to a
host that advertises neither UTF8SMTPbis nor 8BITMIME.

If example.net (or the MUA) were sufficiently clever, turning
SomeNonASCII into encoded words is well-specified, as is
encoding the message text in Base64 and changing the C-T-E to
Base64 to match.  But there is no downgrade mechanism for the
actual address/mailbox part of the "To:" header field.  As far
as the WG has been able to determine, that leaves three possible
design options:

	(1) Define a new content-type that is like
	message/rfc822 but that permits explicit non-ASCII in
	the headers of the encapsulated material and require a
	UTF8SMTPbis session.
	
	(2) Encapsulate the entire message (with or without the
	envelope), pushing the headers into Base64.  This would
	obviously require a new content-type as well, but would
	render the encapsulated message somewhat opaque.  It
	would not require UTF8SMTPbis since all material would
	be in ASCII.
	
	(3) Figure out a way to apply encoded-words to address
	subfields  (clauses) and other header fields and clauses
	in which encoded-words are not now permitted.  Depending
	on how it were done, this might require an SMTP
	extension (not necessarily UTF8SMTPbis) and/or a new
	content-type.

In reverse order, the WG discussed variations on (3) -- it is,
after all, isomorphic with "downgrading" ideas and, fwiw, ideas
about avoiding any need for 8bit transport of any header
information including addresses -- and rejected them as
impractical given the wide variety of information now encoded in
local-parts and the "no tampering enroute" rule.   The WG also
decided against (2) because the opacity would cause other
problems.  The idea was not new -- I was recently reminded that
it was one of the options I proposed in
draft-klensin-i18n-message in early 2004.  The first option was
selected by the WG with message/global and UTF8SMTP /
UTF8SMTPbis (as usual, "whatever the latter ends up being
called).

    john

(3) Figure out

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 08 Mar 2011 10:07:03 -0800

On 3/8/2011 12:49 AM, John C Klensin wrote:
>> this,,

John asked for a pointer to the archive, not an assurance that the discussion 
took place.

I'd like to see the pointer, too, because your lengthy response indicates a 
rather basic misunderstanding of the way MIME-handling rules are different from 
SMTP-level message-handling rules.

It also suggests a misunderstanding of the primary reason for having the SMTP 
handling restriction being defined by this group:

      The issue is not whether the recipient "supports" the enhanced characters, 
but the need to easily distinguish between legacy character usage versus 
enhanced (UTF-8) character usage; a message having a header using the enhanced 
characters might break a legacy message processing engine.

    When aa established base of data processing software is handed data that 
falls outside of the range that was previously legal, it is likely that some of 
that software will break or will damage the data.

      The SMTP-level rule is the means of ensuring that receiving engines will 
not break and will not erroneously modify the data.

By contrast, MIME uses the Content-type field to provide an "out of band" 
indication of the type, so that a processing engine that dives into the MIME 
content is forewarned.  As with all MIME labels, message/global means both "the 
body part contains the labeled type of data" but also "do not process this 
body-part unless you understand that type of data."

In other words, the rules for propagating a new MIME content-type are -- and 
need to be -- fundamentally different than for a new type of email header. 
Currently, folks frequently pass around MIME attachments for data the recipient 
cannot (currently) process.  It's legal and actually constructive.

Consequently the SMTP-level restriction on the carriage of message/global is 
gratuitous, serving mostly to raise yet-another high barrier to adoption for 
interoperable UTF-8.  It also qualifies as a layer violation.

Note that a major factor in MIME's success was precisely because it did NOT 
impose a restriction like this.  It meant that any two cooperating MUAs could 
process the data, without being dependent on an upgrade of the infrastructure. 
The current draft's restriction makes it impossible for the MUAs to pass an 
attachment that happens to be message/global even though all sorts of other 
attachments can be passed that the recipient might not be able to process.

> Nothing in any of the base MIME or message header specs permits
...
> UTF8SMTPbis.  So far, so good.

Also so far, so irrelevant.

The first part of your message covers the handling of a message from posting to 
delivery and has nothing to do with MIME message/global.  How the message/global 
content came into being is irrelevant.

What is relevant is that someone wants to send a message with a message/global 
attachment.

> actual address/mailbox part of the "To:" header field.

You are inventing a requirement that the infrastructure provide assurance that a 
recipient can process a particular MIME type.

I believe this is both brand new and counter-productive.

Defining the new MIME message type is fine and appropriate.

Specifying special transport handling restrictions is not.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 09 Mar 2011 11:48:21 -0000

On Tue, 08 Mar 2011 18:07:03 -0000, Dave CROCKER <[email-masked]> wrote:

> John asked for a pointer to the archive, not an assurance that the  
> discussion took place.
>
> I'd like to see the pointer, too, because your lengthy response  
> indicates a rather basic misunderstanding of the way MIME-handling rules  
> are different from SMTP-level message-handling rules.
>
> It also suggests a misunderstanding of the primary reason for having the  
> SMTP handling restriction being defined by this group:
>
>       The issue is not whether the recipient "supports" the enhanced  
> characters, but the need to easily distinguish between legacy character  
> usage versus enhanced (UTF-8) character usage; a message having a header  
> using the enhanced characters might break a legacy message processing  
> engine.

I think there are two cases the WG took into account during the early days.

1. Someone wants to send a txt document in UTF-8.

OK, MIME already covers 99% of that (Content-Type gives charset=utf8 and  
CTE gives QP or Base64). So it can normally all happen with a legacy  
message. But supposing that the attachment contains a Content-Disposition  
with a filename in utf8, of a Content-Description in utf8. Then it  
technically becomes a UTF8SMTPbis message (or can RFC 2047 fix those  
cases?) In practice, such a message would almost certainly get through  
unscathed through legacy servers, but you are not supposed to do it that  
way.

2. Similar thing sending an rfc/822 document that happens to be a  
UTF8SMTPbis message.

Rfc/822 is an unusual MIME type with all sorts of special restriction  
concerning the headers in the attached message. So again sending it as a  
legacy message is not allowed. It was because of the extra complications  
of this case that the WG invented message/global

-- 
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 Levine <[email-masked]>
Date: 9 Mar 2011 15:18:53 -0000

>interoperable UTF-8.  It also qualifies as a layer violation.

Squinting at the specs, I note that RFC 2045 section 6.4 says that a
message/* MIME part can only be encoded with "7bit", "8bit", or
"binary", on the theory that anything else would make it too hard to
find the MIME structure of the enclosed message.  This means that a
message with a message/global part would always need a server that
handles 8BITMIME or CHUNKING to handle the message.

It would be straightforward to adjust the draft to say something
suitable, e.g., the usual rules apply about what encodings can go over
what transport, but since there are restrictions either way on how you
can send message/global, it seems less compelling.

R's,
John

Counter Argument: no matter what we say, people will send
message/global attachments over 8bitmime with or without the EAI flag,
so we might as well adjust to spec to describe the inevitable
practice.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 09 Mar 2011 10:20:40 -0800

On 3/9/2011 3:48 AM, Charles Lindsey wrote:
> supposing that the attachment contains a Content-Disposition with a filename in
> utf8, of a Content-Description in utf8. Then it technically becomes a
> UTF8SMTPbis message (or can RFC 2047 fix those cases?) In practice, such a
> message would almost certainly get through unscathed through legacy servers, but
> you are not supposed to do it that way.

Since you are referring to a header field, the existing rules of UTF8SMTPbis 
apply.

In terms of handling rules, it actually has nothing to do with MIME.

> 2. Similar thing sending an rfc/822 document that happens to be a UTF8SMTPbis
> message.
>
> Rfc/822 is an unusual MIME type with all sorts of special restriction concerning
> the headers in the attached message. So again sending it as a legacy message is
> not allowed. It was because of the extra complications of this case that the WG
> invented message/global

The need for continuing the restriction on message/rfc-822 encoding restrictions 
has been challenged recently; certainly there is no obvious argument for 
extending it so something new, nor for imposing a requirement of end-to-end 
support of a new extension.

But really, I do not understand your second point.

d/

-- 

   Dave Crocker

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 10 Mar 2011 11:22:03 -0000

On Wed, 09 Mar 2011 18:20:40 -0000, Dave CROCKER <[email-masked]> wrote:

> Since you are referring to a header field, the existing rules of  
> UTF8SMTPbis apply.
>

the case I was referring to was where there was a multipart mixed one of  
whose components started with a Content-* header using UTF8. Insofar as we  
allow that (as I understand we do) we are extending MIME as used within  
UTF8SMTPbis messages.
>> UTF8SMTPbis
>> message.global
> The need for continuing the restriction on message/rfc-822 encoding  
> restrictions has been challenged recently; certainly there is no obvious  
> argument for extending it so something new, nor for imposing a  
> requirement of end-to-end support of a new extension.

If they are going to relax some restriction on message/rfc822, that may be  
a Good Thing, but it hasn't happened yet, so your document has to be  
written in terms of the existing MIME rules. And sending a message/rfc822  
with utf8 in its headers (and MIME does not apply any CTE to those  
headers) does not currently work. Which is why message/glonal had to be  
invented.

---

From: [email-masked]
Date: Thu, 10 Mar 2011 12:41:03 -0800 (PST)

> body-part unless you understand that type of data."

Correct, although message/global is in some senses a special case like
multipart or message/rfc822 - it can be seen as a structural artefact rather
than a proper type.

> cannot (currently) process.  It's legal and actually constructive.

Yes, but again, the difference is we're talking about a structural message
element. It's one thing not to be able to interpret the contents of a leaf
part; it's a bit different when the failure to interpet the part may affect the
processing of the message as a whole.

But that said, while the difference is real, I don't believe it is anywhere
near sufficient to justify having the restriction. Such restrictions invariably
prove to be barriers to deployment, sometimes becoming problematic in entirely
unexpected ways.

> interoperable UTF-8.  It also qualifies as a layer violation.

I agree with the former and support dropping the restriction, but it's actually
something of a judgement call. I'm not sure it qualifies as a layer violation,
however - this is where the structural aspects may come into play.

> attachments can be passed that the recipient might not be able to process.

That's exactly why the restriction should be removed.

> I believe this is both brand new and counter-productive.

No, it's not new. It was discussed at length during the development of MIME,
and even came close to derailing things a couple of times.

The problem is that while it would in some ways be nice to operate in a world
with more constraints on how things are represented, this is in no way, shape,
or form the world we actually operate in, and there's ample "running code"* to
show that attempts to impose this sort of thing at the email transport layer do
not work.

> Defining the new MIME message type is fine and appropriate.

+1

> Specifying special transport handling restrictions is not.

+1

				Ned

* There have been several attempts to do this sort of thing, but the one that
really stands out is X.400. The original X.400 specification actually went so
far as to define all the media types you were supposed to use, even including
what was effectively a simple word processing format. The only escape hatch was
a typeless unlabelled octet stream object. And of all the mistakes that X.400
made, this was the one that topped the list of things that people immediately
and actively tried to fix. Keep in mind that this was an email protocol without
a proper way to represent user *addreses*, and yet the pressure to deal with
the addressing problem was less than there was to be able to send arbitrary
typed attachments.

---

From: [email-masked]
Date: Thu, 10 Mar 2011 13:05:45 -0800 (PST)

> handles 8BITMIME or CHUNKING to handle the message.

Yes, this is an unfortunate restriction that should have only been applied to
message/rfc822. We need to just fix it, since the alternatives of moving the
message/global type under application or defining a new messagebis top level
type are much less appealing.

> so we might as well adjust to spec to describe the inevitable

I actually don't find this argument to be hugely compelling, but there's a
related one that is.

Consider the problem a MIME processor faces that needs to downgrade an 8bit or
binary  MIME message to 7bit. If that processor encounters a message/rfc822
part, there's no problem: It descends into the part and applies encoding to the
parts contained inside; no need to apply a non-identity CTE to the enclosing
part. But when you hit a message/* part of some other type you don't recognize
with an 8bit or binary CTE (and content to match), you're screwed: You don't
know the structure so you can't go inside, and you can't apply a CTE to
the part without breaking the rules.

In practice what happens is the rule is ignored. And this is entirely
appropriate because it's a bad rule that should never have been put in MIME in
the first place. But that means not only is message/global going to leak, it's
going to get encoded once it does - and probably in some cases where no
actual leakage is involved.

All this is the price we pay for adding a structural element to MIME very late
in the game. And I'd be against making this set of changes if there was any
reasonable alternative, but AFAICT there isn't.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 10 Mar 2011 16:27:53 -0500

>> "binary" ...

> Yes, this is an unfortunate restriction that should have only been 
> applied to message/rfc822. We need to just fix it, since the 
> alternatives of moving the message/global type under application or 
> defining a new messagebis top level type are much less appealing.

See subsequent message -- it's fixed in 5335bis which says you can encode 
message/global any way you want.

> actual leakage is involved.

Do we agree that the 5336bis rule about needing the EAI flag for mail that 
contains message/global is wrong?  That seems the natural result here.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: [email-masked]
Date: Thu, 10 Mar 2011 13:44:42 -0800 (PST)

> contains message/global is wrong?  That seems the natural result here.

Yes and it is the natural result.

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 11 Mar 2011 08:55:02 -0800

> the addressing problem was less than there was to be able to send arbitrary

Indeed the difference in design philosophy between Internet Mail and X.400 
demonstrate this issue repeatedly:  Constrain as little as you possibly can.

Besides trying to define all the legal content types, they insisted that all the 
components of an address were globally controlled.  The fact that Internet Mail 
constrained only the hostname globally left local sites able to explore and 
exploit all sorts of enhancements that otherwise would not have been possible. 
CSNet and Usenet depended on this, as does your own address for this message...

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Mar 2011 12:43:36 -0400

--On Thursday, March 10, 2011 16:27 -0500 John R Levine
<[email-masked]> wrote:

> Do we agree that the 5336bis rule about needing the EAI flag
> for mail that contains message/global is wrong?  That seems
> the natural result here.

Hi.  I've been saying fairly little about this because I'm
pretty agnostic about the result, i.e., precisely because I
recognize the tradeoffs that you, Ned, and others have pointed
out, anything that that WG concludes is right after due
consideration is fine with me.

Getting rid of the nested encoding rule entirely would also be
fine with me.  That option was not considered by the WG in the
initial round because it (or any other change to the
fundamentals of the MIME definition) was believed (by the
previous co-chairs) to be out of scope/ charter.

I am concerned that we not accidentally compromise or
alter/update two provisions of 5321/5322 that really aren't part
of the nested encoding restriction:

(1) There is an absolute prohibition in SMTP against the message
payload (Headers and body) containing anything but ASCII
characters (in RFC 5321, see the first paragraph of Section
4.1.1.4) unless extensions are present.  Pre-EAI, there is no
extension that permits headers in anything but ASCII.

(2)  5322 repeats the ASCII restriction (Section 2.2 and syntax)
as does the RFC2045 version of the MIME spec.   If one is going
to have raw (not ACE, encoded-word, or, in the MIME case,
Hex-encoded) non-ASCII content in headers, then it appears to me
that there are only two choices: 

	-- enable non-ASCII encodings (presumably UTF-8 and
	UTF-8 only, although that is, in principle, a separate
	issue) through an SMTP extension or 
	
	-- adopt a just-send-8 philosophy and hope the content
	goes through without being trashed, that parsers accept
	the 8-bit data as reasonable and treat it and UTF-8 and
	that things work out more generally.  

I'm too paranoid, and have seen too much damage, to believe that
the latter is a good idea.  But maybe that is just me.

Now, to reprise pieces of comments made by others, the "cause"
for message/global was the following scenario:

	(i) User/MUA receives a message over a UTF8SMTPbis path
	that contains addresses in some header fields that
	require EAI.  (EAI use of UTF-8 in other fields give
	much the same result but, because the possibility of
	converting many of them to encoded-words complicates the
	example, let's stick to addresses).
	
	(ii) User decides to forward the message to someone
	else, encapsulating it via message/rfc822.
	
	(iii) The _message header_ of the message to be
	encapsulated is now incompatible with the MIME spec
	generally, and the message/rfc822 spec in particular,
	because it contains non-ASCII characters.  Remember that
	the main thing that differentiates message/rfc822 from
	multipart/mixed is that the former is designed to
	encapsulate RFC822/IMF messages, header fields and all,
	not just blobs of some arbitrary content-type.

The user is now stuck and stuck whether there is a requirement
for UTF8SMTPbis flags and transport or not.   And, so far, this
has nothing to do with the content of any body parts (we know
what to do about those) or the nested encoding rule.  And, as
far as I know, there are only the following ways to allow
encapsulation of headers that contain those non-ASCII addresses:

	(a) Modify the spec for message/rfc822 so that it
	permits non-ASCII data (or, if one prefers to think of
	it that way, 8bit data) in the headers of the message(s)
	being encapsulated.  Whether that is wise or feasible is
	a separate question, but it would certainly be a
	modification of the existing spec.
	
	(b) Create a new encapsulation content-type, presumably
	another subtype of message/ that allows for 8bit
	material in the headers of encapsulated messages.
	Independent of either the nested encoding rule or
	anything having to do with UTF8SMTPbis flagging, that is
	what message/global was intended to accomplish.
	
	(c) Create a new encapsulation content-type, one that
	might or might not be a subtype of message/ (separate
	decision, but multipart/ might work equally well and
	there are other variations on this theme) that views the
	encapsulated messages --including their headers-- as
	just a slightly-special type of data blob that treats
	message headers as just variations on text/plain that
	could be Base64-encoded if needed.

The problem with (a) and (b) is that we still have that
"transport ASCII-only" restriction in 5321 and the "headers in
ASCII" restriction of 5322/MIME.  If things have to be
transported over the default/ assumed 7bit path, then we need a
way to encapsulate and encode the headers themselves.  That
either pushes us toward (c) or requires a model that I don't
think we have yet.

Again, I'm not advocating for anything; I'm just trying to put
the constraints that have nothing to do with nested encodings
into context in the hope of advancing the discussion.

    john

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 14 Mar 2011 12:25:47 -0000

> the latter is a good idea.  But maybe that is just me.

Broadly I agree with that, but it is arguable that "just sending-8" in the  
body may well work in practice. Servers are in general notorious for doing  
nasty/stupid things to headers, but hardly ever do anything to bodies  
beyond perhaps changing CTEs. I believe all widely used servers are now in  
practice 8-bit clean in bodies.

So it may be a reasonable risk to do things slightly in violation of the  
MIME standards, as regards headers contained within multiparts within  
bodies, using just an 8BITMIME restriction rather than the more difficult  
UTF8SMTPbis restriction.

Or you could say that if Ned thinks some small violation of MIME should be  
permitted, then we should go ahead and do it.

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Mar 2011 09:13:07 -0400

Charles,

Again, I don't necessarily disagree with this... just trying to
make sure that I've given a correct statement of the situation
and options (in case we are asked later) and that everyone
understands those options and their implications.

On the other hand, if we believe it is now safe to send 8bit
message bodies without any SMTP extensions, it may be a little
ironic that we just published RFC 6152, moving 8BITMIME and its
restrictions to Full Standard.  

It does suggest a possibly-odd intermediate position that the WG
might consider:

	Case 1 Main message headers contain 8bit material:
	UTF8SMTPbis and 8BITMIME required regardless of the
	contents of any MIME headers.
	
	Case 2: Main message headers are entirely ASCII, but some
	MIME headers contain 8bit material: UTF8SMTPbis possibly
	preferred, but not required (i.e., possibly SHOULD,
	perhaps MAY); 8BITMIME required.
	
	Case 3: Neither main message headers nor MIME headers
	contain 8bit material:  Not Our Problem.

Put differently, rather than implicitly changing the definition
of message/rfc822 to permit non-ASCII material in embedded
headers, we implicitly change the definition of 8BITMIME to
permit non-ASCII in MIME headers that are not the main message
headers.   Its advantage is that it takes a half-step beyond
your analysis by noticing that, if the server asserts 8BITMIME
is available and the client responds by specifying
BODY=8BITBIME, we pretty much know that both are sufficiently
8bit-capable that trashing or rejecting an 8bit body part header
would require extra effort and represent either really
compulsive standards-enforcement or generally perverse behavior.

Note that characterization does not have any special interaction
with message/global, message/rfc822, etc.  It would apply
equally well to, e.g.,  multipart/mixed and some MIME body part
header with a non-ASCII content-disposition field.  And it still
doesn't address the problem of forwarding an encapsulated
message that contains non-ASCII headers to a system with no
apparent 8bit capability at all (i.e., not even 8BITMIME is
advertised by the server).

Anyone want to advocate that one as an intermediary position?

   john

--On Monday, March 14, 2011 12:25 +0000 Charles Lindsey
<[email-masked]> wrote:

>> (2)  5322 repeats the ASCII restriction (Section 2.2 and
>> syntax) as does the RFC2045 version of the MIME spec.   If
>> one is going to have raw (not ACE, encoded-word, or, in the
>...
>> I'm too paranoid, and have seen too much damage, to believe
>> that the latter is a good idea.  But maybe that is just me.
 
> Broadly I agree with that, but it is arguable that "just
> sending-8" in the body may well work in practice. Servers are
> in general notorious for doing nasty/stupid things to headers,
> but hardly ever do anything to bodies beyond perhaps changing
> CTEs. I believe all widely used servers are now in practice
> 8-bit clean in bodies.
> 
> So it may be a reasonable risk to do things slightly in
> violation of the MIME standards, as regards headers contained
> within multiparts within bodies, using just an 8BITMIME
> restriction rather than the more difficult UTF8SMTPbis
> restriction.
> 
> Or you could say that if Ned thinks some small violation of
> MIME should be permitted, then we should go ahead and do it.

---

From: Tony Hansen <[email-masked]>
Date: Mon, 14 Mar 2011 11:16:00 -0400

> the latter is a good idea.  But maybe that is just me.

You are not alone. I also feel that the latter is not a good idea.

     Tony Hansen
     [email-masked]

---

From: John Levine <[email-masked]>
Date: 14 Mar 2011 15:26:14 -0000

>Anyone want to advocate that one as an intermediary position?

Sounds right to me, ensures that the server can accept the bits that
the client is sending.  A sufficiently broken implementation could
still lose the message at a later gateway, but there's nothing we
can do about that.

R's,
John