idnits 2.17.1 draft-ietf-eai-mailinglist-07.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 -- 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 (June 28, 2010) is 5044 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4952 (ref. 'EAI-Framework') (Obsoleted by RFC 6530) ** Obsolete normative reference: RFC 5336 (ref. 'UTF8SMTP') (Obsoleted by RFC 6531) -- Obsolete informational reference (is this intentional?): RFC 5504 (ref. 'EAI-Downgrade') (Obsoleted by RFC 6530) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 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-07.txt 6 Expires: December 28, 2010 June 28, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Conventions Used in this Document . . . . . . . . . . . . . 5 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. Introduction 84 This document describes considerations for mailing lists with the 85 introduction of internationalized email addresses. 87 Mailing lists are an important part of email usage and collaborative 88 communications. The introduction of internationalized email 89 addresses affects mailing lists in three main areas: (1) transport 90 (receiving and sending messages); (2) message headers of received 91 and retransmitted messages; and (3) mailing list operational 92 policies. 94 A mailing list is a mechanism whereby a message may be distributed 95 to multiple recipients by sending to one address. An agent 96 (typically not a human being) at that single address receives the 97 message and then causes the message to be redistributed to a list of 98 recipients. This agent sets the envelope return address of the 99 redistributed message to a different address from that of the 100 original message. Using a different envelope return address 101 (reverse-path) directs error (and other automatically generated) 102 messages to an error handling address associated with the mailing 103 list. (This avoids having error and other automatic messages go to 104 the original sender, who typically doesn't control the list and 105 hence can't do anything about them.) 107 In most cases, the mailing list agent redistributes a received 108 message to its subscribers as a new message, that is, conceptually 109 it uses message submission [submission] (as did the sender of the 110 original message). The exception, where the mailing list is not a 111 separate agent that receives and redistributes messages in separate 112 transactions, but is instead an expansion step within an SMTP 113 transaction where one local address expands to multiple local or 114 non-local addresses, is out of scope for this document. 116 Some mailing lists alter message header fields, while others do not. 117 A number of standardized list-related header fields have been 118 defined, and many lists add one or more of these headers. Separate 119 from these standardized list-specific header fields, and despite a 120 history of interoperability problems from doing so, some lists alter 121 or add header fields in an attempt to control where replies are 122 sent. Such lists typically add or replace the "Reply-To" field and 123 some add or replace the "Sender" field. Poorly-behaved lists may 124 alter or replace other fields, including "From". 126 Among these list-specific header fields are those specified in RFC 127 2369 ("The Use of URLs as Meta-Syntax for Core Mail List Commands 128 and their Transport through Message Header Fields") [List-*] and RFC 129 2919 ("List-Id: A Structured Field and Namespace for the 130 Identification of Mailing Lists") [List-ID]. For more information, 131 see Section 5. 133 While the mail transport protocol does not differ between regular 134 email recipients and mailing list recipients, lists have special 135 considerations with internationalized email addresses because they 136 retransmit messages composed by other agents to potentially many 137 recipients. 139 There are considerations for internationalized email addresses in 140 the envelope as well as in header fields of redistributed messages. 141 In particular, an internationalized message cannot be downgraded 142 unless all envelope addresses are available in ASCII (that is, each 143 address either is ASCII or has an alt-address [UTF8SMTP]). 145 With mailing lists, there are two different types of considerations: 146 first, the purely technical ones involving message handling, error 147 cases, downgrades, and the like, and second, those that arise from 148 the fact that humans use mailing lists to communicate. As an 149 example of the first, mailing lists might choose to reject all 150 messages from internationalized addresses that lack an alt-address, 151 or even all internationalized messages that can not be downgraded. 152 As an example of the second, a user who sends a message to a list 153 often is unaware of the list membership. In particular, the user 154 often doesn't know if the members are UTF-8 mail users or not, and 155 often neither the original sender nor the recipients personally know 156 each other. As a consequence of this, remedies that may be readily 157 available for one-to-one communication might not be appropriate when 158 dealing with mailing lists. For example, if a user sends a message 159 which is undeliverable, normally the telephone, instant messaging, 160 or other forms of communication are available to obtain a working 161 address. With mailing lists, the users may not have any recourse. 162 Of course, with mailing lists, the original sender usually does not 163 know if the message was successfully received by any list members, 164 or if it was undeliverable to some. 166 Conceptually, a mailing list's internationalization can be divided 167 into three capabilities: First, does it have a UTF-8 submission or 168 return-path address? Second, does it accept subscriptions to UTF-8 169 addresses? And third, does it accept [UTF8SMTP] messages? This is 170 explored in Section 4. 172 A brief discussion on a few additional considerations for mailing 173 list operation is in Section 6. 175 2. Conventions Used in this Document 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [KEYWORDS]. 181 3. Scenarios Involving Mailing Lists 183 Generally (and exclusively within the scope of this document), an 184 original message is sent to a mailing list as a completely separate 185 and independent transaction from the mailing list agent sending the 186 retransmitted message to one or more list recipients. In both 187 cases, the message might have only one recipient, or might have 188 multiple recipients. That is, the original message might be sent to 189 additional recipients as well as the mailing list agent, and the 190 mailing list might choose to send the retransmitted message to each 191 list recipient in a separate message submission [submission] 192 transaction, or might choose to include multiple recipients per 193 transaction. (Often, mailing lists are constructed to work in 194 cooperation with, rather than include the functionality of, a 195 message submission server [submission], and hence the list transmits 196 to a single submission server one copy of the retransmitted message, 197 with all list recipients specified in the SMTP envelope. The 198 submission server then decides which recipients to include in which 199 transaction.) 201 The retransmitted message sent by the mailing list to its 202 subscribers might need to be downgraded [EAI-Downgrade]. In order 203 for a downgrade to be possible, the return path set by the mailing 204 list agent must be an ASCII address or have alt-address [UTF8SMTP] 205 specified. In addition, the recipient addresses need to have ASCII 206 addresses available. It may be advisable for mailing list operators 207 to pre-obtain an alt-address for all its internationalized member 208 addresses. 210 In the case where a member or non-member with an internationalized 211 email address is sending to a mailing list, no alt-address 212 [UTF8SMTP] is specified, and a downgrade is required, the message 213 cannot be delivered. To protect against this, a UTF8SMTP-aware 214 [UTF8SMTP] mailing list might prefer to reject submissions from 215 internationalized email addresses that lack an alt-address. 217 (Note that the situation is not unique to mailing lists. Mail 218 relays that are UTF8SMTP-aware will potentially encounter the same 219 situation.) Further discussions are included in section 6 of this 220 document. 222 4. Capabilities and Requirements 224 There are three primary internationalization capabilities of mailing 225 lists: First, does it have a UTF-8 submission or return-path 226 address? Second, does it allow subscriptions from UTF-8 addresses? 227 And third, does it accept [UTF8SMTP] messages? 229 In theory, any list can support any combination of these. In 230 practice, only some offer any benefit. For example, neither 231 allowing UTF-8 addresses to subscribe, nor accepting UTF8SMTP 232 messages, makes much sense without the other (an all-ASCII address 233 might or might not be capable of receiving UTF8SMTP messages, but a 234 UTF-8 address of necessity needs to accept UTF8SMTP messages). 235 Likewise, there is no real benefit to a list in using a UTF-8 236 submission address unless it also accepts UTF8SMTP messages and 237 permits UTF-8 addresses to subscribe. 239 However, requirements for lists can be discussed separately for each 240 of the three capabilities. 242 1. If the list uses a UTF-8 submission or return-path address, it 243 SHOULD specify an alt-address [UTF8SMTP] for it. Clearly, it needs 244 to sit behind a UTF8SMTP-enabled final-delivery SMTP server 245 [UTF8SMTP] and delivery agent. Likewise, if a list uses a UTF-8 246 return-path address, then its MSA [submission] needs to support 247 UTF8SMTP. 249 The list's return-path address is usually separate from its 250 submission address (so that delivery reports and other 251 automatically-generated messages are not sent to the submission 252 address). For reliability in receiving delivery status 253 notifications, a list MAY choose to use an all-ASCII return-path 254 even if it uses a UTF-8 submission address. If the list does use a 255 UTF-8 return path, it MUST specify an alt-address [UTF8SMTP] (or 256 else there is a high risk of being unable to receive non-delivery 257 reports). 259 There are also implications for the List-* headers (see below). 261 2. If it allows UTF-8 addresses to subscribe, it MAY require an 262 alt-address [UTF8SMTP] to be specified for each UTF-8 subscriber. 264 Naturally, if it permits UTF-8 addresses to subscribe, it needs a 265 mechanism to accept subscription requests from such addresses 266 (preferably specified in the form >). In 267 order to send email to its subscribers who have UTF-8 addresses, its 268 MSA needs to support [UTF8SMTP]. 270 3. If it accepts UTF8SMTP messages, the MTAs and MDA in its inbound 271 path need to support UTF8SMTP. 273 5. List Header Fields 275 A number of header fields specifically for mailing lists have been 276 introduced in RFC 2369 and RFC 2919. These include, for example: 278 List-Id: List Header Mailing List 279 List-Help: 280 List-Unsubscribe: 281 List-Subscribe: 282 List-Post: 283 List-Owner: (Contact Person for Help) 284 List-Archive: 286 As described in RFC 2369, "The contents of the list header fields 287 mostly consist of angle-bracket ('<', '>') enclosed URLs, with 288 internal whitespace being ignored." [List-*] Whereas RFC2919 289 specifies that, "The list identifier will, in most cases, appear 290 like a host name in a domain of the list owner." [List-ID] 292 These mailing list header fields contain URLs. The most common 293 schemes are generally HTTP, HTTPS, mailto, and FTP. Schemes which 294 permit both URI and IRI [IRI] forms should use the URI-encoded form 295 described in [IRI]. Future work may extend these header fields or 296 define replacements to directly support non-encoded UTF-8 in IRIs 297 (for example, [mailto-bis]), but in the absence of such extension or 298 replacement, non-ASCII characters can only appear within when 299 encoded as ASCII. Note that discussion on whether internationalized 300 domain names should be percent-encoded or puny-coded, is ongoing; 301 see [IRI-bis] 303 Even without these header fields being extended to support UTF-8, 304 some special provisions may be helpful when downgrading. In 305 particular, if a List-* header contains a UTF-8 mailto (even encoded 306 in ASCII) followed by an ASCII mailto, it may be advisable to not 307 only copy and preserve the original header as usual (ENCAPSULATION 308 method of [EAI-Downgrade]), but also to edit the header to remove 309 the UTF-8 address. Otherwise, a client might run into trouble if 310 the decoded mailto results in a non-ASCII address. 312 When mailing lists use a UTF-8 form of a List-* header, an ASCII 313 form SHOULD also be used. These headers are vital to good 314 operations and use of mailing lists; caution is called for when 315 considering how to form and use these headers in a non-ASCII 316 environment. 318 The most commonly-used URI schemes in List-* headers tend to be HTTP 319 and mailto. The current specification for mailto does not permit 320 unencoded UTF-8 characters, although work has been proposed to 321 extend or more likely replace mailto in order to permit this. For 322 mailto URIs, a separate consideration is how to include an alternate 323 ASCII address (alt-address) [UTF8SMTP] for a UTF-8 address. Note 324 that the existing ability to specify multiple URLs within each 325 List-* header field provides one solution. 327 [List-*] says: 328 A list of multiple, alternate, URLs MAY be specified by a comma- 329 separated list of angle-bracket enclosed URLs. The URLs have 330 order of preference from left to right. The client application 331 should use the left most protocol that it supports, or knows how 332 to access by a separate application. 334 When a UTF-8 mailto is used in a List-* header field, an alt-address 335 [UTF8SMTP], if available, SHOULD be supplied. 337 The List-ID header field uniquely identifies a list. The intent is 338 that the value of this header remain constant, even if the machine 339 or system used to operate or host the list changes. This header 340 field is often used in various filters and tests, such as 341 client-side filters, Sieve filters, and so forth. Such filters and 342 tests may not properly compare a non-ASCII value which has been 343 encoded into ASCII. In addition to these comparison considerations, 344 it is generally desirable that this header field contain something 345 meaningful that users can type in. However, ASCII encodings of 346 non-ASCII characters are unlikely to be meaningful to users or easy 347 for them to accurately type. 349 6. Further Discussion 351 While mailing lists do not create a significant additional burden to 352 the deployment of internationalized email address functionalities, 353 there are some specific areas that need to be considered when the 354 operator of a mailing list or of a final delivery MTA that serves a 355 mailing list upgrades to internationalized mail. 357 Mailing lists face additional complexity since they redistribute 358 messages composed by other agents. Hence, they may be asked to 359 accept a message with non-ASCII headers composed by a UTF8SMTP-aware 360 user agent [UTF8SMTP], and redistribute it to UTF-8 mail and 361 all-ASCII mail users via systems that are not UTF8SMTP-aware. 363 1. Obtaining Downgrade Information -- for a mailing list, or mail 364 relay server for that matter, that is UTF8SMTP-aware, receiving mail 365 from an internationalized email address, the alt-address [UTF8SMTP] 366 is not required from the sending MTA for the transport to be 367 complete. When the mailing list then retransmits the message to its 368 subscribers, it may encounter paths where a downgrade is needed (if 369 a relay or final MSA does not supports UTF8SMTP). In order to 370 mitigate this situation, the mailing list might perhaps decide to 371 reject all incoming mail from an internationalized email address 372 that lacks an alt-address. However, note that in general, 373 downgrades are not expected to be the normal case. 375 2. Downgrading Considerations for mailto URLs -- UTF-8 addresses in 376 mailto links in List-* headers will be easier to downgrade if they 377 contain an alt-address [UTF8SMTP]. 379 7. IANA Considerations 381 None. 383 8. Security Considerations 385 Security considerations are discussed in the Framework document 386 [EAI-Framework]. No further security considerations are raised by 387 this document. 389 9. Acknowledgments 391 Edmon Chung of Afilias wrote the original version of this document. 392 Thanks to Harald Alvestrand for his extensive comments. Ted Hardie 393 contributed helpful text on IRIs. Last-call comments from S. 394 Moonesamy and Amanda Baber, plus shepherd review by Pete Resnick, 395 improved the document. 397 10. Normative References 399 [EAI-Framework] J. Klensin and Y. Ko, "Overview and Framework for 400 Internationalized Email", RFC 4952, July 2007. 402 [KEYWORDS] "Key words for use in RFCs to Indicate Requirement 403 Levels", S. Bradner, RFC 2119, BCP 14, March 1997. 405 [List-*] G. Neufeld and J. Baer, "The Use of URLs as Meta-Syntax for 406 Core Mail List Commands and their Transport through Message Header 407 Fields", RFC 2369, July 1998 409 [List-ID] R. Chandhok and G. Wenger, "List-Id: A Structured Field 410 and Namespace for the Identification of Mailing Lists", RFC 2919, 411 March 2001 413 [submission] R. Gellens and J. Klensin, "Message Submission for 414 Mail", RFC 4409, April 2006. 416 [UTF8SMTP] J. Yao and W. Mao, "SMTP Extension for Internationalized 417 Email Addresses", RFC 5336, September 2008. 419 11. Informative References 421 [mailto-bis] M. Duerst and L. Masinter, "The mailto URI scheme", 422 draft-duerst-mailto-bis-xx (work in progress). 424 [IRI] M. Duerst and M. Suignard,"Internationalized Resource 425 Identifiers (IRIs)", RFC 3987, January 2005 427 [IRI-bis], Internationalized Resource Identifiers IETF Working 428 Group, http://datatracker.ietf.org/wg/iri/ 430 [EAI-Downgrade] K. Fujiwara and Y. Yoneya, "Downgrading Mechanism 431 for Email Address Internationalization", RFC 5504, March 2009. 433 12. Authors' Addresses 435 Randall Gellens 436 QUALCOMM Incorporated 437 5775 Morehouse Drive 438 San Diego, CA 92121 439 rg+ietf@qualcomm.com 441 Appendix A: Changes from Previous Version 443 THIS SECTION TO BE REMOVED PRIOR TO PUBLICATION. 445 Changes made from version -06 to -07: 446 o Added explanatory text in section 2 about why a list server's 447 MSA needs to support UTF8SMTP. 448 o Changed section 5 to say that an alt-address should "be 449 supplied" instead of "immediately follow" the UTF-8 address. 450 o Moved [List-*], [List-ID], [submission], and [UTF8SMTP] 451 references from Informative to Normative. 452 o Switched former sections 1 ("Conventions used in this document") 453 and 2 ("Introduction"). 454 o Added new sentence to start of Introduction. 455 o Changed "the message header" to "message header fields" in 456 Introduction. 457 o Added reference to RFC 5336 after some uses of "alt-address". 458 o Made case consistent in "alt-address". 459 o Used sanctioned instead of ad-hoc example domains. 460 o Replaced "i18mail" with "UTF-8 mail". 461 o Added additional people to Acknowledgments. 463 Changes made from version -05 to -06: 464 o Reworded IRI text per Ted Hardie's suggestion. 465 o Added reference to IRI WG. 466 o Deleted remaining fEditor's Note. 468 Changes made from version -04 to -05: 469 o Added [submission] as informative reference. 470 o Normalized "UTF-8" for descriptive terms except as part of 471 hyphenated compounds. 472 o Reworded Introduction text on envelope addresses and ASCII. 473 o Added informative reference to RFC 5336. 474 o Reworded discussion of List-ID in "List Header Fields" section 475 to more clearly explain the risks of using ASCII encodings of 476 non-ASCII characters. 477 o Added text to "Further Discussion" clarifying that downgrade 478 might be needed if an MAA between the list and a subscriber does 479 not support UTF8SMTP. 480 o Corrected some references. 482 Changes made from version -03 to -04: 483 o Rewrote text in Section 5 on List-* headers. Added new text 484 specifically on List-ID. Noted that currently, IRIs in List-* 485 headers must be encoded as ASCII. 487 Changes made from version -02 to -03: 488 o Deleted Section 6. 489 o Restored missing text in third paragraph from the end of Section 490 3.1. 491 o Deleted broken suggestion in Section 5. 492 o Additional text fixes. 493 o Reworked text on List-* header fields. 494 o Removed most Editor's Notes, including deletion of all text that 495 had been followed by an Editor's Note asking if it was useful. 496 o Modified Abstract. 497 o Edited Sections 3, 4, and 5. 499 Changes made from version -01 to -02: 500 o Significant changes throughout the document. Sorry. 502 Changes made from version -00 to -01: 503 o Fixed SMTP envelope versus message header confusion. 504 o Fixed erroneous mailing list operation text. 505 o Removed references to ATOMIC. 506 o Removed unneeded scenarios. 507 o Added discussion of human considerations which arise with lists. 508 o Fixed some typos.