Internet Engineering Task Force (IETF) J. Levine Request for Comments: 6783 Taughannock Networks Obsoletes: 5983 R. Gellens Category: Informational Qualcomm Incorporated ISSN: 2070-1721 November 2012 Mailing Lists and Non-ASCII Addresses
AbstractThis document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6783. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Mailing List Header Additions and Modifications . . . . . . 3 1.2. Non-ASCII Email Addresses . . . . . . . . . . . . . . . . . 3 2. Scenarios Involving Mailing Lists . . . . . . . . . . . . . . . 4 2.1. Fully SMTPUTF8 Lists . . . . . . . . . . . . . . . . . . . 4 2.2. Mixed SMTPUTF8 and ASCII Lists . . . . . . . . . . . . . . 5 2.3. SMTP Issues . . . . . . . . . . . . . . . . . . . . . . . . 5 3. List Headers . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. SMTPUTF8 List Headers . . . . . . . . . . . . . . . . . . . 6 3.2. Downgrading List Headers . . . . . . . . . . . . . . . . . 7 3.3. Subscribers' Addresses in Downgraded Headers . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . . 8 5.2. Informative References . . . . . . . . . . . . . . . . . . 9 RFC6530]. Mailing lists are an important part of email usage and collaborative communications. The introduction of internationalized email addresses affects mailing lists in three main areas: (1) transport (receiving and sending messages); (2) message headers of received and retransmitted messages; and (3) mailing list operational policies. A mailing list is a mechanism that distributes a message to multiple recipients when the originator sends it to a single address. An agent, usually software rather than a person, at that single address receives the message and then causes the message to be redistributed to a list of recipients. This agent usually sets the envelope return address (henceforth called the "bounce address") of the redistributed message to a different address from that of the original message. Using a different bounce address directs error and other automatically generated messages to an error-handling address associated with the mailing list. This sends error and other automatic messages to the list agent, which can often do something useful with them, rather than to the original sender, who typically doesn't control the list and hence can't do anything about them. In most cases, the mailing list agent redistributes a received message to its subscribers as a new message, that is, conceptually it uses message submission [RFC6409] (as did the sender of the original message). The exception, where the mailing list is not managed by a
separate agent that receives and redistributes messages in separate transactions but is implemented by an expansion step within an SMTP transaction where one local address expands to multiple local or non- local addresses, is not addressed by this document. RFC2369] and 2919 [RFC2919]. For more information, see Section 3.
address. With mailing lists, the users may not have any recourse. Of course, with mailing lists, the original sender usually does not know which list members successfully received a message or if it was undeliverable to some. Conceptually, a mailing list's internationalization can be divided into three capabilities. First, does the list have a non-ASCII submission address? Second, does the list agent accept subscriptions for addresses containing non-ASCII characters? And third, does the list agent accept messages that require SMTPUTF8 capabilities? If a list has subscribers with ASCII addresses, those subscribers might or might not be able to accept SMTPUTF8 messages.
3.2 and 3.3. To determine which set an address belongs in, list software might make the conservative assumption that ASCII addresses get ASCII messages, it might try to probe the address with an SMTPUTF8 test message, or it might let the subscriber set the message format manually, similar to the way that some lists now let subscribers choose between plain text and HTML mail, or individual messages and a daily digest. To determine whether a message needs to be downgraded for ASCII recipients, list software might assume that any message received via an SMTPUTF8 SMTP session is an SMTPUTF8 message or might examine the headers and body of the message to see whether it needs SMTPUTF8 treatment. Depending on the interface between the list software and the Mail Transfer Agent (MTA) and Mail Delivery Agent (MDA) that handle incoming messages, it may not be able to tell the type of session for incoming messages. VERP]. The bounce address for a list typically includes the name of the list, so a list with a non-ASCII name will have a non-ASCII bounce address. Given the unknown paths that bounce messages might take, list software might instead use an ASCII bounce address to make it more likely that bounces can be delivered back to the list agent. Similarly, a VERP address for each subscriber typically embeds a version of the subscriber's address so the VERP bounce address for a non-ASCII subscriber address will be a non-ASCII address. For the same reason, the list software might use ASCII bounce addresses that encode the recipient's identity in some other way.
RFC2369] and 2919 [RFC2919] were all specified before SMTPUTF8 mail existed, and their definitions do not address where non-ASCII characters might appear. These include, for example: List-Id: List Header Mailing List <list-header.example.com> List-Help: <mailto:email@example.com?subject=help> List-Unsubscribe: <mailto:firstname.lastname@example.org?subject=unsubscribe> List-Subscribe: <mailto:email@example.com?subject=subscribe> List-Post: <mailto:firstname.lastname@example.org> List-Owner: <mailto:email@example.com> (Contact Person for Help) List-Archive: <mailto:firstname.lastname@example.org?subject=index%20list> As described in [RFC2369], "[t]he contents of the list header fields mostly consist of angle-bracket ('<', '>') enclosed URLs, with internal whitespace being ignored". [RFC2919] specifies that "[t]he list identifier will, in most cases, appear like a host name in a domain of the list owner". Since these headers were defined in the context of ASCII mail, these headers permit only ASCII text, including in the URLs. The most commonly used URI schemes in List-* headers tend to be http and mailto [RFC6068], although they sometimes include https and ftp and, in principle, can contain any valid URI. Even if a scheme permits an internationalized form, it should use a pure ASCII form of the URI described in [RFC3986]. Future work may extend these header fields or define replacements to directly support unencoded non-ASCII outside the ASCII repertoire in these and other header fields, but in the absence of such extension or replacement, non-ASCII characters can only be included by encoding them as ASCII.
The encoding technique specified in [RFC3986] is to use a pair of hex digits preceded by a percent sign, but percent signs have been used informally in mail addresses to do source routing. Although few mail systems still permit source routing, a lot of mail software still forbids or escapes characters formerly used for source routing, which can lead to unfortunate interactions with percent-encoded URIs or any URI that includes one of those characters. If a program interpreting a mailto: URI knew that the Mail User Agent (MUA) in use were able to handle non-ASCII data, the program could pass the URI in unencoded non-ASCII, avoiding problems with misinterpreted percent signs, but at this point, there is no standard or even informal way for MUAs to signal SMTPUTF8 capabilities. Also, note that whether internationalized domain names should be percent-encoded or appear in A-label form [RFC5890] depends on the context in which they occur. The List-ID header field uniquely identifies a list. The intent is that the value of this header remain constant, even if the machine or system used to operate or host the list changes. This header field is often used in various filters and tests, such as client-side filters, Sieve filters [RFC5228], and so forth. If the definition of a List-ID header field were to be extended to allow non-ASCII text, filters and tests might not properly compare encoded and unencoded versions of a non-ASCII value. In addition to these comparison considerations, it is generally desirable that this header field contain something meaningful that users can type in. However, ASCII encodings of non-ASCII characters are unlikely to be meaningful to users or easy for them to accurately type.
If lists permit mail with multiple MIME parts, some MIME headers in SMTPUTF8 messages may include non-ASCII characters in file names and other descriptive text strings. Downgrading these strings may lose the sense of the names, break references from other MIME parts (such as HTML IMG references to embedded images), and otherwise damage the mail. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010. [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011. [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998. [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001. [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [VERP] Bernstein, D., "Variable Envelope Return Paths", February 1997, <http://cr.yp.to/proto/verp.txt>. http://jl.ly Randall Gellens Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 US EMail: email@example.com