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

[Ned Freed <[e-mail]>]

+1 to all of Claudio's points raised here.

				Ned

> 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
> _______________________________________________
> IMA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima