Re: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply

["YAO Jiankang" <yaojk at cnnic.cn>]

----- Original Message ----- 
From: "Chris Newman" <Chris.Newman at Sun.COM>
To: "Kari Hurtta" <hurtta+gmane at siilo.fmi.fi>; <ima at ietf.org>
Sent: Tuesday, June 19, 2007 12:49 AM
Subject: Re: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply


>For SMTP, allowing UTF-8 in error responses opens a can of worms.

>SMTP error response text needs to be comprehensible by:
>* An arbitrary remote system administrator
>* The local system administrator
>* The end-user
>Probably in that priority order (although that's debatable and may be different 
>for SUBMIT).  That means SMTP response text may have to be in more than one 
>language and guidance needs to be provided for language selection.

>I would not consider a document allowing UTF-8 in response text complete unless 
>dodges this issue (e.g., by only allowing UTF-8 in addresses) or confronts this 
>issue.

Dear Chris,

We would like to add one sentence in this section: 
"UTF-8 is needed to represent email addresses in responses. This extension does
not authorize the use of UTF-8 for any other purpose".

is it ok for you?


YAO Jiankang
CNNIC





>                - Chris

Kari Hurtta wrote on 6/16/07 9:29 +0300:

> Harald Tveit Alvestrand <harald at alvestrand.no> writes in gmane.ietfima:
>
>> The following tickets are open on the EAI issue tracker:
>>
>> 1483 SMTPEXT 2.7: Non-ASCII in response texts Text proposed in -06, no
>> later discussion.
>
> I suggest small change to text. Change here is on diff format.
> Dicussion follows.
>
> ---------------------------------------------------------------------------
> --- draft-ietf-eai-smtpext-06.txt 2007-06-05 06:40:53.000000000 +0300
> +++ draft-ietf-eai-smtpext-06.txt--1483 2007-06-16 09:16:28.000000000 +0300
> @@ -600,18 +600,26 @@
>     MUST be transmitted in the form of ACE labels.  The protocol value of
>     the WITH clause is UTF8SMTP when this extension is used.  More
>     information is in the "IANA Considerations" section of this document.
>
>  2.7.4.  UTF-8 Reply
>
> -   If the client issues the "RCPT" command which contains non-ASCII
> +   If the client issues the RCPT command which contains non-ASCII
>     characters, the SMTP server is permitted to use UTF-8 characters
>     within 251 and 551 response codes.  Servers MUST NOT include non-
>     ASCII characters except in the limited cases specifically permitted
> -   in this section.
> +   in this section. The SMTP client following this specification MUST
> +   accept UTF-8 on replies of the RCPT command on that case.
>
> +   If SMTP reply requires UTF-8, but SMTP client does not use
> +   RCPT command which contains non-ASCII characters, the response
> +   code 250 meaning "OK"  or 550 meaning "Requested action not taken:
> +   mailbox unavailable" is used.  When response codes 250 and 550 is
> +   used on place of 251 and 551 response codes, response do not include
> +   new mailbox. If enhanced mail system status code [RFC3463]
> +   is used,  response codes given on below is used.
>
>
>  Yao & Mao               Expires December 8, 2007               [Page 11]
>  
>  Internet-Draft                     EAI                         June 2007
>
> @@ -627,28 +635,26 @@
>     is included in it and therefore UTF-8 is not needed.  UTF8REPLY
>     parameter on the VRFY and EXPN commands tells the SMTP server that
>     the client is prepared for UTF-8 on SMTP replies.
>
>     VERIFY (VRFY) and EXPAND (EXPN)command syntaxes are changed to:
>
> -       "VRFY" SP uAtom [SP "UTF8REPLY"] CRLF;
> -              ;uAtom is defined in section 2.3 of this document
> +       "VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF;
> +              ;uLocal-part and uMailbox is defined in section 2.3 of this
> document
> -       "EXPN" SP uAtom [SP "UTF8REPLY"] CRLF;
> -              ;uAtom is defined in section 2.3 of this document
> +       "EXPN" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF;
> +              ;uLocal-part and uMailbox is defined in section 2.3 of this
> document
>     This parameter "UTF8REPLY" does not have value.  If SMTP reply
>     requires UTF-8, but SMTP client does not use "UTF8REPLY" parameter in
> -   the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code "252"
> +   the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code 252
>     is used, defined in [RFC2821], meaning "Cannot VRFY user, but will
> -   accept the message and attempt the delivery".  If enhanced mail
> -   system status code [RFC3463] is used, the response code should be
> -   "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The UTF-8 reply
> -   required, but the UTF8REPLY parameter not used.". [[anchor13: REMOVE
> -   THIS: IANA please assign the proper error codes for "5.6.y" and
> -   "2.6.y".]]  "UTF8REPLY" on the VERIFY (VRFY) or EXPAND (EXPN)
> +   accept the message and attempt the delivery". Also response code 550
> +   may be used, meaning "Requested action not taken: mailbox unavailable".
> +   If enhanced mail system status code [RFC3463] is used, response codes
> +   given on below is used. "UTF8REPLY" on the VERIFY (VRFY) or EXPAND (EXPN)
>     commands enables UTF-8 for that command only.
>
>     The uAtom of the VRFY and EXPN commands is a user name or a user name
>     and a domain (see below).  If a normal (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
> @@ -658,12 +664,20 @@
>                  ; uMailbox is defined in section 2.3 of this document
>                  ; User Name allows the non-ASCII character.
>
>           uMailbox
>                  ; uMailbox is defined in section 2.3 of this document
>
> +
> +   If SMTP reply requires UTF-8, but UTF-8 is not allowed on reply,
> +   and enhanced mail system status code [RFC3463] is used,
> +   the response code should be  "5.6.y" or "2.6.y" [SMTP-codes],
> +   meaning that "The UTF-8 reply required, but not allowed.".
> +   [[anchor13: REMOVE THIS: IANA please assign the proper error codes
> +   for "5.6.y" and "2.6.y".]]
> +
>     If the SMTP Client lack of the UTF8SMTP support receives the UTF-8
>     message on reply, it may crash.  UTF-8 messages on reply are only
>     allowed in the commands under the situations described above.  Under
>
>
>
>
> ---------------------------------------------------------------------------
>
> Discussion:
>
> 1)
>
> SMTP client needed to be required to accept UTF-8 also on RCPT response.
>
> 2)
>
> 251  response with UTF-8 mailbox can be replaced with 250 response.
> 250 response does not include new address.
>
> Instead of
>
>         RCPT TO:<support at example.com>
>         251 2.1.5 New address is <käyttäjätuki@@example.com>, will forward
>
> use
>
>         RCPT TO:<support at example.com>
>         250 2.6.y Address is changed, will forward
>
>
> Of course 251 can not replaced with 550 because that recipient is accepted.
> Therefore 250 is correct response code.
>
> 3)
>
> --- start quote --
> This parameter "UTF8REPLY" does not have value. If SMTP reply
> requires UTF-8, but SMTP client does not use "UTF8REPLY" parameter in
> the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code "252"
> is used, defined in [RFC2821], meaning "Cannot VRFY user, but will
> accept the message and attempt the delivery". If enhanced mail
> system status code [RFC3463] is used, the response code should be
> "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The UTF-8 reply
> required, but the UTF8REPLY parameter not used.".
> --- end quote ---
>
> Here is problem that that talks only response code "252", but
> enchanced response codes talk both "5.6.y" and "2.6.y".
>
> These "5.6.y" and "2.6.y" are fine -- these should NOT removed.
>
> Problem is that these enchanced response codes now apply only
> to VERIFY and EXPAND. My original text these apply also to
> RCPT command.
>
> On that change effectively
>    ``If enhanced mail
>      system status code [RFC3463] is used, the response code should be
>      "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The UTF-8 reply
>      required, but the UTF8REPLY parameter not used."??
> is moved just to new chapter so that it applies to RCPT
> -command also. menaing text is also of course change, because
> RCPT command here did not taken UTF8REPLY paramater.
>
> 4)
>
> Limiting VRFY and EXPN to uAtom is very restrictive.
>
> RFC 2821 quote: ------------------------------
>
>
>    "User name" is a fuzzy term and has been used deliberately.  An
>    implementation of the VRFY or EXPN commands MUST include at least
>    recognition of local mailboxes as "user names".  However, since
>    current Internet practice often results in a single host handling
>    mail for multiple domains, hosts, especially hosts that provide this
>    functionality, SHOULD accept the "local-part at domain" form as a "user
>    name"; hosts MAY also choose to recognize other strings as "user
>    names".
> ---- end RFC 2821 quote -------------------------------
>
>
> uAtom do not accept "@domain" which is "SHOULD" on RFC 2821.
>
> With suggested syntax it roughly matches with RFC 2821 text.
>
>
> Yes, actual syntax on RFC 2821 is somewhat conflict with
> this:
>
> RFC 2821 quote: ------------------------------
> 4.1.1.6 VERIFY (VRFY)
>
>    This command asks the receiver to confirm that the argument
>    identifies a user or mailbox.  If it is a user name, information is
>    returned as specified in section 3.5.
>
>    This command has no effect on the reverse-path buffer, the forward-
>    path buffer, or the mail data buffer.
>
>    Syntax:
>       "VRFY" SP String CRLF
>
> 4.1.1.7 EXPAND (EXPN)
>
>    This command asks the receiver to confirm that the argument
>    identifies a mailing list, and if so, to return the membership of
>    that list.  If the command is successful, a reply is returned
>    containing information as described in section 3.5.  This reply will
>    have multiple lines except in the trivial case of a one-member list.
>
>    This command has no effect on the reverse-path buffer, the forward-
>    path buffer, or the mail data buffer and may be issued at any time.
>
>    Syntax:
>       "EXPN" SP String CRLF
>
> ---- end RFC 2821 quote -------------------------------
>
> Where String seems to be
>
>          String = Atom / Quoted-string
>
>
>
> ( And anyway uAtom do not cover Quoted-string which is allowed on
>   String ).
>
> Seems that  RFC 2821 is mess on here also :-(
>
>
> / Kari Hurtta
>
>
>
> _______________________________________________
> IMA mailing list
> IMA at ietf.org
> https://www1.ietf.org/mailman/listinfo/ima
>






_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima