Subject: [EAI] EDITORIAL: draft-ietf-eai-smtpext-08.txt

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Sep 2007 10:56:10 +0100

Hi,

Most of the issues below are editorial, some of them can be considered 
nitpicking.

1). I am having a deja vue about this: why is the document referencing 
RFC 1869, which got obsoleted by RFC 2821? The two references to RFC 
1869 are talking about ESMTP, I think RFC 2821 is quite appropriate.

2). In Section 2.2:

   The UTF8SMTP extension is valid on the submission port [RFC4409].

This sentence is usually a part of the SMTP service registration template,
should it be moved to section 2.1?

   An SMTP Client that receives the UTF8SMTP extension keyword in
   response to the "EHLO" command MAY transmit a mailbox name as an
   internationalized string in UTF-8 form and MAY send an UTF-8 header
   [EAI-utf8header].  It MAY transmit the domain part of that string in
   either the form of ACE labels specified in [RFC3490] or UTF-8 form.
   In the domain part of the mailbox string, if any of the labels are
   intended to be interpreted as non-ASCII (i.e., are IDNs), then the
   Message Submission Server ("MSA") [RFC4409] MUST take responsibility
   for ensuring that the labels are valid (whether they appear in native
   character or ACE form).

Does "native character" mean UTF-8 here? I hope we are not recommending 
use of any other charsets here.

 [...]

   2.  Reject the message during the SMTP transaction or generate a
       notification of non-deliverability, as specified in RFC 2821
       [RFC2821] and RFC 3464 [RFC3464].  If the message content can be
       returned without alteration, content should be returned as
       specified in 2821 but, if a server is encountered along the
       return path that cannot accept UTF8SMTP traffic, the content
       should simply be abridged or dropped.

The last sentence is trying to redefine something already specified in 
[EAI-dsn]. I think it contradicts [EAI-dsn]. Suggestion to replace the 
last sentence with a pointer to [EAI-dsn]

3). In Section 2.4:

        "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" /

Should "domain" be replaced with "uDomain" for consistency?
(It can be argued that Postmaster@<uDomain> is still allowed by 
uForward-Path below:)

                  uForward-Path) [ SP Rcpt-parameters ] CRLF
               ; Update rcpt command in RFC 2821, section 4.1.1.3.
               ; A new parameter defined by the ABNF non-terminal
               ; <ALT-ADDRESS-parameter> is added. It complies
               ; with the syntax specified by <esmtp-param>.

4). In section 2.6:

   The UTF8SMTP extension MAY be used with the BODY=8BITMIME
   parameter if that is appropriate given the body content or, if the
   server advertises it and it is appropriate, with the BODY=BINARYMIME

The use of "it" is confusing here.

   parameter specified in [RFC3030].

I think the part starting from "if the server advertises" should read:

   if the server advertises BINARYMIME [RFC3030] and the the BODY=BINARYMIME
   is appropriate, with the BODY=BINARYMIME parameter.

5). In section 2.7.4:

   If the VRFY and EXPN commands have the optional parameter
   "UTF8REPLY", it indicates the client can accept UTF-8 on replies of

UTF-8 *in* replies *to*

   the VRFY and EXPN commands.  Specially this allows to use UTF-8 on

UTF-8 *in* (here and in many cases below)

   mailboxes and full names which occur on replies.  The SMTP client
   following this specification MUST accept UTF-8 on replies of the VRFY
   and EXPN commands.  However the SMTP server MUST not use UTF-8 on
   replies, if the SMTP client does not ask UTF-8 replies.  Some replies
   include the mailbox, but usually most of replies do not require that
   the mailbox is included in it and therefore UTF-8 is not needed.  The
   UTF8REPLY parameter on the VRFY and EXPN commands tells the SMTP
   server that the client is prepared for UTF-8 on SMTP replies.

 [...]

   If the SMTP Client lack of the UTF8SMTP support receives the UTF-8

SMTP client *which lacks UTF8SMTP support* receives a UTF-8

   message on reply, it may crash.  UTF-8 messages on reply are only

[*in* reply.]

I would change "message" to "text" here to avoid any confusion with RFC 
2821 message.

   allowed in the commands under the situations described above.  Under
   any other circumstances, UTF-8 messages on the reply MUST NOT be
   used.

6). In Section 3.2:

   The existing draft standard Delivery status notifications
   (DSNs)[RFC3461] is presently limited to US-ASCII text in the machine
   readable portions of the protocol.  "International Delivery and
   Disposition Notifications" [EAI-dsn] 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.  If an SMTP server advertises both the UTF8SMTP and the
   DSN extension, that server MUST implement EAI-dsn [EAI-dsn] including
   support for the ORCPT parameter.

This reference to [EAI-dsn] is not informative! I think [EAI-dsn] should 
be moved from Informative References to Normative References.

7). In Section 10.2:

   [RFC2554bis]
              Siemborski, R. and A. Melnikov, "SMTP Service Extension
              for Authentication", draft-siemborski-rfc2554bis-09 (work
              in progress), April 2007.

This is now an RFC 4954.

   [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
       RFC 4409, April 2006.

As this document puts some requirements on Submission Agents, I don't think this reference is informative.

Regards,
Alexey

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Sep 2007 11:11:50 +0100

> Most of the issues below are editorial, some of them can be considered 

I need to add that otherwise I find the document to be in good shape and 
support its publication.

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Sep 2007 17:38:20 -0400

--On Wednesday, 19 September, 2007 10:56 +0100 Alexey Melnikov
<[email-masked]> wrote:

> The last sentence is trying to redefine something already
> specified in [EAI-dsn]. I think it contradicts [EAI-dsn].
> Suggestion to replace the last sentence with a pointer to
> [EAI-dsn]

IMO, this suggestion does not go far enough.  The correct fix,
IMO, is to replace this paragraph with 

	2.  Reject the message during the SMTP transaction or
	generate a notification of non-deliverability, as
	specified in RFC 2821 [RFC2821], RFC 3464 [RFC3464], and
	[EAI-dsn]. 

If any of the other material in that paragraph is not adequately
specified in the DSN document, that should be fixed.

And I agree that the references to EAI-DSN and to RFC 4409 are
normative.

     john

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 25 Sep 2007 00:40:36 +0200

John C Klensin wrote:

> Alexey Melnikov <[email-masked]> wrote:
[...]
 
> IMO, this suggestion does not go far enough.  The correct
> fix, IMO, is to replace this paragraph with 
 
> specified in RFC 2821 [RFC2821], RFC 3464 [RFC3464], and

Yes, that should cover UTF8SMTP with and without DSN. 

If Alexey prefers to couple the UTF8SMTP extension with DSN
like it's already coupled with 8BITMIME this would need fresh
MUSTard in the I-D, and a subject starting with "ISSUE" for
the Chairs :-)

IIRC DSN-support is at SHOULD in 2821 and 2821bis, I could
not tell spontaneously why UTF8SMTP needs a MUST.

> I agree that the references to EAI-DSN and to RFC 4409 are
> normative.

+1