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

[Claudio Allocchio <[e-mail]>]

I have been selected as the Applications Area Review Team reviewer for this
draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you
may receive. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.

Document: draft-ietf-eai-rfc5336bis
Reviewer: Claudio Allocchio (GARR, Italian Research and Academic Network)
Review Date: 2010-12-22
IETF Last Call Date:  N/A
IESG Telechat Date:  N/A

Summary:

The document specifies how to apply internationalization to some SMTP
elements, and to some Header elements which depends from the SMTP elements.
However there seem to be a discrepancy from what the abstract states, and
what is elaborated into the document details: the document also deals with
quite a number of elements which involve bodyparts, and affect the whole
email legacy system, and beyond, such as logs, traces, and wherever email
addresses are used (certificates, etc.). This seems thus to go beyond what
the summary states, even this fact is not explicitly discussed. It is
unclear thus if this "update" of RFC5321 and RFC5322 is only limited in
scope or not. My reading of the document say it goes beyond, and implicitly
affects also what is being transported into the email system. This is thus a
serious issue to be solved before the document can go to the Standard Track.
Another big issue is about blending the boundaries of servers in the
transport system (MTAs), clients (UAs) and their roles, when the document
specify that servers shall use guessing techniques from looking into
bodyparts to understand if what they're transporting is internationalized
according to this specification or not. This is IMHO a basic violation of
the role distiction in the legacy email system, and affects the MIME model
al well.

The document quite often repeats rules from other specifications, AND
re-describes these rules. This is dangerous (it makes very difficult to keep
aligned documents, and will lead to different interpretations) and not
needed.

The full specification probably needs a serious "english language" revision,
because the language issues which I specified in "Minor Issues" seems to be
a non neglegible number. I'll try to identify as many as possible and
suggest changes.

Major Issues:

This specification updates a number of SMTP and Headers fields from RFC5321
and RFC5322. However these fields are also used in Gatewaying to other email
systems, which are still existing. Section 3.7 in RFC5321 describes specific
cases. However this memo provides no clue on possible effect that
internationalized fields can have in case gatewaying occurs. Gatewaying
functions strongly rely on these values, and the introduction of these
modification should describe this scenario, too. I suggest to include a
specific section about these issues, and suggest at least a number of
possible actions which Gateways can take to survive this change.

The EAI WG charter states that in handling email message we shall be
"consistent with the long-term view that email with invalid addresses or
syntax should be rejected, rather than fixed up in transit between
submission servers and delivery servers.". However a number of sections in
the specification seem to contradict this, where they suggest actions, by
exammining message elements (in the SMTP and in the Headers and in the
Bodyparts) in order to try to deliver anyhow. This is a subtle line between
maximising the service chance to deliver, and "fixing" things during the
transaction, and it can encourage implementors to do many of these acions,
instead of stiching to the idea "not supported --> non delivery".

Major Issues by sections.

Abstract:

" This document specifies an SMTP extension for transport and delivery
    of email messages with internationalized email addresses or header
    information."

"internationalized" is not defined here in details. Sections 1 and 1.2 try 
to do this, but the language is not crystal clear: "to permit 
internationalized email addresses in envelopes, and UNICODE characters 
(encoded in UTF-8) [RFC3629] in headers." Are addresses in envelopes (SMTP 
envelopes!) also via UNICODE characters encoded in UTF-8? The reference to 
"the framework document" seem to come too late in the text to ensure the 
reader fully understand the relationship.

  3.2 The UTF8SMTPbis Extension

"An SMTP server that announces this extension MUST be prepared to
accept a UTF-8 string [RFC3629] in any position in which RFC 5321
specifies that a mailbox can appear."

s/mailbox/<mailbox>/  (it's a definition!).

The specification does NOT suggest a preferred order among the 3 possible
options when the SMTP server state it does not support UTF8SMTPbis. Having 3
"MAY" options at the same level can create a very uncertain email service
behaviour, and a very bad user's experience! This is consistent with what
happens in other cases for other "options" in the email system (like DSNs
and MDNs), but there should be at least an informative document describing
the various scenarios, and giving some guidance to implementors in order to
avoid totally incosistent behaviours.

If we do not specify a consistent procedure to try the 3 options, in many
cases we will just in practice break the concept of universal email common
service, creating islands which do not talk to each other. The 3.6.2 section
gives some suggestions about this, but this is limited to MX listed servers
for a single domain. My concern is more general. In 3.6.2 anyhow the
language should be more precise. It states "orgnisations", which something
totally undefined from a protocol point of view. MX records refer to
"domains", not to "organisations".


   3.3.  Extended Mailbox Address Syntax

The definition of

              uAtom = 1*ucharacter
                ; Replace Atom in RFC 5321, Section 4.1.2

              ucharacter = atext / UTF8-non-ascii

              atext = <See Section 3.2.3 of RFC 5322>

permits that uAtom is either an atext OR an UTF8-non-ascii... which in the
end allows a uMailbox to be a mixed contruction where some uAtom is in
atext, while some other uAtom is in UTF8-non-ascii AT THE SAME TIME, e.g. a
construct like

      [e-mail]

is allowed. However the distinction here seems to be unneeded, as ASCII is a
subset of UTF8.

Section 3.6 tries to clarify that this is not allowed; owever there is
normative language there apart on SHOULD for the domain name. I think this
shold be fixed with a clearer normative specfication.

This of course applies also to all other tokens where uAtom is used.

3.5 Body Parts and SMTP Extensions

I have problems in understanding why an SMTP server should peek extensively
into the message geing transfered to understand that it is handling an
interationalzed message. "There is no ESMTP parameter to assert that a
message is an internationalized message." in my opinion should be fixed in
another way, by ADDING an appropriate ESMTP parameter to state this! This
will solve already in the SMTP dialogue many isses which in this
specification are handeled by guessing techinques.

3.6.1 "the server normally sends..." --> "the server sends" (sorry... we do
not like ABnormal servers!) :-)

   Minor Issues:

1. Introduction

The sentence "This document use this mechanism to support an
internationalized email address." defintly needs a better form; if you do
not know already know what we are talking about, it can be misleading.

"This document uses this mechanism to allow internationalized email
addresses support in SMTP elements."

3.1 Framework for the Internationalization Extension

- bullet point 3. I do not see any need to state that clients MUST reject...
and MUST be fully compliant... etc. This is implicit in any specification.
If there is a specific need to add this detailed behaviour (to prevent wrong
implementions? why?) either we shall ensure the text is clear and
unambiguous, or we shall add an Implementers Note, as it was done in some
other RFCs.

3.2 The UTF8SMTPbis Extension

same general comment as per 3.1: in general the section states behaviours
which do not need to be specified again, because they're alredy described
seomewhere else. This might also become a Major issue if the specification
of such behaviours are changed elsewhere. Just poit to extrnal references.
(it seems editors are worried of implmentors which do not fully undesrtand
or know the other email specifications... )

3.3.  Extended Mailbox Address Syntax

What does the sentence "..., using the production for a mailbox and those
productions on which it depends." mean? I assume you meant <mailbox>, is
this correct?

5.  Security Considerations

there is one more issue: as internationalized items will also result into
logs and traces, their presence may affects trouble ticket systems used by
security operations teams (CERTs/CSIRTs). And they also can affect quick
handling of incidents, has it may require more time to correctly read and
understand logs and traces if they are not in current ascii form. This might
even be a Major Issue. I propose adding this text in the section, besides
pointing to the exteral reference:

---------------------- start of added text
Beyond the use inside the email global system (in SMTP envelopes and message
headers), internationalized email addresses will also show up inside other
scenarios, in particular:

  - the logging systems of SMTP transactions and other logs to monitor
    the email systems;

  - the trouble ticket systems used by Security Teams to manage security
    incidents, when an email address is involved

This will likely require extending support for full UTF8 also into these
systems, in order to avoid problems, which could cause also important loss
of data, or require to provide an adequate mechanism to map non ASCII
strings into them.

Another Security aspect to consider is related to the ability by Security
Team members to quickly understand/read and identify email addresses from
the logs, when they are tracking an incident. Mechanims to automatically and
quickly provide the origin or ownership of an internationalized email
address shall implemented for use also by log readers which cannot read
easily non-ASCII information.
--------------------------- end of added text

Also, in Security Consideration, there is no mention of the fact that we are
changing VRFY/EXPN commands to include internationalized addresses.
VRFY/EXPN commands can exist ALSO in an SMTP transaction which is not
supoused to transfer an email messages between MTAs. And their use has also
do to with Security. Here is an additional text for this:

---------------------- start of added text
The SMTP commands VRFY and EXPN are sometimes used in SMTP transactions
where there is no message to transfer (by tools used to take automated
actions in case potential spam messages are identified). RFC5321 section 3.5
and 7.3 give some detailed description of use and possible behaviours.
Implementation of internationalized addrsses can affect also logs and
actions by these tools.
--------------------------- end of added text

   Nits:

see
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-eai-rfc5336bis-07.txt

Best Regards!

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [e-mail]
                         Senior Technical Officer
tel: [phone]      Italian Academic and       G=Claudio; S=Allocchio;
fax: [phone]        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca