[EAI] apps-team review of draft-ietf-eai-rfc5336bis
Claudio Allocchio <Claudio.Allocchio@garr.it> Wed, 22 December 2010 17:22 UTC
Return-Path: <Claudio.Allocchio@garr.it>
X-Original-To: ima@core3.amsl.com
Delivered-To: ima@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314063A6B93; Wed, 22 Dec 2010 09:22:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level:
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDWh19coFosJ; Wed, 22 Dec 2010 09:22:30 -0800 (PST)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id C03B53A6B91; Wed, 22 Dec 2010 09:22:29 -0800 (PST)
Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id oBMHOHLc001829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 18:24:17 +0100 (CET)
X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it oBMHOHLc001829
DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=roKPdmhQpHF81dShcG6jug9nCIiG1uJHA4qDeE/yLidzpQvZRcsXZLAuj83J1P/iE /xobSXJXNu1TnpF1LTnhB8U6GD6anCxXBZWa6h6+c9D0CgtHFkb6KOWd5DptoQ87NTy xL1MSfD127NKaQOdDrjmhfNaYeWd436MxOvJ04w=
Date: Wed, 22 Dec 2010 18:24:11 +0100
From: Claudio Allocchio <Claudio.Allocchio@garr.it>
X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it
To: apps-discuss@ietf.org, ima@ietf.org, draft-ietf-eai-rfc5336bis@tools.ietf.org
Message-ID: <Pine.OSX.4.64.1012221602490.40683@mac-allocchio3.elettra.trieste.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Mailman-Approved-At: Wed, 22 Dec 2010 16:51:37 -0800
Cc: Alexey.Melnikov@isode.com, SM <sm+ietf@elandsys.com>
Subject: [EAI] apps-team review of draft-ietf-eai-rfc5336bis
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Dec 2010 17:22:33 -0000
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 some-ascii.some-UTF8-non-ascii@some-UTF8-non-ascii.some-ascii.tld 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 Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca
- [EAI] apps-team review of draft-ietf-eai-rfc5336b… Claudio Allocchio
- Re: [EAI] apps-team review of draft-ietf-eai-rfc5… Ned Freed
- Re: [EAI] apps-team review of draft-ietf-eai-rfc5… Ned Freed
- Re: [EAI] apps-team review of draft-ietf-eai-rfc5… Charles Lindsey
- Re: [EAI] apps-team review of draft-ietf-eai-rfc5… Ned Freed
- Re: [EAI] apps-team review of draft-ietf-eai-rfc5… Dave CROCKER
- [EAI] RFC5336 and VRFY/EXPN (was: Re: apps-team r… John C Klensin
- Re: [EAI] [apps-discuss] RFC5336 and VRFY/EXPN (w… Al Costanzo
- Re: [EAI] apps-team review of draft-ietf-eai-rfc5… Charles Lindsey
- Re: [EAI] apps-team review of draft-ietf-eai-rfc5… John C Klensin
- Re: [EAI] [apps-discuss] RFC5336 and VRFY/EXPN (w… John C Klensin
- [EAI] Analysis of comments on 5336bis (was: Re: a… John C Klensin
- Re: [EAI] apps-team review of draft-ietf-eai-rfc5… Dave CROCKER
- Re: [EAI] apps-team review of draft-ietf-eai-rfc5… Barry Leiba
- [EAI] Unicode vs. UTF-8 / Encoding vs. Representa… Dave CROCKER
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… John C Klensin
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Dave CROCKER
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… John C Klensin
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Yangwoo Ko
- Re: [EAI] apps-team review of draft-ietf-eai-rfc5… Charles Lindsey
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Andrew Sullivan
- Re: [EAI] [apps-discuss] RFC5336 and VRFY/EXPN (w… Charles Lindsey
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Dave CROCKER
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… John C Klensin
- Re: [EAI] [apps-discuss] RFC5336 and VRFY/EXPN (w… John C Klensin
- Re: [EAI] RFC5336 and VRFY/EXPN Alexey Melnikov
- Re: [EAI] apps-team review of draft-ietf-eai-rfc5… ned+ima
- Re: [EAI] apps-team review of draft-ietf-eai-rfc5… Barry Leiba
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Dave CROCKER
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Yangwoo Ko
- [EAI] new terms Re: Unicode vs. UTF-8 / Encoding … Jiankang YAO
- Re: [EAI] [apps-discuss] RFC5336 and VRFY/EXPN (w… Charles Lindsey
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… John C Klensin
- Re: [EAI] [apps-discuss] RFC5336 and VRFY/EXPN (w… John C Klensin
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Joseph Yee
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Yangwoo Ko
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Charles Lindsey
- [EAI] Repeating normative text from other specifi… Dave CROCKER
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Joseph Yee
- Re: [EAI] Repeating normative text from other spe… ned+ima
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Dave CROCKER
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Yangwoo Ko
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Charles Lindsey
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… John C Klensin
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… John C Klensin
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Charles Lindsey
- Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Repres… Barry Leiba
- [EAI] vrfy syntax Jiankang YAO