idnits 2.17.1 draft-ietf-eai-email-clients-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2009) is 5407 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC 4952' is mentioned on line 89, but not defined ** Obsolete undefined reference: RFC 4952 (Obsoleted by RFC 6530) == Missing Reference: 'RFC 2047' is mentioned on line 404, but not defined == Missing Reference: 'RFC 2231' is mentioned on line 404, but not defined == Unused Reference: 'RFC2822' is defined on line 691, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530) ** Obsolete normative reference: RFC 5335 (Obsoleted by RFC 6532) ** Obsolete normative reference: RFC 5336 (Obsoleted by RFC 6531) ** Obsolete normative reference: RFC 5504 (Obsoleted by RFC 6530) -- Obsolete informational reference (is this intentional?): RFC 4409 (Obsoleted by RFC 6409) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Dainow 3 Internet-Draft Afilias 4 Intended status: Experimental K. Fujiwara 5 Expires: January 8, 2010 JPRS 6 July 8, 2009 8 Guidelines for Internationalized Email Clients 9 draft-ietf-eai-email-clients-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and 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 months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 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. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 8, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document provides some guidelines for email clients that support 48 Email Address Internationalization (EAI) as outlined in RFC 4952. A 49 number of interoperability cases between different versions of email 50 components are reviewed. Recommendations are made to improve 51 interoperability and usability and to minimize discrepancies between 52 the display of composed and received email in different language 53 environments. 55 Table of Contents 57 1. Conventions used in this document..............................3 58 2. Introduction...................................................3 59 2.1. Terminology...............................................3 60 3. Version Interoperability.......................................4 61 3.1. Sending...................................................6 62 3.1.1. Downgrade............................................7 63 3.2. Receiving.................................................8 64 3.2.1. Display of Downgraded Messages As Received...........9 65 3.2.2. Downgraded Display...................................9 66 4. Alternate Addresses...........................................10 67 4.1. Sender...................................................10 68 4.2. Recipients...............................................11 69 4.3. Entry and Display of Alternate Addresses.................11 70 4.4. Mailbox Integration......................................12 71 5. Character Encoding............................................13 72 6. Normalization.................................................13 73 7. Security Considerations.......................................14 74 8. IANA Considerations...........................................14 75 9. Acknowledgments...............................................14 76 10. References...................................................14 77 10.1. Normative References....................................14 78 10.2. Informative References..................................16 79 Author's Addresses...............................................16 81 1. Conventions used in this document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Introduction 89 [RFC 4952] Overview and Framework for Internationalized Email 90 describes changes to electronic mail (email) to fully support 91 internationalized characters. The fundamental change is to remove the 92 ASCII only restriction on email addresses and allow them to contain 93 UTF-8 characters. Additional documents provide detailed 94 specifications for the extensions required to email headers [RFC5335] 95 and to the protocols SMTP [RFC5336], POP [draft-ietf-eai-pop] and 96 IMAP [draft-ietf-eai-imap-utf8]. 98 This document provides guidelines for email clients that support 99 these specifications for Email Address Internationalization (EAI). It 100 does not introduce any protocol extensions that are not defined in 101 the above documents. It highlights the extensions that are important 102 to the design and implementation of email clients and makes a number 103 of recommendations intended to improve interoperability and 104 usability. 106 2.1. Terminology 108 A number of different acronyms are typically used to describe the 109 major functional components of email. 111 Mail User Agent (MUA) 112 Message Submission Agent (MSA) 113 Message Transfer Agent (MTA) 114 Message Delivery Agent (MDA) 115 Message Store (MS) 117 The architecture of modern email systems can range from simple, with 118 all components running on one server, to very complex, with 119 components being distributed across multiple, geographically 120 dispersed machines. Nevertheless, the above terminology is generally 121 sufficient to represent different architectures from a functional 122 point of view. For a comprehensive description of email architecture 123 see [draft-crocker-email-arch]. 125 sender -> MUA -> MSA -> MTA 126 ... 127 MTA -> MDA -> MS -> PIF -> MUA -> recipient 129 (where ... represents possible additional MTA relays) 131 In this context, an "Email Client" is an MUA that has an interface to 132 an MSA to send email and an interface to the MS to retrieve email. 133 The interface to retrieve mail (PIF) is a POP or IMAP server or 134 direct access to the File system. The MUA also provides a User 135 Interface (UI) that allows an end user to read (display) and write 136 (compose) their email. 138 A common email architecture includes the MSA function within the MTA. 139 An improved architecture that better addresses security concerns is a 140 separate MSA component as shown here [RFC4409], [RFC5068]. 142 "UTF8SMTP" is used to indicate email address internationalization as 143 specified by [RFC4952] and related documents. 145 "ASCII" refers to the strict 7-bit ASCII character set [ASCII]. 147 "UTF-8", Unicode Transformation Format/8-bit is a character encoding 148 scheme that can represent any character in the Unicode standard 149 [RFC3629]. It contains ASCII as a subset. 151 "message/global" is an email message that contains UTF-8 characters 152 beyond 7-bit ASCII in message headers and/or body parts [RFC5335]. 154 "message/rfc822" is an email message that contains only 7 bit ASCII 155 and does not use any UTF8SMTP extensions. Note that the original 156 message (as composed by the user) may contain non-ASCII characters 157 that have been encoded into ASCII using IDNA [RFC3490], MIME body 158 encoding [RFC2045] or MIME header encoding [RFC2047]. 160 3. Version Interoperability 162 Not all the components in Internet email systems will get upgraded to 163 UTF8SMTP at the same time. There will be a transition period where 164 upgraded components should be backwards compatible with traditional 165 email components. 167 The following table characterizes the most typical (but not all the 168 possible) email paths between users in different organizations or 169 enterprises (E1, E2, etc.) and highlights the boundaries where 170 incompatibilities will occur most frequently. 172 Cases where email does not cross a jurisdictional boundary between 173 sender and receiver are not shown. This includes email between users 174 within the same organization and email between users in different 175 organizations who use the same third party mail service. 177 | Sending |Receiving 178 Case| MUA |MSA |MTA...MTA |MTA...MTA |MDA |MUA | 179 ----+-----+----+----------+----------+----+----+ 180 1 | E1------------------|E2--------------> | 181 2 | E1--|E2-------------|E3-------------|E4 | 182 3a | E1--|E2-------------|E3--------------> | 183 3b | E1------------------|E2-------------|E3 | 185 It is assumed in all cases that SMTP mail between MTAs uses DNS. 186 Lookup of the MX record for the destination domain means that there 187 is only one boundary of incompatibility between MTAs. 189 Case 1 represents the larger organizations and expert users who 190 manage their own email infrastructure. In these environments there 191 will likely be a coordinated effort to upgrade all components of the 192 email system together. Each organization typically has several MTAs 193 that act as virus scanners, spam filters, mail relays and gateways to 194 manage mail across different divisions and locations of the 195 organization. The boundary of incompatibility is the MTA between the 196 organizations. If both enterprises support UTF8SMTP, they will be 197 able to send Internationalized email without the risk of 198 incompatibility or Downgrade. 200 For large organizations that allow end users to select and install 201 their own email client software, the MUA boundaries are also possible 202 incompatibilities. Users in this category would actually be 203 represented by cases 2 and 3. 205 Case 2 represents the home user and small to medium sized businesses 206 who use the email infrastructure of a third party, such as an ISP 207 (Internet Service Provider) or an outsourced provider. The mail 208 provider has an infrastructure similar to Case 1. The boundaries of 209 incompatibility are at the MUA and between the MTAs of the email 210 providers. 212 Case 3 covers mixed cases where a user with an outsourced email 213 service sends to or receives from a user in an organization that 214 manages its own email infrastructure. The boundaries of 215 incompatibility correspond to Cases 1 and 2. These cases may also 216 apply to some applications within larger organizations. For example, 217 cell phone email may utilize a mail gateway from a third party 218 provider even though the rest of the email infrastructure is in- 219 house. 221 For an MUA, the boundaries where version compatibility is most likely 222 to occur is between home/small office users and their email 223 providers. The worst case scenario is Case 2, where three boundaries 224 of incompatibility are possible between sender and recipient. 226 3.1. Sending 228 For an MUA that supports UTF8SMTP, there is a matrix of possibilities 229 based on whether the email envelope and the message contain non-ASCII 230 characters and whether the MSA supports the UTF8SMTP extensions or 231 not. The following table shows all the possible combinations. 233 Case|Envelope |Message |MSA is |MUA sends 234 | | |UTF8SMTP| 235 ----+----------+---------+--------+----------------- 236 1 |UTF8SMTP |global |Yes |UTF8SMTP 237 2 |UTF8SMTP |rfc822 |Yes |UTF8SMTP 238 3 |ASCII |global |Yes |UTF8SMTP 239 4 |ASCII |rfc822 |Yes |Traditional email 240 5 |UTF8SMTP |global |No |Reject/Downgrade 241 6 |UTF8SMTP |rfc822 |No |Reject/Downgrade 242 7 |ASCII |global |No |Reject/Downgrade 243 8 |ASCII |rfc822 |No |Traditional email 244 ----+----------+---------+--------+----------------- 246 The Envelope and the Message type are considered separately because 247 the Envelope may contain, for example, email addresses that are all 248 ASCII but the Subject or other header fields in the Message may 249 contain non-ASCII (Cases 3, 7). 251 Cases 2 and 6 are unusual since a UTF8SMTP address in the envelope is 252 usually also in the message header. An example of when this can occur 253 is when an rfc822 message is forwarded with server-based forwarding 254 (as with a .forward file) to a UTF8SMTP address. 256 Cases 1-3 258 Messages containing non-ASCII characters SHOULD be sent using the 259 UTF8SMTP extensions in preference to older encoding methods, such as 260 IDNA [RFC3490] and MIME header encoding [RFC2047]. If the message 261 body contains non-ASCII characters, it SHOULD be sent using 8BITMIME 262 [RFC1652] instead of MIME body encoding such as quoted-printable or 263 base64 [RFC2045]. 265 Cases 5-7 267 This could be considered a configuration error. If the MSA does not 268 support UTF8SMTP, the user should upgrade the MSA, or switch to an 269 email provider that supports UTF8SMTP. 271 Upgrading the MSA is a reasonable approach in the case of larger 272 organizations, where an IT group would be expected to synchronize MUA 273 and MSA versions. However, home/small office users may end up in this 274 situation when they have a computer that came with UTF8SMTP email 275 client software and their Internet Service Provider (ISP) does not 276 support UTF8SMTP. 278 In these cases, the MUA MUST NOT submit a message with UTF8SMTP 279 headers if the MSA does not support the UTF8SMTP extensions 280 [RFC5336]-Section 3.2. 282 If the message is not submitted, some guidance should be provided to 283 the user about how to correct the problem. It may also be desirable 284 to save this status and highlight it for the user before they compose 285 a message. This would provide advance warning that internationalized 286 email cannot be sent. 288 3.1.1. Downgrade 290 The MUA MAY support the "downgrade" option, which is specified as an 291 option for all email components MUA, MSA, MTA and MDA. Downgrade 292 builds a message with all ASCII headers so that it is compatible with 293 email components that don't support the UTF8SMTP extensions. 294 Downgrade basically redirects mail from a UTF8SMTP address to an 295 Alternate ASCII Address [RFC5504]. 297 It is not recommended that the MUA support Downgrade for cases 5-7. 298 The user should be encouraged to correct the configuration and 299 upgrade the MSA or switch email providers in order to get support for 300 internationalized email. 302 The following shows an example of downgrading a "From" header with a 303 non-ASCII "Display-Name", non-ASCII email address and ASCII Alternate 304 Address. 306 Original header: 308 From: Display-Name > 310 Downgrade would change the From address to the Alternate Address and 311 preserve the EAI address in a new "Downgraded-From" header. 313 From: =?UTF-8?Q?Display-Name?= 314 Downgraded-From: =?UTF-8?Q?Display-Name?= 315 =?UTF-8?Q?> 317 Note that the Display-Name in the From header is encoded using 318 traditional MIME email standards [RFC2047] with charset UTF-8. The 319 MUA at the recipient end does not need to support the UTF8SMTP 320 extensions to decode and display the original name. 322 Complete examples of Downgrade are shown in the Appendix of 323 [RFC5504]. 325 3.2. Receiving 327 The matrix of possibilities is based on the email message type and 328 whether IMAP/POP and the MUA support the UTF8SMTP extensions or 329 not(Y/N) [draft-ietf-eai-imap-utf8], [draft-ietf-eai-pop]. 331 Case|Original|Spooled |IMAP|Transfered|MUA|Displayed 332 |Message |Message |/POP|Message | |Message 333 ----+--------+----------+----+----------+---+---------- 334 1 |global |global | Y |global | Y |global 335 2 |global |global | Y |downgraded| N |downgraded 336 3 |global |global | N | - |Y/N| - 337 4a |global |downgraded|Y/N |downgraded| Y |downgraded 338 4b |global |downgraded|Y/N |downgraded| Y |global 339 5 |global |downgraded|Y/N |downgraded| N |downgraded 340 6 |rfc822 |rfc822 |Y/N |rfc822 |Y/N|rfc822 341 ----+--------+----------+----+----------+---+---------- 343 Note that the cases in which the recipient receives the message as 344 sent are 1 (all UTF8SMTP), 6 (traditional email) and 4b (downgraded 345 conversion display). 347 In cases 2, 4a and 5 the recipient receives a downgraded message. 349 Case 2 351 IMAP or POP must support Downgrade for this configuration. Direct 352 maildrop access for message/global is prohibited if the MUA does not 353 support UTF8SMTP. 355 Case 3 357 This is a configuration error. If IMAP or POP does not support 358 UTF8SMTP, then it is not possible for the MUA to receive global 359 messages. 361 Cases 4-6 363 An ASCII message may be received from either a UTF8SMTP or a non- 364 UTF8SMTP interface. 366 It is possible that the original message was a UTF8SMTP message that 367 got downgraded to ASCII in transit. A message can be identified as 368 downgraded because it will have one or more headers that are prefixed 369 with "Downgraded-". 371 (Case 4a) A UTF8SMTP compliant MUA MAY display a downgraded message 372 as received, or (Case 4b) it MAY apply a conversion to restore the 373 information contained in the "Downgraded-" headers as specified in 374 [draft-ietf-eai-downgraded-display]. 376 3.2.1. Display of Downgraded Messages As Received 378 Cases 2, 4a, 5 380 When displaying a downgraded message as received, UTF8SMTP addresses 381 that had Alternate Addresses in the original email will not be shown 382 in the headers when reading, replying or forwarding email. Only the 383 Alternate Addresses will be shown. 385 If a UTF8SMTP address in the original email did not have an Alternate 386 Address, then the UTF8SMTP address will be displayed in an empty 387 group (using ":;") to note that a UTF8SMTP address has been removed 388 [RFC5504]-Section 5.1.7. This may appear in any header such as To: or 389 Cc: as 391 Display-Name Internationalized Address eai-addr Removed:; 393 If a user replies to an email with such a group, many MUAs do not 394 handle this correctly. Observed behavior has ranged from refusing to 395 send the message due to an "invalid address", or attempting to send 396 to the group and reporting a DSN failure, or deleting the group 397 altogether. The user may resort to removing the group in order to get 398 around these problems. Recipients of such email will not have an 399 accurate record of who the original recipients were. MUAs should be 400 upgraded to support groups, as defined in [RFC2822]-Section 3.4. 402 Note that even if an MUA does not support UTF8SMTP (Cases 2, 5), it 403 is able to decode and display "Downgraded-" header fields because 404 Downgrade uses MIME encoding [RFC 2047][RFC 2231]. 406 3.2.2. Downgraded Display 408 Case 4b 410 Support for conversion of "Downgraded-" headers is separate from 411 support for Downgrade. An MUA MAY support none or one or both of 412 these options. 414 Conversion replaces the Alternate Addresses in email headers with the 415 original UTF8SMTP addresses that were recorded in the "Downgraded-" 416 headers. 418 If the MUA supports conversion of "Downgraded-" headers, the 419 following considerations should be taken into account: 421 1. If the MUA receives mail from an IMAP/POP server, the conversion 422 may have already been done but the message will still contain 423 "Downgraded-Mail-From" and "Downgraded-Rcpt-To" headers. 425 2. Conversion of Downgraded headers is not a reliable, reversible 426 process. 428 3. There is no authenticated binding between the original UTF8SMTP and 429 the downgraded Alternate Address. This introduces various security 430 concerns [draft-ietf-eai-downgraded-display]-Section 5. 432 4. Alternate Addresses 434 Alternate Addresses MAY be required for Downgrade, which may occur 435 anywhere on the path that a non-UTF8SMTP email component is 436 encountered [RFC5336]-Section 3.2. If Downgrade cannot be done in 437 these cases, the email may be returned ("bounced"). 439 Downgrade is expected to be important initially during a transition 440 period but less important over time as more email systems upgrade to 441 the UTF8SMTP extensions. To the extent that Downgrade is deemed 442 important at the time an implementation is undertaken, Alternate 443 Addresses [RFC5336] SHOULD be supported. 445 4.1. Sender 447 An Alternate Address for the sender MAY be provided, so that after 448 Downgrade there is a return path for delivery status notifications 449 (DSN). 451 Email addresses are generally created and set up on the server side, 452 not by the MUA. An email provider may wish to set up an Alternate 453 Address automatically for each UTF8SMTP account that is created. 454 While in some environments it may be difficult or unfamiliar for a 455 user to enter ASCII characters, selecting an Alternate Address for 456 the user's UTF8SMTP address SHOULD NOT be done automatically. 457 Automatic generation often results in usability problems when names 458 that are difficult to read or pronounce are produced. Any generation 459 of an Alternate Address should be presented to the user as a 460 suggestion that can be changed. 462 A UTF8SMTP implementation of an MSA/MTA may provide the ability to 463 bind an Alternate Address to a UTF8SMTP address. In this case, the 464 MUA may not need to provide Alternate Addresses for the sender. 466 However, users may wish to use different Alternate Addresses than 467 those created for their UTF8SMTP email account, such as when they 468 already have an ASCII address on another email system. 470 In general, the MUA SHOULD allow users to save an Alternate Address 471 for the sender's UTF8SMTP address, typically under "Account" 472 settings. The configured value of this field is used as an ALT- 473 ADDRESS parameter on the SMTP command "MAIL FROM:" and in From: 474 message headers. 476 4.2. Recipients 478 There are two cases where Downgrade can occur: 480 1. Mail sent from a UTF8SMTP user to a non-UTF8SMTP user. 482 2. Mail sent from a UTF8SMTP user to a UTF8SMTP user where a non- 483 UTF8SMTP component is on the path. 485 Downgrade in Case 1 provides backwards compatibility with recipients 486 who are not UTF8SMTP. In this case, the recipient has an ASCII 487 address and an Alternate Address is not required. 489 In Case 2, Downgrade REQUIRES an Alternate Address for the recipient. 490 However, this case could be considered a configuration error. As 491 reviewed in section 3, when DNS is used to determine the transport 492 path from sender to receiver, mail does not get routed through an 493 email relay of a third party. If the sender and recipient both have 494 UTF8SMTP addresses, then one of their MTA mail relays was not 495 upgraded to UTF8SMTP. Users should only be set up with UTF8SMTP 496 addresses if all the mail relays within the organization support 497 UTF8SMTP. 499 If it is decided that it is important to support Downgrade for Case 500 2, then the MUA SHOULD allow the user to enter and edit an optional 501 Alternate Address wherever a UTF8SMTP recipient address can be 502 entered and edited. This would typically be message headers when 503 composing email and entries stored in an "Address Book". 505 The recipient Alternate Address, if provided in an email composition, 506 is used as an ALT-ADDRESS parameter on the SMTP command "RCPT TO:" 507 and in message headers where the recipient address is used. 509 4.3. Entry and Display of Alternate Addresses 511 The following applies to both sender and recipient Alternate 512 Addresses. 514 Alternate Address fields MUST NOT contain non-ASCII addresses. 516 If the main email address is not UTF8SMTP, then entering an address 517 in the Alternate Address field SHOULD NOT be allowed [RFC5336]- 518 Section 3.4. 520 The following is one example of how to display Alternate Addresses, 521 by using the UTF8SMTP "double angle bracket" format defined in 522 [RFC5335]-Section 4.4: 524 Display-Name > 526 It would be helpful to display an indicator on UTF8SMTP email 527 addresses that do not have an Alternate Address. This would alert the 528 user to the possibility that the message may bounce. In the example 529 above, an empty double bracket could be displayed in a highlighted 530 color, reminding the user to provide the missing alternate address, 531 as in 533 Display-Name > 535 When sending the message, the MUA would have to remove empty double 536 angle brackets. 538 Since Downgrade and Alternate Addresses may not be widely used after 539 a transition period, such an indicator should be configurable so that 540 a user is able to turn it off. 542 4.4. Mailbox Integration 544 If Alternate Addresses are supported, it may be desirable to combine 545 mail for the UTF8SMTP address and the Alternate Address into one 546 mailbox so that all related mail can be managed in one place. 548 For example, if a message is sent from a UTF8SMTP address to a list 549 of recipients, some of the messages may be downgraded. Replies to 550 downgraded messages will be delivered to the Alternate Address, so 551 all the replies to a message may be split across two different 552 mailboxes. 554 Mailbox integration is not generally handled by an MUA. Many existing 555 MTAs/MDAs can do this with a mail "alias" or "forward". One address 556 is selected as the primary mailbox and the other address is 557 configured as an alias. 559 Forwarding allows an email address on one email provider to be 560 integrated into the mailbox on another email provider. Mailbox 561 integration can make it easier for users to migrate from an old email 562 system that does not support UTF8SMTP to a newer one that does. All 563 they need to do is forward their old email address to an Alternate 564 Address that was created on their new mail service. 566 5. Character Encoding 568 Email message bodies may be composed and displayed using many 569 different character encoding schemes. Numerous character encodings 570 have been developed over time in order to best represent different 571 language scripts. In recent years there has been a trend to prefer 572 Unicode as a "universal" character set and UTF-8 as the preferred 573 encoding method. 575 A good general principle to follow is to minimize character 576 conversions. This will reduce the chance that the received message is 577 displayed differently from how it was composed. Displaying received 578 mail SHOULD use the character encoding of the received mail. 580 Since older MUAs may not be able to parse UTF-8, the MUA SHOULD try 581 to reply to mail using the character encoding of the received mail. 582 This may not be possible if the sender adds new characters that 583 cannot be encoded in the original encoding. For example, if the 584 received message is encoded in ISO-2022-JP and characters in ISO- 585 8859-1 are added to the message, the text cannot be carried in ISO- 586 2022-JP and conversion to UTF-8 may be the best solution. 588 For new mail, A UTF8SMTP compliant MUA SHOULD use UTF-8 as the 589 default encoding if the message type is global or if the envelope 590 contains non-ASCII addresses. If email clients utilize this default, 591 character conversions will be minimized and there will be less chance 592 that someone will receive mail in an unrecognized encoding. 594 If the message type is rfc822, other considerations may apply, such 595 as using the system locale/language. 597 Notwithstanding the above, there may be cases where the default does 598 not work well. There SHOULD be options for the user to reset the 599 default character encoding. There SHOULD also be options to change 600 the encoding when reading or writing individual email messages. 602 6. Normalization 604 Different sequences of UTF-8 characters may represent the same thing. 605 Normalization is a process that converts all canonically equivalent 606 sequences to a single unique form. 608 For example, in the Japanese environment, special consideration is 609 needed for the "@" symbol used to separate the local name from the 610 domain name in email addresses. Normalization is necessary to replace 611 FULLWIDTH COMMERCIAL AT (U+FF20) with ASCII "@", COMMERCIAL AT 612 (U+0040) for proper parsing of email addresses. 614 Normalization of email headers is specified in [RFC 5335]-Section 615 4.1. The MUA SHOULD normalize all email addresses in the envelope and 616 message headers. 618 If the MUA saves email addresses (such as in an address book), they 619 SHOULD be stored in normalized form. For example, an email address 620 entered as 622 user@host*domain 624 where * represents IDEOGRAPHIC FULL STOP (U+3002), as used in some 625 Asian languages, would display as 627 user@host.domain 629 For message bodies that contain UTF-8 characters (message/global), 630 the "Net-Unicode" standardized text transmission format specified in 631 [RFC5198] SHOULD be followed. It covers both normalization and 632 control characters that may affect display of text. 634 7. Security Considerations 636 This document does not introduce any security considerations beyond 637 those already covered by the normative references for Email Address 638 Internationalization (EAI). 640 8. IANA Considerations 642 IANA changes are covered by the normative references for Email 643 Address Internationalization (EAI). 645 9. Acknowledgments 647 10. References 649 10.1. Normative References 651 [ASCII] American National Standards Institute (formerly United States 652 of America Standards Institute), "USA Code for Information 653 Interchange", ANSI X3.4-1968, 1968. 655 ANSI X3.4-1968 has been replaced by newer versions with 656 slight modifications, but the 1968 version remains 657 definitive for the Internet. 659 [draft-ietf-eai-downgraded-display] Fujiwara, K., "Displaying 660 Downgraded Messages for Email Address 661 Internationalization", draft-ietf-eai-downgraded-display-01 662 (work in progress), March 2009. 664 [draft-ietf-eai-imap-utf8] Resnick, P. and Newman, C., "IMAP Support 665 for UTF-8", draft-ietf-eai-imap-utf8-04 (work in progress), 666 June 2009. 668 [draft-ietf-eai-pop] Newman, C. and Gellens, R., "POP3 Support for 669 UTF-8", draft-ietf-eai-pop-06 (work in progress), June 670 2009. 672 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 673 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 674 RFC 1652, July 1994. 676 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 677 Extensions (MIME) Part One: Format of Internet Message 678 Bodies", RFC 2045, November 1996. 680 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 681 Part Three: Message Header Extensions for Non-ASCII Text", 682 RFC 2047, November 1996. 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, March 1997. 687 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 688 Part Three: Message Header Extensions for Non-ASCII Text", 689 RFC 2047, November 1996. 691 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 692 2001. 694 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 695 "Internationalizing Domain Names in Applications (IDNA)", 696 RFC 3490, March 2003. 698 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 699 STD 63, RFC 3629, November 2003. 701 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 702 Internationalized Email", RFC 4952, July 2007. 704 [RFC5198] Klensin, J. and Padlipsky, M., "Unicode Format for Network 705 Interchange", RFC 5198, March 2008. 707 [RFC5335] Yeh, J., "Internationalized Email Headers", RFC 5335, 708 November 2008. 710 [RFC5336] Yao, J. and W. Mao, "SMTP extension for internationalized 711 email address", RFC 5336, September 2008. 713 [RFC5504] Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for 714 Email Address Internationalization", RFC 5504, March 2009. 716 10.2. Informative References 718 [draft-crocker-email-arch] D. Crocker, "Internet Mail Architecture", 719 draft-crocker-email-arch-14 (work in progress), June 2009. 721 [RFC4409] Gellens, R. and Klensin, J., "Message Submission for Mail", 722 RFC 4409, 2006. 724 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E. and 725 Finch, T., "Email Submission Operations: Access and 726 Accountability Requirements", RFC 5068, November 2007. 728 Authors' Addresses 730 Ernie Dainow 731 Afilias Canada 732 4141 Yonge Street 733 Toronto, Ontario M2P 2A8 734 Canada 736 Email: edainow@ca.afilias.info 738 Kazunori Fujiwara 739 JPRS 740 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 741 Chiyoda-ku, Tokyo 101-0065 742 Japan 744 Email: fujiwara@jprs.co.jp