[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 5983

Internet Draft: Mailing Lists and Internationalized          R. Gellens
                Email Addresses                                Qualcomm
Document: draft-ietf-eai-mailinglist-01.txt                    E. Chung
Expires: July 2007                                              Afilias
                                                           January 2007


          Mailing Lists and Internationalized Email Addresses


Status of this Memo

    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.

    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 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.


Copyright Notice

    Copyright (C) The IETF Trust (2007).  All Rights Reserved.


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 are discussed.






Gellens & Chung                [Page 1]                Expires July 2007

Internet Draft     Mailing Lists and i18mail Addresses     January 2007


    This document makes specific recommendations on how mailing lists
    should act in various situations.

















































Gellens & Chung                [Page 2]                Expires July 2007

Internet Draft     Mailing Lists and i18mail Addresses     January 2007


Table of Contents

     1  Conventions Used in this Document . . . . . . . . . . . . . .  3
     2  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
     3  Scenarios Involving Mailing Lists   . . . . . . . . . . . . .  4
     4  Mailing List Header Fields   . . . . . . . . . . . . . . . .   6
     5  Managing Mailing Lists with Internationalized Email Address    6
     6  Further Discussion   . . . . . . . . . . . . . . . . . . . .   7
     7  IANA Considerations   . . . . . . . . . . . . . . . . . . . .  8
     8  Security Considerations  . . . . . . . . . . . . . . . . . .   8
     9  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  8
    10  Normative References . . . . . . . . . . . . . . . . . . . .   8
    11  Informative References  . . . . . . . . . . . . . . . . . . .  9
    12  Author's Address . . . . . . . . . . . . . . . . . . . . . .   9
       Appendix A: Changes from Previous Version  . . . . . . . . . . 10
       Intellectual Property Statement . . . . . . . . . . . . . . .   9
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10
    13  Copyright Statement  . . . . . . . . . . . . . . . . . . . .  -1


1 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 [KEYWORDS].


2 Introduction

    Mailing lists are an important part of email usage and collaborative
    communications.  The introduction of internationalized email
    addresses must take into consideration the 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.

    A mailing list is a mechanism whereby a message may be distributed
    to multiple recipients by sending to one recipient address.  An
    agent (typically not a human being) at that single address then
    causes the message to be redistributed to the target recipients.
    This agent sets the envelope return address of the redistributed
    message to a different address from that of the original single
    recipient message.  Using a different envelope return address
    (reverse-path) causes error (and other automatically generated)
    messages to go to an error handling address associated with the
    mailing list. (This avoids having error and other automatic messages
    go to the original sender, who typically doesn't control the list
    and hence can't do anything about them.)


Gellens & Chung                [Page 3]                Expires July 2007

Internet Draft     Mailing Lists and i18mail Addresses     January 2007


    Some mailing lists alter the message header, while others do not.  A
    number of standardized list-related header fields have been defined,
    and many lists add these headers.  Separate from these standardized
    list-specific header fields, and despite a history of
    interoperability problems from doing so, some lists alter or add
    header fields in an attempt to control where replies are sent.  Such
    lists typically add or replace the "Reply-To" field and some add or
    replace the "Sender" field.  Poorly-behaved lists may alter or
    replace other fields, including "From".

    While the mail transport protocol does not differ between regular
    email accounts and mailing list accounts, lists have special
    considerations with internationalized email addresses because they
    retransmit to potentially many recipients messages composed by other
    agents.  Discussion of the different scenarios involving mailing
    lists and internationalized email addresses is in Section 3.

    Internationalized email address considerations arise in the
    return-path as well as header fields of redistributed messages.
    Among these header fields are those 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 4.

    With mailing lists, there are two different types of considerations:
    first, the purely technical ones involving message handling, error
    cases, downgrades, and the like, and second, those that arise from
    the fact that humans use mailing lists to communicate.  As an
    example of the first, mailing lists may choose to reject all
    messages from internationalized addresses that lack an alt-address.
    As an example of the second, a user who sends a message to a list
    often is unaware of the list membership.  In particular, the user
    often doesn't know if the members are i18mail users or not, and
    often neither the original sender nor the recipients personally know
    each other.  As a consequence of this, remedies that may be readily
    available may not be appropriate when dealing with mailing lists.
    For example, if a user sends a message which is undeliverable, the
    user can often use the telephone, IM, or other forms of
    communication to obtain a working address.  With mailing lists, the
    users may not have any recourse.

    A brief discussion on some key considerations for mailing list
    operation in an internationalized email address environment is
    proposed in Section 5.  This is followed by further discussions in
    Section 6.





Gellens & Chung                [Page 4]                Expires July 2007

Internet Draft     Mailing Lists and i18mail Addresses     January 2007


3 Scenarios Involving Mailing Lists

    Expanding from Sections 2.3 ("i18mail mailing list") and 2.6 ("An
    i18mail user sends to a mailing list with a mix of users") 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, the
    original message is sent to the mailing list agent as a completely
    separate and independenet transaction from the mailing list agent
    sending the retransmitted message to one or more list recipients.
    In each case, the message might have only one recipient, or might
    have multiple recipients.  That is, the original message might be
    sent to additional recipients as well as the mailing list agent, and
    the mailing list might choose to send the retransmitted message to
    each list recipient in a separate SMTP transaction, or might choose
    to include multiple recipients per transaction. (Often, mailing
    lists are constructed to work in cooperation with, rather than
    include the functionality of, an SMTP server, and hence the list
    transmits to a single SMTP server one copy of the retransmitted
    message, with all list recipients specified in the SMTP envelope.)

    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.  In
    general, it may be prudent for mailing list operators to pre-obtain
    an alt-address for all its internationalized member addresses.  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 5 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 of the non-member's internationalized email address,
    therefore failing to deliver the message to some members.  To
    protect against this, a UTF8SMTP-aware mailing list might prefer to
    reject submissions from internationalized email addresses that lack
    an alt-address.

    (Note that in the situation is not unique to mailing lists.  Mail
    relays that are UTF8SMTP- aware will potentially encounter the same
    situation.) Further discussions are included in section 6 of this
    document.



Gellens & Chung                [Page 5]                Expires July 2007

Internet Draft     Mailing Lists and i18mail Addresses     January 2007


4 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 often 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.

    These fields might contain other URLs, such as HTTP.  In these
    cases, there are no EAI-specific considerations, since these
    non-mail-related URLs are out of scope for internationalized email
    documents, and have been addressed elsewhere, such as RFC3987
    "Internationalized Resource Identifier (IRI)" [RFC3987].

    Downgrading provisions should also follow the chosen mechanism based
    on the Downgrading document [EAI-Downgrade].

    Because the email addresses are expressed as "mailto" URLs, further
    specifications for presentation and inclusion of alt-addresses as
    well as other considerations may be necessary, other than simply
    following RFC3987 "Internationalized Resource Identifier (IRI)"
    [RFC3987] specifications.  This will be further discussed in Section
    6.


5 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 an alt-address from each member with
    an internationalized email address before adding the member.


Gellens & Chung                [Page 6]                Expires July 2007

Internet Draft     Mailing Lists and i18mail Addresses     January 2007


    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 from) a non-member who is
    interacting with the mailing list from an internationalized email
    address.  This is further discussed in Section 6.

    Furthermore, operators should take caution to avoid setting up 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.

    The reverse may be less harmful but nevertheless should also be
    avoided.


6 Further Discussion

    While generally speaking, mailing lists do not create a significant
    additional burden to the deployment of internationalized email
    address functionalities, the study in this document does uncover a
    couple of relevant areas for further consideration.  While neither
    items is entirely unique to mailing lists, it is true that mailing
    lists face additional complexity since they redistribute messages
    composed by other agents.  Hence, they may be asked to accept a
    message with non-ASCII headers composed by a UTF8SMTP-aware user
    agent, and redistribute it to i18mail and non-i18mail users via
    systems that are not UTF8SMTP-aware.

    1.  Obtaining Downgrade Information -- for a mailing list, or mail
    relay server for that matter, that is UTF8SMTP-aware, receiving mail
    from an internationalized email address, the alt-address is not
    required from the sending MTA for the transport to be complete.
    Thereupon when the mailing list retransmits the message to 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 an internationalized email
    address that lacks an alt-address.  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 the
    alt- address.  This may be useful in other scenarios as well,
    especially 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.  The
    UTF8 Headers document [EAI-UTF8Headers] suggests including a
    parameter within the angle 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,


Gellens & Chung                [Page 7]                Expires July 2007

Internet Draft     Mailing Lists and i18mail Addresses     January 2007


    "<mailto:non-ascii@example.tld<alt-ascii@domain>?subject=help" or
    perhaps "<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.


7 IANA Considerations

    None.


8 Security Considerations

    Security considerations are discussed in the Framework document
    [EAI-Framework].


9 Acknowledgments


10 Normative 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




Gellens & Chung                [Page 8]                Expires July 2007

Internet Draft     Mailing Lists and i18mail Addresses     January 2007


    [RFC3987] M. Duerst and M. Suignard,"Internationalized Resource
    Identifiers (IRIs)", January 2005


11 Informative References

12 Author's Address

    Randall Gellens
    QUALCOMM Incorporated
    5775 Morehouse Drive
    San Diego, CA  92121
    rg+ietf@qualcomm.com

    Edmon Chung
    Afilias
    Suite 204, 4141 Yonge Street,
    Toronto, Ontario,
    Canada M2P 2A8
    edmon@afilias.info


Appendix A:  Changes from Previous Version

    THIS SECTION TO BE REMOVED PRIOR TO PUBLICATION.

    Changes made from version -00 to -01:
    o   Fixed SMTP envelope versus message header confusion.
    o   Fixed erroneous mailing list operation text.
    o   Removed references to ATOMIC.
    o   Removed unneeded scenarios.
    o   Added discussion of human considerations which arise with lists.
    o   Fixed some typos.

Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed
    to pertain to the implementation or use of the technology described
    in this document or the extent to which any license under such
    rights might or might not be available; nor does it represent that
    it has made any independent effort to identify any such rights.
    Information on the procedures with respect to rights in RFC
    documents can be found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use
    of such proprietary rights by implementers or users of this


Gellens & Chung                [Page 9]                Expires July 2007

Internet Draft     Mailing Lists and i18mail Addresses     January 2007


    specification can be obtained from the IETF on-line IPR repository
    at http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    ietf-ipr@ietf.org.


Full Copyright Statement

    Copyright (C) The IETF Trust (2007).

    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, THE
    IETF TRUST 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.

13 Copyright Statement

    Copyright (C) The Internet Society (2007).  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.











Gellens & Chung               [Page 10]               Expires July 2007


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/