idnits 2.17.1 draft-ietf-eai-mailinglist-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 452. 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 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 20, 2008) is 5636 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) == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-09 ** Downref: Normative reference to an Experimental draft: draft-ietf-eai-downgrade (ref. 'EAI-Downgrade') Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 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-04.txt 6 Expires: May 20, 2009 November 20, 2008 8 Mailing Lists and Internationalized Email Addresses 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt The list of 29 Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The IETF Trust (2008). All Rights Reserved. 36 Abstract 38 This document describes considerations for mailing lists with the 39 introduction of internationalized email addresses. 41 This document makes some specific recommendations on how mailing 42 lists should act in various situations. 44 Table of Contents 46 1. Conventions Used in this Document . . . . . . . . . . . . . 2 47 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 48 3. Scenarios Involving Mailing Lists . . . . . . . . . . . . . 4 49 4. Capabilities and Requirements . . . . . . . . . . . . . . . 5 50 5. List Header Fields . . . . . . . . . . . . . . . . . . . . 6 51 6. Further Discussion . . . . . . . . . . . . . . . . . . . . 7 52 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 53 8. Security Considerations . . . . . . . . . . . . . . . . . 8 54 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8 55 10. Normative References . . . . . . . . . . . . . . . . . . . 8 56 11. Informative References . . . . . . . . . . . . . . . . . . . 9 57 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 9 58 Appendix A: Changes from Previous Version . . . . . . . . . . 9 59 Intellectual Property Statement . . . . . . . . . . . . . . . 10 60 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 62 1. Conventions Used in this Document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [KEYWORDS]. 68 2. Introduction 70 Mailing lists are an important part of email usage and collaborative 71 communications. The introduction of internationalized email 72 addresses affects mailing lists in three main areas: (1) transport 73 (receiving and sending messages); (2) message headers of received 74 and retransmitted messages; and (3) mailing list operational 75 policies. 77 A mailing list is a mechanism whereby a message may be distributed 78 to multiple recipients by sending to one address. An agent 79 (typically not a human being) at that single address receives the 80 message and then causes the message to be redistributed to a list of 81 recipients. This agent sets the envelope return address of the 82 redistributed message to a different address from that of the 83 original message. Using a different envelope return address 84 (reverse-path) directs error (and other automatically generated) 85 messages to an error handling address associated with the mailing 86 list. (This avoids having error and other automatic messages go to 87 the original sender, who typically doesn't control the list and 88 hence can't do anything about them.) 89 In most cases, the mailing list agent redistributes a received 90 message to its subscribers as a new message, that is, conceptually 91 it uses message submission [submit] (as did the sender of the 92 original message). The exception, where the mailing list is not a 93 separate agent that receives and redistributes messages in separate 94 transactions, but is instead an expansion step within an SMTP 95 transaction where one local address expands to multiple local or 96 non-local addresses, is out of scope for this document. 98 Some mailing lists alter the message header, while others do not. A 99 number of standardized list-related header fields have been defined, 100 and many lists add one or more of these headers. Separate from 101 these standardized list-specific header fields, and despite a 102 history of interoperability problems from doing so, some lists alter 103 or add header fields in an attempt to control where replies are 104 sent. Such lists typically add or replace the "Reply-To" field and 105 some add or replace the "Sender" field. Poorly-behaved lists may 106 alter or replace other fields, including "From". 108 Among these list-specific header fields are those specified in 109 RFC2369 -- The Use of URLs as Meta-Syntax for Core Mail List 110 Commands and their Transport through Message Header Fields [List-*] 111 and RFC2919 -- List-Id: A Structured Field and Namespace for the 112 Identification of Mailing Lists [List-ID]. For more information, 113 see Section 5. 115 While the mail transport protocol does not differ between regular 116 email recipients and mailing list recipients, lists have special 117 considerations with internationalized email addresses because they 118 retransmit messages composed by other agents to potentially many 119 recipients. 121 There are considerations for internationalized email addresses in 122 the envelope as well as header fields of redistributed messages. In 123 particular, an internationalized message cannot be downgraded unless 124 envelope addresses are in ASCII (which includes use of ALT-ADDRESS). 126 With mailing lists, there are two different types of considerations: 127 first, the purely technical ones involving message handling, error 128 cases, downgrades, and the like, and second, those that arise from 129 the fact that humans use mailing lists to communicate. As an 130 example of the first, mailing lists might choose to reject all 131 messages from internationalized addresses that lack an alt-address, 132 or even all internationalized messages that can not be downgraded. 133 As an example of the second, a user who sends a message to a list 134 often is unaware of the list membership. In particular, the user 135 often doesn't know if the members are i18mail users or not, and 136 often neither the original sender nor the recipients personally know 137 each other. As a consequence of this, remedies that may be readily 138 available for one-to-one communication might not be appropriate when 139 dealing with mailing lists. For example, if a user sends a message 140 which is undeliverable, normally the telephone, instant messaging, 141 or other forms of communication are available to obtain a working 142 address. With mailing lists, the users may not have any recourse. 143 Of course, with mailing lists, the original sender usually does not 144 know if the message was successfully received by any list members, 145 or if it was undeliverable to some. 147 Conceptually, a mailing list's internationalization can be divided 148 into three capabilities: First, does it have a UTF8 submission or 149 return-path address? Second, does it accept subscriptions to UTF8 150 addresses? And third, does it accept UTF8SMTP messages? This is 151 explored in Section 4. 153 A brief discussion on a few additional considerations for mailing 154 list operation is in Section 6. 156 3. Scenarios Involving Mailing Lists 158 Generally (and exclusively within the scope of this document), an 159 original message is sent to a mailing list as a completely separate 160 and independent transaction from the mailing list agent sending the 161 retransmitted message to one or more list recipients. In both 162 cases, the message might have only one recipient, or might have 163 multiple recipients. That is, the original message might be sent to 164 additional recipients as well as the mailing list agent, and the 165 mailing list might choose to send the retransmitted message to each 166 list recipient in a separate message submission transaction, or 167 might choose to include multiple recipients per transaction. 168 (Often, mailing lists are constructed to work in cooperation with, 169 rather than include the functionality of, a message submission 170 server, and hence the list transmits to a single submission server 171 one copy of the retransmitted message, with all list recipients 172 specified in the SMTP envelope. The submission server then decides 173 which recipients to include in whi ch transaction.) 175 The retransmitted message sent by the mailing list to its 176 subscribers might need to be downgraded [EAI-Downgrade]. In order 177 for a downgrade to be possible, the return path set by the mailing 178 list agent must be an ASCII address or have ALT-ADDRESS specified. 179 In addition, the recipient addresses need to have ASCII addresses 180 available. It may be advisable for mailing list operators to 181 pre-obtain an alt-address for all its internationalized member 182 addresses. 184 In the case where a member or non-member with an internationalized 185 email address is sending to a mailing list, no alt-address is 186 specified, and a downgrade is required, the message cannot be 187 delivered. To protect against this, a UTF8SMTP-aware mailing list 188 might prefer to reject submissions from internationalized email 189 addresses that lack an alt-address. 191 (Note that the situation is not unique to mailing lists. Mail 192 relays that are UTF8SMTP- aware will potentially encounter the same 193 situation.) Further discussions are included in section 6 of this 194 document. 196 4. Capabilities and Requirements 198 There are three primary internationalization capabilities of mailing 199 lists: First, does it have a UTF8 submission or return-path 200 address? Second, does it allow subscriptions from UTF8 addresses? 201 And third, does it accept UTF8SMTP messages? 203 In theory, any list can support any combination of these. In 204 practice, only some offer any benefit. For example, neither 205 allowing UTF8 addresses to subscribe, nor accepting UTF8SMTP 206 messages, makes much sense without the other (an all-ASCII address 207 might or might not be capable of receiving UTF8SMTP messages, but a 208 UTF8 address of necessity needs to accept UTF8SMTP messages). 209 Likewise, there is no real benefit to a list in using a UTF8 210 submission address unless it also accepts UTF8SMTP messages and 211 permits UTF8 addresses to subscribe. 213 However, requirements for lists can be discussed separately for each 214 of the three capabilities. 216 1. If the list uses a UTF8 submission or return-path address, it 217 SHOULD specify an alt-address for it. Clearly, it needs to sit 218 behind a UTF8SMTP-enabled final-delivery SMTP server and delivery 219 agent. Likewise, if a list uses a UTF8 return-path address, then 220 its MSA needs to support UTF8SMTP. 222 The list's return-path address is usually separate from its 223 submission address (so that delivery reports and other 224 automatically-generated messages are not sent to the submission 225 address). For reliability in receiving delivery status 226 notifications, a list MAY choose to use an all-ASCII return-path 227 even if it uses a UTF8 submission address. If the list does use a 228 UTF8 return path, it MUST specify an alt-address (or else there is a 229 high risk of being unable to receive non-delivery reports). 231 There are also implications for the List-* headers (see below). 233 2. If it allows UTF8 addresses to subscribe, it MAY require an 234 alt-address to be specified for each UTF8 subscriber. 236 Naturally, if it permits UTF8 addresses to subscribe, it needs a 237 mechanism to accept subscription requests from such addresses 238 (preferably specified in the form >). 239 Likewise, its MSA needs to support UTF8SMTP. 241 3. If it accepts UTF8SMTP messages, its MSA needs to support 242 UTF8SMTP. 244 5. List Header Fields 246 A number of header fields specifically for mailing lists have been 247 introduced in RFC2369 and RFC2919. These include, for example: 249 List-Id: List Header Mailing List 250 List-Help: (List Instructions) 251 List-Unsubscribe: 252 List-Subscribe: 253 List-Post: 254 List-Owner: (Contact Person for Help) 255 List-Archive: 257 As described in RFC2369, "The contents of the list header fields 258 mostly consist of angle-bracket ('<', '>') enclosed URLs, with 259 internal whitespace being ignored." [List-*] Whereas RFC2919 260 specifies that, "The list identifier will, in most cases, appear 261 like a host name in a domain of the list owner." [List-ID] 263 These mailing list header fields contain URLs. The most common 264 schemes are generally HTTP, HTTPS, mailto, and FTP. The URLs in 265 these fields can use RFC3987 "Internationalized Resource Identifier 266 (IRI)" [IRI] encoded as URLs. Future work may extend these header 267 fields or define replacements to directly support non-encoded UTF8 268 in IRIs (for example, [mailto-bis]), but in the absence of such 269 extension or replacement, non-ASCII characters can only appear 270 within IRIs when properly encoded. Note that internationalized 271 domain names could potentially be either percent-encoded or 272 puny-coded, but punycode is likely to have better results. 274 Even without these header fields being extended to support UTF8, 275 some special provisions may be helpful when downgrading. In 276 particular, when a List-* header contains a UTF8 mailto (even 277 encoded in ASCII) followed by an ASCII mailto, it may be advisable 278 to not only copy and preserve the original header as usual, but also 279 to edit the header to remove the UTF8 address. Otherwise, a 280 non-UTF8-aware client might run into trouble if the decoded mailto 281 results in a non-ASCII address. [[[EDITOR'S NOTE: This needs to be 282 vetted by the eai list.]]] 284 When mailing lists use a UTF8 form of a List-* header, an ASCII form 285 SHOULD also be used. These headers are vital to good operations and 286 use of mailing lists; caution is called for when considering how to 287 form and use these headers in a non-ASCII environment. 289 The most commonly-used URI schemes in List-* headers tend to be HTTP 290 and mailto. The current specification for mailto does not permit 291 unencoded UTF8 characters, although work has been proposed to extend 292 or more likely replace mailto in order to permit this. For mailto 293 URIs, a separate consideration is how to include an alternate ASCII 294 address (alt-address) for a UTF8 address. Note that the existing 295 ability to specify multiple URLs within each List-* header field 296 provides one solution. 298 [List-*] says: 299 A list of multiple, alternate, URLs MAY be specified by a comma- 300 separated list of angle-bracket enclosed URLs. The URLs have 301 order of preference from left to right. The client application 302 should use the left most protocol that it supports, or knows how 303 to access by a separate application. 305 When a UTF8 mailto is used in a List-* header field, an alt-address, 306 if available, SHOULD immediately follow it. 308 The List-ID header filed uniquely identifies a list. The intent is 309 that the value of this header remain constant, even if the machine 310 or system used to operate and host the list changes. This header 311 field is often used in various filters and tests, such as 312 client-side filters, Sieve filters, and so forth. Because of this, 313 great care should be taken, as a non-ASCII value might not match 314 when encoded into ASCII. It is generally desirable that this header 315 field contain something meaningful that users can type in. However, 316 non-ASCII characters encoded into ASCII are unlikely to be 317 meaningful to users or easy for them to accurately type. 319 6. Further Discussion 321 While mailing lists do not create a significant additional burden to 322 the deployment of internationalized email address functionalities, 323 there are some specific areas that need to be considered when the 324 operator of a mailing list or of a final delivery MTA that serves a 325 mailing list upgrades to internationalized mail. 327 Mailing lists face additional complexity since they redistribute 328 messages composed by other agents. Hence, they may be asked to 329 accept a message with non-ASCII headers composed by a UTF8SMTP-aware 330 user agent, and redistribute it to i18mail and non-i18mail users via 331 systems that are not UTF8SMTP-aware. 333 1. Obtaining Downgrade Information -- for a mailing list, or mail 334 relay server for that matter, that is UTF8SMTP-aware, receiving mail 335 from an internationalized email address, the alt-address is not 336 required from the sending MTA for the transport to be complete. 337 Thereupon when the mailing list retransmits the message to its 338 subscribers, it may encounter paths where a downgrade is called for. 339 In order to mitigate this situation, the mailing list might perhaps 340 decide to reject all incoming mail from an internationalized email 341 address that lacks an alt-address. However, note that in general, 342 downgrades are not expected to be the normal case. 344 2. Downgrading Considerations for mailto URLs -- UTF8 addresses in 345 mailto links in List-* headers will be easier to downgrade if they 346 contain an alt-address. 348 7. IANA Considerations 350 None. 352 8. Security Considerations 354 Security considerations are discussed in the Framework document 355 [EAI-Framework]. No further security considerations are raised by 356 this document. 358 9. Acknowledgments 360 Edmon Chung of Afilias wrote the original version of this document. 361 Thanks to Harald Alvestrand for his comments. 363 10. Normative References 365 [EAI-Framework] J. Klensin and Y. Ko, "Overview and Framework for 366 Internationalized Email", RFC 4952, July 2007. 368 [EAI-Downgrade] Y. YONEYA and K. Fujiwara, "Downgrading mechanism 369 for Internationalized eMail Address (IMA)", 370 draft-ietf-eai-downgrade-09.txt (work in progress). 372 [KEYWORDS] "Key words for use in RFCs to Indicate Requirement 373 Levels", S. Bradner, RFC 2119, BCP 14, March 1997. 375 11. Informative References 377 [mailto-bis] M. Duerst and L. Masinter, "The mailto URI scheme", 378 draft-duerst-mailto-bis-xx (work in progress). 380 [List-*] G. Neufeld and J. Baer, "The Use of URLs as Meta-Syntax for 381 Core Mail List Commands and their Transport through Message Header 382 Fields", July 1998 384 [List-ID] R. Chandhok and G. Wenger, "List-Id: A Structured Field 385 and Namespace for the Identification of Mailing Lists", March 2001 387 [IRI] M. Duerst and M. Suignard,"Internationalized Resource 388 Identifiers (IRIs)", January 2005 390 12. Authors' Addresses 392 Randall Gellens 393 QUALCOMM Incorporated 394 5775 Morehouse Drive 395 San Diego, CA 92121 396 rg+ietf@qualcomm.com 398 Appendix A: Changes from Previous Version 400 THIS SECTION TO BE REMOVED PRIOR TO PUBLICATION. 402 Changes made from version -03 to -04: 403 o Rewrote text in Section 5 on List-* headers. Added new text 404 specifically on List-ID. Noted that currently, IRIs in List-* 405 headers must be encoded as ASCII. 407 Changes made from version -02 to -03: 408 o Deleted Section 6. 409 o Restored missing text in third paragraph from the end of Section 410 3.1. 411 o Deleted broken suggestion in Section 5. 412 o Additional text fixes. 413 o Reworked text on List-* header fields. 414 o Removed most Editor's Notes, including deletion of all text that 415 had been followed by an Editor's Note asking if it was useful. 416 o Modified Abstract. 417 o Edited Sections 3, 4, and 5. 419 Changes made from version -01 to -02: 420 o Significant changes throughout the document. Sorry. 422 Changes made from version -00 to -01: 423 o Fixed SMTP envelope versus message header confusion. 424 o Fixed erroneous mailing list operation text. 425 o Removed references to ATOMIC. 426 o Removed unneeded scenarios. 427 o Added discussion of human considerations which arise with lists. 428 o Fixed some typos. 430 Intellectual Property Statement 432 The IETF takes no position regarding the validity or scope of any 433 Intellectual Property Rights or other rights that might be claimed 434 to pertain to the implementation or use of the technology described 435 in this document or the extent to which any license under such 436 rights might or might not be available; nor does it represent that 437 it has made any independent effort to identify any such rights. 438 Information on the procedures with respect to rights in RFC 439 documents can be found in BCP 78 and BCP 79. 441 Copies of IPR disclosures made to the IETF Secretariat and any 442 assurances of licenses to be made available, or the result of an 443 attempt made to obtain a general license or permission for the use 444 of such proprietary rights by implementers or users of this 445 specification can be obtained from the IETF on-line IPR repository 446 at http://www.ietf.org/ipr. 448 The IETF invites any interested party to bring to its attention any 449 copyrights, patents or patent applications, or other proprietary 450 rights that may cover technology that may be required to implement 451 this standard. Please address the information to the IETF at 452 ietf-ipr@ietf.org. 454 Full Copyright Statement 456 Copyright (C) The IETF Trust (2008). 458 This document is subject to the rights, licenses and restrictions 459 contained in BCP 78, and except as set forth therein, the authors 460 retain all their rights. 462 This document and the information contained herein are provided on 463 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 464 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 465 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 466 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 467 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 468 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 469 FOR A PARTICULAR PURPOSE.