Re: [apps-discuss] [EAI] apps-team review of draft-ietf-eai-rfc5336bis

[Ned Freed <[e-mail]>]

I was asked to review draft-ietf-eai-rfc5336bis-07.txt. I was also provided
with a preliminary copy of the review Dave did, so these notes should be viewed
as an addendum to Dave's review, not as a standalone critique. In particular,
any failure to reiterate Dave's various points here should not be taken as
disagreement with him; on the contrary, I am in agreement with almost all of
his comments.

Now for the specifics:

(0) I cannot emphasize strongly enough how important it is to have a
    UTF8SMTP sort of parameter on the MAIL FROM to indicate that a message
    employing this extension is being submitted/relayed/delivered. This is
    especially important in the relay case - we do not want to require
    that relays grub through every message they receive looking for possible
    utf-8 so they can carry the negotiation of this extension forward, but
    that's exactly what the present proposal forces them to do.

(1) 3.1 item 4 and 3.6.4.2 add an optional UTF8REPLY parameter to VRFY and
    EXPN. They do this by redefining the syntax to be:

    vrfy = "VRFY" SP ( uLocal-part / uMailbox )
                     [ SP "UTF8REPLY" ] CRLF

    expn = "EXPN" SP ( uLocal-part / uMailbox )
                     [ SP "UTF8REPLY" ] CRLF

    The original syntax for VRFY and EXPN given in RFC 5321 is:

    vrfy = "VRFY" SP String CRLF
    expn = "EXPN" SP String CRLF
    String = Atom / Quoted-string
    Atom = 1*atext

    It's not immediately obvious, but the new syntax is in fact a superset of
    the old. (uLocal-part subsumes local-part, which in turn allows atoms
    and quoted strings.) However, this change does much more than hang a
    parameter on the command; for the first time an entire address is
    permitted as an EXPN/VRFY argument. But no semantics are given for
    this significant syntax expansion, nor does this expansion appear to be
    within scope for EAI.

    A more reasonable syntax would be:

    vrfy = "VRFY" SP uString [ SP "UTF8REPLY" ] CRLF

    expn = "EXPN" SP uString [ SP "UTF8REPLY" ] CRLF

    uString = uAtom / uQuoted-string

    But this now fails along a different dimension: When adding a parameter
    capability to a command, it should be done in a general way, so that any
    future extensions can build on a cleanly specified foundation. Like so:

    vrfy = "VRFY" SP uString [ SP vrfy-parameters ] CRLF
    vrfy-parameters = esmtp-param *(SP esmtp-param)

    expn = "EXPN" SP uString [ SP expn-parameters ] CRLF
    expn-parameters = esmtp-param *(SP esmtp-param)

    uString = uAtom / uQuoted-string

    Of course this will add 555 as a possible response to VRFY/EXPN, and that
    needs to be noted.

(2) In response to Dave's critique/query about why the parameter on VRFY and
    EXPN is needed, it's because these commands can appear outside of a
    transaction and thus there's not necessarily an indication that the client
    is prepared to accept UTF-8 responses. However, this brings up another
    issue, which is that a server that supports this extension needs a way
    to tell a client that doesn't that it cannot return a proper response
    to VRFY/EXPN without that parameter being specified. A new SMTP error
    status is needed, but the document only defines an extended status
    for this purpose; it doesn't specify a regular status code to use.

(3) Section 3.2 says:

   1.  If and only if the SMTP client (sender) is a Message Submission
       Server ("MSA") [RFC4409], it MAY, consistent with the general
       provisions for changes by such servers, rewrite the envelope,
       headers, or message material to make them entirely ASCII and
       consistent with the provisions of RFC 5321 [RFC5321] and RFC 5322
       [RFC5322].

    This is a bad idea no matter how you slice it. Such transformations
    depend on the availability of address mapping (from a UTF-8 address to
    an equivalent ASCII address) information; an agent being an MSA is neither
    necessary nor sufficient reason to have this information.

    But the bigger problem by far is defining what transformations are
    permissible. The present framework document is basically silent on
    what's allowed, so I for one have no idea what it means to be
    "consistent with the general provisions for changes by such servers"
    actually means. And unless you're willing to spell this out, I see this
    as practically guarnteeing a slew of interop problems.

(4) Also from 3.2:

  3.  It may find an alternate route to the destination that permits
       UTF8SMTPbis.  That route may be discovered by trying alternate
       Mail eXchanger (MX) hosts (using preference rules as specified in
       RFC 5321) or using other means available to the SMTP-sender.

    So you can use alternate MXes, but not alternate A records? I actually
    agree with this - an alternate A is presumably another address for
    the same host, so no point in trying it. But this needs to be spelled
    out.

    At an absolute minimum this needs to be accompanied by some
    security considerations text. The issue, I hope, is obvious: There
    are sites aplenty with large numbers of MX records and which won't
    support this extension any time soon. And all too often those MXes
    are *slow* to respond. So sending a message that causes them all to
    be tried is ... you get the idea.

    In fact I'm tempted to go one further and say that if an MX at a given
    priority is found not to support this extension, you SHOULD assume that
    MXes at lower priority don't either.

(5) Consider this text from 3.5:

   Assuming that the server advertises UTF8SMTPbis and 8BITMIME, and
   receives at least one non-ASCII address, the precise interpretation
   of "BODY=8BITMIME", and "BODY=BINARYMIME" in the MAIL command is:

   Since when are the addresses in the envelope a predictor of the addresses
   that appear in the outermost header, let alone any enclosed message/rfc822
   headers? Really, this could not be more fundamental: There's no requirement
   that envelope addresses appear in the outermost header or vice versa, and
   circumstances abound where the addresses in the header and envelope end up
   being partly or entirely disjoint. As such, while the use of UTF-8 in the
   envelope can be taken as an indication that this is an EAI message, the
   absence tells you nothing.

   Addrressing item (0) above and having a parameter on MAIL FROM addresses the
   technical side of this one, but the entire notion of coupling and
   confusion between envelope and header needs to be stamped out in this
   specification.

(6) A bunch of the references are to bis-versions, but the actual cite is to
    the current RFC.

One final comment. Several of the issues that have been raised are so
fundamental that once they are addressed (point (0) especially), this document
is almost certainly going to require another full review cycle.

				Ned