idnits 2.17.1 draft-ietf-eai-popimap-downgrade-03.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 (Oct 31, 2011) is 4560 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) == Outdated reference: A later version (-06) exists of draft-ietf-eai-rfc5337bis-dsn-05 -- Obsolete informational reference (is this intentional?): RFC 5504 (Obsoleted by RFC 6530) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 Oct 31, 2011 5 Updates: 5322 (if approved) 6 Intended status: Standards Track 7 Expires: May 3, 2012 9 Post-delivery Message Downgrading for Internationalized Email Messages 10 draft-ietf-eai-popimap-downgrade-03.txt 12 Abstract 14 The Email Address Internationalization (UTF8SMTP) extension allows 15 UTF-8 characters in mail header fields. POP and IMAP servers support 16 internationalized email messages. If a POP/IMAP client does not 17 support Email Address Internationalization, POP/IMAP servers cannot 18 send Internationalized Email Headers to the client and cannot remove 19 the message. To avoid the situation, this document describes a 20 conversion mechanism for internationalized Email messages to be 21 traditional message format. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 3, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Updating RFC 5322 . . . . . . . . . . . . . . . . . . . . . . 5 60 4. New Header Fields Definition . . . . . . . . . . . . . . . . . 6 61 4.1. Preservation Header Fields . . . . . . . . . . . . . . . . 6 62 5. Email Header Fields Downgrading . . . . . . . . . . . . . . . 7 63 5.1. Downgrading Method for Each ABNF Element . . . . . . . . . 7 64 5.1.1. RECEIVED Downgrading . . . . . . . . . . . . . . . . . 7 65 5.1.2. UNSTRUCTURED Downgrading . . . . . . . . . . . . . . . 7 66 5.1.3. WORD Downgrading . . . . . . . . . . . . . . . . . . . 7 67 5.1.4. COMMENT Downgrading . . . . . . . . . . . . . . . . . 7 68 5.1.5. MIME-VALUE Downgrading . . . . . . . . . . . . . . . . 7 69 5.1.6. DISPLAY-NAME Downgrading . . . . . . . . . . . . . . . 8 70 5.1.7. GROUP Downgrading . . . . . . . . . . . . . . . . . . 8 71 5.1.8. MAILBOX Downgrading . . . . . . . . . . . . . . . . . 8 72 5.1.9. ENCAPSULATION Downgrading . . . . . . . . . . . . . . 9 73 5.1.10. TYPED-ADDRESS Downgrading . . . . . . . . . . . . . . 9 74 5.2. Downgrading Method for Each Header Field . . . . . . . . . 9 75 5.2.1. Address Header Fields That Contain
s . . . . 9 76 5.2.2. Address Header Fields with Typed Addresses . . . . . . 10 77 5.2.3. Downgrading Non-ASCII in Comments . . . . . . . . . . 10 78 5.2.4. Message-ID Header Fields . . . . . . . . . . . . . . . 10 79 5.2.5. Received Header Field . . . . . . . . . . . . . . . . 11 80 5.2.6. MIME Content Header Fields . . . . . . . . . . . . . . 11 81 5.2.7. Non-ASCII in . . . . . . . . . . . . . 11 82 5.2.8. Non-ASCII in . . . . . . . . . . . . . . . . 11 83 5.2.9. Other Header Fields . . . . . . . . . . . . . . . . . 11 84 6. MIME Body-Part Header Field Downgrading . . . . . . . . . . . 12 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 8. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 13 87 8.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 13 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 89 9.1. Statement about Downgraded- registration . . . . . . . . . 14 90 9.2. Existing Downgraded- registrations . . . . . . . . . . . . 14 91 9.3. Additional header fields . . . . . . . . . . . . . . . . . 14 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 93 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 94 11.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 15 95 11.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 15 96 11.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 16 97 11.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 16 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 100 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 101 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17 102 A.1. Downgrading Example . . . . . . . . . . . . . . . . . . . 17 104 1. Introduction 106 Traditional mail systems, which are defined by [RFC5322], allow ASCII 107 characters in mail header field values. The UTF8SMTP extension 108 ([I-D.ietf-eai-frmwrk-4952bis] and [I-D.ietf-eai-rfc5335bis] allows 109 UTF-8 characters in mail header field values. 111 If a header field contains non-ASCII characters, POP/IMAP servers 112 cannot send Internationalized Email Headers to the client and cannot 113 remove the message. This message downgrading mechanism converts mail 114 header fields to an all-ASCII representation. The POP/IMAP servers 115 can use the downgrading mechanism and send the Internationalized 116 Email message as a traditional form. 118 [I-D.ietf-eai-rfc5335bis] allows UTF-8 characters to be used in mail 119 header fields and MIME header fields. The message downgrading 120 mechanism specified here describes the conversion method from the 121 internationalized email messages that are defined in 122 [I-D.ietf-eai-frmwrk-4952bis], and [I-D.ietf-eai-rfc5335bis] to the 123 traditional email messages defined in [RFC5322]. 125 There is no good way to convert "From:" and "Sender:" header fields, 126 the draft need to update [RFC5322] to allow empty "From:" and 127 "Sender:" header fields and it is described in Section 3. 129 Message Downgrading may be implemented in POP server and IMAP server 130 only. 132 This document tries to define the message downgrading process 133 clearly. 135 Downgrading consists of the following four parts: 137 o Updating RFC 5322 139 o New header field definitions 141 o Email header field downgrading 143 o MIME header field downgrading 145 In Section 4 of this document, header fields starting with 146 "Downgraded-" are introduced. They preserve the original header 147 fields. 149 Email header field downgrading is described in Section 5. It 150 generates ASCII-only header fields. 152 MIME header fields are expanded in [I-D.ietf-eai-rfc5335bis]. MIME 153 header field downgrading is described in Section 6. It generates 154 ASCII-only MIME header fields. 156 Displaying downgraded messages that originally contained 157 internationalized header fields is out of scope of this document. A 158 POP/IMAP client which does not support UTF8 extension does not know 159 internationalized message format described in 160 [I-D.ietf-eai-rfc5335bis]. 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 All specialized terms used in this specification are defined in the 169 Email Address Internationalization (EAI) overview 170 [I-D.ietf-eai-frmwrk-4952bis], in the mail message specifications 171 [RFC5322], or in the MIME documents [RFC2045] [RFC2047] [RFC2183] 172 [RFC2231]. The terms "ASCII address", "internationalized email 173 address", "non-ASCII address", "i18mail address", "UTF8SMTP", 174 "message", and "mailing list" are used with the definitions from 175 [I-D.ietf-eai-frmwrk-4952bis]. 177 This document depends on [I-D.ietf-eai-rfc5335bis]. Key words used 178 in those documents are used in this document, too. 180 The term "non-ASCII" refers to a UTF-8 string that contains at least 181 one non-ASCII character. 183 A "UTF8SMTP message" is an email message expanded by 184 [I-D.ietf-eai-rfc5335bis]. 186 3. Updating RFC 5322 188 "From:" header field or "Sender:" header field may contain non-ASCII 189 addresses in internationalized Email messages. These non-ASCII 190 addresses are not allowed in [RFC5322]. The draft proposes that the 191 pop/imap downgrading uses syntax and encodes non-ASCII 192 addresses into with empty described in 193 Section 5. 195 This specification redefines "From:", "Sender:", "Resent-From:" and 196 "Resent-Sender:" header fields defined in Section 3.6.2 and 3.6.6 of 197 [RFC5322] to allow in the header fields. 199 from = "From:" address-list CRLF 200 resent-from = "Resent-From:" address-list CRLF 201 sender = "Sender:" address CRLF 202 resent-sender = "Resent-Sender:" address CRLF 204 4. New Header Fields Definition 206 New header fields starting with "Downgraded-" are defined here to 207 preserve those mail header field values that contain UTF-8 208 characters. During downgrading, one new "Downgraded-" header field 209 is added for each mail header field that cannot be passed as-is to a 210 POP/IMAP client that does not support UTF8 extension. The original 211 mail header field is removed. Only those mail header fields that 212 contain non-ASCII characters are affected. The result of this 213 process is a message that is compliant with existing email 214 specifications [RFC5322]. The original internationalized information 215 can be retrieved by examining the "Downgraded-" header fields that 216 were added. 218 4.1. Preservation Header Fields 220 New preservation header fields are defined to preserve information 221 that appeared in non-ASCII text in header fields of the incoming 222 message. The values of the new fields holds the original header 223 field value in encoded form. The revised header field syntax is 224 specified as follows: 226 fields =/ known-downgraded-headers ":" 227 unstructured CRLF 229 known-downgraded-headers = "Downgraded-" original-headers 231 original-headers = "Message-Id" / "Resent-Message-Id" / 232 "In-Reply-To:" / "References:" / 233 "Original-Recipient" / "Final-Recipient" 235 To preserve a header field in a "Downgraded-" header field: 237 1. Generate a new "Downgraded-" header field whose value is the 238 original header field value. 240 2. Treat the generated header field content as if it were 241 unstructured, and then apply [RFC2047] encoding with charset 242 UTF-8 as necessary so that the result is ASCII. 244 3. Remove the original header field. 246 5. Email Header Fields Downgrading 248 This section defines the conversion method to ASCII for each header 249 field that may contain non-ASCII characters. 251 [I-D.ietf-eai-rfc5335bis] expands "Received:" header fields; 252 [RFC5322] describes ABNF elements , , , 253 ; [RFC2045] describes ABNF element . 255 5.1. Downgrading Method for Each ABNF Element 257 Header field downgrading is defined below for each ABNF element. 258 Converting the header field terminates when no non-ASCII characters 259 remain in the header field. 261 5.1.1. RECEIVED Downgrading 263 If the header field name is "Received:" and the FOR clause contains a 264 non-ASCII address, remove the FOR clause from the header field. 265 Other parts (not counting s) should not contain non-ASCII 266 values. 268 5.1.2. UNSTRUCTURED Downgrading 270 If the header field has an field that contains non- 271 ASCII characters, apply [RFC2047] encoding with charset UTF-8. 273 5.1.3. WORD Downgrading 275 If the header field has any fields that contain non-ASCII 276 characters, apply [RFC2047] encoding with charset UTF-8. 278 5.1.4. COMMENT Downgrading 280 If the header field has any fields that contain non-ASCII 281 characters, apply [RFC2047] encoding with charset UTF-8. 283 5.1.5. MIME-VALUE Downgrading 285 If the header field has any elements defined by [RFC2045] and 286 the elements contain non-ASCII characters, encode the 287 elements according to [RFC2231] with charset UTF-8 and leave the 288 language information empty. If the element is and it contains outside the DQUOTE, remove the 290 before this conversion. 292 5.1.6. DISPLAY-NAME Downgrading 294 If the header field has any
( or ) elements 295 and they have elements that contain non-ASCII 296 characters, encode the elements according to [RFC2047] 297 with charset UTF-8. DISPLAY-NAME downgrading is the same algorithm 298 as WORD downgrading. 300 5.1.7. GROUP Downgrading 302 is defined in Section 3.4 of [RFC5322]. The elements 303 may contain s which contain non-ASCII addresses. 305 If the header field has any elements that contain 306 elements, and those elements in turn contain non-ASCII 307 addresses, rewrite each element as 309 "Internationalized address removed" display-name ENCODED_WORD ":;" 311 where the is the original encoded 312 according to [RFC2047]. 314 5.1.8. MAILBOX Downgrading 316 The elements have no equivalent format for non-ASCII 317 addresses. If the header field has any elements that 318 contain non-ASCII characters in their element, rewrite 319 each element to ASCII-only format. The 320 element that contains non-ASCII characters may appear in two forms 321 as: 323 "<" addr-spec ">" 324 addr-spec 326 Rewrite both as: 328 "Internationalized address " ENCODED-WORD " removed:;" 330 where the is the original encoded 331 according to [RFC2047]. 333 5.1.9. ENCAPSULATION Downgrading 335 Encapsulate the header field in a "Downgraded-" header field as 336 described in Section 4 as a last resort. 338 Applying this procedure to "Received:" header field is prohibited. 339 ENCAPSULATION Downgrading is allowed for "Message-ID", 340 "In-Reply-To:", "References:", "Original-Recipient" and "Final- 341 Recipient" header fields. 343 5.1.10. TYPED-ADDRESS Downgrading 345 If the header field contains and the contains raw non-ASCII characters, it is in utf-8-address form. 347 Convert it to utf-8-addr-xtext form. Those forms are described in 348 [I-D.ietf-eai-rfc5337bis-dsn]. COMMENT downgrading is also performed 349 in this case. If the address type is unrecognized and the header 350 field contains non-ASCII characters, then fall back to using 351 ENCAPSULATION downgrading on the entire header field. 353 5.2. Downgrading Method for Each Header Field 355 Header fields are listed in [RFC4021]. This section describes the 356 downgrading method for each header field. 358 If the whole mail header field does not contain non-ASCII characters, 359 email header field downgrading is not required. Each header field's 360 downgrading method is described below. 362 5.2.1. Address Header Fields That Contain
s 364 From: 365 Sender: 366 To: 367 Cc: 368 Bcc: 369 Reply-To: 370 Resent-From: 371 Resent-Sender: 372 Resent-To: 373 Resent-Cc: 374 Resent-Bcc: 375 Resent-Reply-To: 377 Return-Path: 378 Disposition-Notification-To: 380 If the header field contains elements that contain non-ASCII 381 addresses, perform COMMENT downgrading, DISPLAY-NAME downgrading, and 382 GROUP downgrading. 384 If the header field contains elements that contain non- 385 ASCII addresses, perform COMMENT downgrading, DISPLAY-NAME 386 downgrading, and MAILBOX downgrading. 388 5.2.2. Address Header Fields with Typed Addresses 390 Original-Recipient: 391 Final-Recipient: 393 If the header field contains non-ASCII characters, perform TYPED- 394 ADDRESS downgrading. 396 5.2.3. Downgrading Non-ASCII in Comments 398 Date: 399 Resent-Date: 400 MIME-Version: 401 Content-ID: 402 Content-Transfer-Encoding: 403 Content-Language: 404 Accept-Language: 405 Auto-Submitted: 407 These header fields do not contain non-ASCII characters except in 408 comments. If the header field contains UTF-8 characters in comments, 409 perform COMMENT downgrading. 411 5.2.4. Message-ID Header Fields 413 Message-ID: 414 Resent-Message-ID: 415 In-Reply-To: 416 References: 418 Perform ENCAPSULATION Downgrading. 420 5.2.5. Received Header Field 422 Received: 424 Perform COMMENT downgrading and RECEIVED downgrading. 426 5.2.6. MIME Content Header Fields 428 Content-Type: 429 Content-Disposition: 431 Perform MIME-VALUE downgrading and COMMENT downgrading. 433 5.2.7. Non-ASCII in 435 Subject: 436 Comments: 437 Content-Description: 439 Perform UNSTRUCTURED downgrading. 441 5.2.8. Non-ASCII in 443 Keywords: 445 Perform WORD downgrading. 447 5.2.9. Other Header Fields 449 There are other header fields that contain non-ASCII characters. 450 They are user-defined and missing from this document, or future 451 defined header fields. They are treated as "Optional Fields" and 452 their field value are treated as unstructured described in Section 453 3.6.8 of [RFC5322]. 455 Perform UNSTRUCTURED downgrading. 457 If the software understands the header field's structure and a 458 downgrading algorithm other than UNSTRUCTURED is applicable, that 459 software SHOULD use that algorithm; UNSTRUCTURED downgrading is used 460 as a last resort. 462 Mailing list header fields (those that start in "List-") are part of 463 this category. 465 6. MIME Body-Part Header Field Downgrading 467 MIME body-part header fields may contain non-ASCII characters 468 [I-D.ietf-eai-rfc5335bis]. This section defines the conversion 469 method to ASCII-only header fields for each MIME header field that 470 contains non-ASCII characters. Parse the message body's MIME 471 structure at all levels and check each MIME header field to see 472 whether it contains non-ASCII characters. If the header field 473 contains non-ASCII characters in the header field value, the header 474 field is a target of the MIME body-part header field's downgrading. 475 Each MIME header field's downgrading method is described below. 476 COMMENT downgrading, MIME-VALUE downgrading, and UNSTRUCTURED 477 downgrading are described in Section 5. 479 Content-ID: 480 The "Content-ID:" header field does not contain non-ASCII 481 characters except in comments. If the header field contains UTF-8 482 characters in comments, perform COMMENT downgrading. 484 Content-Type: 486 Content-Disposition: 487 Perform MIME-VALUE downgrading and COMMENT downgrading. 489 Content-Description: Perform UNSTRUCTURED downgrading. 491 7. Security Considerations 493 Existing clients do not know new From: and Sender: header fields 494 syntax updated by Section 3 and may get wrong when they confront 495 syntax in From: and Sender: fields. 497 A downgraded message's header fields contain ASCII characters only. 498 But they still contain MIME-encapsulated header fields that contain 499 non-ASCII UTF-8 characters. Furthermore, the body part may contain 500 UTF-8 characters. Implementations parsing Internet messages need to 501 accept UTF-8 body parts and UTF-8 header fields that are MIME- 502 encoded. Thus, this document inherits the security considerations of 503 MIME-encoded header fields ([RFC2047] and [RFC3629]). 505 Rewriting header fields increases the opportunities for undetected 506 spoofing by malicious senders. However, rewritten header fields are 507 preserved into Downgraded-* header fields, and parsing Downgraded-* 508 header fields enables the detection of spoofing caused by 509 downgrading. 511 The techniques described here invalidate methods that depend on 512 digital signatures over any part of the message, which includes the 513 top-level header fields and body-part header fields. Depending on 514 the specific message being downgraded, the following techniques are 515 likely to break: DomainKeys Identified Mail (DKIM), and possibly 516 S/MIME and Pretty Good Privacy (PGP). The two obvious mitigations 517 are to stick to 7-bit transport when using these techniques (as most/ 518 all of them presently require) or to make sure to have UTF8SMTP end- 519 to-end when needed. 521 While information in any email header field should usually be treated 522 with some suspicion, current email systems commonly employ various 523 mechanisms and protocols to make the information more trustworthy. 524 Currently, information in the new Downgraded-* header fields is 525 usually not inspected by these mechanisms, and may be even less 526 trustworthy than the traditional header fields. Note that the 527 Downgraded-* header fields could have been inserted with malicious 528 intent (and with content unrelated to the traditional header fields). 530 See the "Security Considerations" section in 531 [I-D.ietf-eai-frmwrk-4952bis] for more discussion. 533 8. Implementation Notes 535 8.1. RFC 2047 Encoding 537 While [RFC2047] has a specific algorithm to deal with whitespace in 538 adjacent encoded words, there are a number of deployed 539 implementations that fail to implement the algorithm correctly. As a 540 result, whitespace behavior is somewhat unpredictable in practice 541 when multiple encoded words are used. While RFC 5322 states that 542 implementations SHOULD limit lines to not more than 78 characters, 543 implementations MAY choose to allow overly long encoded words in 544 order to work around faulty [RFC2047] implementations. 545 Implementations that choose to do so SHOULD have an optional 546 mechanism to limit line length to 78 characters. 548 9. IANA Considerations 550 [[RFC Editor: Please change "should now be" and "should be" to "have 551 been" when the IANA actions are complete.]] 553 [[ Notes in draft: this section is not finished, to be reviewed with 554 IANA. ]] 556 Following instructions in the now-obsolete [RFC5504], IANA has made a 557 series of entries in the the Permanent Message Header Field registry. 558 Those registrations should now be changed as follows: 560 9.1. Statement about Downgraded- registration 562 The statement about refusing any "Downgraded-" registrations should 563 be updated to refer to this document and to provide for registering 564 such fields as specified in Section 9.3. 566 [[ Note in draft: The restriction may become useless if unknown 567 header fields may be treated as unstructured. ]] 569 9.2. Existing Downgraded- registrations 571 Individual existing registrations for 573 Downgraded-Bcc 574 Downgraded-Cc 575 Downgraded-Disposition-Notification-To 576 Downgraded-From 577 Downgraded-Mail-From 578 Downgraded-Rcpt-To 579 Downgraded-Reply-To 580 Downgraded-Resent-Bcc 581 Downgraded-Resent-Cc 582 Downgraded-Resent-From 583 Downgraded-Resent-Reply-To 584 Downgraded-Resent-Sender 585 Downgraded-Resent-To 586 Downgraded-Return-Path 587 Downgraded-Sender 588 Downgraded-To 590 should be updated to replace "experimental" with "obsoleted" and to 591 reference this document. 593 9.3. Additional header fields 595 The following header fields should be registered in the Permanent 596 Message Header Field registry, in accordance with the procedures set 597 out in [RFC3864]. 599 Header field name: Downgraded-Message-Id 600 Applicable protocol: mail 601 Status: standard 602 Author/change controller: IETF 603 Specification document(s): This document (Section 4) 604 Header field name: Downgraded-In-Reply-To 605 Applicable protocol: mail 606 Status: standard 607 Author/change controller: IETF 608 Specification document(s): This document (Section 4) 610 Header field name: Downgraded-References 611 Applicable protocol: mail 612 Status: standard 613 Author/change controller: IETF 614 Specification document(s): This document (Section 4) 616 Header field name: Downgraded-Original-Recipient 617 Applicable protocol: mail 618 Status: standard 619 Author/change controller: IETF 620 Specification document(s): This document (Section 4) 622 Header field name: Downgraded-Final-Recipient 623 Applicable protocol: mail 624 Status: standard 625 Author/change controller: IETF 626 Specification document(s): This document (Section 4) 628 10. Acknowledgements 630 This document draws heavily from the experimental in-transit message 631 downgrading procedure described in RFC 5504 [RFC5504]. The 632 contribution of the co-author of that earlier document, Y. Yoneya, 633 are gratefully acknowledged. 635 11. Change History 637 This section is used for tracking the update of this document. Will 638 be removed after finalize. 640 11.1. Version 00 642 o Initial version 644 o Imported header field downgrading from RFC 5504 646 11.2. Version 01 648 o same as Version 00 650 11.3. Version 02 652 o Added updating RFC 5322 to allow syntax in From: and 653 Sender 655 o Added GROUP Downgrading 657 11.4. Version 03 659 o Replaced with 661 o Added updating RFC 5322 to allow syntax in From: and 662 Sender 664 o Added one sentence in Security considerations 666 o Updated IANA considerations 668 12. References 670 12.1. Normative References 672 [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and 673 Framework for Internationalized 674 Email", 675 draft-ietf-eai-frmwrk-4952bis-12 (work 676 in progress), October 2011. 678 [I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., and N. Freed, 679 "Internationalized Email Headers", 680 draft-ietf-eai-rfc5335bis-13 (work in 681 progress), October 2011. 683 [I-D.ietf-eai-rfc5337bis-dsn] Hansen, T., Newman, C., and A. 684 Melnikov, "Internationalized Delivery 685 Status and Disposition Notifications", 686 draft-ietf-eai-rfc5337bis-dsn-05 (work 687 in progress), October 2011. 689 [RFC2045] Freed, N. and N. Borenstein, 690 "Multipurpose Internet Mail Extensions 691 (MIME) Part One: Format of Internet 692 Message Bodies", RFC 2045, 693 November 1996. 695 [RFC2047] Moore, K., "MIME (Multipurpose 696 Internet Mail Extensions) Part Three: 697 Message Header Extensions for Non- 698 ASCII Text", RFC 2047, November 1996. 700 [RFC2183] Troost, R., Dorner, S., and K. Moore, 701 "Communicating Presentation 702 Information in Internet Messages: The 703 Content-Disposition Header Field", 704 RFC 2183, August 1997. 706 [RFC2231] Freed, N. and K. Moore, "MIME 707 Parameter Value and Encoded Word 708 Extensions: Character Sets, Languages, 709 and Continuations", RFC 2231, 710 November 1997. 712 [RFC5322] Resnick, P., Ed., "Internet Message 713 Format", RFC 5322, October 2008. 715 [RFC3629] Yergeau, F., "UTF-8, a transformation 716 format of ISO 10646", STD 63, 717 RFC 3629, November 2003. 719 [RFC4021] Klyne, G. and J. Palme, "Registration 720 of Mail and MIME Header Fields", 721 RFC 4021, March 2005. 723 [RFC2119] Bradner, S., "Key words for use in 724 RFCs to Indicate Requirement Levels", 725 BCP 14, RFC 2119, March 1997. 727 [RFC3864] Klyne, G., Nottingham, M., and J. 728 Mogul, "Registration Procedures for 729 Message Header Fields", BCP 90, 730 RFC 3864, September 2004. 732 12.2. Informative References 734 [RFC5504] Fujiwara, K. and Y. Yoneya, 735 "Downgrading Mechanism for Email 736 Address Internationalization", 737 RFC 5504, March 2009. 739 Appendix A. Examples 741 A.1. Downgrading Example 743 This appendix shows an message downgrading example. Consider a 744 received mail message where: 746 o The sender address is a non-ASCII address, 747 "NON-ASCII-local@example.com". Its display-name is "DISPLAY- 748 local". 750 o The "To:" header field contains two non-ASCII addresses, 751 "NON-ASCII-remote1@example.net" and 752 "NON-ASCII-remote2@example.com" Its display-names are "DISPLAY- 753 remote1" and "DISPLAY-remote2". 755 o The "Cc:" header field contains a non-ASCII address, 756 "NON-ASCII-remote3@example.org". Its display-name is "DISPLAY- 757 remote3". 759 o Four display names contain non-ASCII characters. 761 o The Subject header field is "NON-ASCII-SUBJECT", which contains 762 non-ASCII characters. 764 o The "Message-Id:" header field contains "NON-ASCII-MESSAGE_ID", 765 which contains non-ASCII characters. 767 o There is an unknown header field "X-Unknown-Header" which contains 768 non-ASCII characters. 770 Return-Path: 771 Received: from ... by ... for 772 Received: from ... by ... for 773 From: DISPLAY-local 774 To: DISPLAY-remote1 , 775 DISPLAY-remote2 776 Cc: DISPLAY-remote3 777 Subject: NON-ASCII-SUBJECT 778 Date: DATE 779 Message-Id: NON-ASCII-MESSAGE_ID 780 Mime-Version: 1.0 781 Content-Type: text/plain; charset="UTF-8" 782 Content-Transfer-Encoding: 8bit 783 X-Unknown-Header: NON-ASCII-CHARACTERS 785 MAIL_BODY 787 Figure 1: Received message in a mail drop 789 The downgraded message is shown in Figure 2. "Return-Path:", 790 "From:", "To:" and "Cc:" header fields are rewritten. "Subject:" and 791 "X-Unknown-Header:" header fields are encoded using [RFC2047]. 792 "Message-Id:" header field is encapsulated as 793 "Downgraded-Message-Id:" header field. 795 Return-Path: Internationalized address 796 =?UTF-8?Q?NON-ASCII-local@example.com?= removed:; 797 Received: from ... by ... 798 Received: from ... by ... 799 From: =?UTF-8?Q?DISPLAY-local?= Internationalized address 800 =?UTF-8?Q?NON-ASCII-local@example.com?= removed:; 801 To: =?UTF-8?Q?DISPLAY-remote1?= Internationalized address 802 =?UTF-8?Q?NON-ASCII-remote1@example.net?= removed:;, 803 =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 804 =?UTF-8?Q?NON-ASCII-remote2@example.com?= removed:;, 805 Cc: =?UTF-8?Q?DISPLAY-remote3?= Internationalized address 806 =?UTF-8?Q?NON-ASCII-remote3@example.org?= removed:; 807 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 808 Date: DATE 809 Downgraded-Message-Id: =?UTF-8?Q?MESSAGE_ID?= 810 Mime-Version: 1.0 811 Content-Type: text/plain; charset="UTF-8" 812 Content-Transfer-Encoding: 8bit 813 X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?= 815 MAIL_BODY 817 Figure 2: Downgraded message 819 Author's Address 821 Kazunori Fujiwara 822 Japan Registry Services Co., Ltd. 823 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 824 Chiyoda-ku, Tokyo 101-0065 825 Japan 827 Phone: +81 3 5215 8451 828 EMail: fujiwara@wide.ad.jp, fujiwara@jprs.co.jp