Email Address Internationalization (EAI WG) Edmon Chung Internet Draft Afilias June 19, 2006 Mailing Lists and Internationalized Email Addresses STATUS OF THIS MEMO Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The reader is cautioned not to depend on the values that appear in examples to be current or complete, since their purpose is primarily educational. Distribution of this memo is unlimited. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Intellectual Property Rights Statement By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Abstract This document describes considerations for mailing-lists with the introduction of internationalized email addressing capabilities. Different scenarios involving interaction between mailing-lists and internationalized email addresses are examined. Furthermore, mailing-list header fields will be discussed. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Edmon Chung [Page 1] EAI-Mailinglist JUNE 2006 Table of Contents 1. Introduction....................................................2 2. Scenarios Involving Mailing-Lists...............................3 2.1 Pure Case Scenarios............................................4 2.2 Mixed Case Scenarios...........................................4 3. Mailing List Header Fields......................................5 4. Managing Mailing Lists with Internationalized Email Address.....5 5. Further Discussion..............................................6 6. IANA Considerations.............................................6 7. Security Considerations.........................................6 8. Copyright Statement.............................................6 1. Introduction Mailing-lists are an important part of email usage and collaborative communications. The introduction of internationalized email addresses must take into consideration impact on mailing-list functionality. The consideration of mailing-lists in the context of internationalized email addresses includes three main areas: (1) transport protocol; (2) message headers; and (3) mailing-list operation policies. Mailing-lists are generally deployed either as a mass mailer client or act in essence like a mail relay. In the case of a mailer client, the mailing-list program is activated when it receives an email to the mailing-list email account. The message is then sent to the members on the mailing-list. In a relay model, the mail server upon receipt of mail to the mailing-list account, relays the mail to all members. Under both models, the mailing-list program usually rewrites the return-path of the email to the corresponding mailing- list. This allows recipients to observe the original sender of the email, and be able to reply to the mailing-list conveniently. In essence, the mail transport protocol does not differ between regular email accounts and mailing-list accounts. Discussion on the different scenarios involving mailing-lists and internationalized email addresses are included in Section 2. In terms of message headers, internationalized email address considerations are required for the return-path rewrite as well as internationalized email addresses in list fields as specified in RFC2369 -- The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields [RFC2369] and RFC2919 -- List-Id: A Structured Field and Namespace for the Identification of Mailing Lists [RFC2919]. This will be described in Section 3. A brief discussion on some key considerations for mailing-list operation in an internationalized email address environment is proposed in Section 4. This is followed by further discussions in Section 5. Edmon Chung [Page 2] EAI-Mailinglist JUNE 2006 2. Scenarios Involving Mailing-Lists Expanding from Sections 2.3 and 2.6 of the Scenarios document [EAI- Scenarios], this section will provide an overview of the different scenarios involving mailing-lists and internationalized email addresses. What is worth noting is that generally, for mailing-lists, each message is transported between a sender email address and a recipient mailing-list address or a sending mailing-list address and a receiving member. A multi-recipient message is usually only a result of situations where a sender includes additional addresses in the "To" or "CC" fields while sending (or replying) to a mailing-list. The following diagram summarizes the conceptual working of a mailing- list (Pure Case): (b) -----> User1@exmaple.tld (a) / (c) User1@example.tld ------> mailing@list.tld ------> User2@example.tld \ (d) -----> ... As observed above, the mail transport transactions (a), (b), (c) and (d) all involves two parties, that is: 1. The mailing-list account; and, 2. The user / member account. These scenarios are essentially the same as those already described in Sections 2.1 and 2.4 of the Scenarios document [EAI-Scenarios]. Multiple recipients are involved usually only when one (or more) additional account(s) is (are) included (Mixed Case): -----> User1@exmaple.tld (a) / User1@example.tld ---+--> mailing@list.tld ------> User2@example.tld | ^ \ (d) | | -----> ... | | | v | (e) | cc@example.tld <-----+-------------(reply)--+ Under this situation, scenarios (a) and (e) resemble the situations already described in Sections 2.2 and 2.5 of the Scenarios document [EAI-Scenarios]. More specific discussions based on these two general cases are included below. Edmon Chung [Page 3] EAI-Mailinglist JUNE 2006 2.1 Pure Case Scenarios In the Pure Case described above, the following are possible for (a): User1@example.tld mailing@list.tld (1) ASCII ASCII (2) non-ASCII ASCII (3) ASCII non-ASCII (4) non-ASCII non-ASCII Among this set, (1) is simply the conventional case without involving any internationalized email address. (2) and (3) are scenarios described in Section 2.4 -- One i18nmail user sends to one ASCII user -- of the Scenarios document, whereas (4) is described in Section 2.1 -- Two i18nmail users [EAI-Scenarios]. For (d) -- generalizing (b) and (c) -- it may be branched further where: (i) Mailing-list contains only ASCII email addresses (ii) Mailing-list contains at least one internationalized email address For (ii), as the mailing-list is sending out to its members, its MTA may encounter a situation where a downgrade [EAI-Downgrade] may be called for. In order for a downgrade to be possible, the mailing- list (and/or its MTA) must therefore have the alt-address or atomic information. In general, it may be prudent for mailing-list operators to pre-obtain this for all its member accounts. This will ensure that mailing-list transactions within members will be able to be delivered and replied to. Further discussion on mailing-list policy considerations is included in section 4 of this document. In the specific case where a non-member with an internationalized email address is sending to a mailing-list, and that mailing-list is UTF8SMTP-aware, and the path to a constituent member calls for a downgrade, the mailing-list (and/or its MTA) may not have the alt- address or atomic information of the non-member’s internationalized email address, therefore failing to deliver the mail. Nevertheless, this is not unique for mailing-lists. Mail relays that are UTF8SMTP- aware will potentially encounter the same situation. Further discussions are included in section 5 of this document. 2.2 Mixed Case Scenarios The Mixed Case scenarios are essentially a combination of the discussion in section 2.1 above, plus those described in Section 2.2 -- Three i18nmail users -- and, Section 2.5 -- An i18mail user sends to one ascii user and one i18nmail user -- of the Scenarios [EAI- Scenarios] document. Similar issues arise with regards to members versus non-members, especially non-members with an internationalized email address, as discussed in the above section. Edmon Chung [Page 4] EAI-Mailinglist JUNE 2006 3. Mailing List Header Fields A number of header fields specifically for mailing-lists have been introduced in RFC2369 and RFC2919. These include, for example: List-Id: List Header Mailing List List-Help: (List Instructions) List-Unsubscribe: List-Subscribe: List-Post: List-Owner: (Contact Person for Help) List-Archive: As described in RFC2369, "The contents of the list header fields mostly consist of angle-bracket ('<', '>') enclosed URLs, with internal whitespace being ignored." [RFC2369] Whereas RFC2919 specifies that, "The list identifier will, in most cases, appear like a host name in a domain of the list owner." [RFC2919] By and large, the data contained in these mailing-list header fields are URLs which contain email addresses. The same mechanism should be used for these fields as with other fields specifically discussed in the UTF8-Headers document [EAI-UTF8Headers]. Generally therefore, for fields that contain an internationalized email address, it could be expressed as a UTF8 string. Downgrading provisions should also follow the chosen mechanism based on the Downgrading document [EAI-Downgrade]. Because the email addresses will be expressed in URL format, further specifications for presentation and inclusion of the alt-address and atomic information may be necessary, other than simply following RFC3987 Internationalized Resource Identifier (IRI) [RFC3987] specifications. This will be further discussed in Section 5. 4. Managing Mailing Lists with Internationalized Email Address Given the need potentially to deal with non-UTF8SMTP-aware MTAs in the path of delivery for different members, it is advisable that mailing-list operators obtain from all members their alt-address or atomic information before setting up the mailing-list (or adding a member with an internationalized email address) In consideration for consistent delivery to all members in a mailing- list, a mailing-list may want to consider rejecting (or otherwise obtaining alt-address or atomic information from) a non-member who is interacting with the mailing-list with an internationalized email address. This is further discussed in Section 5. Furthermore, operators should take caution to avoid setting up of an MTA that is UTF8SMTP-aware with a mailing-list program that is non- aware. This is especially important for mailing-list programs that are based on a mail client and not directly integrated into an MTA. Edmon Chung [Page 5] EAI-Mailinglist JUNE 2006 The reverse may be less harmful but nevertheless should also be avoided. 5. Further Discussion While generally speaking, mailing-lists do not create additional complexity for the deployment of internationalized email address functionalities, the study in this document does uncover a couple of relevant areas for further consideration. Nevertheless, neither items are entirely unique to mailing-lists. 1. Obtaining Downgrade Information -- for a mailing-list, or mail relay server for that matter, that is EAI-aware, receiving email from an internationalized email address, the alt-address or atomic information is not required from the sending MTA for the transport to be complete. Thereupon when the mailing-list "relays" or "explodes" the mail to all its members, it may encounter paths where a downgrade is called for. In order to mitigate this situation, the mailing-list may perhaps decide to reject all incoming mail from any non-member internationalized email address or that alt-address or atomic information is not provided. Alternatively, it may be useful to consider having a mechanism, such as an additional SMTP command, for the receiving MTA (in this case the mailing-list) to request for alt- address or atomic information from the sender. This may be useful in other scenarios as well, such as those concerning multiple recipients. 2. Downgrading Considerations for mailto URLs -- downgrading specifications may have to be specified particularly for mailto URLs to take into consideration the presentation of alt-address or atomic information. The UTF8 Headers document [EAI-UTF8Headers] suggests including a parameter within the angled brackets of an email address (e.g. ). In the case of a mailto URL, it may be possible to use the same mechanism, for example, , however this should be further studied. Other places where an internationalized email address could appear in a URL may also require further examination. 6. IANA Considerations This document does not make any request to IANA. 7. Security Considerations Extensive security considerations have been included in the Framework document [EAI-Framework]. Edmon Chung [Page 6] EAI-Mailinglist JUNE 2006 8. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. References [EAI-Framework] J. Klensin and Y. Ko, "Overview and Framework for Internationalized Email", draft-ietf-eai-framework-00.txt, May 24, 2006 [EAI-Scenarios] H. Alvestrand, "Internationalized Email Addresses: Scenarios",draft-ietf-eai-scenarios-00.txt , May 12, 2006 [EAI-SMTPEXT] J. Yao and W. Mao, "SMTP extension for internationalized email address", draft-ietf-eai-smtpext-00.txt, May 12, 2006 [EAI-UTF8Headers] J. Yeh, "Internationalized Email Headers", draft- ietf-eai-utf8headers-00.txt, May 30, 2006 [EAI-Downgrade] Y. YONEYA and K. Fujiwara, "Downgrading mechanism for Internationalized eMail Address (IMA)", draft-ietf-eai-downgrade- 00.txt, May 26, 2006 [RFC2369] G. Neufeld and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", July 1998 [RFC2919] R. Chandhok and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", March 2001 [RFC3987] M. Duerst and M. Suignard,"Internationalized Resource Identifiers (IRIs)", January 2005 Authors' Address: Edmon Chung Afilias Suite 204, 4141 Yonge Street, Toronto, Ontario, Canada M2P 2A8 edmon@afilias.info Edmon Chung [Page 7]