Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-08.txt

From: [email-masked]
Date: Tue, 04 Sep 2007 15:15:01 -0400

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-08.txt
	Pages		: 20
	Date		: 2007-9-4
	
This document specifies the use of SMTP extension for
   internationalized email address delivery.  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-08.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-08.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-08.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: SM <[email-masked]>
Date: Wed, 12 Sep 2007 10:51:54 -0700

>         Title           : SMTP extension for internationalized email address

In Section 2.2.  The UTF8SMTP Extension:

   "3.  Find an alternate route to the destination that permits UTF8SMTP.
        That route may be discovered by trying alternate MX hosts (using
        preference rules as specified in RFC 2821) or using other means
        available to the SMTP-sender."

The receiver publishes MX records to indicate which MX hosts will be 
handling mail for the domain and the order in which they should be 
tried (preference).  The rules are described in Section 5.1 of RFC 
2821.  The "or using other means available to the SMTP-sender" 
introduces a rule for the sender to sidestep that.  I suggest 
dropping that to keep the behavior in line with RFC 2821 and having 
that paragraph as:

    3.  Find an alternate route to the destination that permits UTF8SMTP.
        That route may be discovered by trying alternate MX hosts according
        to the preference rules specified in RFC 2821.

Note that the rule prescribes that all records at that preference 
level and higher-numbered ones MUST be discarded from consideration.

In Section 2.5.  ALT-ADDRESS parameter usage and response codes:

   "When messages are rejected because they require UTF8SMTP, the
    response code "550" is used, defined in [RFC2821], meaning "mailbox
    unavailable".  If enhanced mail system status codes [RFC3463] are"

Shouldn't that be a "553", i.e. mailbox name not allowed?

If the SMTP server does not advertize the UTF8SMTP extension, I don't 
see how we are getting to the stage where we get that response code 
as we cannot use the ALT-ADDRESS parameter in the MAIL FROM or RCPT 
TO unless we ignore the absence of UTF8SMTP  support.

Regards,
-sm

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 14 Sep 2007 16:14:17 +0800

----- Original Message ----- 
From: "SM" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 13, 2007 1:51 AM
Subject: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt 

>        to the preference rules specified in RFC 2821.

good text. We will consider to update it.

> Shouldn't that be a "553", i.e. mailbox name not allowed?

In my view, both "553" and "550" are ok.

> TO unless we ignore the absence of UTF8SMTP  support.

I still can not understand what is your meaning above very clearly.
Could you help me being understood?
it means that
 If the SMTP server does not advertize the UTF8SMTP extension and  there is no ALT-ADDRESS parameter in the MAIL FROM or RCPT , 
how we get the response code?

Thanks a lot.

YAO Jiankang
CNNIC

---

From: John C Klensin <[email-masked]>
Date: Fri, 14 Sep 2007 04:33:33 -0400

--On Wednesday, 12 September, 2007 10:51 -0700 SM
<[email-masked]> wrote:

> The receiver publishes MX records to indicate which MX hosts
> will be handling mail for the domain and the order in which
> they should be tried (preference).  The rules are described in
> Section 5.1 of RFC 2821.  The "or using other means available
> to the SMTP-sender" introduces a rule for the sender to
> sidestep that.  I suggest dropping that to keep the behavior
> in line with RFC 2821 and having that paragraph as:
> 
> Note that the rule prescribes that all records at that
> preference level and higher-numbered ones MUST be discarded
> from consideration.

Careful...  2821 is _very_ careful about this.  Once any host in
the preference list receives the mail, it is responsible for
delivery, etc., but using SMTP and following the preference
rules is only one of the options available to it.  It is free to
move the mail toward the final destination using any method it
likes, including ocpying it to small pieces of paper and sending
out a flock of pigeons.  EAI-smtpext should not be more
restrictive, IMO.

> If the SMTP server does not advertize the UTF8SMTP extension,
> I don't see how we are getting to the stage where we get that
> response code as we cannot use the ALT-ADDRESS parameter in
> the MAIL FROM or RCPT TO unless we ignore the absence of
> UTF8SMTP  support.

Correct, I believe.

    john

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 14 Sep 2007 11:54:11 +0200

SM wrote:
> see how we are getting to the stage where we get that response code as 
> we cannot use the ALT-ADDRESS parameter in the MAIL FROM or RCPT TO 
> unless we ignore the absence of UTF8SMTP  support.

If the SMTP server does not advertise the UTF8SMTP extension, none of 
the procedures described in this document apply; the sender has to 
follow the rules of 2821, and may choose to apply the provisions of the 
-downgrade document in order to get a message that can be sent under 
those rules.

                    Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 14 Sep 2007 12:23:31 +0200

SM wrote:
> consideration.
oops - I misunderstood.

you can get into this situation if the SMTP server advertises the 
UTF8SMTP extension, but knows that it may have to forward the message to 
some other system that does not support UTF8SMTP - for instance, it may 
have a local IMAP server that doesn't support UTF8SMTP, but have a local 
POP server that does - so for a POP recipient, UTF8SMTP-requiring mails 
would be OK, but for an IMAP recipient, it would have to reject them.

Other situations are surely imaginable.

                Harald

---

From: SM <[email-masked]>
Date: Fri, 14 Sep 2007 11:43:30 -0700

At 01:14 14-09-2007, YAO Jiankang wrote:
>  If the SMTP server does not advertize the UTF8SMTP extension 
> and  there is no ALT-ADDRESS parameter in the MAIL FROM or RCPT ,

What I meant was that if the SMTP server does not have UTF8SMTP 
support, then a compliant SMTP client won't try using the ALT-ADDRESS 
parameter in MAIL FROM or RCPT TO.

If the SMTP client is using ALT-ADDRESS (I'm still talking about SMTP 
server mentioned above), then it is not compliant with RFC 
2821.  Quoting Section 4.1.1.3 (RCPT) of RFC 2821:

   "If service extensions were negotiated, the RCPT command may also
    carry parameters associated with a particular service extension
    offered by the server.  The client MUST NOT transmit parameters other
    than those associated with a service extension offered by the server
    in its EHLO response."

Any response code given for such a case would fall under RFC 2821 
then instead of eai-smtpext.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Fri, 14 Sep 2007 13:21:38 -0700

>out a flock of pigeons.  EAI-smtpext should not be more

My point is that EAI-smtpext should defer to RFC 2821 when it comes 
to dealing with the preference list.  Any host in the preference list 
taking responsibility for a message is free to do what it deems 
necessary to get the mail to its destination.

At 03:23 14-09-2007, Harald Alvestrand wrote:
>UTF8SMTP extension, but knows that it may have to forward the 
>message to some other system that does not support UTF8SMTP - for 
>instance, it may have a local IMAP server that doesn't support 
>UTF8SMTP, but have a local POP server that does - so for a POP 
>recipient, UTF8SMTP-requiring mails would be OK, but for an IMAP 
>recipient, it would have to reject them.

Thanks for the explanation.  I suggest the following change in line 
with the above:

    When the address is rejected because the mailbox does not support UTF8SMTP,
    the response code "553" is used, defined in [RFC2821], meaning 
"mailbox name
    not allowed".  If enhanced mail system status codes [RFC3463] are used,
    the response code should be "5.6.x" [SMTP-codes], meaning that
    "The alt-address is required but not specified".

In my opinion, "mailbox does not support UTF8SMTP" covers the case 
where the system where the message will be forwarded to doesn't 
support UTF8SMTP.  If it is not clear, we could have:

  "because of lack of UTF8SMTP support (e.g. mailbox or destination 
does not support
   UTF8SMTP"

The mailbox will be allowed if an alt-address is specified.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Fri, 14 Sep 2007 18:06:08 -0400

--On Friday, 14 September, 2007 13:21 -0700 SM <[email-masked]>
wrote:

>> Careful...  2821 is _very_ careful about this.  Once any host
>> in the preference list receives the mail, it is responsible
>> for delivery, etc., but using SMTP and following the
>> preference rules is only one of the options available to it.
>> It is free to move the mail toward the final destination
>> using any method it likes, including ocpying it to small
>> pieces of paper and sending out a flock of pigeons.
>> EAI-smtpext should not be more restrictive, IMO.
> 
> My point is that EAI-smtpext should defer to RFC 2821 when it
> comes to dealing with the preference list.  Any host in the
> preference list taking responsibility for a message is free to
> do what it deems necessary to get the mail to its destination.

Agreed.  I can see no reason why smtpext should handle this case
differently from the SMTP norm.
 
     john

---

From: "YAO Jiankang" <[email-masked]>
Date: Sun, 30 Sep 2007 10:52:53 +0800

----- Original Message ----- 
From: "SM" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 13, 2007 1:51 AM
Subject: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt 

> Shouldn't that be a "553", i.e. mailbox name not allowed?

After discussion with some editors, we suggest the following text:

when messages are rejected because the RCPT TO requires an ALT-ADDRES, the response code 553 is used. When messages are rejected for other reasons, such as MAIL FROM requiring an ALT-ADDRESS, the response code 550 is used.

any further refinements?

YAO Jiankang
CNNIC