idnits 2.17.1 draft-ietf-eai-mailinglist-02.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 624. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 593. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1, updated by RFC 4748 (on line 597), which is fine, but *also* found old RFC 3978, Section 5.4, paragraph 1 text on line 616. ** Found boilerplate matching RFC 3978, Section 5.5, updated by RFC 4748 (on line 610), which is fine, but *also* found old RFC 3978, Section 5.5 text on line 624. ** The document seems to lack an RFC 3979 Section 5, para. 1 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 326: '...bmission address, it SHOULD specify an...' RFC 2119 keyword, line 334: '...ications, a list MAY choose to use an ...' RFC 2119 keyword, line 336: '... return path, it MUST specify an alt-a...' RFC 2119 keyword, line 345: '...resses to subscribe, it MAY require an...' RFC 2119 keyword, line 412: '... alternate, URLs MAY be specified by a...' (3 more instances...) 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 == Line 241 has weird spacing: '...ple.tld mai...' ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [KEYWORDS], but that reference does not seem to mention RFC 2119 either. -- 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 (July 2007) is 6130 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 76, but not defined == Unused Reference: 'EAI-SMTPEXT' is defined on line 511, 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: 10 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft: Mailing Lists and Internationalized R. Gellens 2 Email Addresses Qualcomm 3 Document: draft-ietf-eai-mailinglist-02.txt E. Chung 4 Expires: January 2008 Afilias 5 July 2007 7 Mailing Lists and Internationalized Email Addresses 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt The list of 28 Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The IETF Trust (2007). All Rights Reserved. 35 Abstract 37 This document describes considerations for mailing lists with the 38 introduction of internationalized email addressing capabilities. 40 Different scenarios involving interaction between mailing lists and 41 internationalized email addresses are examined. Furthermore, 42 mailing list header fields are discussed. 44 Gellens & Chung [Page 1] Expires January 2008 45 This document makes specific recommendations on how mailing lists 46 should act in various situations. 48 Gellens & Chung [Page 2] Expires January 2008 49 Table of Contents 51 1 Conventions Used in this Document . . . . . . . . . . . . . . 3 52 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3 Scenarios Involving Mailing Lists . . . . . . . . . . . . . 5 54 3.1 Pure Case Scenarios . . . . . . . . . . . . . . . . . . 6 55 3.2 Mixed Case Scenarios . . . . . . . . . . . . . . . . . . 7 56 4 Capabilities and Requirements . . . . . . . . . . . . . . . 8 57 5 List Header Fields . . . . . . . . . . . . . . . . . . . . . 9 58 6 List Management . . . . . . . . . . . . . . . . . . . . . 10 59 7 Further Discussion . . . . . . . . . . . . . . . . . . . . . 11 60 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 61 9 Security Considerations . . . . . . . . . . . . . . . . . . 12 62 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 63 11 Normative References . . . . . . . . . . . . . . . . . . . . 12 64 12 Informative References . . . . . . . . . . . . . . . . . . . 12 65 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 66 Appendix A: Changes from Previous Version . . . . . . . . . . 14 67 Intellectual Property Statement . . . . . . . . . . . . . . . 13 68 Full Copyright Statement . . . . . . . . . . . . . . . . . . 14 69 14 Copyright Statement . . . . . . . . . . . . . . . . . . . . -1 71 1 Conventions Used in this Document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [KEYWORDS]. 77 2 Introduction 79 Mailing lists are an important part of email usage and collaborative 80 communications. The introduction of internationalized email 81 addresses affects mailing lists in three main areas: (1) transport 82 (receiving and sending messages); (2) message headers of received 83 and retransmitted messages; and (3) mailing list operational 84 policies. 86 A mailing list is a mechanism whereby a message may be distributed 87 to multiple recipients by sending to one address. An agent 88 (typically not a human being) at that single address receives the 89 message and then causes the message to be redistributed to a list of 90 recipients. This agent sets the envelope return address of the 91 redistributed message to a different address from that of the 92 original message. Using a different envelope return address 93 (reverse-path) directs error (and other automatically generated) 94 messages to an error handling address associated with the mailing 95 list. (This avoids having error and other automatic messages go to 97 Gellens & Chung [Page 3] Expires January 2008 98 the original sender, who typically doesn't control the list and 99 hence can't do anything about them.) 101 In most cases, the mailing list agent redistributes a received 102 message to its subscribers as a new message, that is, conceptually 103 it uses message submission [submit] (as did the sender of the 104 original message). The exception, where the mailing list is not a 105 separate agent that receives and redistributes messages in separate 106 transactions, but is instead an expansion step within an SMTP 107 transaction where one local address expands to multiple local or 108 non-local addresses, is out of scope for this document. 110 Some mailing lists alter the message header, while others do not. A 111 number of standardized list-related header fields have been defined, 112 and many lists add one or more of these headers. Separate from 113 these standardized list-specific header fields, and despite a 114 history of interoperability problems from doing so, some lists alter 115 or add header fields in an attempt to control where replies are 116 sent. Such lists typically add or replace the "Reply-To" field and 117 some add or replace the "Sender" field. Poorly-behaved lists may 118 alter or replace other fields, including "From". 120 Among these list-specific header fields are those specified in 121 RFC2369 -- The Use of URLs as Meta-Syntax for Core Mail List 122 Commands and their Transport through Message Header Fields [List-*] 123 and RFC2919 -- List-Id: A Structured Field and Namespace for the 124 Identification of Mailing Lists [List-ID]. For more information, 125 see Section 5. 127 While the mail transport protocol does not differ between regular 128 email recipients and mailing list recipients, lists have special 129 considerations with internationalized email addresses because they 130 retransmit messages composed by other agents to potentially many 131 recipients. Discussion of the different scenarios involving mailing 132 lists and internationalized email addresses is in Section 3. 134 There are considerations for internationalized email addresses in 135 the envelope as well as header fields of redistributed messages. In 136 particular, an internationalized message cannot be downgraded unless 137 envelope addresses are in ASCII (which includes use of ALT-ADDRESS). 139 With mailing lists, there are two different types of considerations: 140 first, the purely technical ones involving message handling, error 141 cases, downgrades, and the like, and second, those that arise from 142 the fact that humans use mailing lists to communicate. As an 143 example of the first, mailing lists might choose to reject all 144 messages from internationalized addresses that lack an alt-address, 145 or even all internationalized messages that can not be downgraded. 146 As an example of the second, a user who sends a message to a list 148 Gellens & Chung [Page 4] Expires January 2008 149 often is unaware of the list membership. In particular, the user 150 often doesn't know if the members are i18mail users or not, and 151 often neither the original sender nor the recipients personally know 152 each other. As a consequence of this, remedies that may be readily 153 available for one-to-one communication might not be appropriate when 154 dealing with mailing lists. For example, if a user sends a message 155 which is undeliverable, normally the telephone, instant messaging, 156 or other forms of communication are available to obtain a working 157 address. With mailing lists, the users may not have any recourse. 158 Of course, with mailing lists, the original sender usually does not 159 know if the message was successfully received by any list members, 160 or if it was undeliverable to some. 162 Conceptually, a mailing list's internationalization can be divided 163 into three capabilities: First, does it have a UTF8 submission 164 address? Second, does it accept subscriptions to UTF8 addresses? 165 And third, does it accept UTF8SMTP messages? This is explored in 166 Section 4. 168 A brief discussion on some key considerations for mailing list 169 operation in an internationalized email address environment is 170 proposed in Section 6. This is followed by further discussions in 171 Section 7. 173 3 Scenarios Involving Mailing Lists 175 Expanding from Sections 2.3 ("i18mail mailing list") and 2.6 ("An 176 i18mail user sends to a mailing list with a mix of users") of the 177 Scenarios document [EAI- Scenarios], this section will provide an 178 overview of the different scenarios involving mailing lists and 179 internationalized email addresses. 181 What is worth noting is that generally (and exclusively within the 182 scope of this document) the original message is sent to a mailing 183 list as a completely separate and independent transaction from the 184 mailing list agent sending the retransmitted message to one or more 185 list recipients. In both cases, the message might have only one 186 recipient, or might have multiple recipients. That is, the original 187 message might be sent to additional recipients as well as the 188 mailing list agent, and the mailing list might choose to send the 189 retransmitted message to each list recipient in a separate message 190 submission transaction, or might choose to include multiple 191 recipients per transaction. (Often, mailing lists are constructed to 192 work in cooperation with, rather than include the functionality of, 193 a message submission server, and hence the list transmits to a 194 single submission server one copy of the retransmitted message, with 195 all list recipients specified in the SMTP envelope. The submission 196 server then decides which recipients to include in which 198 Gellens & Chung [Page 5] Expires January 2008 199 transaction.) 201 [[[EDITOR'S NOTE: Is there any value to the text starting here?]]] 203 The following diagram summarizes the conceptual working of a 204 mailing- list (Pure Case): 206 (b) 207 -----> User1@exmaple.tld 208 (a) / (c) 209 User1@example.tld ------> mailing@list.tld ------> User2@example.tld 210 \ (d) 211 -----> ... 213 As observed above, the mail transport transactions (a), (b), (c) and 214 (d) all involves two parties, that is: 1. The mailing list agent; 215 and, 2. The original author / subscriber. These scenarios are 216 essentially the same as those already described in Sections 2.1 and 217 2.4 of the Scenarios document [EAI-Scenarios]. 219 Multiple recipients are involved when additional addresses are 220 included (Mixed Case): 222 -----> User1@exmaple.tld 223 (a) / 224 User1@example.tld ---+--> mailing@list.tld ------> User2@example.tld 225 | ^ \ (d) 226 | | -----> ... 227 | | | 228 v | (e) | 229 cc@example.tld <-----+-------------(reply)--+ 231 Under this situation, scenarios (a) and (e) resemble the situations 232 already described in Sections 2.2 and 2.5 of the Scenarios document 233 [EAI-Scenarios]. More specific discussions based on these two 234 general cases are included below. 236 3.1 Pure Case Scenarios 238 In the Pure Case described above, the following are possible for 239 (a): 241 User1@example.tld mailing@list.tld 242 (1) ASCII ASCII 243 (2) non-ASCII ASCII 245 Gellens & Chung [Page 6] Expires January 2008 246 (3) ASCII non-ASCII 247 (4) non-ASCII non-ASCII 249 Among this set, (1) is simply the conventional case without 250 involving any internationalized email address. (2) and (3) are 251 scenarios described in Section 2.4 -- One i18nmail user sends to one 252 ASCII user -- of the Scenarios document, whereas (4) is described in 253 Section 2.1 -- Two i18nmail users [EAI-Scenarios]. 255 For (d) -- generalizing (b) and (c) -- it may be branched further 256 where: (i) Mailing list contains only ASCII email addresses (ii) 257 Mailing list contains at least one internationalized email address 259 [[[EDITOR'S NOTE: Is there any value to the text ending here?]]] 261 The retransmitted message sent by the mailing list to its 262 subscribers might need to be downgraded [EAI-Downgrade]. In order 263 for a downgrade to be possible, the return path set by the mailing 264 list agent must be an ASCII address or have ALT-ADDRESS specified. 266 list (and/or its MTA) must therefore have the alt-address. In 267 general, it may be prudent for mailing list operators to pre-obtain 268 an alt-address for all its internationalized member addresses. This 269 will ensure that mailing list transactions within members will be 270 able to be delivered and replied to. Further discussion on mailing 271 list policy considerations is included in section 6 of this 272 document. 274 In the specific case where a non-member with an internationalized 275 email address is sending to a mailing list, and that mailing list is 276 UTF8SMTP-aware, and the path to a constituent member calls for a 277 downgrade, the mailing list (and/or its MTA) may not have the alt- 278 address of the non-member's internationalized email address, 279 therefore failing to deliver the message to some members. To 280 protect against this, a UTF8SMTP-aware mailing list might prefer to 281 reject submissions from internationalized email addresses that lack 282 an alt-address. 284 (Note that in the situation is not unique to mailing lists. Mail 285 relays that are UTF8SMTP- aware will potentially encounter the same 286 situation.) Further discussions are included in section 7 of this 287 document. 289 [[[EDITOR'S NOTE: Is there any value to the text starting here?]]] 291 3.2 Mixed Case Scenarios 293 Gellens & Chung [Page 7] Expires January 2008 294 The Mixed Case scenarios are essentially a combination of the 295 discussion in section 3.1 above, plus those described in Section 296 3.2 -- Three i18nmail users -- and, Section 2.5 -- An i18mail user 297 sends to one ascii user and one i18nmail user -- of the Scenarios 298 [EAI- Scenarios] document. 300 Similar issues arise with regards to members versus non-members, 301 especially non-members with an internationalized email address, as 302 discussed in the above section. 304 [[[EDITOR'S NOTE: Is there any value to the text ending here?]]] 306 4 Capabilities and Requirements 308 There are three primary internationalization capabilities of mailing 309 lists: First, does it have a UTF8 submission address? Second, does 310 it allow subscriptions from UTF8 addresses? And third, does it 311 accept UTF8SMTP messages? 313 In theory, any list can support any combination of these. In 314 practice, only some offer any benefit. For example, neither 315 allowing UTF8 addresses to subscribe, nor accepting UTF8SMTP 316 messages, makes much sense without the other (an all-ASCII address 317 might or might not be capable of receiving UTF8SMTP messages, but a 318 UTF8 address of necessity needs to accept UTF8SMTP messages). 319 Likewise, there is no real benefit to a list in using a UTF8 320 submission address unless it also accepts UTF8SMTP messages and 321 permits UTF8 addresses to subscribe. 323 However, requirements for lists can be discussed separately for each 324 of the three capabilities. 326 1. If the list uses a UTF8 submission address, it SHOULD specify an 327 alt-address for it. Clearly, it needs to sit behind a 328 UTF8SMTP-enabled final-delivery SMTP server and delivery agent. 330 The list's return-path address is usually separate from its 331 submission address (so that delivery reports and other 332 automatically-generated messages are not sent to the submission 333 address). For reliability in receiving delivery status 334 notifications, a list MAY choose to use an all-ASCII return-path 335 even if it uses a UTF8 submission address. If the list does use a 336 UTF8 return path, it MUST specify an alt-address (or else there is a 337 high risk of being unable to receive non-delivery reports). 339 Gellens & Chung [Page 8] Expires January 2008 340 It follows that if a list uses a UTF8 submission (or return-path) 341 address, then its MSA needs to support UTF8SMTP. 343 There are also implications for the List-* headers (see below). 345 2. If it allows UTF8 addresses to subscribe, it MAY require an 346 alt-address to be specified for each UTF8 subscriber. 348 Naturally, if it permits UTF8 addresses to subscribe, it needs a 349 mechanism to accept subscription requests from such addresses 350 (preferably specified in the form >). 351 Likewise, its MSA needs to support UTF8SMTP. 353 3. If it accepts UTF8SMTP messages, its MSA needs to support 354 UTF8SMTP. 356 5 List Header Fields 358 A number of header fields specifically for mailing lists have been 359 introduced in RFC2369 and RFC2919. These include, for example: 361 List-Id: List Header Mailing List 362 List-Help: (List Instructions) 363 List-Unsubscribe: 364 List-Subscribe: 365 List-Post: 366 List-Owner: (Contact Person for Help) 367 List-Archive: 369 As described in RFC2369, "The contents of the list header fields 370 mostly consist of angle-bracket ('<', '>') enclosed URLs, with 371 internal whitespace being ignored." [List-*] Whereas RFC2919 372 specifies that, "The list identifier will, in most cases, appear 373 like a host name in a domain of the list owner." [List-ID] 375 These mailing list header fields contain URLs. The most common 376 schemes are generally HTTP, HTTPS, mailto, and FTP. These header 377 fields will need to be extended to support UTF8 addresses. Except 378 for mailto, there are no EAI-specific considerations, since these 379 URLs can use RFC3987 "Internationalized Resource Identifier (IRI)" 380 [IRI]. Note that mailto is being updated in a separate effort 381 (outside of EAI), in [mailto-bis]. 383 The same mechanism should be used for these fields as with other 384 fields specifically discussed in the UTF8-Headers document 385 [EAI-UTF8Headers]. Generally therefore, for fields that contain an 386 internationalized email address, it is preferable for it to be 387 expressed as a UTF8 string. 389 Gellens & Chung [Page 9] Expires January 2008 391 [[[EDITOR'S NOTE: Does RFC 2369 need to be updated to permit the 392 use of IRIs?]]] 394 Downgrading provisions should also follow the mechanism in the 395 downgrading document [EAI-Downgrade]. However, special provisions 396 may be helpful for list-specific headers. In particular, when a 397 List-* header contains a UTF8 mailto followed by an ASCII mailto, it 398 may be advisable to copy and preserve the original header as usual, 399 but also edit the header to remove the UTF8 address. [[[EDITOR'S 400 NOTE: This needs to be vetted by the eai list, and if agreed, the 401 eai-downgrade document adjusted, and if not, deleted from here.]]] 403 For mailto URIs, an additional consideration is how to include an 404 alternative ASCII address (alt-address) for a UTF8 address. The 405 most consistent approach is to extend mailto to permit the same 406 syntax for alt-address as is used in address header fields, that is, 407 >. Until this is done, the existing ability 408 to specify multiple URLs within each List-* header field provides a 409 solution. 411 [List-*] says: 412 A list of multiple, alternate, URLs MAY be specified by a comma- 413 separated list of angle-bracket enclosed URLs. The URLs have 414 order of preference from left to right. The client application 415 should use the left most protocol that it supports, or knows how 416 to access by a separate application. 418 When a UTF8 mailto is used in a List-* header field, an alt-address, 419 if available, SHOULD immediately follow it. 421 This is further discussed in Section 7. 423 6 List Management 425 Given the need potentially to deal with non-UTF8SMTP-aware MTAs in 426 the path of delivery for different members, it is advisable that 427 mailing list operators obtain an alt-address from each member with 428 an internationalized email address before adding the member. 429 [[[EDITOR's NOTE: This contradicts an assumption that the group has 430 been operating under that the sender obviously won't use UTF8SMTP 431 unless his or her MSA and outbound MTAs support it, the recipient 432 won't use a UTF8 address unless his or her final-delivery MTA and 433 delivery agent support UTF8SMTP, and hence downgrading is unlikely 434 in the normal case of UTF8SMTP sender to UTF8SMTP recipient. 435 Accordingly, perhaps this requirement should be deleted or 436 weakened.]]] 438 Gellens & Chung [Page 10] Expires January 2008 439 In consideration for consistent delivery to all members in a 440 mailing- list, a mailing list may want to consider rejecting (or 441 otherwise obtaining alt-address from) a non-member who is 442 interacting with the mailing list from an internationalized email 443 address without specifying an alt-address. This is further 444 discussed in Section 7. 446 It is important that the final delivery MTA and delivery agent not 447 deliver internationalized messages to a mailing list that is not 448 capable of receiving and processing them. Such messages MUST be 449 downgraded or rejected unless the list supports internationalized 450 email. 452 Since a mailing list's MSA needs to support UTF8SMTP in order for it 453 to send internationalized messages (including otherwise ASCII 454 messages to UTF8 addresses), a list MUST NOT accept subscriptions 455 from UTF8 addresses nor accept UTF8SMTP messages unless its MSA 456 supports UTF8SMTP or it is prepared and able to downgrade such 457 messages. 459 7 Further Discussion 461 While mailing lists do not create a significant additional burden to 462 the deployment of internationalized email address functionalities, 463 there are some specific areas that need to be considered when the 464 operator of a mailing list or of a final delivery MTA that serves a 465 mailing list upgrades to internationalized mail. 467 Mailing lists face additional complexity since they redistribute 468 messages composed by other agents. Hence, they may be asked to 469 accept a message with non-ASCII headers composed by a UTF8SMTP-aware 470 user agent, and redistribute it to i18mail and non-i18mail users via 471 systems that are not UTF8SMTP-aware. 473 1. Obtaining Downgrade Information -- for a mailing list, or mail 474 relay server for that matter, that is UTF8SMTP-aware, receiving mail 475 from an internationalized email address, the alt-address is not 476 required from the sending MTA for the transport to be complete. 477 Thereupon when the mailing list retransmits the message to its 478 subscribers, it may encounter paths where a downgrade is called for. 479 In order to mitigate this situation, the mailing list might perhaps 480 decide to reject all incoming mail from an internationalized email 481 address that lacks an alt-address. However, note that in general, 482 downgrades are not expected to be the normal case. 484 Gellens & Chung [Page 11] Expires January 2008 485 2. Downgrading Considerations for mailto URLs -- UTF8 addresses in 486 mailto links in List-* headers will be easier to downgrade if they 487 contain an alt-address. 489 8 IANA Considerations 491 None. 493 9 Security Considerations 495 Security considerations are discussed in the Framework document 496 [EAI-Framework]. 498 10 Acknowledgments 500 TBD. 502 11 Normative References 504 [EAI-Framework] J. Klensin and Y. Ko, "Overview and Framework for 505 Internationalized Email", draft-ietf-eai-framework-00.txt, May 24, 506 2006 508 [EAI-Scenarios] H. Alvestrand, "Internationalized Email Addresses: 509 Scenarios",draft-ietf-eai-scenarios-00.txt , May 12, 2006 511 [EAI-SMTPEXT] J. Yao and W. Mao, "SMTP extension for 512 internationalized email address", draft-ietf-eai-smtpext-00.txt, May 513 12, 2006 515 [EAI-UTF8Headers] J. Yeh, "Internationalized Email Headers", draft- 516 ietf-eai-utf8headers-00.txt, May 30, 2006 518 [EAI-Downgrade] Y. YONEYA and K. Fujiwara, "Downgrading mechanism 519 for Internationalized eMail Address (IMA)", 520 draft-ietf-eai-downgrade- 00.txt, May 26, 2006 522 12 Informative References 524 [mailto-bis] M. Duerst and L. Masinter, "The mailto URI scheme", 525 draft-duerst-mailto-bis-xx (work in progress). 527 Gellens & Chung [Page 12] Expires January 2008 529 [List-*] G. Neufeld and J. Baer, "The Use of URLs as Meta-Syntax for 530 Core Mail List Commands and their Transport through Message Header 531 Fields", July 1998 533 [List-ID] R. Chandhok and G. Wenger, "List-Id: A Structured Field 534 and Namespace for the Identification of Mailing Lists", March 2001 536 [IRI] M. Duerst and M. Suignard,"Internationalized Resource 537 Identifiers (IRIs)", January 2005 539 13 Author's Address 541 Randall Gellens 542 QUALCOMM Incorporated 543 5775 Morehouse Drive 544 San Diego, CA 92121 545 rg+ietf@qualcomm.com 547 Edmon Chung 548 Afilias 549 Suite 204, 4141 Yonge Street, 550 Toronto, Ontario, 551 Canada M2P 2A8 552 edmon@afilias.info 554 Appendix A: Changes from Previous Version 556 THIS SECTION TO BE REMOVED PRIOR TO PUBLICATION. 558 Changes made from version -01 to -02: 559 o Significant changes throughout the document. Sorry. 561 Changes made from version -00 to -01: 562 o Fixed SMTP envelope versus message header confusion. 563 o Fixed erroneous mailing list operation text. 564 o Removed references to ATOMIC. 565 o Removed unneeded scenarios. 566 o Added discussion of human considerations which arise with lists. 567 o Fixed some typos. 569 Intellectual Property Statement 571 The IETF takes no position regarding the validity or scope of any 572 Intellectual Property Rights or other rights that might be claimed 573 to pertain to the implementation or use of the technology described 574 in this document or the extent to which any license under such 575 rights might or might not be available; nor does it represent that 577 Gellens & Chung [Page 13] Expires January 2008 578 it has made any independent effort to identify any such rights. 579 Information on the procedures with respect to rights in RFC 580 documents can be found in BCP 78 and BCP 79. 582 Copies of IPR disclosures made to the IETF Secretariat and any 583 assurances of licenses to be made available, or the result of an 584 attempt made to obtain a general license or permission for the use 585 of such proprietary rights by implementers or users of this 586 specification can be obtained from the IETF on-line IPR repository 587 at http://www.ietf.org/ipr. 589 The IETF invites any interested party to bring to its attention any 590 copyrights, patents or patent applications, or other proprietary 591 rights that may cover technology that may be required to implement 592 this standard. Please address the information to the IETF at 593 ietf-ipr@ietf.org. 595 Full Copyright Statement 597 Copyright (C) The IETF Trust (2007). 599 This document is subject to the rights, licenses and restrictions 600 contained in BCP 78, and except as set forth therein, the authors 601 retain all their rights. 603 This document and the information contained herein are provided on 604 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 605 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 606 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 607 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 608 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 609 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 610 FOR A PARTICULAR PURPOSE. 612 14 Copyright Statement 614 Copyright (C) The Internet Society (2007). This document is subject 615 to the rights, licenses and restrictions contained in BCP 78, and 616 except as set forth therein, the authors retain all their rights. 618 This document and the information contained herein are provided on 619 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 620 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 621 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 622 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 623 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 624 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 626 Gellens & Chung [Page 14] Expires January 2008 627 Gellens & Chung [Page 15] Expires January 2008