Subject: [EAI] I-D Action:draft-ietf-eai-smtpext-10.txt

From: [email-masked]
Date: Mon, 07 Jan 2008 02: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           : SMTP extension for internationalized email address
	Author(s)       : J. Yao, W. MAO
	Filename        : draft-ietf-eai-smtpext-10.txt
	Pages           : 22
	Date            : 2008-01-07

This document specifies an SMTP extension for transport and delivery
of email messages with internationalized email addresses or header
information.  Communication with systems that do not implement this
specification is specified in another document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-10.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-smtpext-10.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-smtpext-10.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: "Charles Lindsey" <[email-masked]>
Date: Tue, 08 Jan 2008 14:23:49 -0000

> 	Filename        : draft-ietf-eai-smtpext-10.txt

I am confused.

This draft states:

    If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP
    client MUST NOT transmit an internationalized address and MUST NOT
    transmit a mail message which contains containing internationalized  
mail headers as
    described in [EAI-utf8header] at any level within its MIME structure.
    Instead, if an SMTP client (SMTP sender) attempts to transfer a UTF8SMTP
    internationalized message and encounters a server that does not
    support the extension, it MUST make one of the following four
    choices:

This seems to state, quite clearly, that a non-UTF8SMTP server, even if it  
supports 8BITMIME, MUST NOT transmit a message containing a  
message/global. IOW it MUST NOT violate that EXPRESSLY FORBIDDEN in RFC  
2045.

If this is what it means then, of course, I Approve. But in that case it  
is inconsistent with utf8headers, which explicitly allows them and permits  
them to be encoded in Base64 or Q-P. And it is inconsistent with our DSN  
draft for the same reason.

A couple of further niggles.

It still uses the ABNF rule <UTF8-xtra-char>. I thought we had agreed to  
change this to <UTF8-non-ascii> (this change is also not yet in the  
utf8headers draft).

And I also find the words:

    If a normal success response (i.e., 250) response is returned, the  
response
    MAY include the full name of the user and MUST include the mailbox of
    the user.  It MUST be in either of the following forms:

          User Name <uMailbox>
             ; uMailbox is defined in section 2.3 of this document
             ; User Name allows the can contain non-ASCII character.  
characters.

          uMailbox
             ; uMailbox is defined in section 2.3 of this document

It uses the word "either", but I don't see two things between which I am  
supposed to choose.

-- 
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: "YAO Jiankang" <[email-masked]>
Date: Wed, 9 Jan 2008 09:45:18 +0800

----- Original Message ----- 
From: "Charles Lindsey" <[email-masked]>
To: "IMA" <[email-masked]>
Sent: Tuesday, January 08, 2008 10:23 PM
Subject: Re: [EAI] I-D Action:draft-ietf-eai-smtpext-10.txt 

> message/global.
> IOW it MUST NOT violate that EXPRESSLY FORBIDDEN in RFC  
> 2045.
> 
> is inconsistent with utf8headers,

according to the definition of section 4.6 of utf8header document, 
A message is a "message/global message", if
   o  it contains UTF-8 header values as specified in this document, or
   o  it contains UTF-8 values in the headers fields of body parts.

section 4.6 also said that "  Internationalized messages must only be transmitted as authorized by
   [EAI-SMTP-extension] or within a non-SMTP environment which supports
   these messages. " So it means that if uf8header document allows message/global, it will follow the specification in EAI smtpxet document.

IMO, it is still consistent with utf8header document.

>which explicitly allows them and permits  
> them to be encoded in Base64 or Q-P. 

I do not think that utf8header document clearly permit the message/global to be encoded in Base64 or Q-P.
utf8header document  try to authorize the utf8 header instead of base64 or Q-P.

>And it is inconsistent with our DSN  

I am not sure.

Alexey Melnikov or Chris may have more comments on it.

> change this to <UTF8-non-ascii> (this change is also not yet in the  

if nobody object it, I will use UTF8-non-ascii in next version. (Thanks :))

> It uses the word "either", but I don't see two things between which I am  

option 1: you choose:  User Name <uMailbox>

option 2: you choose :  uMailbox

is my understanding right?

Thanks a lot and Happ new year
YAO Jiankang
CNNIC

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 9 Jan 2008 12:05:15 +0100

YAO Jiankang wrote:

>>| client MUST NOT transmit an internationalized address and MUST NOT
>>| transmit a mail message which contains containing internationalized  
>>| mail headers as described in [EAI-utf8header] at any level within
>>| its MIME structure.

>> This seems to state, quite clearly, that a non-UTF8SMTP server, even
>> if it supports 8BITMIME, MUST NOT transmit a message containing a  
>> message/global.

But that would be very wrong.  It's nobody's business what MIME parts
an ordinary 8bit message/rfc822 contains as long as they are 8BITMIME
compatible.  One or more of these parts can be message/global objects
with UTF-8 in their header.  Only 8bit to 7bit gateways need to worry
about non-ASCII octets.  UTF8SMTP to 8BITMIME gateways can ignore it.

>    o  it contains UTF-8 values in the headers fields of body parts.

The second clause is dubious.  UTF-8 characters are not allowed in a
MIME part header for MIME version 1.0.  An "experimental MIME update"
allowing it, if this survives the IETF Last Call, but I hope it won't,
would force poor UTF8SMTP to 8BITMIME gateways to look into MIME part
headers, where they'll find many variations of what's best described
as garbage.  At that point they are forced to reject the dubious mail,
and this could kill the whole EAI effort only because "we" (= not me)
tried to "improve" MIME part headers.

> IMO, it is still consistent with utf8header document.

Please make it also consistent with MIME.  You don't want "any level
within its MIME structure".  The internal structure of a message/???
embedded in the top level message is opaque, no matter if a gateway
happens to know a few ??? subtypes like rfc822, global, news, etc.,
or not.  For embedded messages the point is to catch non-ASCII octets
not allowed for 7bit in the case of an 8bit to 7bit gateway.  IMO an
UTF8SMTP to 8BITMIME gateway isn't the same as 8bit to 7bit.  If the
top level message is no message/global it must be a message/rfc822,
embedded message objects of any subtype can't change this decision.

> I do not think that utf8header document clearly permit the 
> message/global to be encoded in Base64 or Q-P.

Yes, I think that is limited to emergencies when trying to send a
DSN to a message/global sender, who somehow managed to have still
some 7bit-only reverse routes.

 Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 09 Jan 2008 12:02:38 -0000

>    o  it contains UTF-8 values in the headers fields of body parts.

Yes, it is the first of those cases we should focus upon. It seems that  
smtpext will not allow you to transmit a message containing an attachment  
of that form to a non-UTF8SMTP system.
>    these messages. " So it means that if uf8header document allows  
> message/global, it will follow the specification in EAI smtpxet document.
>

But confusing, since it implies you may send such messages if  
[EAI-SMTP-extension] allows it, in the full knowledge that  
[EAI-SMTP-extension] does not.
> utf8header document  try to authorize the utf8 header instead of base64  

utf8headers says:

    The type message/global is similar to message/rfc822, except that it
    contains a message that can contain UTF-8 characters in the headers
    of the message or body parts.  If this type is sent to a 7-bit-only
    system, it has to be encoded in [RFC2045]. ...

That surely means encoding in Base64 or Q-P?

    (Note that a system
    compliant with MIME that doesn't recognize message/global would treat
    it as "application/octet-stream" as described in Section 5.2.4 of
    [RFC2046].)

And of course my position has always been that that sentence is a  
misreading of 5.2.4 of [RFC2046], and that in any case a large number of  
current MTAs will not treat it that way.

> Alexey Melnikov or Chris may have more comments on it.

Indeed.

> option 2: you choose :  uMailbox

OK, I see it now.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 17 Jan 2008 21:23:33 +0100

Charles Lindsey skrev:
> message/global. IOW it MUST NOT violate that EXPRESSLY FORBIDDEN in
> RFC 2045.
>
> If this is what it means then, of course, I Approve. But in that case
> it is inconsistent with utf8headers, which explicitly allows them and
> permits them to be encoded in Base64 or Q-P. And it is inconsistent
> with our DSN draft for the same reason. 
It was intended to say that the structure

Content-type: multipart/mixed

  Content-type: text/plain
  Content-description: <Unencoded UTF-8>

is illegal to send, but that the structure

Content-type: multipart/mixed

  Content-type: message/global
  Content-transfer-encoding: base64

    (base64-encoding of)
       Subject: <Unecoded UTF-8>
   (end base64-encoding)

is completely legal to send.

One way to describe it is that the stuff that's inside a
content-transfer-encoding, or where a content-transfer-encoding can be
applied, has ceased being part of the message's MIME structure; the MIME
processor no longer cares about its headers, only about whether or not
the part conforms to the 7-bit, 8-bit or binary formats.

I'm not sure what words to use to make this distinction obvious.

                    Harald

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 18 Jan 2008 04:29:21 +0100

> I'm not sure what words to use to make this distinction obvious.

Should I try the "2045 erratum" approach ?  The "new" (proposed)
rules for errata apparently require AD verification for IETF RFCs.

See http://article.gmane.org/gmane.ietf.ima/2150 (we're at 2370)

 Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 19 Jan 2008 15:13:26 -0000

> is illegal to send, but that the structure

But it does not say that, since it is only prohibiting "internationalized  
mail headers" in certain contexts (though I am sure there is text  
elsewhere in the drafts to prohibit your example).
> is completely legal to send.

Yes, it permits that, but it PROHIBITS

    Content-type: message/global
    Content-transfer-encoding: 8bit

         Subject: <Unencoded UTF-8>

to be sent to a server that does not support UTF8SMTP (but presumably does  
support 8BITMIME).

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 21 Jan 2008 10:11:02 +0100

Charles Lindsey wrote:
> But it does not say that, since it is only prohibiting 
> "internationalized mail headers" in certain contexts (though I am sure 
> there is text elsewhere in the drafts to prohibit your example).
in what way is "content-description: <Unencoded UTF-8>" not an 
internationalized mail header?
> to be sent to a server that does not support UTF8SMTP (but presumably 
> does support 8BITMIME). 
I believe that if the text can be interpreted that way, it is a problem 
with the text.

                    Harald