idnits 2.17.1 draft-ietf-eai-popimap-downgrade-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5322, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5322, updated by this document, for RFC5378 checks: 2006-06-20) -- 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 (Feb 27, 2012) is 4443 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5451 (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 5504 (Obsoleted by RFC 6530) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Email Address Internationalization K. Fujiwara 3 (EAI) JPRS 4 Internet-Draft Feb 27, 2012 5 Updates: 5322 (if approved) 6 Intended status: Standards Track 7 Expires: August 30, 2012 9 Post-delivery Message Downgrading for Internationalized Email Messages 10 draft-ietf-eai-popimap-downgrade-04.txt 12 Abstract 14 The Email Address Internationalization (SMTPUTF8) extension allows 15 UTF-8 characters in mail header fields. Upgraded POP and IMAP 16 servers support internationalized email messages. If a POP/IMAP 17 client does not support Email Address Internationalization, POP/IMAP 18 servers cannot send Internationalized Email Headers to the client and 19 cannot remove the message. To avoid the situation, this document 20 describes a conversion mechanism for internationalized Email messages 21 to be traditional message format. The purpose of post-delivery 22 message downgrading is to enable POP/IMAP servers to deliver 23 internationalized messages to traditional POP/IMAP clients. In the 24 process, message elements requiring internationalized treatment can 25 be removed or recoded and receivers can know they received messages 26 containing such elements even if they cannot receive the elements 27 themselves. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 30, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Possible solutions . . . . . . . . . . . . . . . . . . . . 4 66 1.3. Approach taken in this specification . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Updating RFC 5322 . . . . . . . . . . . . . . . . . . . . . . 6 69 4. New Header Fields Definition . . . . . . . . . . . . . . . . . 7 70 5. Email Header Fields Downgrading . . . . . . . . . . . . . . . 8 71 5.1. Downgrading Method for Each ABNF Element . . . . . . . . . 8 72 5.1.1. RECEIVED Downgrading . . . . . . . . . . . . . . . . . 8 73 5.1.2. UNSTRUCTURED Downgrading . . . . . . . . . . . . . . . 8 74 5.1.3. WORD Downgrading . . . . . . . . . . . . . . . . . . . 8 75 5.1.4. COMMENT Downgrading . . . . . . . . . . . . . . . . . 8 76 5.1.5. MIME-VALUE Downgrading . . . . . . . . . . . . . . . . 9 77 5.1.6. DISPLAY-NAME Downgrading . . . . . . . . . . . . . . . 9 78 5.1.7. GROUP Downgrading . . . . . . . . . . . . . . . . . . 9 79 5.1.8. MAILBOX Downgrading . . . . . . . . . . . . . . . . . 9 80 5.1.9. ENCAPSULATION Downgrading . . . . . . . . . . . . . . 10 81 5.1.10. TYPED-ADDRESS Downgrading . . . . . . . . . . . . . . 10 82 5.2. Downgrading Method for Each Header Field . . . . . . . . . 10 83 5.2.1. Address Header Fields That Contain
s . . . . 10 84 5.2.2. Address Header Fields with Typed Addresses . . . . . . 11 85 5.2.3. Downgrading Non-ASCII in Comments . . . . . . . . . . 11 86 5.2.4. Message-ID Header Fields . . . . . . . . . . . . . . . 11 87 5.2.5. Received Header Field . . . . . . . . . . . . . . . . 12 88 5.2.6. MIME Content Header Fields . . . . . . . . . . . . . . 12 89 5.2.7. Non-ASCII in . . . . . . . . . . . . . 12 90 5.2.8. Non-ASCII in . . . . . . . . . . . . . . . . 12 91 5.2.9. Other Header Fields . . . . . . . . . . . . . . . . . 12 92 6. MIME Body-Part Header Field Downgrading . . . . . . . . . . . 13 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 94 8. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 14 95 8.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 14 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 98 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16 99 11.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 16 100 11.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 16 101 11.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 16 102 11.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 16 103 11.5. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 17 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 105 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 106 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 107 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 108 A.1. Downgrading Example . . . . . . . . . . . . . . . . . . . 18 110 1. Introduction 112 1.1. Problem statement 114 Traditional (legacy) mail systems, which are defined by [RFC5322], 115 allow only ASCII characters in mail header field values. The 116 SMTPUTF8 extension ([RFC6530] and [RFC6532] allows UTF-8 characters 117 in those mail header fields. 119 If a header field contains non-ASCII characters, POP/IMAP servers 120 cannot send Internationalized Email Headers to legacy clients and, 121 because they have no obvious or standardized way to explain what is 122 going on to those clients, cannot even safely discard the message. 124 1.2. Possible solutions 126 Discussions leading to this specification concluded that there are 127 four plausible approaches to the problem, with the preferred one 128 depending on the particular circumstances and relationship among the 129 delivery SMTP server, the mail store, the POP or IMAP server, and the 130 users and their MUA clients: 132 1. If the delivery MTA has sufficient knowledge about the POP and/or 133 IMAP servers and clients being used, the message may be rejected 134 as undeliverable. 136 2. The message may be downgraded by the POP or IMAP server, in a way 137 that preserves maximum information at the expense of some 138 complexity. 140 3. Some intermediate downgrading may be applied that balances more 141 information loss against lower complexity and greater ease of 142 implementation. 144 4. The POP or IMAP server may fabricate a message whose intent is to 145 notify the client that an internationalized message is waiting 146 but cannot be delivered until an upgraded client is available. 148 1.3. Approach taken in this specification 150 This specification describes the second of those options. It is 151 worth noticing that, at least in the general case, none of these 152 options preserve sufficient information to guarantee that it is 153 possible to reply to an incoming message without loss of information, 154 so the choice may be considered to be among "least bad" options. 156 This message downgrading mechanism converts mail header fields to an 157 all-ASCII representation. The POP/IMAP servers can use the 158 downgrading mechanism and send the Internationalized Email message as 159 a traditional form. Receivers can know they received some 160 internationalized messages or some unknown/broken messages. 162 [RFC6532] allows UTF-8 characters to be used in mail header fields 163 and MIME header fields. The message downgrading mechanism specified 164 here describes the conversion method from the internationalized email 165 messages that are defined in [RFC6530], and [RFC6532] to the 166 traditional email messages defined in [RFC5322]. 168 There is no good way to convert "From:" and "Sender:" header fields, 169 this document updates [RFC5322] by redefining "From:" and "Sender:" 170 header fields in Section 3. 172 This document provides a precise definition of the minimum- 173 information-loss message downgrading process. 175 Downgrading consists of the following three parts: 177 o New header field definitions 179 o Email header field downgrading 181 o MIME header field downgrading 183 In Section 4 of this document, header fields starting with 184 "Downgraded-" are introduced. They preserve the information that 185 appeared in the original header fields. 187 Email header field downgrading is described in Section 5. It 188 generates ASCII-only header fields. 190 MIME header fields are expanded in [RFC6532]. MIME header field 191 downgrading is described in Section 6. It generates ASCII-only MIME 192 header fields. 194 Displaying downgraded messages that originally contained 195 internationalized header fields is out of scope of this document. A 196 POP/IMAP client which does not support UTF8 extension does not know 197 internationalized message format described in [RFC6532]. 199 2. Terminology 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in RFC 2119 [RFC2119]. 205 All specialized terms used in this specification are defined in the 206 Overview and Framework for Internationalized Email [RFC6530], in the 207 mail message specifications [RFC5322], or in the MIME documents 208 [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address", 209 "internationalized email address", "non-ASCII address", "i18mail 210 address", "SMTPUTF8", "message", and "mailing list" are used with the 211 definitions from [RFC6530]. 213 This document depends on [RFC6532]. Key words used in those 214 documents are used in this document, too. 216 The term "non-ASCII" refers to a UTF-8 string that contains at least 217 one non-ASCII character. 219 A "SMTPUTF8 message" is an email message expanded by [RFC6532]. 221 3. Updating RFC 5322 223 "From:" header field or "Sender:" header field may contain non-ASCII 224 addresses in internationalized Email messages. These non-ASCII 225 addresses are not allowed in [RFC5322]. The draft proposes that the 226 pop/imap downgrading uses syntax and encodes non-ASCII 227 addresses into with empty described in 228 Section 5. 230 This specification redefines "From:", "Sender:", "Resent-From:" and 231 "Resent-Sender:" header fields defined in Section 3.6.2 and 3.6.6 of 232 [RFC5322] to allow in the header fields. 234 from = "From:" address-list CRLF 235 resent-from = "Resent-From:" address-list CRLF 236 sender = "Sender:" address CRLF 237 resent-sender = "Resent-Sender:" address CRLF 239 This adds group syntax to "From" and "Sender" that was previously 240 allowed only in destination fields such as "To" and "cc". It is 241 anticipated that when existing implementations encounter a downgraded 242 field from this set, many will tolerate the appearance of a group, 243 even though [RFC5322] does not permit it. Implementations that do 244 not tolerate it will fail in unpredictable ways, and they might 245 refuse to process such messages. 247 [[ Notes in Draft: If this update is rejected, one possible solution 248 is to rewrite each element in "From" and "Sender" header 249 fields as 250 ENCODED-WORD "<" NO_EXISTING_ADDRESS ">" 252 where the is the original encoded 253 according to [RFC2047] and NO_EXISTING_ADDRESS is an ASCII email 254 address which does not exist, should, as illustrated in the example 255 below, always generate an error and is specified by the administrator 256 of the POP3 or IMAP server. 258 For example, if the local-part of the "From:" address were the 259 Russian (in Cyrillic) equivalent of Ivan, with domain-part 260 "foo.example.net" and the IMAP server being used by the recipient was 261 "imap.example.com", the encoded word from suggested in this note 262 might appear as: 264 From: =?UTF-8?Q?=d0=b8=d0=b2=d0=b0=d0=bd@foo.example.net?= 265 267 That would lead to immediate rejection if a user attempted to reply 268 uncritically to the message. 270 4. New Header Fields Definition 272 New header fields are defined to preserve information that appeared 273 in non-ASCII text in header fields of the incoming message. The 274 values of the new fields holds the original header field value in 275 encoded form. The revised header field syntax is specified as 276 follows: 278 fields =/ downgraded 280 downgraded = "Downgraded-Message-Id:" unstructured CRLF / 281 "Downgraded-Resent-Message-Id:" unstructured CRLF / 282 "Downgraded-In-Reply-To:" unstructured CRLF / 283 "Downgraded-References:" unstructured CRLF / 284 "Downgraded-Original-Recipient:" unstructured CRLF / 285 "Downgraded-Final-Recipient:" unstructured CRLF 287 To preserve a header field in a "Downgraded-" header field: 289 1. Generate a new header field. 291 * The field name is a concatenation of "Downgraded-" and the 292 original field name. 294 * The initial new field value is the original header field 295 value. 297 2. Treat the initial new header field value as if it were 298 unstructured, and then apply [RFC2047] encoding with charset 299 UTF-8 as necessary so that the resulting new header field value 300 is completely in ASCII. 302 3. Remove the original header field. 304 5. Email Header Fields Downgrading 306 This section defines the conversion method to ASCII for each header 307 field that may contain non-ASCII characters. 309 [RFC6532] expands "Received:" header fields; [RFC5322] describes ABNF 310 elements , , , ; [RFC2045] 311 describes ABNF element . 313 5.1. Downgrading Method for Each ABNF Element 315 Header field downgrading is defined below for each ABNF element. 316 Converting the header field terminates when no non-ASCII characters 317 remain in the header field. 319 5.1.1. RECEIVED Downgrading 321 If the header field name is "Received:" and the FOR clause contains a 322 non-ASCII address, remove the FOR clause from the header field. 323 Other parts (not counting s) should not contain non-ASCII 324 values. 326 5.1.2. UNSTRUCTURED Downgrading 328 If the header field has an field that contains non- 329 ASCII characters, apply [RFC2047] encoding with charset UTF-8. 331 5.1.3. WORD Downgrading 333 If the header field has any fields that contain non-ASCII 334 characters, apply [RFC2047] encoding with charset UTF-8. 336 5.1.4. COMMENT Downgrading 338 If the header field has any fields that contain non-ASCII 339 characters, apply [RFC2047] encoding with charset UTF-8. 341 5.1.5. MIME-VALUE Downgrading 343 If the header field has any elements defined by [RFC2045] and 344 the elements contain non-ASCII characters, encode the 345 elements according to [RFC2231] with charset UTF-8 and leave the 346 language information empty. If the element is and it contains outside the DQUOTE, remove the 348 before this conversion. 350 5.1.6. DISPLAY-NAME Downgrading 352 If the header field has any
( or ) elements 353 and they have elements that contain non-ASCII 354 characters, encode the elements according to [RFC2047] 355 with charset UTF-8. DISPLAY-NAME downgrading is the same algorithm 356 as WORD downgrading. 358 5.1.7. GROUP Downgrading 360 is defined in Section 3.4 of [RFC5322]. The elements 361 may contain s which contain non-ASCII addresses. 363 If the header field has any elements that contain 364 elements, and those elements in turn contain non-ASCII 365 addresses, rewrite each element as 367 display-name ENCODED_WORD " :;" 369 where the is the original encoded 370 according to [RFC2047]. 372 5.1.8. MAILBOX Downgrading 374 The elements have no equivalent format for non-ASCII 375 addresses. If the header field has any elements that 376 contain non-ASCII characters in their element, rewrite 377 each element to ASCII-only format. The 378 element that contains non-ASCII characters may appear in two forms 379 as: 381 "<" addr-spec ">" 382 addr-spec 384 Rewrite both as: 386 ENCODED-WORD " :;" 388 where the is the original encoded 389 according to [RFC2047]. 391 5.1.9. ENCAPSULATION Downgrading 393 Encapsulate the header field in a "Downgraded-" header field as 394 described in Section 4 as a last resort. 396 Applying this procedure to "Received:" header field is prohibited. 397 ENCAPSULATION Downgrading is allowed for "Message-ID", 398 "In-Reply-To:", "References:", "Original-Recipient" and "Final- 399 Recipient" header fields. 401 5.1.10. TYPED-ADDRESS Downgrading 403 If the header field contains and the contains raw non-ASCII characters, it is in utf-8-address form. 405 Convert it to utf-8-addr-xtext form. Those forms are described in 406 [RFC6533]. COMMENT downgrading is also performed in this case. If 407 the address type is unrecognized and the header field contains non- 408 ASCII characters, then fall back to using ENCAPSULATION downgrading 409 on the entire header field. 411 5.2. Downgrading Method for Each Header Field 413 Header fields are listed in [RFC4021]. This section describes the 414 downgrading method for each header field. 416 If the whole mail header field does not contain non-ASCII characters, 417 email header field downgrading is not required. Each header field's 418 downgrading method is described below. 420 5.2.1. Address Header Fields That Contain
s 422 From: 423 Sender: 424 To: 425 Cc: 426 Bcc: 427 Reply-To: 429 Resent-From: 430 Resent-Sender: 431 Resent-To: 432 Resent-Cc: 433 Resent-Bcc: 434 Resent-Reply-To: 435 Return-Path: 436 Disposition-Notification-To: 438 If the header field contains elements that contain non-ASCII 439 addresses, perform COMMENT downgrading, DISPLAY-NAME downgrading, and 440 GROUP downgrading. 442 If the header field contains elements that contain non- 443 ASCII addresses, perform COMMENT downgrading, DISPLAY-NAME 444 downgrading, and MAILBOX downgrading. 446 5.2.2. Address Header Fields with Typed Addresses 448 Original-Recipient: 449 Final-Recipient: 451 If the header field contains non-ASCII characters, perform TYPED- 452 ADDRESS downgrading. 454 5.2.3. Downgrading Non-ASCII in Comments 456 Date: 457 Resent-Date: 458 MIME-Version: 459 Content-ID: 460 Content-Transfer-Encoding: 461 Content-Language: 462 Accept-Language: 463 Auto-Submitted: 465 These header fields do not contain non-ASCII characters except in 466 comments. If the header field contains UTF-8 characters in comments, 467 perform COMMENT downgrading. 469 5.2.4. Message-ID Header Fields 470 Message-ID: 471 Resent-Message-ID: 472 In-Reply-To: 473 References: 475 Perform ENCAPSULATION Downgrading. 477 5.2.5. Received Header Field 479 Received: 481 Perform COMMENT downgrading and RECEIVED downgrading. 483 5.2.6. MIME Content Header Fields 485 Content-Type: 486 Content-Disposition: 488 Perform MIME-VALUE downgrading and COMMENT downgrading. 490 5.2.7. Non-ASCII in 492 Subject: 493 Comments: 494 Content-Description: 496 Perform UNSTRUCTURED downgrading. 498 5.2.8. Non-ASCII in 500 Keywords: 502 Perform WORD downgrading. 504 5.2.9. Other Header Fields 506 There are other header fields that contain non-ASCII characters. 507 They are user-defined and missing from this document, or future 508 defined header fields. They are treated as "Optional Fields" and 509 their field value are treated as unstructured described in Section 510 3.6.8 of [RFC5322]. 512 Perform UNSTRUCTURED downgrading. 514 If the software understands the header field's structure and a 515 downgrading algorithm other than UNSTRUCTURED is applicable, that 516 software SHOULD use that algorithm; UNSTRUCTURED downgrading is used 517 as a last resort. 519 Mailing list header fields (those that start in "List-") are part of 520 this category. 522 6. MIME Body-Part Header Field Downgrading 524 MIME body-part header fields may contain non-ASCII characters 525 [RFC6532]. This section defines the conversion method to ASCII-only 526 header fields for each MIME header field that contains non-ASCII 527 characters. Parse the message body's MIME structure at all levels 528 and check each MIME header field to see whether it contains non-ASCII 529 characters. If the header field contains non-ASCII characters in the 530 header field value, the header field is a target of the MIME body- 531 part header field's downgrading. Each MIME header field's 532 downgrading method is described below. COMMENT downgrading, MIME- 533 VALUE downgrading, and UNSTRUCTURED downgrading are described in 534 Section 5. 536 Content-ID: 537 The "Content-ID:" header field does not contain non-ASCII 538 characters except in comments. If the header field contains UTF-8 539 characters in comments, perform COMMENT downgrading. 541 Content-Type: 543 Content-Disposition: 544 Perform MIME-VALUE downgrading and COMMENT downgrading. 546 Content-Description: Perform UNSTRUCTURED downgrading. 548 7. Security Considerations 550 The purpose of post-delivery message downgrading is to allow POP/IMAP 551 servers to deliver internationalized messages to traditional POP/IMAP 552 clients and permit them to work with those messages. Users who 553 receive such messages can know that they were internationalized. It 554 does not permit receivers to read the messages in their original form 555 and, in general, will not permit generating replies, at least without 556 significant user intervention. 558 This specification is designed so that MUAs that receive converted 559 messages may be traditional and SMTPUTF8-unaware. The specification 560 assumes that such MUAs have no special provisions for either 561 "Downgraded-" header fields or the new syntax of From and Sender 562 header fields described in Section 3. 564 A downgraded message's header fields contain ASCII characters only. 565 But they still contain MIME-encapsulated header fields that contain 566 non-ASCII UTF-8 characters. Furthermore, the body part may contain 567 UTF-8 characters. Implementations parsing Internet messages need to 568 accept UTF-8 body parts and UTF-8 header fields that are MIME- 569 encoded. Thus, this document inherits the security considerations of 570 MIME-encoded header fields ([RFC2047] and [RFC3629]). 572 Rewriting header fields increases the opportunities for undetected 573 spoofing by malicious senders. However, the rewritten header field 574 values are preserved in equivalent MIME form or in newly defined 575 header fields which traditional MUAs do not care. 577 The techniques described here invalidate methods that depend on 578 digital signatures over any part of the message, which includes the 579 top-level header fields and body-part header fields. Depending on 580 the specific message being downgraded, at least the following 581 techniques are likely to break: DomainKeys Identified Mail (DKIM), 582 and possibly S/MIME and Pretty Good Privacy (PGP). Receivers may 583 know they need to update their MUAs, or they don't care. 585 While information in any email header field should usually be treated 586 with some suspicion, current email systems commonly employ various 587 mechanisms and protocols to make the information more trustworthy. 588 Information in the new Downgraded-* header fields is not inspected by 589 MUAs, and may be even less trustworthy than the traditional header 590 fields. Note that the Downgraded-* header fields could have been 591 inserted with malicious intent (and with content unrelated to the 592 traditional header fields), however traditional MUAs do not parse 593 Downgraded-* header fields. 595 In addition, if an Authentication-Results header field [RFC5451] is 596 present, traditional MUAs may treat that the digital signatures are 597 valid. 599 See the "Security Considerations" section in [RFC6530] for more 600 discussion. 602 8. Implementation Notes 604 8.1. RFC 2047 Encoding 606 While [RFC2047] has a specific algorithm to deal with whitespace in 607 adjacent encoded words, there are a number of deployed 608 implementations that fail to implement the algorithm correctly. As a 609 result, whitespace behavior is somewhat unpredictable in practice 610 when multiple encoded words are used. While RFC 5322 states that 611 implementations SHOULD limit lines to not more than 78 characters, 612 implementations MAY choose to allow overly long encoded words in 613 order to work around faulty [RFC2047] implementations. 614 Implementations that choose to do so SHOULD have an optional 615 mechanism to limit line length to 78 characters. 617 9. IANA Considerations 619 [[RFC Editor: Please change "should now be" and "should be" to "have 620 been" when the IANA actions are complete.]] 622 [[ Notes in draft: this section is not finished, to be reviewed with 623 IANA. ]] 625 [RFC5504] registered many "Downgraded-" header fields and requested 626 that 'IANA will refuse registration of all field names that start 627 with "Downgraded-", to avoid possible conflict with the procedure for 628 unknown header fields' preservation described in Section 3.3 of 629 [RFC5504].' However [RFC6530] obsoleted [RFC5504] and this document 630 does not use all "Downgraded-" header fields registered by [RFC5504]. 632 The following header fields should be registered in the Permanent 633 Message Header Field registry, in accordance with the procedures set 634 out in [RFC3864]. 636 Header field name: Downgraded-Message-Id 637 Applicable protocol: mail 638 Status: standard 639 Author/change controller: IETF 640 Specification document(s): This document (Section 4) 642 Header field name: Downgraded-In-Reply-To 643 Applicable protocol: mail 644 Status: standard 645 Author/change controller: IETF 646 Specification document(s): This document (Section 4) 648 Header field name: Downgraded-References 649 Applicable protocol: mail 650 Status: standard 651 Author/change controller: IETF 652 Specification document(s): This document (Section 4) 654 Header field name: Downgraded-Original-Recipient 655 Applicable protocol: mail 656 Status: standard 657 Author/change controller: IETF 658 Specification document(s): This document (Section 4) 660 Header field name: Downgraded-Final-Recipient 661 Applicable protocol: mail 662 Status: standard 663 Author/change controller: IETF 664 Specification document(s): This document (Section 4) 666 10. Acknowledgements 668 This document draws heavily from the experimental in-transit message 669 downgrading procedure described in RFC 5504 [RFC5504]. The 670 contribution of the co-author of that earlier document, Y. Yoneya, 671 are gratefully acknowledged. Significant comments and suggestions 672 were received from John Klensin, Barry Leiba, Randall Gellens, Pete 673 Resnick, and other WG participants. 675 11. Change History 677 [[RFC Editor: Please remove this section prior to publication.]] 679 This section is used for tracking the update of this document. Will 680 be removed after finalize. 682 11.1. Version 00 684 o Initial version 686 o Imported header field downgrading from RFC 5504 688 11.2. Version 01 690 o same as Version 00 692 11.3. Version 02 694 o Added updating RFC 5322 to allow syntax in From: and 695 Sender 697 o Added GROUP Downgrading 699 11.4. Version 03 701 o Replaced with 702 o Added updating RFC 5322 to allow syntax in From: and 703 Sender 705 o Added one sentence in Security considerations 707 o Updated IANA considerations 709 11.5. Version 04 711 o Removed "Internationalized Address removed" from GROUP and MAILBOX 712 downgrading 714 o Updated "Updating RFC 5322" 716 o Compacted new header field definition 718 o Compacted security considerations 720 o Updated IANA considerations to remove obsoleting header fields 721 that are registered by RFC 5504 723 o Added a discussion of alternate downgrading models for the POP and 724 IMAP cases. 726 o Incorporated a large number of editorial changes to improve 727 clarity. 729 12. References 731 12.1. Normative References 733 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 734 Internationalized Email", RFC 6530, February 2012. 736 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 737 Email Headers", RFC 6532, February 2012. 739 [RFC6533] Hansen, T., Newman, C., and A. Melnikov, 740 "Internationalized Delivery Status and Disposition 741 Notifications", RFC 6533, February 2012. 743 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 744 Extensions (MIME) Part One: Format of Internet Message 745 Bodies", RFC 2045, November 1996. 747 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 748 Part Three: Message Header Extensions for Non-ASCII Text", 749 RFC 2047, November 1996. 751 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 752 Presentation Information in Internet Messages: The 753 Content-Disposition Header Field", RFC 2183, August 1997. 755 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 756 Word Extensions: 757 Character Sets, Languages, and Continuations", RFC 2231, 758 November 1997. 760 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 761 October 2008. 763 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 764 10646", STD 63, RFC 3629, November 2003. 766 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 767 Header Fields", RFC 4021, March 2005. 769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 770 Requirement Levels", BCP 14, RFC 2119, March 1997. 772 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 773 Procedures for Message Header Fields", BCP 90, RFC 3864, 774 September 2004. 776 12.2. Informative References 778 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 779 Message Authentication Status", RFC 5451, April 2009. 781 [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for 782 Email Address Internationalization", RFC 5504, March 2009. 784 Appendix A. Examples 786 A.1. Downgrading Example 788 This appendix shows an message downgrading example. Consider a 789 received mail message where: 791 o The sender address is a non-ASCII address, 792 "NON-ASCII-local@example.com". Its display-name is "DISPLAY- 793 local". 795 o The "To:" header field contains two non-ASCII addresses, 796 "NON-ASCII-remote1@example.net" and 797 "NON-ASCII-remote2@example.com" Its display-names are "DISPLAY- 798 remote1" and "DISPLAY-remote2". 800 o The "Cc:" header field contains a non-ASCII address, 801 "NON-ASCII-remote3@example.org". Its display-name is "DISPLAY- 802 remote3". 804 o Four display names contain non-ASCII characters. 806 o The Subject header field is "NON-ASCII-SUBJECT", which contains 807 non-ASCII characters. 809 o The "Message-Id:" header field contains "NON-ASCII-MESSAGE_ID", 810 which contains non-ASCII characters. 812 o There is an unknown header field "X-Unknown-Header" which contains 813 non-ASCII characters. 815 Return-Path: 816 Received: from ... by ... for 817 Received: from ... by ... for 818 From: DISPLAY-local 819 To: DISPLAY-remote1 , 820 DISPLAY-remote2 821 Cc: DISPLAY-remote3 822 Subject: NON-ASCII-SUBJECT 823 Date: DATE 824 Message-Id: NON-ASCII-MESSAGE_ID 825 Mime-Version: 1.0 826 Content-Type: text/plain; charset="UTF-8" 827 Content-Transfer-Encoding: 8bit 828 X-Unknown-Header: NON-ASCII-CHARACTERS 830 MAIL_BODY 832 Figure 1: Received message in a mail drop 834 The downgraded message is shown in Figure 2. "Return-Path:", 835 "From:", "To:" and "Cc:" header fields are rewritten. "Subject:" and 836 "X-Unknown-Header:" header fields are encoded using [RFC2047]. 837 "Message-Id:" header field is encapsulated as 838 "Downgraded-Message-Id:" header field. 840 Return-Path: =?UTF-8?Q?NON-ASCII-local@example.com?= :; 841 Received: from ... by ... 842 Received: from ... by ... 843 From: =?UTF-8?Q?DISPLAY-local?= 844 =?UTF-8?Q?NON-ASCII-local@example.com?= :; 845 To: =?UTF-8?Q?DISPLAY-remote1?= 846 =?UTF-8?Q?NON-ASCII-remote1@example.net?= :;, 847 =?UTF-8?Q?DISPLAY-remote2?= 848 =?UTF-8?Q?NON-ASCII-remote2@example.com?= :;, 849 Cc: =?UTF-8?Q?DISPLAY-remote3?= 850 =?UTF-8?Q?NON-ASCII-remote3@example.org?= :; 851 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 852 Date: DATE 853 Downgraded-Message-Id: =?UTF-8?Q?MESSAGE_ID?= 854 Mime-Version: 1.0 855 Content-Type: text/plain; charset="UTF-8" 856 Content-Transfer-Encoding: 8bit 857 X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?= 859 MAIL_BODY 861 Figure 2: Downgraded message 863 Author's Address 865 Kazunori Fujiwara 866 Japan Registry Services Co., Ltd. 867 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 868 Chiyoda-ku, Tokyo 101-0065 869 Japan 871 Phone: +81 3 5215 8451 872 EMail: fujiwara@wide.ad.jp, fujiwara@jprs.co.jp