summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5983.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5983.txt')
-rw-r--r--doc/rfc/rfc5983.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc5983.txt b/doc/rfc/rfc5983.txt
new file mode 100644
index 0000000..fe92e36
--- /dev/null
+++ b/doc/rfc/rfc5983.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Gellens
+Request for Comments: 5983 Qualcomm
+Category: Experimental October 2010
+ISSN: 2070-1721
+
+
+ Mailing Lists and Internationalized Email Addresses
+
+Abstract
+
+ This document describes considerations for mailing lists with the
+ introduction of internationalized email addresses.
+
+ This document makes some specific recommendations on how mailing
+ lists should act in various situations.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. 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/rfc5983.
+
+Copyright Notice
+
+ Copyright (c) 2010 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.
+
+
+
+Gellens Experimental [Page 1]
+
+RFC 5983 Mailing Lists and UTF-8 Mail Addresses October 2010
+
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Conventions Used in This Document ...............................4
+ 3. Scenarios Involving Mailing Lists ...............................4
+ 4. Capabilities and Requirements ...................................5
+ 5. List Header Fields ..............................................6
+ 6. Further Discussion ..............................................8
+ 7. Security Considerations .........................................8
+ 8. Acknowledgments .................................................9
+ 9. References ......................................................9
+ 9.1. Normative References .......................................9
+ 9.2. Informative References ....................................10
+
+1. Introduction
+
+ This document describes considerations for mailing lists with the
+ introduction of internationalized email addresses [RFC5335].
+
+ 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 whereby a message may be distributed to
+ multiple recipients by sending to one address. An agent (typically
+ not a human being) at that single address receives the message and
+ then causes the message to be redistributed to a list of recipients.
+ This agent sets the envelope return address of the redistributed
+ message to a different address from that of the original message.
+ Using a different envelope return address (reverse-path) directs
+ error (and other automatically generated) messages to an error
+
+
+
+
+
+
+Gellens Experimental [Page 2]
+
+RFC 5983 Mailing Lists and UTF-8 Mail Addresses October 2010
+
+
+ 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.)
+
+ 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 [submission] (as did the sender of the
+ original message). The exception, where the mailing list is not a
+ separate agent that receives and redistributes messages in separate
+ transactions, but is instead an expansion step within an SMTP
+ transaction where one local address expands to multiple local or non-
+ local addresses, is out of scope for this document.
+
+ Some mailing lists alter message header fields, while others do not.
+ A number of standardized list-related header fields have been
+ defined, and many lists add one or more of these header fields.
+ 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".
+
+ Among these list-specific header fields are those specified in RFC
+ 2369 ("The Use of URLs as Meta-Syntax for Core Mail List Commands and
+ their Transport through Message Header Fields") [List-*] and RFC 2919
+ ("List-Id: A Structured Field and Namespace for the Identification
+ of Mailing Lists") [List-ID]. For more information, see Section 5.
+
+ While the mail transport protocol does not differ between regular
+ email recipients and mailing list recipients, lists have special
+ considerations with internationalized email addresses because they
+ retransmit messages composed by other agents to potentially many
+ recipients.
+
+ There are considerations for internationalized email addresses in the
+ envelope as well as in header fields of redistributed messages. In
+ particular, an internationalized message cannot be downgraded unless
+ all envelope addresses are available in ASCII (that is, each address
+ either is ASCII or has an alt-address [UTF8SMTP]).
+
+ 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 might choose to reject all messages from
+ internationalized addresses that lack an alt-address, or even all
+
+
+
+Gellens Experimental [Page 3]
+
+RFC 5983 Mailing Lists and UTF-8 Mail Addresses October 2010
+
+
+ internationalized messages that cannot be downgraded. 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 UTF-8 mail 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 for a
+ missed email in one-to-one communications might not be appropriate
+ when dealing with mailing lists. For example, if a user sends a
+ message that is undeliverable, normally the telephone, instant
+ messaging, or other forms of communication are available to obtain a
+ working address. With mailing lists, the users may not have any
+ recourse. Of course, with mailing lists, the original sender usually
+ does not know if the message was successfully received by any list
+ members or if it was undeliverable to some.
+
+ Conceptually, a mailing list's internationalization can be divided
+ into three capabilities: First, does it have a UTF-8 submission or
+ return-path address? Second, does it accept subscriptions to UTF-8
+ addresses? And third, does it accept [UTF8SMTP] messages? This is
+ explored in Section 4.
+
+ A brief discussion on a few additional considerations for mailing
+ list operation is in Section 6.
+
+2. 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].
+
+3. Scenarios Involving Mailing Lists
+
+ Generally (and exclusively within the scope of this document), an
+ original message is sent to a mailing list as a completely separate
+ and independent transaction from the mailing list agent sending the
+ retransmitted message to one or more list recipients. In both cases,
+ 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 message submission [submission]
+ transaction, or it might choose to include multiple recipients per
+ transaction. (Often, mailing lists are constructed to work in
+ cooperation with, rather than include the functionality of, a message
+ submission server [submission], and hence the list transmits to a
+ single submission server one copy of the retransmitted message, with
+
+
+
+
+
+Gellens Experimental [Page 4]
+
+RFC 5983 Mailing Lists and UTF-8 Mail Addresses October 2010
+
+
+ all list recipients specified in the SMTP envelope. The submission
+ server then decides which recipients to include in which
+ transaction.)
+
+ The retransmitted message sent by the mailing list to its subscribers
+ might need to be downgraded [EAI-Downgrade]. In order for a
+ downgrade to be possible, the return path set by the mailing list
+ agent must be an ASCII address or have an alt-address [UTF8SMTP]
+ specified. In addition, the recipient addresses need to have ASCII
+ addresses available. It may be advisable for mailing list operators
+ to pre-obtain an alt-address for all its internationalized member
+ addresses.
+
+ In the case where a member or non-member with an internationalized
+ email address is sending to a mailing list, no alt-address [UTF8SMTP]
+ is specified, and a downgrade is required, the message cannot be
+ delivered. To protect against this, a UTF8SMTP-aware [UTF8SMTP]
+ mailing list might prefer to reject submissions from
+ internationalized email addresses that lack an alt-address.
+
+ (Note that this 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.
+
+4. Capabilities and Requirements
+
+ There are three primary internationalization capabilities of mailing
+ lists: First, does it have a UTF-8 submission or return-path
+ address? Second, does it allow subscriptions from UTF-8 addresses?
+ And third, does it accept [UTF8SMTP] messages?
+
+ In theory, any list can support any combination of these. In
+ practice, only some offer any benefit. For example, neither allowing
+ UTF-8 addresses to subscribe, nor accepting UTF8SMTP messages, makes
+ much sense without the other (an all-ASCII address might or might not
+ be capable of receiving UTF8SMTP messages, but a UTF-8 address of
+ necessity needs to accept UTF8SMTP messages). Likewise, there is no
+ real benefit to a list in using a UTF-8 submission address unless it
+ also accepts UTF8SMTP messages and permits UTF-8 addresses to
+ subscribe.
+
+ However, requirements for lists can be discussed separately for each
+ of the three capabilities.
+
+ 1. If the list uses a UTF-8 submission or return-path address, it
+ SHOULD specify an alt-address [UTF8SMTP] for it. Clearly, it
+ needs to sit behind a UTF8SMTP-enabled final-delivery SMTP server
+
+
+
+Gellens Experimental [Page 5]
+
+RFC 5983 Mailing Lists and UTF-8 Mail Addresses October 2010
+
+
+ [UTF8SMTP] and delivery agent. Likewise, if a list uses a UTF-8
+ return-path address, then its Message Submission Agent (MSA)
+ [submission] needs to support UTF8SMTP.
+
+ The list's return-path address is usually separate from its
+ submission address (so that delivery reports and other
+ automatically generated messages are not sent to the submission
+ address). For reliability in receiving delivery status
+ notifications, a list MAY choose to use an all-ASCII return path
+ even if it uses a UTF-8 submission address. If the list does use
+ a UTF-8 return path, it MUST specify an alt-address [UTF8SMTP] (or
+ else there is a high risk of being unable to receive non-delivery
+ reports).
+
+ There are also implications for the List-* header fields (see
+ below).
+
+ 2. If it allows UTF-8 addresses to subscribe, it MAY require an alt-
+ address [UTF8SMTP] to be specified for each UTF-8 subscriber.
+
+ Naturally, if it permits UTF-8 addresses to subscribe, it needs a
+ mechanism to accept subscription requests from such addresses
+ (preferably specified in the form <utf8@utf8 <ascii@ascii>>). In
+ order to send email to its subscribers who have UTF-8 addresses,
+ its MSA needs to support [UTF8SMTP].
+
+ 3. If it accepts UTF8SMTP messages, the Message Transfer Agents
+ (MTAs) and Mail Delivery Agent (MDA) in its inbound path need to
+ support UTF8SMTP.
+
+5. List Header Fields
+
+ A number of header fields, specifically for mailing lists, have been
+ introduced in RFCs 2369 and 2919. For example, these include:
+
+ List-Id: List Header Mailing List <list-header.example.com>
+ List-Help: <mailto:list@example.com?subject=help>
+ List-Unsubscribe: <mailto:list@example.com?subject=unsubscribe>
+ List-Subscribe: <mailto:list@example.com?subject=subscribe>
+ List-Post: <mailto:list@example.com>
+ List-Owner: <mailto:listmom@example.com> (Contact Person for Help)
+ List-Archive: <mailto:archive@example.com?subject=index%20list>
+
+ As described in RFC 2369, "The contents of the list header fields
+ mostly consist of angle-bracket ('<', '>') enclosed URLs, with
+ internal whitespace being ignored" [List-*]. For List-ID, RFC 2919
+ specifies that, "The list identifier will, in most cases, appear like
+ a host name in a domain of the list owner" [List-ID].
+
+
+
+Gellens Experimental [Page 6]
+
+RFC 5983 Mailing Lists and UTF-8 Mail Addresses October 2010
+
+
+ Except for the List-ID header field, these mailing list header fields
+ contain URLs [RFC3986]. The most common schemes are generally HTTP,
+ HTTPS, mailto, and FTP. Schemes that permit both URI and
+ Internationalized Resource Identifier (IRI) [IRI] forms should use
+ the URI-encoded form described in [IRI]. Future work may extend
+ these header fields or define replacements to directly support non-
+ encoded UTF-8 in IRIs (for example, [mailto-bis]), but in the absence
+ of such extension or replacement, non-ASCII characters can only
+ appear within when encoded as ASCII. Note that discussion on whether
+ internationalized domain names should be percent encoded or puny
+ coded is ongoing; see [IRI-bis].
+
+ Even without these header fields being extended to support UTF-8,
+ some special provisions may be helpful when downgrading. In
+ particular, if a List-* header field contains a UTF-8 mailto (even
+ encoded in ASCII) followed by an ASCII mailto, it may be advisable
+ not only to copy and preserve the original header field as usual
+ (ENCAPSULATION method of [EAI-Downgrade]), but also to edit the
+ header field to remove the UTF-8 address. Otherwise, a client might
+ run into trouble if the decoded mailto results in a non-ASCII
+ address.
+
+ When mailing lists use a UTF-8 form of a List-* header field, an
+ ASCII form SHOULD also be used. These header fields are vital to
+ good operations and use of mailing lists; caution is called for when
+ considering how to form and use these header fields in a non-ASCII
+ environment.
+
+ The most commonly used URI schemes in List-* header fields tend to be
+ HTTP and mailto. The current specification for mailto does not
+ permit unencoded UTF-8 characters, although work has been proposed to
+ extend or more likely replace mailto in order to permit this. For
+ mailto URIs, a separate consideration is how to include an alternate
+ ASCII address (alt-address) [UTF8SMTP] for a UTF-8 address. Note
+ that the existing ability to specify multiple URLs within each List-*
+ header field provides one solution.
+
+ [List-*] says:
+
+ A list of multiple, alternate, URLs MAY be specified by a comma-
+ separated list of angle-bracket enclosed URLs. The URLs have
+ order of preference from left to right. The client application
+ should use the left most protocol that it supports, or knows how
+ to access by a separate application.
+
+ When a UTF-8 mailto is used in a List-* header field, an alt-address
+ [UTF8SMTP], if available, SHOULD be supplied.
+
+
+
+
+Gellens Experimental [Page 7]
+
+RFC 5983 Mailing Lists and UTF-8 Mail Addresses October 2010
+
+
+ The List-ID header field provides an opaque value that uniquely
+ identifies a list. The intent is that the value of this header field
+ 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, and so
+ forth. Such filters and tests may not properly compare a non-ASCII
+ value that has been encoded into ASCII. 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.
+
+6. Further Discussion
+
+ While mailing lists do not create a significant additional burden to
+ the deployment of internationalized email address functionalities,
+ there are some specific areas that need to be considered when the
+ operator of a mailing list or of a final delivery MTA that serves a
+ mailing list upgrades to internationalized mail.
+
+ 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 header fields composed by a UTF8SMTP-
+ aware user agent [UTF8SMTP] and redistribute it to UTF-8 mail and
+ all-ASCII mail users via systems that are not UTF8SMTP-aware.
+
+ 1. Obtaining Downgrade Information -- for a mailing list, or mail
+ relay server for that matter, which is UTF8SMTP-aware, receiving
+ mail from an internationalized email address, the alt-address
+ [UTF8SMTP] is not required from the sending MTA for the transport
+ to be complete. When the mailing list then retransmits the
+ message to its subscribers, it may encounter paths where a
+ downgrade is needed (if a relay or final MSA does not supports
+ UTF8SMTP). In order to mitigate this situation, the mailing list
+ might perhaps decide to reject all incoming mail from an
+ internationalized email address that lacks an alt-address.
+ However, note that in general, downgrades are not expected to be
+ the normal case.
+
+ 2. Downgrading Considerations for mailto URLs -- UTF-8 addresses in
+ mailto links in List-* header fields will be easier to downgrade
+ if they contain an alt-address [UTF8SMTP].
+
+7. Security Considerations
+
+ Because use of both a UTF-8 address and an alt-address for the same
+ entity introduces a potential ambiguity regarding the identity of
+ list subscribers and message senders, implementers are advised to
+
+
+
+Gellens Experimental [Page 8]
+
+RFC 5983 Mailing Lists and UTF-8 Mail Addresses October 2010
+
+
+ carefully handle authorization decisions regarding subscriptions,
+ sender filters, and other common list administration features. For
+ example, a binding between a UTF-8 address and an ASCII alt-address
+ can be used by an attacker to deny another person admission to an
+ Email Address Internationalization (EAI) mailing list.
+
+ Other relevant security considerations are discussed in the Framework
+ document [EAI-Framework].
+
+8. Acknowledgments
+
+ Edmon Chung of Afilias wrote the original version of this document.
+ Thanks to Harald Alvestrand for his extensive comments. Ted Hardie
+ contributed helpful text on IRIs. Last-Call comments from S.
+ Moonesamy and Amanda Baber, plus shepherd review by Pete Resnick,
+ improved the document.
+
+9. References
+
+9.1. Normative References
+
+ [EAI-Framework]
+ Klensin, J. and Y. Ko, "Overview and Framework for
+ Internationalized Email", RFC 4952, July 2007.
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [List-*] 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.
+
+ [List-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field
+ and Namespace for the Identification of Mailing Lists",
+ RFC 2919, March 2001.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC
+ 3986, January 2005.
+
+ [RFC5335] Abel, Y., Ed., "Internationalized Email Headers", RFC
+ 5335, September 2008.
+
+ [submission]
+ Gellens, R. and J. Klensin, "Message Submission for Mail",
+ RFC 4409, April 2006.
+
+
+
+
+
+Gellens Experimental [Page 9]
+
+RFC 5983 Mailing Lists and UTF-8 Mail Addresses October 2010
+
+
+ [UTF8SMTP] Yao, J., Ed., and W. Mao, Ed., "SMTP Extension for
+ Internationalized Email Addresses", RFC 5336, September
+ 2008.
+
+9.2. Informative References
+
+ [EAI-Downgrade]
+ Fujiwara, K., Ed., and Y. Yoneya, Ed., "Downgrading
+ Mechanism for Email Address Internationalization", RFC
+ 5504, March 2009.
+
+ [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
+ Identifiers (IRIs)", RFC 3987, January 2005.
+
+ [IRI-bis] Duerst, M., Suignard, M., and L. Masinter,
+ "Internationalized Resource Identifiers (IRIs)", Work in
+ Progress, July 2010.
+
+ [mailto-bis]
+ Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
+ URI Scheme", Work in Progress, May 2010.
+
+Author's Address
+
+ Randall Gellens
+ QUALCOMM Incorporated
+ 5775 Morehouse Drive
+ San Diego, CA 92121
+ rg+ietf@qualcomm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens Experimental [Page 10]
+