idnits 2.17.1 draft-ietf-eai-mailinglistbis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (July 2012) is 4302 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAI J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Informational R. Gellens 5 Expires: December 31, 2012 Qualcomm Incorporated 6 July 2012 8 Mailing Lists and non-ASCII Addresses 9 draft-ietf-eai-mailinglistbis-05 11 Abstract 13 This document describes considerations for mailing lists with the 14 introduction of non-ASCII UTF-8 email addresses. It outlines some 15 possible scenarios for handling lists with mixtures of non-ASCII and 16 traditional addresses, but does not specify protocol changes or offer 17 implementation or deployment advice. 19 *NOTE TO REVIEWERS: Missing or odd-looking references between 20 sections are due to bugs in xml2rfc. The XML is OK, and the HTML 21 output looks reasonable.* 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 31, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Mailing list header additions and modifications . . . . . 3 58 1.2. Non-ASCII email addresses . . . . . . . . . . . . . . . . 3 59 2. Scenarios Involving Mailing Lists . . . . . . . . . . . . . . 4 60 2.1. Fully SMTPUTF8 lists . . . . . . . . . . . . . . . . . . . 4 61 2.2. Mixed SMTPUTF8 and ASCII lists . . . . . . . . . . . . . . 5 62 2.3. SMTP issues . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. List headers . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. SMTPUTF8 list headers . . . . . . . . . . . . . . . . . . 6 65 3.2. Downgrading list headers . . . . . . . . . . . . . . . . . 7 66 3.3. Subscribers' addresses in downgraded headers . . . . . . . 8 67 4. Security considerations . . . . . . . . . . . . . . . . . . . 8 68 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 9 73 Appendix A.1. Change from -04 to -05 . . . . . . . . . . . . . 9 74 Appendix A.2. Change from -03 to -04 . . . . . . . . . . . . . 9 75 Appendix A.3. Change from -02 to -03 . . . . . . . . . . . . . 9 76 Appendix A.4. Changes up to -02 . . . . . . . . . . . . . . . . 9 77 Appendix A.5. Changes up to -00 . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 This document describes considerations for mailing lists with the 83 introduction of non-ASCII UTF-8 email addresses. The usage of such 84 addresses is described in [RFC6530]. 86 Mailing lists are an important part of email usage and collaborative 87 communications. The introduction of internationalized email 88 addresses affects mailing lists in three main areas: (1) transport 89 (receiving and sending messages); (2) message headers of received and 90 retransmitted messages; and (3) mailing list operational policies. 92 A mailing list is a mechanism that distributes a message to multiple 93 recipients when the originator sends it to a single address. An 94 agent, usually software rather than a person, at that single address 95 receives the message and then causes the message to be redistributed 96 to a list of recipients. This agent usually sets the envelope return 97 address (henceforth called the bounce address) of the redistributed 98 message to a different address from that of the original message. 99 Using a different bounce address directs error and other 100 automatically generated messages to an error handling address 101 associated with the mailing list. This sends error and other 102 automatic messages to the list agent, which can often do something 103 useful with them, rather than to the original sender, who typically 104 doesn't control the list and hence can't do anything about them. 106 In most cases, the mailing list agent redistributes a received 107 message to its subscribers as a new message, that is, conceptually it 108 uses message submission [RFC6409] (as did the sender of the original 109 message). The exception, where the mailing list is not managed by a 110 separate agent that receives and redistributes messages in separate 111 transactions, but is implemented by an expansion step within an SMTP 112 transaction where one local address expands to multiple local or non- 113 local addresses, is not addressed by this document. 115 1.1. Mailing list header additions and modifications 117 Some list agents alter message header fields, while others do not. A 118 number of standardized list-related header fields have been defined, 119 and many lists add one or more of these headers. Separate from these 120 standardized list-specific header fields, and despite a history of 121 interoperability problems from doing so, some lists alter or add 122 header fields in an attempt to control where replies are sent. Such 123 lists typically add or replace the "Reply-To" field and some add or 124 replace the "Sender" field. Some lists alter or replace other 125 fields, including "From". 127 Among these list-specific header fields are those specified in RFCs 128 2369 [RFC2369] and 2919 [RFC2919]. For more information, see Section 129 3. 131 1.2. Non-ASCII email addresses 133 While the mail transport protocol is the same for regular email 134 recipients and mailing list recipients, list agents have special 135 considerations with non-ASCII email addresses because they retransmit 136 messages composed by other agents to potentially many recipients. 138 There are considerations for non-ASCII email addresses in the 139 envelope as well as in header fields of redistributed messages. In 140 particular, a message with non-ASCII addresses in the headers or 141 envelope cannot be sent to non-SMTPUTF8 recipients. 143 With mailing lists, there are two different types of considerations: 144 first, the purely technical ones involving message handling, error 145 cases, and the like, and second, those that arise from the fact that 146 humans use mailing lists to communicate. As an example of the first, 147 list agents might choose to reject all messages from non-ASCII 148 addresses if they are unprepared to handle SMTPUTF8 mail. As an 149 example of the second, a user who sends a message to a list often is 150 unaware of the list membership. In particular, the user often 151 doesn't know if the members are SMTPUTF8 mail users or not, and often 152 neither the original sender nor the recipients personally know each 153 other. As a consequence of this, remedies that may be readily 154 available for one-to-one communication might not be appropriate when 155 dealing with mailing lists. For example, if a user sends a message 156 which is undeliverable, normally the telephone, instant messaging, or 157 other forms of communication are available to obtain a working 158 address. With mailing lists, the users may not have any recourse. 159 Of course, with mailing lists, the original sender usually does not 160 know which list members successfully received a message, or if it was 161 undeliverable to some. 163 Conceptually, a mailing list's internationalization can be divided 164 into three capabilities: First, does the list have a non-ASCII 165 submission address? Second, does the list agent accept subscriptions 166 for addresses containing non-ASCII characters? And third, does the 167 list agent accept messages that require SMTPUTF8 capabilities? 169 If a list has subscribers with ASCII addresses, those subscribers 170 might or might not be able to accept SMTPUTF8 messages. 172 2. Scenarios Involving Mailing Lists 174 Generally (and exclusively within the scope of this document), an 175 original message is sent to a mailing list as a completely separate 176 and independent transaction from the list agent sending the 177 retransmitted message to one or more list recipients. In both cases, 178 the message might be addressed only to the list address, or might 179 have recipients in addition to the list. Furthermore, the list agent 180 might choose to send the retransmitted message to each list recipient 181 in a separate message submission transaction, or might choose to 182 include multiple recipients per transaction. Often, list agents are 183 constructed to work in cooperation with, rather than include the 184 functionality of, a message submission server, and hence the list 185 transmits to a single submission server one copy of the retransmitted 186 message. The submission server then decides which recipients to 187 include in which transaction. 189 2.1. Fully SMTPUTF8 lists 191 Some lists may wish to be fully SMTPUTF8. That is, all subscribers 192 are expected to be able to receive SMTPUTF8 mail. For list hygiene 193 reasons, such a list would probably want to prevent subscriptions 194 from addresses that are unable to receive SMTPUTF8 mail. If a 195 putative subscriber has a non-ASCII address, it must be able to 196 receive SMTPUTF8 mail, but there is no way to tell whether a 197 subscriber with an ASCII address can receive SMTPUTF8 mail short of 198 sending an SMTPUTF8 probe or confirmation message and somehow finding 199 out whether it was delivered, e.g., if the user clicked a link in the 200 confirmation message. 202 2.2. Mixed SMTPUTF8 and ASCII lists 204 Other lists may wish to handle a mixture of SMTPUTF8 and ASCII 205 subscribers, either as a transitional measure as subscribers upgrade 206 to SMTPUTF8-capable mail software, or as an ongoing feature. While 207 it is not possible in general to downgrade SMTPUTF8 mail to ASCII 208 mail, list software might divide the recipients into two sets, 209 SMTPUTF8 and ASCII recipients, and create a downgraded version of 210 SMTPUTF8 list messages to send to ASCII recipients. See Section 3.2 211 and Section 3.3. 213 To determine which set an address belongs in, list software might 214 make the conservative assumption that ASCII addresses get ASCII 215 messages, it might try to probe the address with an SMTPUTF8 test 216 message, or it might let the subscriber set the message format 217 manually, similar to the way that some lists now let subscribers 218 choose between plain text and HTML mail, or individual messages and a 219 daily digest. 221 To determine whether a message needs to be downgraded for ASCII 222 recipients, list software might assume that any message received via 223 an SMTPUTF8 SMTP session is an SMTPUTF8 message, or might examine the 224 headers and body of the message to see whether it needs SMTPUTF8 225 treatment. Depending on the interface between the list software and 226 the MTA and MDA that handle incoming messages, it may not be able to 227 tell the type of session for incoming messages. 229 2.3. SMTP issues 231 Mailing list software usually changes the envelope addresses on each 232 message. The bounce address is set to an address that will return 233 bounces to the list agent, and the recipient addresses are set to the 234 subscribers of the list. For some lists, all messages to a list get 235 the same bounce address. For others, list software may create a 236 bounce address per recipient, or a unique bounce address per message 237 per recipient, bounce management techniques known as Variable 238 Envelope Return Path or VERP [VERP]. 240 The bounce address for a list typically includes the name of the 241 list, so a list with a non-ASCII name will have a non-ASCII bounce 242 address. Given the unknown paths that bounce messages might take, 243 list software might instead use an ASCII bounce address to make it 244 more likely that bounces can be delivered back to the list agent. 245 Similarly, a VERP address for each subscriber typically embeds a 246 version of the subscriber's address so the VERP bounce address for a 247 non-ASCII subscriber address will be a non-ASCII address. For the 248 same reason, the list software might use ASCII bounce addresses that 249 encode the recipient's identity in some other way. 251 3. List headers 253 List agents typically adds list-specific headers to each message 254 before resending the message to list recipients. 256 3.1. SMTPUTF8 list headers 258 The list headers in RFCs 2369 [RFC2369] and 2919 [RFC2919] were all 259 specified before SMTPUTF8 mail existed and their definitions do not 260 address where non-ASCII characters might appear. These include, for 261 example: 263 List-Id: List Header Mailing List 264 265 List-Help: 266 267 List-Unsubscribe: 268 269 List-Subscribe: 270 271 List-Post: 272 273 List-Owner: 274 (Contact Person for Help) 276 List-Archive: 278 As described in [RFC2369], "The contents of the list header fields 279 mostly consist of angle-bracket ('<', '>') enclosed URLs, with 280 internal whitespace being ignored." [RFC2919] specifies that "The 281 list identifier will, in most cases, appear like a host name in a 282 domain of the list owner." Since these headers were defined in the 283 context of ASCII mail, these headers permit only ASCII text including 284 in the URLs. 286 The most commonly-used URI schemes in List-* headers tend to be http 287 and mailto [RFC6068], although they sometimes include https and ftp, 288 and in principle can contain any valid URI. 290 Even if a scheme permits an internationalized form, it should use a 291 pure ASCII form of the URI described in [RFC3986]. Future work may 292 extend these header fields or define replacements to directly support 293 unencoded non-ASCII outside the ASCII repertoire in these and other 294 header fields, but in the absence of such extension or replacement, 295 non-ASCII characters can only be included by encoding them as ASCII. 297 The encoding technique specified in [RFC3986] is to use a pair of hex 298 digits preceded by a percent sign, but percent signs have been used 299 informally in mail addresses to do source routing. Although few mail 300 systems still permit source routing, a lot of mail software still 301 forbids or escapes characters formerly used for source routing, which 302 can lead to unfortunate interactions with percent-encoded URIs or any 303 URI that includes one of those characters. If a program interpreting 304 a mailto: URI knew that the MUA in use were able to handle non-ASCII 305 data, the program could pass the URI in unencoded non-ASCII, avoiding 306 problems with misinterpreted percent signs, but at this point there 307 is no standard or even informal way for MUAs to signal SMTPUTF8 308 capabilities. Also, note that whether internationalized domain names 309 should be percent-encoded or puny-coded depends on the context in 310 which they occur. 312 The List-ID header field uniquely identifies a list. The intent is 313 that the value of this header remain constant, even if the machine or 314 system used to operate or host the list changes. This header field 315 is often used in various filters and tests, such as client-side 316 filters, Sieve filters [RFC5228], and so forth. If the definition of 317 a List-ID header field were to be extended to allow non-ASCII text, 318 filters and tests might not properly compare encoded and unencoded 319 versions of a non-ASCII value. In addition to these comparison 320 considerations, it is generally desirable that this header field 321 contain something meaningful that users can type in. However, ASCII 322 encodings of non-ASCII characters are unlikely to be meaningful to 323 users or easy for them to accurately type. 325 3.2. Downgrading list headers 327 If list software prepares a downgraded version of an SMTPUTF8 328 message, all the List-* headers must be downgraded. In particular, 329 if a List-* header contains a non-ASCII mailto (even encoded in 330 ASCII), it may be advisable to edit the header to remove the non- 331 ASCII address, or replace it with an equivalent ASCII address if one 332 is known to the list software. Otherwise, a client might run into 333 trouble if the decoded mailto results in a non-ASCII address. If a 334 header that contains a mailto URL is downgraded by percent encoding, 335 some mail software may misinterpret the percent signs as attempted 336 source routing. 338 When downgrading list headers, it may not be possible to produce a 339 downgraded version that is satisfactorily equivalent to the original 340 header. In particular, if a non-ASCII List-ID is downgraded to an 341 ASCII version, software and humans at recipient systems will 342 typically not be able to tell that both refer to the same list. 344 If lists permit mail with multiple MIME parts, some MIME headers in 345 SMTPUTF8 messages may include non-ASCII characters in file names and 346 other descriptive text strings. Downgrading these strings may lose 347 the sense of the names, break references from other MIME parts (such 348 as HTML IMG references to embedded images) and otherwise damage the 349 mail. 351 3.3. Subscribers' addresses in downgraded headers 353 List software typically leaves the original submitter's address in 354 the From: line, both so that recipients can tell who wrote the 355 message, and so that they have a choice of responding to the list or 356 directly to the submitter. If a submitter has a non-ASCII address, 357 there is no way to downgrade the From: header and preserve the 358 address so that ASCII recipients can respond to it, since non- 359 SMTPUTF8 mail systems can't send mail to non-ASCII addresses. 361 Possible work arounds (none implemented that we know of) might 362 include allowing subscribers with non-ASCII addresses to register an 363 alternate ASCII address with the list software, having the list 364 software itself create ASCII forwarding addresses, or just putting 365 the list's address in the From: line and losing the ability to 366 respond directly to the submitter. 368 4. Security considerations 370 None beyond what mailing list agents do now. 372 5. IANA considerations 374 *NOTE TO RFC EDITOR: This section may be removed upon publication of 375 this document as an RFC.* 377 This document makes no requests to IANA. 379 6. References 381 6.1. Normative References 383 [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 384 Resource Identifier (URI): Generic Syntax", STD 66, RFC 385 3986, January 2005. 387 [RFC6068] Duerst, M., Masinter, L. and J. Zawinski, "The 'mailto' 388 URI Scheme", RFC 6068, October 2010. 390 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 391 STD 72, RFC 6409, November 2011. 393 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 394 Internationalized Email", RFC 6530, February 2012. 396 6.2. Informative References 398 [RFC2369] Neufeld, G. and J.D. Baer, "The Use of URLs as Meta-Syntax 399 for Core Mail List Commands and their Transport through 400 Message Header Fields", RFC 2369, July 1998. 402 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 403 and Namespace for the Identification of Mailing Lists", 404 RFC 2919, March 2001. 406 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 407 Language", RFC 5228, January 2008. 409 [VERP] "Variable Envelope Return Path", . 411 Appendix A. Change Log 413 *NOTE TO RFC EDITOR: This section may be removed upon publication of 414 this document as an RFC.* 416 Appendix A.1. Change from -04 to -05 418 Add place holder IANA considerations 420 Appendix A.2. Change from -03 to -04 422 Update references 424 Appendix A.3. Change from -02 to -03 426 Distinguish lists from agents. 428 Change refs to EAI to non-ASCII addresses or SMTPUTF8 mail 429 capabilities. 431 Reference for VERP 433 Clarify discussions of IRIs. 435 CapiTALiZe MaiLto and hTTp ConsistentlY. 437 Appendix A.4. Changes up to -02 439 Various editorial changes. 441 Refer to RFC 6068. 443 Appendix A.5. Changes up to -00 445 Rewrite completely. 447 Authors' Addresses 448 John Levine 449 Taughannock Networks 450 PO Box 727 451 Trumansburg, NY 14886 453 Phone: +1 831 480 2300 454 Email: standards@taugh.com 455 URI: http://jl.ly 457 Randall Gellens 458 Qualcomm Incorporated 459 5775 Morehouse Drive 460 San Diego, CA 92121 462 Email: rg+ietf@qualcomm.com