idnits 2.17.1 draft-ietf-eai-mailinglist-00.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 33. -- Found old boilerplate from RFC 3978, Section 5.5 on line 316. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There is 1 instance of lines with non-ascii characters in the document. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 153 has weird spacing: '...ple.tld mai...' == 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 (June 19, 2006) is 6514 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: 'RFC2119' is mentioned on line 48, but not defined == Unused Reference: 'EAI-SMTPEXT' is defined on line 327, 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') == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-eai-downgrade (ref. 'EAI-Downgrade') Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Email Address Internationalization (EAI WG) Edmon Chung 3 Internet Draft Afilias 4 5 June 19, 2006 7 Mailing Lists and Internationalized Email Addresses 9 STATUS OF THIS MEMO 11 Internet-Drafts are working documents of the Internet Engineering 12 Task Force (IETF), its areas, and its working groups. Note that 13 other groups may also distribute working documents as Internet- 14 Drafts. Internet-Drafts are draft documents valid for a maximum of 15 six months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet-Drafts as 17 reference material or to cite them other than as "work in progress." 19 The reader is cautioned not to depend on the values that appear in 20 examples to be current or complete, since their purpose is primarily 21 educational. Distribution of this memo is unlimited. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Intellectual Property Rights Statement 30 By submitting this Internet-Draft, each author represents that any 31 applicable patent or other IPR claims of which he or she is aware 32 have been or will be disclosed, and any of which he or she becomes 33 aware will be disclosed, in accordance with Section 6 of BCP 79. 35 Abstract 37 This document describes considerations for mailing-lists with the 38 introduction of internationalized email addressing capabilities. 39 Different scenarios involving interaction between mailing-lists and 40 internationalized email addresses are examined. Furthermore, 41 mailing-list header fields will be discussed. 43 Conventions Used In This Document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in [RFC2119]. 49 Table of Contents 51 1. Introduction....................................................2 52 2. Scenarios Involving Mailing-Lists...............................3 53 2.1 Pure Case Scenarios............................................4 54 2.2 Mixed Case Scenarios...........................................4 55 3. Mailing List Header Fields......................................5 56 4. Managing Mailing Lists with Internationalized Email Address.....5 57 5. Further Discussion..............................................6 58 6. IANA Considerations.............................................6 59 7. Security Considerations.........................................6 60 8. Copyright Statement.............................................6 62 1. Introduction 64 Mailing-lists are an important part of email usage and collaborative 65 communications. The introduction of internationalized email 66 addresses must take into consideration impact on mailing-list 67 functionality. The consideration of mailing-lists in the context of 68 internationalized email addresses includes three main areas: (1) 69 transport protocol; (2) message headers; and (3) mailing-list 70 operation policies. 72 Mailing-lists are generally deployed either as a mass mailer client 73 or act in essence like a mail relay. In the case of a mailer client, 74 the mailing-list program is activated when it receives an email to 75 the mailing-list email account. The message is then sent to the 76 members on the mailing-list. In a relay model, the mail server upon 77 receipt of mail to the mailing-list account, relays the mail to all 78 members. Under both models, the mailing-list program usually 79 rewrites the return-path of the email to the corresponding mailing- 80 list. This allows recipients to observe the original sender of the 81 email, and be able to reply to the mailing-list conveniently. 83 In essence, the mail transport protocol does not differ between 84 regular email accounts and mailing-list accounts. Discussion on the 85 different scenarios involving mailing-lists and internationalized 86 email addresses are included in Section 2. 88 In terms of message headers, internationalized email address 89 considerations are required for the return-path rewrite as well as 90 internationalized email addresses in list fields as specified in 91 RFC2369 -- The Use of URLs as Meta-Syntax for Core Mail List Commands 92 and their Transport through Message Header Fields [RFC2369] and 93 RFC2919 -- List-Id: A Structured Field and Namespace for the 94 Identification of Mailing Lists [RFC2919]. This will be described in 95 Section 3. 97 A brief discussion on some key considerations for mailing-list 98 operation in an internationalized email address environment is 99 proposed in Section 4. This is followed by further discussions in 100 Section 5. 102 2. Scenarios Involving Mailing-Lists 104 Expanding from Sections 2.3 and 2.6 of the Scenarios document [EAI- 105 Scenarios], this section will provide an overview of the different 106 scenarios involving mailing-lists and internationalized email 107 addresses. 109 What is worth noting is that generally, for mailing-lists, each 110 message is transported between a sender email address and a recipient 111 mailing-list address or a sending mailing-list address and a 112 receiving member. A multi-recipient message is usually only a result 113 of situations where a sender includes additional addresses in the 114 "To" or "CC" fields while sending (or replying) to a mailing-list. 116 The following diagram summarizes the conceptual working of a mailing- 117 list (Pure Case): 119 (b) 120 -----> User1@exmaple.tld 121 (a) / (c) 122 User1@example.tld ------> mailing@list.tld ------> User2@example.tld 123 \ (d) 124 -----> ... 126 As observed above, the mail transport transactions (a), (b), (c) and 127 (d) all involves two parties, that is: 1. The mailing-list account; 128 and, 2. The user / member account. These scenarios are essentially 129 the same as those already described in Sections 2.1 and 2.4 of the 130 Scenarios document [EAI-Scenarios]. 132 Multiple recipients are involved usually only when one (or more) 133 additional account(s) is (are) included (Mixed Case): 135 -----> User1@exmaple.tld 136 (a) / 137 User1@example.tld ---+--> mailing@list.tld ------> User2@example.tld 138 | ^ \ (d) 139 | | -----> ... 140 | | | 141 v | (e) | 142 cc@example.tld <-----+-------------(reply)--+ 144 Under this situation, scenarios (a) and (e) resemble the situations 145 already described in Sections 2.2 and 2.5 of the Scenarios document 146 [EAI-Scenarios]. More specific discussions based on these two 147 general cases are included below. 149 2.1 Pure Case Scenarios 151 In the Pure Case described above, the following are possible for (a): 153 User1@example.tld mailing@list.tld 154 (1) ASCII ASCII 155 (2) non-ASCII ASCII 156 (3) ASCII non-ASCII 157 (4) non-ASCII non-ASCII 159 Among this set, (1) is simply the conventional case without involving 160 any internationalized email address. (2) and (3) are scenarios 161 described in Section 2.4 -- One i18nmail user sends to one ASCII user 162 -- of the Scenarios document, whereas (4) is described in Section 2.1 163 -- Two i18nmail users [EAI-Scenarios]. 165 For (d) -- generalizing (b) and (c) -- it may be branched further 166 where: 167 (i) Mailing-list contains only ASCII email addresses 168 (ii) Mailing-list contains at least one internationalized email 169 address 171 For (ii), as the mailing-list is sending out to its members, its MTA 172 may encounter a situation where a downgrade [EAI-Downgrade] may be 173 called for. In order for a downgrade to be possible, the mailing- 174 list (and/or its MTA) must therefore have the alt-address or atomic 175 information. In general, it may be prudent for mailing-list 176 operators to pre-obtain this for all its member accounts. This will 177 ensure that mailing-list transactions within members will be able to 178 be delivered and replied to. Further discussion on mailing-list 179 policy considerations is included in section 4 of this 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 or atomic information of the non-member�s internationalized 186 email address, therefore failing to deliver the mail. Nevertheless, 187 this is not unique for mailing-lists. Mail relays that are UTF8SMTP- 188 aware will potentially encounter the same situation. Further 189 discussions are included in section 5 of this document. 191 2.2 Mixed Case Scenarios 193 The Mixed Case scenarios are essentially a combination of the 194 discussion in section 2.1 above, plus those described in Section 2.2 195 -- Three i18nmail users -- and, Section 2.5 -- An i18mail user sends 196 to one ascii user and one i18nmail user -- of the Scenarios [EAI- 197 Scenarios] document. 199 Similar issues arise with regards to members versus non-members, 200 especially non-members with an internationalized email address, as 201 discussed in the above section. 203 3. Mailing List Header Fields 205 A number of header fields specifically for mailing-lists have been 206 introduced in RFC2369 and RFC2919. These include, for example: 207 List-Id: List Header Mailing List 208 List-Help: (List Instructions) 209 List-Unsubscribe: 210 List-Subscribe: 211 List-Post: 212 List-Owner: (Contact Person for Help) 213 List-Archive: 215 As described in RFC2369, "The contents of the list header fields 216 mostly consist of angle-bracket ('<', '>') enclosed URLs, with 217 internal whitespace being ignored." [RFC2369] Whereas RFC2919 218 specifies that, "The list identifier will, in most cases, appear like 219 a host name in a domain of the list owner." [RFC2919] 221 By and large, the data contained in these mailing-list header fields 222 are URLs which contain email addresses. The same mechanism should be 223 used for these fields as with other fields specifically discussed in 224 the UTF8-Headers document [EAI-UTF8Headers]. Generally therefore, 225 for fields that contain an internationalized email address, it could 226 be expressed as a UTF8 string. 228 Downgrading provisions should also follow the chosen mechanism based 229 on the Downgrading document [EAI-Downgrade]. 231 Because the email addresses will be expressed in URL format, further 232 specifications for presentation and inclusion of the alt-address and 233 atomic information may be necessary, other than simply following 234 RFC3987 Internationalized Resource Identifier (IRI) [RFC3987] 235 specifications. This will be further discussed in Section 5. 237 4. Managing Mailing Lists with Internationalized Email Address 239 Given the need potentially to deal with non-UTF8SMTP-aware MTAs in 240 the path of delivery for different members, it is advisable that 241 mailing-list operators obtain from all members their alt-address or 242 atomic information before setting up the mailing-list (or adding a 243 member with an internationalized email address) 245 In consideration for consistent delivery to all members in a mailing- 246 list, a mailing-list may want to consider rejecting (or otherwise 247 obtaining alt-address or atomic information from) a non-member who is 248 interacting with the mailing-list with an internationalized email 249 address. This is further discussed in Section 5. 251 Furthermore, operators should take caution to avoid setting up of an 252 MTA that is UTF8SMTP-aware with a mailing-list program that is non- 253 aware. This is especially important for mailing-list programs that 254 are based on a mail client and not directly integrated into an MTA. 256 The reverse may be less harmful but nevertheless should also be 257 avoided. 259 5. Further Discussion 261 While generally speaking, mailing-lists do not create additional 262 complexity for the deployment of internationalized email address 263 functionalities, the study in this document does uncover a couple of 264 relevant areas for further consideration. Nevertheless, neither 265 items are entirely unique to mailing-lists. 267 1. Obtaining Downgrade Information -- for a mailing-list, or mail 268 relay server for that matter, that is EAI-aware, receiving email from 269 an internationalized email address, the alt-address or atomic 270 information is not required from the sending MTA for the transport to 271 be complete. Thereupon when the mailing-list "relays" or "explodes" 272 the mail to all its members, it may encounter paths where a downgrade 273 is called for. In order to mitigate this situation, the mailing-list 274 may perhaps decide to reject all incoming mail from any non-member 275 internationalized email address or that alt-address or atomic 276 information is not provided. Alternatively, it may be useful to 277 consider having a mechanism, such as an additional SMTP command, for 278 the receiving MTA (in this case the mailing-list) to request for alt- 279 address or atomic information from the sender. This may be useful in 280 other scenarios as well, such as those concerning multiple 281 recipients. 283 2. Downgrading Considerations for mailto URLs -- downgrading 284 specifications may have to be specified particularly for mailto URLs 285 to take into consideration the presentation of alt-address or atomic 286 information. The UTF8 Headers document [EAI-UTF8Headers] suggests 287 including a parameter within the angled brackets of an email address 288 (e.g. ). In the case of a mailto 289 URL, it may be possible to use the same mechanism, for example, 290 , 291 however this should be further studied. Other places where an 292 internationalized email address could appear in a URL may also 293 require further examination. 295 6. IANA Considerations 297 This document does not make any request to IANA. 299 7. Security Considerations 301 Extensive security considerations have been included in the Framework 302 document [EAI-Framework]. 304 8. Copyright Statement 306 Copyright (C) The Internet Society (2006). This document is subject 307 to the rights, licenses and restrictions contained in BCP 78, and 308 except as set forth therein, the authors retain all their rights. 310 This document and the information contained herein are provided on an 311 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 312 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 313 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 314 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 315 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 316 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 318 References 320 [EAI-Framework] J. Klensin and Y. Ko, "Overview and Framework for 321 Internationalized Email", draft-ietf-eai-framework-00.txt, May 24, 322 2006 324 [EAI-Scenarios] H. Alvestrand, "Internationalized Email Addresses: 325 Scenarios",draft-ietf-eai-scenarios-00.txt , May 12, 2006 327 [EAI-SMTPEXT] J. Yao and W. Mao, "SMTP extension for 328 internationalized email address", draft-ietf-eai-smtpext-00.txt, May 329 12, 2006 331 [EAI-UTF8Headers] J. Yeh, "Internationalized Email Headers", draft- 332 ietf-eai-utf8headers-00.txt, May 30, 2006 334 [EAI-Downgrade] Y. YONEYA and K. Fujiwara, "Downgrading mechanism for 335 Internationalized eMail Address (IMA)", draft-ietf-eai-downgrade- 336 00.txt, May 26, 2006 338 [RFC2369] G. Neufeld and J. Baer, "The Use of URLs as Meta-Syntax for 339 Core Mail List Commands and their Transport through Message Header 340 Fields", July 1998 342 [RFC2919] R. Chandhok and G. Wenger, "List-Id: A Structured Field and 343 Namespace for the Identification of Mailing Lists", March 2001 345 [RFC3987] M. Duerst and M. Suignard,"Internationalized Resource 346 Identifiers (IRIs)", January 2005 348 Authors' Address: 350 Edmon Chung 351 Afilias 352 Suite 204, 4141 Yonge Street, 353 Toronto, Ontario, 354 Canada M2P 2A8 355 edmon@afilias.info