[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc5983                               
Email Address Internationalization (EAI WG)                 Edmon Chung
Internet Draft                                                  Afilias
<draft-ietf-eai-mailinglist-00.txt>
                                                          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-header.nisto.com>
   List-Help: <mailto:list@host.com?subject=help> (List Instructions)
   List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
   List-Subscribe: <mailto:list@host.com?subject=subscribe>
   List-Post: <mailto:list@host.com>
   List-Owner: <mailto:listmom@host.com> (Contact Person for Help)
   List-Archive: <mailto:archive@host.com?subject=index%20list>

   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. <non-ascii@domain, alt-ascii@domain>).  In the case of a mailto
   URL, it may be possible to use the same mechanism, for example,
   <mailto:non-ascii@example.tld?subject=help, alt-ascii@domain>,
   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]