Subject: [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt

From: [email-masked]
Date: Mon, 29 Jan 2007 15:50:02 -0500

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		: International Delivery and Disposition Notifications
	Author(s)	: C. Newman
	Filename	: draft-ietf-eai-dsn-00.txt
	Pages		: 17
	Date		: 2007-1-29
	
   Delivery status notifications (DSNs) are critical to the correct
   operation of an email system.  However, the existing draft standard
   is presently limited to US-ASCII text in the machine readable
   portions of the protocol.  This specification adds a new address type
   for international email addresses so an original recipient address
   with non-US-ASCII characters can be correctly preserved even after
   downgrading.  This also provides updated content return media types
   for delivery status notifications and message disposition
   notifications to support use of the new address type.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-eai-dsn-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-eai-dsn-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Tony Finch <[email-masked]>
Date: Wed, 31 Jan 2007 02:20:57 +0000

> 	Filename	: draft-ietf-eai-dsn-00.txt

MIME forbids the encoding of message/* parts, so a message/utf-8 part
would have to be downgraded instead. Note that new message/* parts inside
8bit messages will cause problems for existing 8BITMIME downgraders.

I did wonder why text/rfc822-headers was not message/rfc822-headers, so I
think the introduction of message/utf-8-headers is an improvement. The
caveats about downgrading instead of encoding apply here too.

The message/utf-8-delivery-status and -disposition-notification types will
also need to be downgraded to their 7bit originals in some cases. This can
probably be done fairly easily using the utf-8-enc address type. However
there remains the problem of how to handle utf-8 SMTP response texts (if
they become permitted) in DSNs.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL MALIN HEBRIDES BAILEY: SOUTHWEST 7 TO SEVERE GALE 9, LATER DECREASING
5 OR 6. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. OCCASIONAL RAIN. MODERATE OR
GOOD.

---

From: Kari Hurtta <[email-masked]>
Date: 31 Jan 2007 17:41:13 +0200

> caveats about downgrading instead of encoding apply here too.

For unknown text/*  types there is on MIME default that they should displayed
as text/plain. Other unknown types is required to be treated as
application/octet-stream.

Therefore text/rfc822-headers makes sense. 

/ Kari Hurtta

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 31 Jan 2007 17:43:57 -0000

> 8bit messages will cause problems for existing 8BITMIME downgraders.

Not quite. In fact I see no such generic rule for all of message/*.

For message/rfc822, it states that the encoding must be 7bit, 8bit or  
binary, but if you look closely this only applies to the headers (at any  
depth of contained multiparts), since those headers can still specify Q-P  
or Base64 for the body parts under their control (but if those headers  
specify 8bit or binary, then the message/rfc822 as a whole must be at  
least 8bit or binary). It is all horribly described, but that seems to be  
the intent.

All of which means that it IS possible, with care, to downgrade a  
message/rfc822 both for 8BITMIME and for UTF8SMTP purposes (and, for  
example, sendmail seems to do the former correctly).

What is more of a problem is downgrading other (possibly not yet even  
defined) message/* subtypes. It turns out, AFAICS, that all of the ones so  
far known to IANA will survive being treated in the same way as  
message/rfc822, either because downgrading can never be needed, or because  
their structure is sufficiently similar (for example, message/partial  
would work in practice even if someone broke the restrictions on what you  
are supposed to do there). So the Perl script I recently published made  
that assumption, and so did the one I wrote to show how a message could be  
canonicalized for DKIM purposes.

But it is always possible that someone someday will invent a message  
subtype where this does not work, and then any machinery already written  
(e.g. to check whether a given message requires UTF8SMTP or not) might  
suddenly fail to work. Fortunately, multipart subtypes are all guaranteed  
to obey the same basic structure, so no corresponding problem there.
> caveats about downgrading instead of encoding apply here too.

I would find it odd if DSN used text/something for ordinary email and  
message/something for UTF8SMTP mail, but I have not had time to read the  
latest draft yet.

-- 
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: Tony Finch <[email-masked]>
Date: Wed, 31 Jan 2007 18:06:02 +0000

> Not quite. In fact I see no such generic rule for all of message/*.

The following extracts from RFC 2046 cover the encodings of all the
possible message/* subtypes.

5.2.1.  RFC822 Subtype

   No encoding other than "7bit", "8bit", or "binary" is permitted for
   the body of a "message/rfc822" entity.

5.2.2.  Partial Subtype

   entities of type "message/partial" must always have a content-
   transfer-encoding of 7bit (the default).  In particular, even in
   environments that support binary or 8bit transport, the use of a
   content- transfer-encoding of "8bit" or "binary" is explicitly
   prohibited for MIME entities of type "message/partial". This in turn
   implies that the inner message must not use "8bit" or "binary"
   encoding.

5.2.3.  External-Body Subtype

   As with "message/partial", MIME entities of type "message/external-
   body" MUST have a content-transfer-encoding of 7bit (the default).
   In particular, even in environments that support binary or 8bit
   transport, the use of a content- transfer-encoding of "8bit" or
   "binary" is explicitly prohibited for entities of type
   "message/external-body".

5.2.4.  Other Message Subtypes

   MIME implementations must in general treat unrecognized subtypes of
   "message" as being equivalent to "application/octet-stream".

   Future subtypes of "message" intended for use with email should be
   restricted to "7bit" encoding. A type other than "message" should be
   used if restriction to "7bit" is not possible.

> depth of contained multiparts), since those headers can still specify
> Q-P or Base64 for the body parts under their control (but if those
> headers specify 8bit or binary, then the message/rfc822 as a whole must
> be at least 8bit or binary). It is all horribly described, but that
> seems to be the intent.

message/rfc822 works the same way as multipart/* in that the CTE of the
part itself only applies to that one layer of nesting and nested sub-parts
have their own CTEs. It makes perfect sense if you consider the double
encoding that would result if a multipart attachment were encoded, and the
hoops a MIME handler would have to leap through to find boundaries.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY FITZROY: EAST OR NORTHEAST 3 OR 4. MODERATE, OCCASIONALLY SLIGHT IN
BISCAY. OCCASIONAL RAIN IN SOUTH BISCAY. GOOD, OCCASIONALLY MODERATE IN SOUTH
BISCAY.

---

From: Chris Newman <[email-masked]>
Date: Wed, 31 Jan 2007 15:37:59 -0800

> 8bit messages will cause problems for existing 8BITMIME downgraders.

MIME only forbids message encodings for the message subtypes it defines, no 
normative restrictions are placed on other message subtypes.  If one of the 
functions of this experiment is to make email UTF-8 clean, then the advisory 
text in section 5.2.4 of RFC 2046 does not apply to the documents in this 
experiment.

> they become permitted) in DSNs.

Downgrading message/utf-8-delivery-status to message/delivery-status is a bad 
idea, IMHO.  It's not going to break anything if you leave it alone and it will 
lose information if downgraded.  It's a lot simpler to upgrade the few 
automated message/delivery-status processors to support utf-8-delivery-status 
than to add downgrade code to every MTA.  Bounce processing engines already 
have to deal with bounce messages in non-standard formats, so a new standard 
format is not a big change.  Encoding with QP or base64 is fine if necessary.

FYI, Alexey is working on an individual submission adding the SMTP LANG 
extension so clients can request localized SMTP error text.

                - Chris