idnits 2.17.1 draft-ietf-eai-mailinglist-01.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 on line 430. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 399. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1, updated by RFC 4748 (on line 403), which is fine, but *also* found old RFC 3978, Section 5.4, paragraph 1 text on line 422. ** Found boilerplate matching RFC 3978, Section 5.5, updated by RFC 4748 (on line 416), which is fine, but *also* found old RFC 3978, Section 5.5 text on line 430. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.5 boilerplate, a section with a similar start was also found: This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == In addition to RFC 3978, Section 5.5, updated by RFC 4748 boilerplate, a section with a similar start was also found: This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (January 2007) is 6310 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) == Missing Reference: 'KEYWORDS' is mentioned on line 74, but not defined == Unused Reference: 'EAI-Scenarios' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'EAI-SMTPEXT' is defined on line 323, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-eai-framework-00 ** Downref: Normative reference to an Informational draft: draft-ietf-eai-framework (ref. 'EAI-Framework') == Outdated reference: A later version (-03) exists of draft-ietf-eai-scenarios-00 ** Downref: Normative reference to an Informational draft: draft-ietf-eai-scenarios (ref. 'EAI-Scenarios') == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-eai-smtpext (ref. 'EAI-SMTPEXT') == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-eai-utf8headers (ref. 'EAI-UTF8Headers') -- No information found for draft-ietf-eai-downgrade- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'EAI-Downgrade' Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: Mailing Lists and Internationalized R. Gellens 3 Email Addresses Qualcomm 4 Document: draft-ietf-eai-mailinglist-01.txt E. Chung 5 Expires: July 2007 Afilias 6 January 2007 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 (2007). All Rights Reserved. 36 Abstract 38 This document describes considerations for mailing lists with the 39 introduction of internationalized email addressing capabilities. 41 Different scenarios involving interaction between mailing lists and 42 internationalized email addresses are examined. Furthermore, 43 mailing list header fields are discussed. 45 Gellens & Chung [Page 1] Expires July 2007 46 This document makes specific recommendations on how mailing lists 47 should act in various situations. 49 Gellens & Chung [Page 2] Expires July 2007 50 Table of Contents 52 1 Conventions Used in this Document . . . . . . . . . . . . . . 3 53 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3 Scenarios Involving Mailing Lists . . . . . . . . . . . . . 4 55 4 Mailing List Header Fields . . . . . . . . . . . . . . . . 6 56 5 Managing Mailing Lists with Internationalized Email Address 6 57 6 Further Discussion . . . . . . . . . . . . . . . . . . . . 7 58 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 59 8 Security Considerations . . . . . . . . . . . . . . . . . . 8 60 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 61 10 Normative References . . . . . . . . . . . . . . . . . . . . 8 62 11 Informative References . . . . . . . . . . . . . . . . . . . 9 63 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 64 Appendix A: Changes from Previous Version . . . . . . . . . . 10 65 Intellectual Property Statement . . . . . . . . . . . . . . . 9 66 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 67 13 Copyright Statement . . . . . . . . . . . . . . . . . . . . -1 69 1 Conventions Used in this Document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [KEYWORDS]. 75 2 Introduction 77 Mailing lists are an important part of email usage and collaborative 78 communications. The introduction of internationalized email 79 addresses must take into consideration the impact on mailing list 80 functionality. The consideration of mailing lists in the context of 81 internationalized email addresses includes three main areas: (1) 82 transport protocol; (2) message headers; and (3) mailing list 83 operation policies. 85 A mailing list is a mechanism whereby a message may be distributed 86 to multiple recipients by sending to one recipient address. An 87 agent (typically not a human being) at that single address then 88 causes the message to be redistributed to the target recipients. 89 This agent sets the envelope return address of the redistributed 90 message to a different address from that of the original single 91 recipient message. Using a different envelope return address 92 (reverse-path) causes error (and other automatically generated) 93 messages to go to an error handling address associated with the 94 mailing list. (This avoids having error and other automatic messages 95 go to the original sender, who typically doesn't control the list 96 and hence can't do anything about them.) 98 Gellens & Chung [Page 3] Expires July 2007 99 Some mailing lists alter the message header, while others do not. A 100 number of standardized list-related header fields have been defined, 101 and many lists add these headers. Separate from these standardized 102 list-specific header fields, and despite a history of 103 interoperability problems from doing so, some lists alter or add 104 header fields in an attempt to control where replies are sent. Such 105 lists typically add or replace the "Reply-To" field and some add or 106 replace the "Sender" field. Poorly-behaved lists may alter or 107 replace other fields, including "From". 109 While the mail transport protocol does not differ between regular 110 email accounts and mailing list accounts, lists have special 111 considerations with internationalized email addresses because they 112 retransmit to potentially many recipients messages composed by other 113 agents. Discussion of the different scenarios involving mailing 114 lists and internationalized email addresses is in Section 3. 116 Internationalized email address considerations arise in the 117 return-path as well as header fields of redistributed messages. 118 Among these header fields are those specified in RFC2369 -- The Use 119 of URLs as Meta-Syntax for Core Mail List Commands and their 120 Transport through Message Header Fields [RFC2369] and RFC2919 -- 121 List-Id: A Structured Field and Namespace for the Identification of 122 Mailing Lists [RFC2919]. This will be described in Section 4. 124 With mailing lists, there are two different types of considerations: 125 first, the purely technical ones involving message handling, error 126 cases, downgrades, and the like, and second, those that arise from 127 the fact that humans use mailing lists to communicate. As an 128 example of the first, mailing lists may choose to reject all 129 messages from internationalized addresses that lack an alt-address. 130 As an example of the second, a user who sends a message to a list 131 often is unaware of the list membership. In particular, the user 132 often doesn't know if the members are i18mail users or not, and 133 often neither the original sender nor the recipients personally know 134 each other. As a consequence of this, remedies that may be readily 135 available may not be appropriate when dealing with mailing lists. 136 For example, if a user sends a message which is undeliverable, the 137 user can often use the telephone, IM, or other forms of 138 communication to obtain a working address. With mailing lists, the 139 users may not have any recourse. 141 A brief discussion on some key considerations for mailing list 142 operation in an internationalized email address environment is 143 proposed in Section 5. This is followed by further discussions in 144 Section 6. 146 Gellens & Chung [Page 4] Expires July 2007 147 3 Scenarios Involving Mailing Lists 149 Expanding from Sections 2.3 ("i18mail mailing list") and 2.6 ("An 150 i18mail user sends to a mailing list with a mix of users") of the 151 Scenarios document [EAI- Scenarios], this section will provide an 152 overview of the different scenarios involving mailing lists and 153 internationalized email addresses. 155 What is worth noting is that generally, for mailing lists, the 156 original message is sent to the mailing list agent as a completely 157 separate and independenet transaction from the mailing list agent 158 sending the retransmitted message to one or more list recipients. 159 In each case, the message might have only one recipient, or might 160 have multiple recipients. That is, the original message might be 161 sent to additional recipients as well as the mailing list agent, and 162 the mailing list might choose to send the retransmitted message to 163 each list recipient in a separate SMTP transaction, or might choose 164 to include multiple recipients per transaction. (Often, mailing 165 lists are constructed to work in cooperation with, rather than 166 include the functionality of, an SMTP server, and hence the list 167 transmits to a single SMTP server one copy of the retransmitted 168 message, with all list recipients specified in the SMTP envelope.) 170 As the mailing list is sending out to its members, its MTA may 171 encounter a situation where a downgrade [EAI-Downgrade] may be 172 called for. In order for a downgrade to be possible, the mailing- 173 list (and/or its MTA) must therefore have the alt-address. In 174 general, it may be prudent for mailing list operators to pre-obtain 175 an alt-address for all its internationalized member addresses. This 176 will ensure that mailing list transactions within members will be 177 able to be delivered and replied to. Further discussion on mailing 178 list policy considerations is included in section 5 of this 179 document. 181 In the specific case where a non-member with an internationalized 182 email address is sending to a mailing list, and that mailing list is 183 UTF8SMTP-aware, and the path to a constituent member calls for a 184 downgrade, the mailing list (and/or its MTA) may not have the alt- 185 address of the non-member's internationalized email address, 186 therefore failing to deliver the message to some members. To 187 protect against this, a UTF8SMTP-aware mailing list might prefer to 188 reject submissions from internationalized email addresses that lack 189 an alt-address. 191 (Note that in 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 Gellens & Chung [Page 5] Expires July 2007 197 4 Mailing List Header Fields 199 A number of header fields specifically for mailing lists have been 200 introduced in RFC2369 and RFC2919. These include, for example: 202 List-Id: List Header Mailing List 203 List-Help: (List Instructions) 204 List-Unsubscribe: 205 List-Subscribe: 206 List-Post: 207 List-Owner: (Contact Person for Help) 208 List-Archive: 210 As described in RFC2369, "The contents of the list header fields 211 mostly consist of angle-bracket ('<', '>') enclosed URLs, with 212 internal whitespace being ignored." [RFC2369] Whereas RFC2919 213 specifies that, "The list identifier will, in most cases, appear 214 like a host name in a domain of the list owner." [RFC2919] 216 By and large, the data contained in these mailing list header fields 217 are URLs which often contain email addresses. The same mechanism 218 should be used for these fields as with other fields specifically 219 discussed in the UTF8-Headers document [EAI-UTF8Headers]. Generally 220 therefore, for fields that contain an internationalized email 221 address, it could be expressed as a UTF8 string. 223 These fields might contain other URLs, such as HTTP. In these 224 cases, there are no EAI-specific considerations, since these 225 non-mail-related URLs are out of scope for internationalized email 226 documents, and have been addressed elsewhere, such as RFC3987 227 "Internationalized Resource Identifier (IRI)" [RFC3987]. 229 Downgrading provisions should also follow the chosen mechanism based 230 on the Downgrading document [EAI-Downgrade]. 232 Because the email addresses are expressed as "mailto" URLs, further 233 specifications for presentation and inclusion of alt-addresses as 234 well as other considerations may be necessary, other than simply 235 following RFC3987 "Internationalized Resource Identifier (IRI)" 236 [RFC3987] specifications. This will be further discussed in Section 237 6. 239 5 Managing Mailing Lists with Internationalized Email Address 241 Given the need potentially to deal with non-UTF8SMTP-aware MTAs in 242 the path of delivery for different members, it is advisable that 243 mailing list operators obtain an alt-address from each member with 244 an internationalized email address before adding the member. 246 Gellens & Chung [Page 6] Expires July 2007 247 In consideration for consistent delivery to all members in a 248 mailing- list, a mailing list may want to consider rejecting (or 249 otherwise obtaining alt-address from) a non-member who is 250 interacting with the mailing list from an internationalized email 251 address. This is further discussed in Section 6. 253 Furthermore, operators should take caution to avoid setting up an 254 MTA that is UTF8SMTP-aware with a mailing list program that is non- 255 aware. This is especially important for mailing list programs that 256 are based on a mail client and not directly integrated into an MTA. 258 The reverse may be less harmful but nevertheless should also be 259 avoided. 261 6 Further Discussion 263 While generally speaking, mailing lists do not create a significant 264 additional burden to the deployment of internationalized email 265 address functionalities, the study in this document does uncover a 266 couple of relevant areas for further consideration. While neither 267 items is entirely unique to mailing lists, it is true that mailing 268 lists face additional complexity since they redistribute messages 269 composed by other agents. Hence, they may be asked to accept a 270 message with non-ASCII headers composed by a UTF8SMTP-aware user 271 agent, and redistribute it to i18mail and non-i18mail users via 272 systems that are not UTF8SMTP-aware. 274 1. Obtaining Downgrade Information -- for a mailing list, or mail 275 relay server for that matter, that is UTF8SMTP-aware, receiving mail 276 from an internationalized email address, the alt-address is not 277 required from the sending MTA for the transport to be complete. 278 Thereupon when the mailing list retransmits the message to its 279 members, it may encounter paths where a downgrade is called for. In 280 order to mitigate this situation, the mailing list may perhaps 281 decide to reject all incoming mail from an internationalized email 282 address that lacks an alt-address. Alternatively, it may be useful 283 to consider having a mechanism, such as an additional SMTP command, 284 for the receiving MTA (in this case the mailing list) to request the 285 alt- address. This may be useful in other scenarios as well, 286 especially those concerning multiple recipients. 288 2. Downgrading Considerations for mailto URLs -- downgrading 289 specifications may have to be specified particularly for mailto URLs 290 to take into consideration the presentation of alt-address. The 291 UTF8 Headers document [EAI-UTF8Headers] suggests including a 292 parameter within the angle brackets of an email address (e.g., 293 ">"). In the case of a mailto 294 URL, it may be possible to use the same mechanism, for example, 296 Gellens & Chung [Page 7] Expires July 2007 297 "?subject=help" or 298 perhaps "", however this should be further studied. Other 300 places where an internationalized email address could appear in a 301 URL may also require further examination. 303 7 IANA Considerations 305 None. 307 8 Security Considerations 309 Security considerations are discussed in the Framework document 310 [EAI-Framework]. 312 9 Acknowledgments 314 10 Normative References 316 [EAI-Framework] J. Klensin and Y. Ko, "Overview and Framework for 317 Internationalized Email", draft-ietf-eai-framework-00.txt, May 24, 318 2006 320 [EAI-Scenarios] H. Alvestrand, "Internationalized Email Addresses: 321 Scenarios",draft-ietf-eai-scenarios-00.txt , May 12, 2006 323 [EAI-SMTPEXT] J. Yao and W. Mao, "SMTP extension for 324 internationalized email address", draft-ietf-eai-smtpext-00.txt, May 325 12, 2006 327 [EAI-UTF8Headers] J. Yeh, "Internationalized Email Headers", draft- 328 ietf-eai-utf8headers-00.txt, May 30, 2006 330 [EAI-Downgrade] Y. YONEYA and K. Fujiwara, "Downgrading mechanism 331 for Internationalized eMail Address (IMA)", 332 draft-ietf-eai-downgrade- 00.txt, May 26, 2006 334 [RFC2369] G. Neufeld and J. Baer, "The Use of URLs as Meta-Syntax 335 for Core Mail List Commands and their Transport through Message 336 Header Fields", July 1998 338 [RFC2919] R. Chandhok and G. Wenger, "List-Id: A Structured Field 339 and Namespace for the Identification of Mailing Lists", March 2001 341 Gellens & Chung [Page 8] Expires July 2007 343 [RFC3987] M. Duerst and M. Suignard,"Internationalized Resource 344 Identifiers (IRIs)", January 2005 346 11 Informative References 348 12 Author's Address 350 Randall Gellens 351 QUALCOMM Incorporated 352 5775 Morehouse Drive 353 San Diego, CA 92121 354 rg+ietf@qualcomm.com 356 Edmon Chung 357 Afilias 358 Suite 204, 4141 Yonge Street, 359 Toronto, Ontario, 360 Canada M2P 2A8 361 edmon@afilias.info 363 Appendix A: Changes from Previous Version 365 THIS SECTION TO BE REMOVED PRIOR TO PUBLICATION. 367 Changes made from version -00 to -01: 368 o Fixed SMTP envelope versus message header confusion. 369 o Fixed erroneous mailing list operation text. 370 o Removed references to ATOMIC. 371 o Removed unneeded scenarios. 372 o Added discussion of human considerations which arise with lists. 373 o Fixed some typos. 375 Intellectual Property Statement 377 The IETF takes no position regarding the validity or scope of any 378 Intellectual Property Rights or other rights that might be claimed 379 to pertain to the implementation or use of the technology described 380 in this document or the extent to which any license under such 381 rights might or might not be available; nor does it represent that 382 it has made any independent effort to identify any such rights. 383 Information on the procedures with respect to rights in RFC 384 documents can be found in BCP 78 and BCP 79. 386 Copies of IPR disclosures made to the IETF Secretariat and any 387 assurances of licenses to be made available, or the result of an 388 attempt made to obtain a general license or permission for the use 389 of such proprietary rights by implementers or users of this 391 Gellens & Chung [Page 9] Expires July 2007 392 specification can be obtained from the IETF on-line IPR repository 393 at http://www.ietf.org/ipr. 395 The IETF invites any interested party to bring to its attention any 396 copyrights, patents or patent applications, or other proprietary 397 rights that may cover technology that may be required to implement 398 this standard. Please address the information to the IETF at 399 ietf-ipr@ietf.org. 401 Full Copyright Statement 403 Copyright (C) The IETF Trust (2007). 405 This document is subject to the rights, licenses and restrictions 406 contained in BCP 78, and except as set forth therein, the authors 407 retain all their rights. 409 This document and the information contained herein are provided on 410 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 411 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 412 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 413 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 414 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 415 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 416 FOR A PARTICULAR PURPOSE. 418 13 Copyright Statement 420 Copyright (C) The Internet Society (2007). This document is subject 421 to the rights, licenses and restrictions contained in BCP 78, and 422 except as set forth therein, the authors retain all their rights. 424 This document and the information contained herein are provided on 425 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 426 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 427 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 428 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 429 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 430 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 432 Gellens & Chung [Page 10] Expires July 2007