idnits 2.17.1 draft-ietf-eai-mailinglist-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in 'Intended Status: Experimental.', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 23, 2010) is 5148 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4952 (ref. 'EAI-Framework') (Obsoleted by RFC 6530) -- Obsolete informational reference (is this intentional?): RFC 5336 (ref. 'UTF8SMTP') (Obsoleted by RFC 6531) -- Obsolete informational reference (is this intentional?): RFC 5504 (ref. 'EAI-Downgrade') (Obsoleted by RFC 6530) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intended Status: Experimental. 3 Internet Draft: Mailing Lists and Internationalized R. Gellens 4 Email Addresses Qualcomm 5 Document: draft-ietf-eai-mailinglist-06.txt 6 Expires: September 23, 2010 March 23, 2010 8 Mailing Lists and Internationalized Email Addresses 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (c) 2010 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with 41 respect to this document. Code Components extracted from this 42 document must include Simplified BSD License text as described in 43 Section 4.e of the Trust Legal Provisions and are provided without 44 warranty as described in the BSD License. 46 This document may contain material from IETF Documents or IETF 47 Contributions published or made publicly available before November 48 10, 2008. The person(s) controlling the copyright in some of this 49 material may not have granted the IETF Trust the right to allow 50 modifications of such material outside the IETF Standards Process. 51 Without obtaining an adequate license from the person(s) controlling 52 the copyright in such materials, this document may not be modified 53 outside the IETF Standards Process, and derivative works of it may 54 not be created outside the IETF Standards Process, except to format 55 it for publication as an RFC or to translate it into languages other 56 than English. 58 Abstract 60 This document describes considerations for mailing lists with the 61 introduction of internationalized email addresses. 63 This document makes some specific recommendations on how mailing 64 lists should act in various situations. 66 Table of Contents 68 1. Conventions Used in this Document . . . . . . . . . . . . . 3 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Scenarios Involving Mailing Lists . . . . . . . . . . . . . 5 71 4. Capabilities and Requirements . . . . . . . . . . . . . . . 6 72 5. List Header Fields . . . . . . . . . . . . . . . . . . . . 7 73 6. Further Discussion . . . . . . . . . . . . . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 75 8. Security Considerations . . . . . . . . . . . . . . . . . 9 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 9 77 10. Normative References . . . . . . . . . . . . . . . . . . . 9 78 11. Informative References . . . . . . . . . . . . . . . . . . . 10 79 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 10 80 Appendix A: Changes from Previous Version . . . . . . . . . . 10 82 1. Conventions Used in this Document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [KEYWORDS]. 88 2. Introduction 90 Mailing lists are an important part of email usage and collaborative 91 communications. The introduction of internationalized email 92 addresses affects mailing lists in three main areas: (1) transport 93 (receiving and sending messages); (2) message headers of received 94 and retransmitted messages; and (3) mailing list operational 95 policies. 97 A mailing list is a mechanism whereby a message may be distributed 98 to multiple recipients by sending to one address. An agent 99 (typically not a human being) at that single address receives the 100 message and then causes the message to be redistributed to a list of 101 recipients. This agent sets the envelope return address of the 102 redistributed message to a different address from that of the 103 original message. Using a different envelope return address 104 (reverse-path) directs error (and other automatically generated) 105 messages to an error handling address associated with the mailing 106 list. (This avoids having error and other automatic messages go to 107 the original sender, who typically doesn't control the list and 108 hence can't do anything about them.) 109 In most cases, the mailing list agent redistributes a received 110 message to its subscribers as a new message, that is, conceptually 111 it uses message submission [submission] (as did the sender of the 112 original message). The exception, where the mailing list is not a 113 separate agent that receives and redistributes messages in separate 114 transactions, but is instead an expansion step within an SMTP 115 transaction where one local address expands to multiple local or 116 non-local addresses, is out of scope for this document. 118 Some mailing lists alter the message header, while others do not. A 119 number of standardized list-related header fields have been defined, 120 and many lists add one or more of these headers. Separate from 121 these standardized list-specific header fields, and despite a 122 history of interoperability problems from doing so, some lists alter 123 or add header fields in an attempt to control where replies are 124 sent. Such lists typically add or replace the "Reply-To" field and 125 some add or replace the "Sender" field. Poorly-behaved lists may 126 alter or replace other fields, including "From". 128 Among these list-specific header fields are those specified in RFC 129 2369 ("The Use of URLs as Meta-Syntax for Core Mail List Commands 130 and their Transport through Message Header Fields") [List-*] and RFC 131 2919 ("List-Id: A Structured Field and Namespace for the 132 Identification of Mailing Lists") [List-ID]. For more information, 133 see Section 5. 135 While the mail transport protocol does not differ between regular 136 email recipients and mailing list recipients, lists have special 137 considerations with internationalized email addresses because they 138 retransmit messages composed by other agents to potentially many 139 recipients. 141 There are considerations for internationalized email addresses in 142 the envelope as well as in header fields of redistributed messages. 143 In particular, an internationalized message cannot be downgraded 144 unless all envelope addresses are available in ASCII (that is, each 145 address either is ASCII or has an ALT-ADDRESS). 147 With mailing lists, there are two different types of considerations: 148 first, the purely technical ones involving message handling, error 149 cases, downgrades, and the like, and second, those that arise from 150 the fact that humans use mailing lists to communicate. As an 151 example of the first, mailing lists might choose to reject all 152 messages from internationalized addresses that lack an alt-address, 153 or even all internationalized messages that can not be downgraded. 154 As an example of the second, a user who sends a message to a list 155 often is unaware of the list membership. In particular, the user 156 often doesn't know if the members are i18mail users or not, and 157 often neither the original sender nor the recipients personally know 158 each other. As a consequence of this, remedies that may be readily 159 available for one-to-one communication might not be appropriate when 160 dealing with mailing lists. For example, if a user sends a message 161 which is undeliverable, normally the telephone, instant messaging, 162 or other forms of communication are available to obtain a working 163 address. With mailing lists, the users may not have any recourse. 164 Of course, with mailing lists, the original sender usually does not 165 know if the message was successfully received by any list members, 166 or if it was undeliverable to some. 168 Conceptually, a mailing list's internationalization can be divided 169 into three capabilities: First, does it have a UTF-8 submission or 170 return-path address? Second, does it accept subscriptions to UTF-8 171 addresses? And third, does it accept [UTF8SMTP] messages? This is 172 explored in Section 4. 174 A brief discussion on a few additional considerations for mailing 175 list operation is in Section 6. 177 3. Scenarios Involving Mailing Lists 179 Generally (and exclusively within the scope of this document), an 180 original message is sent to a mailing list as a completely separate 181 and independent transaction from the mailing list agent sending the 182 retransmitted message to one or more list recipients. In both 183 cases, the message might have only one recipient, or might have 184 multiple recipients. That is, the original message might be sent to 185 additional recipients as well as the mailing list agent, and the 186 mailing list might choose to send the retransmitted message to each 187 list recipient in a separate message submission [submission] 188 transaction, or might choose to include multiple recipients per 189 transaction. (Often, mailing lists are constructed to work in 190 cooperation with, rather than include the functionality of, a 191 message submission server [submission], and hence the list transmits 192 to a single submission server one copy of the retransmitted message, 193 with all list recipients specified in the SMTP envelope. The 194 submission server then decides which recipients to include in which 195 transaction.) 197 The retransmitted message sent by the mailing list to its 198 subscribers might need to be downgraded [EAI-Downgrade]. In order 199 for a downgrade to be possible, the return path set by the mailing 200 list agent must be an ASCII address or have ALT-ADDRESS specified. 201 In addition, the recipient addresses need to have ASCII addresses 202 available. It may be advisable for mailing list operators to 203 pre-obtain an alt-address for all its internationalized member 204 addresses. 206 In the case where a member or non-member with an internationalized 207 email address is sending to a mailing list, no alt-address is 208 specified, and a downgrade is required, the message cannot be 209 delivered. To protect against this, a UTF8SMTP-aware [UTF8SMTP] 210 mailing list might prefer to reject submissions from 211 internationalized email addresses that lack an alt-address. 213 (Note that the situation is not unique to mailing lists. Mail 214 relays that are UTF8SMTP-aware will potentially encounter the same 215 situation.) Further discussions are included in section 6 of this 216 document. 218 4. Capabilities and Requirements 220 There are three primary internationalization capabilities of mailing 221 lists: First, does it have a UTF-8 submission or return-path 222 address? Second, does it allow subscriptions from UTF-8 addresses? 223 And third, does it accept [UTF8SMTP] messages? 225 In theory, any list can support any combination of these. In 226 practice, only some offer any benefit. For example, neither 227 allowing UTF-8 addresses to subscribe, nor accepting UTF8SMTP 228 messages, makes much sense without the other (an all-ASCII address 229 might or might not be capable of receiving UTF8SMTP messages, but a 230 UTF-8 address of necessity needs to accept UTF8SMTP messages). 231 Likewise, there is no real benefit to a list in using a UTF-8 232 submission address unless it also accepts UTF8SMTP messages and 233 permits UTF-8 addresses to subscribe. 235 However, requirements for lists can be discussed separately for each 236 of the three capabilities. 238 1. If the list uses a UTF-8 submission or return-path address, it 239 SHOULD specify an alt-address for it. Clearly, it needs to sit 240 behind a UTF8SMTP-enabled final-delivery SMTP server [UTF8SMTP] and 241 delivery agent. Likewise, if a list uses a UTF-8 return-path 242 address, then its MSA [submission] needs to support UTF8SMTP. 244 The list's return-path address is usually separate from its 245 submission address (so that delivery reports and other 246 automatically-generated messages are not sent to the submission 247 address). For reliability in receiving delivery status 248 notifications, a list MAY choose to use an all-ASCII return-path 249 even if it uses a UTF-8 submission address. If the list does use a 250 UTF-8 return path, it MUST specify an alt-address (or else there is 251 a high risk of being unable to receive non-delivery reports). 253 There are also implications for the List-* headers (see below). 255 2. If it allows UTF-8 addresses to subscribe, it MAY require an 256 alt-address to be specified for each UTF-8 subscriber. 258 Naturally, if it permits UTF-8 addresses to subscribe, it needs a 259 mechanism to accept subscription requests from such addresses 260 (preferably specified in the form >). 261 Likewise, its MSA needs to support [UTF8SMTP]. 263 3. If it accepts UTF8SMTP messages, its MSA needs to support 264 UTF8SMTP. 266 5. List Header Fields 268 A number of header fields specifically for mailing lists have been 269 introduced in RFC 2369 and RFC 2919. These include, for example: 271 List-Id: List Header Mailing List 272 List-Help: (List Instructions) 273 List-Unsubscribe: 274 List-Subscribe: 275 List-Post: 276 List-Owner: (Contact Person for Help) 277 List-Archive: 279 As described in RFC 2369, "The contents of the list header fields 280 mostly consist of angle-bracket ('<', '>') enclosed URLs, with 281 internal whitespace being ignored." [List-*] Whereas RFC2919 282 specifies that, "The list identifier will, in most cases, appear 283 like a host name in a domain of the list owner." [List-ID] 285 These mailing list header fields contain URLs. The most common 286 schemes are generally HTTP, HTTPS, mailto, and FTP. Schemes which 287 permit both URI and IRI [IRI] forms should use the URI-encoded form 288 described in [IRI]. Future work may extend these header fields or 289 define replacements to directly support non-encoded UTF-8 in IRIs 290 (for example, [mailto-bis]), but in the absence of such extension or 291 replacement, non-ASCII characters can only appear within when 292 encoded as ASCII. Note that discussion on whether internationalized 293 domain names should be percent-encoded or puny-coded, is ongoing; 294 see [IRI-bis] 296 Even without these header fields being extended to support UTF-8, 297 some special provisions may be helpful when downgrading. In 298 particular, if a List-* header contains a UTF-8 mailto (even encoded 299 in ASCII) followed by an ASCII mailto, it may be advisable to not 300 only copy and preserve the original header as usual (ENCAPSULATION 301 method of [EAI-Downgrade]), but also to edit the header to remove 302 the UTF-8 address. Otherwise, a client might run into trouble if 303 the decoded mailto results in a non-ASCII address. 305 When mailing lists use a UTF-8 form of a List-* header, an ASCII 306 form SHOULD also be used. These headers are vital to good 307 operations and use of mailing lists; caution is called for when 308 considering how to form and use these headers in a non-ASCII 309 environment. 311 The most commonly-used URI schemes in List-* headers tend to be HTTP 312 and mailto. The current specification for mailto does not permit 313 unencoded UTF-8 characters, although work has been proposed to 314 extend or more likely replace mailto in order to permit this. For 315 mailto URIs, a separate consideration is how to include an alternate 316 ASCII address (alt-address) for a UTF-8 address. Note that the 317 existing ability to specify multiple URLs within each List-* header 318 field provides one solution. 320 [List-*] says: 321 A list of multiple, alternate, URLs MAY be specified by a comma- 322 separated list of angle-bracket enclosed URLs. The URLs have 323 order of preference from left to right. The client application 324 should use the left most protocol that it supports, or knows how 325 to access by a separate application. 327 When a UTF-8 mailto is used in a List-* header field, an 328 alt-address, if available, SHOULD immediately follow it. 330 The List-ID header field uniquely identifies a list. The intent is 331 that the value of this header remain constant, even if the machine 332 or system used to operate or host the list changes. This header 333 field is often used in various filters and tests, such as 334 client-side filters, Sieve filters, and so forth. Such filters and 335 tests may not properly compare a non-ASCII value which has been 336 encoded into ASCII. In addition to these comparison considerations, 337 it is generally desirable that this header field contain something 338 meaningful that users can type in. However, ASCII encodings of 339 non-ASCII characters are unlikely to be meaningful to users or easy 340 for them to accurately type. 342 6. Further Discussion 344 While mailing lists do not create a significant additional burden to 345 the deployment of internationalized email address functionalities, 346 there are some specific areas that need to be considered when the 347 operator of a mailing list or of a final delivery MTA that serves a 348 mailing list upgrades to internationalized mail. 350 Mailing lists face additional complexity since they redistribute 351 messages composed by other agents. Hence, they may be asked to 352 accept a message with non-ASCII headers composed by a UTF8SMTP-aware 353 user agent [UTF8SMTP], and redistribute it to i18mail and 354 non-i18mail users via systems that are not UTF8SMTP-aware. 356 1. Obtaining Downgrade Information -- for a mailing list, or mail 357 relay server for that matter, that is UTF8SMTP-aware, receiving mail 358 from an internationalized email address, the alt-address is not 359 required from the sending MTA for the transport to be complete. 360 When the mailing list then retransmits the message to its 361 subscribers, it may encounter paths where a downgrade is needed (if 362 a relay or final MSA does not supports UTF8SMTP). In order to 363 mitigate this situation, the mailing list might perhaps decide to 364 reject all incoming mail from an internationalized email address 365 that lacks an alt-address. However, note that in general, 366 downgrades are not expected to be the normal case. 368 2. Downgrading Considerations for mailto URLs -- UTF-8 addresses in 369 mailto links in List-* headers will be easier to downgrade if they 370 contain an alt-address. 372 7. IANA Considerations 374 None. 376 8. Security Considerations 378 Security considerations are discussed in the Framework document 379 [EAI-Framework]. No further security considerations are raised by 380 this document. 382 9. Acknowledgments 384 Edmon Chung of Afilias wrote the original version of this document. 385 Thanks to Harald Alvestrand for his extensive comments. Ted Hardie 386 contributed helpful text on IRIs. 388 10. Normative References 390 [EAI-Framework] J. Klensin and Y. Ko, "Overview and Framework for 391 Internationalized Email", RFC 4952, July 2007. 393 [KEYWORDS] "Key words for use in RFCs to Indicate Requirement 394 Levels", S. Bradner, RFC 2119, BCP 14, March 1997. 396 11. Informative References 398 [mailto-bis] M. Duerst and L. Masinter, "The mailto URI scheme", 399 draft-duerst-mailto-bis-xx (work in progress). 401 [List-*] G. Neufeld and J. Baer, "The Use of URLs as Meta-Syntax for 402 Core Mail List Commands and their Transport through Message Header 403 Fields", RFC 2369, July 1998 405 [List-ID] R. Chandhok and G. Wenger, "List-Id: A Structured Field 406 and Namespace for the Identification of Mailing Lists", RFC 2919, 407 March 2001 409 [IRI] M. Duerst and M. Suignard,"Internationalized Resource 410 Identifiers (IRIs)", RFC 3987, January 2005 412 [IRI-bis], Internationalized Resource Identifiers IETF Working 413 Group, http://datatracker.ietf.org/wg/iri/ 415 [submission] R. Gellens and J. Klensin, "Message Submission for 416 Mail", RFC 4409, April 2006. 418 [UTF8SMTP] J. Yao and W. Mao, "SMTP Extension for Internationalized 419 Email Addresses", RFC 5336, September 2008. 421 [EAI-Downgrade] K. Fujiwara and Y. Yoneya, "Downgrading Mechanism 422 for Email Address Internationalization", RFC 5504, March 2009. 424 12. Authors' Addresses 426 Randall Gellens 427 QUALCOMM Incorporated 428 5775 Morehouse Drive 429 San Diego, CA 92121 430 rg+ietf@qualcomm.com 432 Appendix A: Changes from Previous Version 434 THIS SECTION TO BE REMOVED PRIOR TO PUBLICATION. 436 Changes made from version -05 to -06: 437 o Reworded IRI text per Ted Hardie's suggestion. 438 o Added reference to IRI WG. 439 o Deleted remaining fEditor's Note. 441 Changes made from version -04 to -05: 442 o Added [submission] as informative reference. 443 o Normalized "UTF-8" for descriptive terms except as part of 444 hyphenated compounds. 445 o Reworded Introduction text on envelope addresses and ASCII. 446 o Added informative reference to RFC 5336. 447 o Reworded discussion of List-ID in "List Header Fields" section 448 to more clearly explain the risks of using ASCII encodings of 449 non-ASCII characters. 450 o Added text to "Further Discussion" clarifying that downgrade 451 might be needed if an MAA between the list and a subscriber does 452 not support UTF8SMTP. 453 o Corrected some references. 455 Changes made from version -03 to -04: 456 o Rewrote text in Section 5 on List-* headers. Added new text 457 specifically on List-ID. Noted that currently, IRIs in List-* 458 headers must be encoded as ASCII. 460 Changes made from version -02 to -03: 461 o Deleted Section 6. 462 o Restored missing text in third paragraph from the end of Section 463 3.1. 464 o Deleted broken suggestion in Section 5. 465 o Additional text fixes. 466 o Reworked text on List-* header fields. 467 o Removed most Editor's Notes, including deletion of all text that 468 had been followed by an Editor's Note asking if it was useful. 469 o Modified Abstract. 470 o Edited Sections 3, 4, and 5. 472 Changes made from version -01 to -02: 473 o Significant changes throughout the document. Sorry. 475 Changes made from version -00 to -01: 476 o Fixed SMTP envelope versus message header confusion. 477 o Fixed erroneous mailing list operation text. 478 o Removed references to ATOMIC. 479 o Removed unneeded scenarios. 480 o Added discussion of human considerations which arise with lists. 481 o Fixed some typos.