idnits 2.17.1 draft-ietf-eai-popimap-downgrade-08.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 : ---------------------------------------------------------------------------- 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 (Oct 22, 2012) is 4204 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 (-09) exists of draft-leiba-5322upd-from-group-06 == Outdated reference: A later version (-12) exists of draft-ietf-eai-5738bis-09 -- 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 (~~), 3 warnings (==), 3 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 22, 2012 5 Intended status: Standards Track 6 Expires: April 25, 2013 8 Post-delivery Message Downgrading for Internationalized Email Messages 9 draft-ietf-eai-popimap-downgrade-08.txt 11 Abstract 13 The Email Address Internationalization (SMTPUTF8) extension to SMTP 14 allows UTF-8 characters in mail header fields. Upgraded POP and IMAP 15 servers support internationalized Email messages. If a POP/IMAP 16 client does not support Email Address Internationalization, POP/IMAP 17 servers cannot deliver Internationalized Email Headers to the client 18 and cannot remove the message. To avoid the situation, this document 19 describes a conversion mechanism for internationalized Email messages 20 to be in traditional message format. In the process, message 21 elements requiring internationalized treatment are recoded or removed 22 and receivers are able to know that they received messages containing 23 such elements even if they cannot process the internationalized 24 elements. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 25, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Possible solutions . . . . . . . . . . . . . . . . . . . . 4 63 1.3. Approach taken in this specification . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Email Header Fields Downgrading . . . . . . . . . . . . . . . 6 66 3.1. Downgrading Method for Each ABNF Element . . . . . . . . . 6 67 3.1.1. UNSTRUCTURED Downgrading . . . . . . . . . . . . . . . 6 68 3.1.2. WORD Downgrading . . . . . . . . . . . . . . . . . . . 6 69 3.1.3. COMMENT Downgrading . . . . . . . . . . . . . . . . . 6 70 3.1.4. MIME-VALUE Downgrading . . . . . . . . . . . . . . . . 7 71 3.1.5. DISPLAY-NAME Downgrading . . . . . . . . . . . . . . . 7 72 3.1.6. DOMAIN Downgrading . . . . . . . . . . . . . . . . . . 7 73 3.1.7. GROUP Downgrading . . . . . . . . . . . . . . . . . . 7 74 3.1.8. MAILBOX Downgrading . . . . . . . . . . . . . . . . . 8 75 3.1.9. TYPED-ADDRESS Downgrading . . . . . . . . . . . . . . 8 76 3.1.10. ENCAPSULATION: A Last Resort . . . . . . . . . . . . . 8 77 3.2. Downgrading Method for Each Header Field . . . . . . . . . 10 78 3.2.1. Address Header Fields That Contain
s . . . . 10 79 3.2.2. Downgrading Non-ASCII in Comments . . . . . . . . . . 11 80 3.2.3. Message-ID Header Fields . . . . . . . . . . . . . . . 11 81 3.2.4. Received Header Field . . . . . . . . . . . . . . . . 11 82 3.2.5. MIME Content Header Fields . . . . . . . . . . . . . . 12 83 3.2.6. Non-ASCII in . . . . . . . . . . . . . 12 84 3.2.7. Non-ASCII in . . . . . . . . . . . . . . . . 12 85 3.2.8. Other Header Fields . . . . . . . . . . . . . . . . . 12 86 4. MIME Downgrading . . . . . . . . . . . . . . . . . . . . . . . 12 87 4.1. MIME Body-Part Header Field Downgrading . . . . . . . . . 13 88 4.2. Delivery Status Notification downgrading . . . . . . . . . 13 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 90 6. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 14 91 6.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 14 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 7.1. Obsolescence of Existing Downgraded-* Header Fields . . . 15 94 7.2. Registration of New Downgraded-* Header Fields . . . . . . 15 95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 98 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 99 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 100 A.1. Downgrading Example . . . . . . . . . . . . . . . . . . . 18 101 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 20 102 B.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 20 103 B.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 20 104 B.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 20 105 B.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 21 106 B.5. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 21 107 B.6. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 21 108 B.7. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 21 109 B.8. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 22 110 B.9. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 22 112 1. Introduction 114 1.1. Problem statement 116 Traditional (legacy) mail systems, which are defined by [RFC5322] and 117 other specifications, allow only ASCII characters in mail header 118 field values. The SMTPUTF8 extension ([RFC6530], [RFC6531] and 119 [RFC6532]) allow raw UTF-8 in those mail header fields. 121 If a header field contains non-ASCII strings, POP/IMAP servers cannot 122 deliver Internationalized Email Headers to legacy clients which does 123 not send UTF8 command or UTF8 capability, and because they have no 124 obvious or standardized way to explain what is going on to those 125 clients, cannot even safely discard the message. 127 1.2. Possible solutions 129 There are four plausible approaches to the problem, with the 130 preferred one depending on the particular circumstances and 131 relationship among the delivery SMTP server, the mail store, the POP 132 or IMAP server, and the users and their MUA clients: 134 1. If the delivery MTA has sufficient knowledge about the POP and/or 135 IMAP servers and clients being used, the message may be rejected 136 as undeliverable. 138 2. The message may be downgraded by the POP or IMAP server, in a way 139 that preserves maximum information at the expense of some 140 complexity, and does not create security or operational problems 141 in the mail system. 143 3. Some intermediate downgrading may be applied that balances more 144 information loss against lower complexity and greater ease of 145 implementation. 147 4. The POP or IMAP server may fabricate a message whose intent is to 148 notify the client that an internationalized message is waiting 149 but cannot be delivered until an upgraded client is available. 151 1.3. Approach taken in this specification 153 This specification describes the second of those options. It is 154 worth noticing that, at least in the general case, none of these 155 options preserve sufficient information to guarantee that it is 156 possible to reply to an incoming message without loss of information, 157 so the choice may be considered to be among "least bad" options. 158 While this document specifies a well designed mechanism, it is only 159 an interim solution while clients are being upgraded 161 [I-D.ietf-eai-rfc5721bis] [I-D.ietf-eai-5738bis]. 163 This message downgrading mechanism converts mail header fields to an 164 all-ASCII representation. The POP/IMAP servers can use the 165 downgrading mechanism and deliver the Internationalized Email message 166 as a traditional form. Receivers can know they received some 167 internationalized messages or some unknown or broken messages. 169 [RFC6532] allows UTF-8 characters to be used in mail header fields 170 and MIME header fields. [RFC6531] allows UTF-8 characters to be used 171 in some trace header fields. The message downgrading mechanism 172 specified here describes the conversion method from the 173 internationalized messages that are defined in [RFC6530], and 174 [RFC6532] to the traditional email messages defined in [RFC5322]. 176 This document provides a precise definition of the minimum- 177 information-loss message downgrading process. 179 Downgrading consists of the following three parts: 181 o New header field definitions 183 o Email header field downgrading 185 o MIME header field downgrading 187 Email header field downgrading is described in Section 3. It 188 generates ASCII-only header fields. 190 In Section 3.1.10 of this document, header fields starting with 191 "Downgraded-" are introduced. They preserve the information that 192 appeared in the original header fields. 194 The definition of MIME header fields in Internationalized Email 195 Messages is described in [RFC6532]. MIME header field downgrading is 196 described in Section 4.1. It generates ASCII-only MIME header 197 fields. 199 Displaying downgraded messages that originally contained 200 internationalized header fields is out of scope of this document. A 201 POP/IMAP client which does not support UTF8 extensions as defined for 202 POP3 [UTF8 command] and IMAP ["ENABLE UTF8=ACCEPT" command] does not 203 know internationalized message format described in [RFC6532]. 205 2. Terminology 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119 [RFC2119]. 211 All specialized terms used in this specification are defined in the 212 Overview and Framework for Internationalized Email [RFC6530], in the 213 mail message specifications [RFC5322], or in the MIME documents 214 [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "U-label", 215 "A-label" and "IDNA" are used with the definitions from [RFC5890]. 216 The terms "ASCII address", "non-ASCII address", "SMTPUTF8", 217 "message", "internationalized message" are used with the definitions 218 from [RFC6530]. The term "non-ASCII string" is used with the 219 definitions from [RFC6532]. 221 3. Email Header Fields Downgrading 223 This section defines the conversion method to ASCII for each header 224 field that may contain non-ASCII strings. Section 3.1 describes 225 rewriting methods for each ABNF element. Section 3.2 describes 226 rewriting methods for each header field. 228 3.1. Downgrading Method for Each ABNF Element 230 Header field downgrading is defined below for each ABNF element. 231 Converting the header field terminates when no non-ASCII strings 232 remain in the header field. 234 [RFC5322] describes ABNF elements , , , 235 , , . [RFC2045] describes ABNF element 236 . is updated to allow non-ASCII characters in Section 237 3.3 of [RFC6531] and Section 3.2 of [RFC6532]. 239 3.1.1. UNSTRUCTURED Downgrading 241 If the header field has an field that contains non- 242 ASCII strings, apply [RFC2047] encoding with charset UTF-8. 244 3.1.2. WORD Downgrading 246 If the header field has any fields that contain non-ASCII 247 strings, apply [RFC2047] encoding with charset UTF-8. 249 3.1.3. COMMENT Downgrading 251 If the header field has any fields that contain non-ASCII 252 strings, apply [RFC2047] encoding with charset UTF-8. 254 3.1.4. MIME-VALUE Downgrading 256 If the header field has any elements defined by [RFC2045] and 257 the elements contain non-ASCII strings, encode the elements 258 according to [RFC2231] with charset UTF-8 and leave the language 259 information empty. If the element is and it 260 contains outside the DQUOTE, remove the before this 261 conversion. 263 3.1.5. DISPLAY-NAME Downgrading 265 If the header field has any
( or ) elements 266 and they have elements that contain non-ASCII strings, 267 encode the elements according to [RFC2047] with 268 charset UTF-8. DISPLAY-NAME downgrading is the same algorithm as 269 WORD downgrading. 271 3.1.6. DOMAIN Downgrading 273 If the header field has any elements that contain U-labels, 274 rewrite the non-ASCII domain name into ASCII domain name using 275 A-labels as specified in IDNA [RFC5891]. 277 3.1.7. GROUP Downgrading 279 is defined in Section 3.4 of [RFC5322]. The elements 280 may contain es which contain non-ASCII addresses. 282 If a element contains elements and one of 283 es contains a non-ASCII , rewrite the 284 element as 286 display-name " " ENCODED_WORD " :;" 288 where the is the original encoded 289 according to [RFC2047]. 291 Otherwise, the element does not contain non-ASCII . If the element contain non-ASCII es, they 293 contains non-ASCII domain names. Rewrite the non-ASCII domain names 294 into ASCII domain names using A-labels as specified in IDNA 295 [RFC5891]. Generated es contain ASCII addresses only. 297 3.1.8. MAILBOX Downgrading 299 If the of the element does not contain non- 300 ASCII characters, the element contains non-ASCII characters. 301 Rewrite the non-ASCII domain name into ASCII domain name using 302 A-labels as specified in IDNA [RFC5891]. 304 Otherwise, the contains non-ASCII characters. The non- 305 ASCII has no equivalent format for ASCII addresses. The 306 element that contains non-ASCII strings may appear in two 307 forms as: 309 "<" addr-spec ">" 310 addr-spec 312 Rewrite both as: 314 ENCODED-WORD " :;" 316 where the is the original encoded 317 according to [RFC2047]. 319 3.1.9. TYPED-ADDRESS Downgrading 321 If the header field contains and the contains raw non-ASCII strings, it is in utf-8-address form. 323 Convert it to utf-8-addr-xtext form. Those forms are described in 324 [RFC6533]. COMMENT downgrading is also performed in this case. If 325 the address type is unrecognized and the header field contains non- 326 ASCII strings, then fall back to using ENCAPSULATION on the entire 327 header field specified in Section 3.1.10. 329 3.1.10. ENCAPSULATION: A Last Resort 331 As a last resort when header fields cannot be converted as discussed 332 in the previous section, the fields are deleted and replaced by 333 specialized new header fields. Those fields are defined to preserve, 334 in encoded form, as much information as possible from the header 335 field values of the incoming message. The syntax of these new header 336 fields is: 338 fields =/ downgraded 340 downgraded = "Downgraded-Message-Id:" unstructured CRLF / 341 "Downgraded-Resent-Message-Id:" unstructured CRLF / 342 "Downgraded-In-Reply-To:" unstructured CRLF / 343 "Downgraded-References:" unstructured CRLF / 344 "Downgraded-Original-Recipient:" unstructured CRLF / 345 "Downgraded-Final-Recipient:" unstructured CRLF 347 Applying this procedure to "Received:" header field is prohibited. 348 ENCAPSULATION Downgrading is allowed for "Message-ID", 349 "In-Reply-To:", "References:", "Original-Recipient" and "Final- 350 Recipient" header fields. 352 To preserve a header field in a "Downgraded-" header field: 354 1. Generate a new header field. 356 * The field name is a concatenation of "Downgraded-" and the 357 original field name. 359 * The initial new field value is the original header field 360 value. 362 2. Treat the initial new header field value as if it were 363 unstructured, and then apply [RFC2047] encoding with charset 364 UTF-8 as necessary so that the resulting new header field value 365 is completely in ASCII. 367 3. Remove the original header field. 369 3.2. Downgrading Method for Each Header Field 371 [RFC4021] establishes a registry of header fields. This section 372 describes the downgrading method for each header field. 374 If the whole mail header field does not contain non-ASCII strings, 375 email header field downgrading is not required. Each header field's 376 downgrading method is described below. 378 3.2.1. Address Header Fields That Contain
s 380 From: 381 Sender: 382 To: 383 Cc: 384 Bcc: 385 Reply-To: 386 Resent-From: 387 Resent-Sender: 388 Resent-To: 389 Resent-Cc: 390 Resent-Bcc: 391 Resent-Reply-To: 392 Return-Path: 393 Disposition-Notification-To: 395 If the header field contains non-ASCII characters, first perform 396 COMMENT downgrading and DISPLAY-NAME downgrading as described in the 397 corresponding subsections of Section 3.1. If the header field still 398 contains non-ASCII characters after that, do the following two steps: 400 1. If the header field contains elements that contain non- 401 ASCII addresses, perform GROUP downgrading on those elements. 403 2. If the header field contains elements that contain non- 404 ASCII addresses, perform MAILBOX downgrading on those elements. 406 This procedure may generate empty elements in "From:", 407 "Sender:" and "Reply-To:" header fields. 408 [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty) 409 elements in "From:", "Sender:" and "Reply-To:" header fields. 411 3.2.2. Downgrading Non-ASCII in Comments 413 Date: 414 Resent-Date: 415 MIME-Version: 416 Content-ID: 417 Content-Transfer-Encoding: 418 Content-Language: 419 Accept-Language: 420 Auto-Submitted: 422 These header fields do not contain non-ASCII strings except in 423 comments. If the header field contains UTF-8 characters in comments, 424 perform COMMENT downgrading. 426 3.2.3. Message-ID Header Fields 428 Message-ID: 429 Resent-Message-ID: 430 In-Reply-To: 431 References: 433 Perform ENCAPSULATION as specified in Section 3.1.10. 435 3.2.4. Received Header Field 437 Received: 439 If elements or elements contains U-labels, perform 440 DOMAIN downgrading specified in Section 3.1.6. Comments may contain 441 non-ASCII strings, perform COMMENT downgrading. 443 After the DOMAIN downgrading and the COMMENT downgrading, if the FOR 444 clause contains a non-ASCII , remove the "FOR" clause. 445 If the ID clause contains a non-ASCII values, remove the "ID" clause. 447 3.2.5. MIME Content Header Fields 449 Content-Type: 450 Content-Disposition: 452 Perform MIME-VALUE downgrading and COMMENT downgrading. 454 3.2.6. Non-ASCII in 456 Subject: 457 Comments: 458 Content-Description: 460 Perform UNSTRUCTURED downgrading. 462 3.2.7. Non-ASCII in 464 Keywords: 466 Perform WORD downgrading. 468 3.2.8. Other Header Fields 470 There are other header fields that contain non-ASCII strings. They 471 are user-defined and missing from this document, or future defined 472 header fields. They are treated as "Optional Fields" and their field 473 values are treated as unstructured described in Section 3.6.8 of 474 [RFC5322]. 476 Perform UNSTRUCTURED downgrading. 478 If the software understands the header field's structure and a 479 downgrading algorithm other than UNSTRUCTURED is applicable, that 480 software SHOULD use that algorithm; UNSTRUCTURED downgrading is used 481 as a last resort. 483 Mailing list header fields (those that start in "List-") are part of 484 this category. 486 4. MIME Downgrading 488 Both MIME Body-Part header fields and contents of a delivery status 489 notification may contain non-ASCII characters. 491 4.1. MIME Body-Part Header Field Downgrading 493 MIME body-part header fields may contain non-ASCII strings [RFC6532]. 494 This section defines the conversion method to ASCII-only header 495 fields for each MIME header field that contains non-ASCII strings. 496 Parse the message body's MIME structure at all levels and check each 497 MIME header field to see whether it contains non-ASCII strings. If 498 the header field contains non-ASCII strings in the header field 499 value, the header field is a target of the MIME body-part header 500 field's downgrading. Each MIME header field's downgrading method is 501 described below. COMMENT downgrading, MIME-VALUE downgrading, and 502 UNSTRUCTURED downgrading are described in Section 3. 504 Content-ID: 505 The "Content-ID:" header field does not contain non-ASCII strings 506 except in comments. If the header field contains UTF-8 characters 507 in comments, perform COMMENT downgrading. 509 Content-Type: 510 Content-Disposition: 511 Perform MIME-VALUE downgrading and COMMENT downgrading. 513 Content-Description: 514 Perform UNSTRUCTURED downgrading. 516 4.2. Delivery Status Notification downgrading 518 If the message contains a delivery status notification defined at 519 Section 6 of [RFC3461], perform the following tests and conversions. 521 If there are "Original-Recipient:" and "Final-Recipient:" header 522 fields, and the header fields contain non-ASCII strings, perform 523 TYPED-ADDRESS downgrading. 525 5. Security Considerations 527 The purpose of post-delivery message downgrading is to allow POP/IMAP 528 servers to deliver internationalized messages to traditional POP/IMAP 529 clients and permit the clients to display those messages. Users who 530 receive such messages can know that they were internationalized. It 531 does not permit receivers to read the messages in their original form 532 and, in general, will not permit generating replies, at least without 533 significant user intervention. 535 A downgraded message's header fields contain ASCII characters only. 536 But they still contain MIME-encapsulated header fields that contain 537 non-ASCII strings. Furthermore, the body part may contain UTF-8 538 characters. Implementations parsing Internet messages need to accept 539 UTF-8 body parts and UTF-8 header fields that are MIME-encoded. 540 Thus, this document inherits the security considerations of MIME- 541 encoded header fields ([RFC2047] and [RFC3629]). 543 Rewriting header fields increases the opportunities for undetected 544 spoofing by malicious senders. However, the rewritten header field 545 values are preserved in equivalent MIME form or in newly defined 546 header fields for which traditional MUAs have no special processing 547 procedures. 549 The techniques described here invalidate methods that depend on 550 digital signatures over any part of the message, which includes the 551 top-level header fields and body-part header fields. Depending on 552 the specific message being downgraded, at least the following 553 techniques are likely to break: DomainKeys Identified Mail (DKIM), 554 and possibly S/MIME and Pretty Good Privacy (PGP). The downgrade 555 mechanism SHOULD NOT remove signatures even if the signatures will 556 fail validation after downgrading. As much of the information as 557 possible from the original message SHOULD be preserved. 559 While information in any email header field should usually be treated 560 with some suspicion, current email systems commonly employ various 561 mechanisms and protocols to make the information more trustworthy. 562 Information in the new Downgraded-* header fields is not inspected by 563 traditional MUAs, and may be even less trustworthy than the 564 traditional header fields. Note that the Downgraded-* header fields 565 could have been inserted with malicious intent (and with content 566 unrelated to the traditional header fields), however traditional MUAs 567 do not parse Downgraded-* header fields. 569 In addition, if an Authentication-Results header field [RFC5451] is 570 present, traditional MUAs may treat that the digital signatures are 571 valid. 573 See the "Security Considerations" section in 574 [I-D.leiba-5322upd-from-group] and [RFC6530] for more discussion. 576 6. Implementation Notes 578 6.1. RFC 2047 Encoding 580 While [RFC2047] has a specific algorithm to deal with whitespace in 581 adjacent encoded words, there are a number of deployed 582 implementations that fail to implement the algorithm correctly. As a 583 result, whitespace behavior is somewhat unpredictable in practice 584 when multiple encoded words are used. While RFC 5322 states that 585 implementations SHOULD limit lines to not more than 78 characters, 586 implementations MAY choose to allow overly long encoded words in 587 order to work around faulty [RFC2047] implementations. 588 Implementations that choose to do so SHOULD have an optional 589 mechanism to limit line length to 78 characters. 591 7. IANA Considerations 593 [[RFC Editor: Please change "is asked to" to "has" (and change the 594 verb correspondingly) when the IESG approval and IANA actions are 595 complete.]] 597 [RFC5504] specified that no new header fields be registered that 598 begin with "Downgraded-". That restriction is now lifted, and this 599 document makes a new set of registrations, replacing the experimental 600 fields with standard ones. 602 7.1. Obsolescence of Existing Downgraded-* Header Fields 604 The "Downgraded-*" header fields that were registered as experimental 605 fields in [RFC5504] are no longer in use. IANA is asked to change 606 the status from "experimental" to "obsoleted" for every name in the 607 Permanent Message Header Field registry that begins with 608 "Downgraded-". 610 7.2. Registration of New Downgraded-* Header Fields 612 [[RFC Editor: Please change "should be" to "have been" when the IANA 613 actions are complete.]] 615 The following header fields should be registered in the Permanent 616 Message Header Field registry, in accordance with the procedures set 617 out in [RFC3864]. 619 Header field name: Downgraded-Message-Id 620 Applicable protocol: mail 621 Status: standard 622 Author/change controller: IETF 623 Specification document(s): This document (Section 3.1.10) 625 Header field name: Downgraded-In-Reply-To 626 Applicable protocol: mail 627 Status: standard 628 Author/change controller: IETF 629 Specification document(s): This document (Section 3.1.10) 630 Header field name: Downgraded-References 631 Applicable protocol: mail 632 Status: standard 633 Author/change controller: IETF 634 Specification document(s): This document (Section 3.1.10) 636 Header field name: Downgraded-Original-Recipient 637 Applicable protocol: mail 638 Status: standard 639 Author/change controller: IETF 640 Specification document(s): This document (Section 3.1.10) 642 Header field name: Downgraded-Final-Recipient 643 Applicable protocol: mail 644 Status: standard 645 Author/change controller: IETF 646 Specification document(s): This document (Section 3.1.10) 648 8. Acknowledgements 650 This document draws heavily from the experimental in-transit message 651 downgrading procedure described in RFC 5504 [RFC5504]. The 652 contribution of the co-author of that earlier document, Y. Yoneya, 653 are gratefully acknowledged. Significant comments and suggestions 654 were received from John Klensin, Barry Leiba, Randall Gellens, Pete 655 Resnick, Martin J. Durst, and other WG participants. 657 9. References 659 9.1. Normative References 661 [RFC2045] Freed, N. and N. Borenstein, 662 "Multipurpose Internet Mail 663 Extensions (MIME) Part One: Format of 664 Internet Message Bodies", RFC 2045, 665 November 1996. 667 [RFC2047] Moore, K., "MIME (Multipurpose 668 Internet Mail Extensions) Part Three: 669 Message Header Extensions for Non- 670 ASCII Text", RFC 2047, November 1996. 672 [RFC2119] Bradner, S., "Key words for use in 673 RFCs to Indicate Requirement Levels", 674 BCP 14, RFC 2119, March 1997. 676 [RFC2183] Troost, R., Dorner, S., and K. Moore, 677 "Communicating Presentation 678 Information in Internet Messages: The 679 Content-Disposition Header Field", 680 RFC 2183, August 1997. 682 [RFC2231] Freed, N. and K. Moore, "MIME 683 Parameter Value and Encoded Word 684 Extensions: Character Sets, Languages 685 , and Continuations", RFC 2231, 686 November 1997. 688 [RFC3461] Moore, K., "Simple Mail Transfer 689 Protocol (SMTP) Service Extension for 690 Delivery Status Notifications 691 (DSNs)", RFC 3461, January 2003. 693 [RFC3629] Yergeau, F., "UTF-8, a transformation 694 format of ISO 10646", STD 63, 695 RFC 3629, November 2003. 697 [RFC3864] Klyne, G., Nottingham, M., and J. 698 Mogul, "Registration Procedures for 699 Message Header Fields", BCP 90, 700 RFC 3864, September 2004. 702 [RFC4021] Klyne, G. and J. Palme, "Registration 703 of Mail and MIME Header Fields", 704 RFC 4021, March 2005. 706 [RFC5322] Resnick, P., Ed., "Internet Message 707 Format", RFC 5322, October 2008. 709 [RFC5890] Klensin, J., "Internationalized 710 Domain Names for Applications (IDNA): 711 Definitions and Document Framework", 712 RFC 5890, August 2010. 714 [RFC5891] Klensin, J., "Internationalized 715 Domain Names in Applications (IDNA): 716 Protocol", RFC 5891, August 2010. 718 [RFC6530] Klensin, J. and Y. Ko, "Overview and 719 Framework for Internationalized 720 Email", RFC 6530, February 2012. 722 [RFC6531] Yao, J. and W. Mao, "SMTP Extension 723 for Internationalized Email", 724 RFC 6531, February 2012. 726 [RFC6532] Yang, A., Steele, S., and N. Freed, 727 "Internationalized Email Headers", 728 RFC 6532, February 2012. 730 [RFC6533] Hansen, T., Newman, C., and A. 731 Melnikov, "Internationalized Delivery 732 Status and Disposition 733 Notifications", RFC 6533, 734 February 2012. 736 [I-D.leiba-5322upd-from-group] Leiba, B., "Update to Internet 737 Message Format to Allow Group Syntax 738 in the "From:" and "Sender:" Header 739 Fields", 740 draft-leiba-5322upd-from-group-06 741 (work in progress), October 2012. 743 [I-D.ietf-eai-rfc5721bis] Gellens, R., Newman, C., Yao, J., and 744 K. Fujiwara, "POP3 Support for 745 UTF-8", draft-ietf-eai-rfc5721bis-08 746 (work in progress), October 2012. 748 [I-D.ietf-eai-5738bis] Resnick, P., Newman, C., and S. Shen, 749 "IMAP Support for UTF-8", 750 draft-ietf-eai-5738bis-09 (work in 751 progress), August 2012. 753 9.2. Informative References 755 [RFC5451] Kucherawy, M., "Message Header Field 756 for Indicating Message Authentication 757 Status", RFC 5451, April 2009. 759 [RFC5504] Fujiwara, K. and Y. Yoneya, 760 "Downgrading Mechanism for Email 761 Address Internationalization", 762 RFC 5504, March 2009. 764 Appendix A. Examples 766 A.1. Downgrading Example 768 This appendix shows an message downgrading example. Consider a 769 received mail message where: 771 o The sender address is a non-ASCII address, 772 "NON-ASCII-LOCAL@example.com". Its display-name is "DISPLAY- 773 LOCAL". 775 o The "To:" header field contains two non-ASCII addresses, 776 "NON-ASCII-REMOTE1@example.net" and 777 "NON-ASCII-REMOTE2@example.com" Its display-names are "DISPLAY- 778 REMOTE1" and "DISPLAY-REMOTE2". 780 o The "Cc:" header field contains a non-ASCII address, 781 "NON-ASCII-REMOTE3@example.org". Its display-name is "DISPLAY- 782 REMOTE3". 784 o Four display names contain non-ASCII characters. 786 o The Subject header field is "NON-ASCII-SUBJECT", which contains 787 non-ASCII strings. 789 o The "Message-Id:" header field contains "NON-ASCII-MESSAGE_ID", 790 which contains non-ASCII strings. 792 o There is an unknown header field "X-Unknown-Header" which contains 793 non-ASCII strings. 795 Return-Path: 796 Received: from ... by ... for 797 Received: from ... by ... for 798 From: DISPLAY-LOCAL 799 To: DISPLAY-REMOTE1 , 800 DISPLAY-REMOTE2 801 Cc: DISPLAY-REMOTE3 802 Subject: NON-ASCII-SUBJECT 803 Date: Mon, 30 Jul 2012 01:23:45 -0000 804 Message-Id: NON-ASCII-MESSAGE_ID 805 Mime-Version: 1.0 806 Content-Type: text/plain; charset="UTF-8" 807 Content-Transfer-Encoding: 8bit 808 X-Unknown-Header: NON-ASCII-CHARACTERS 810 MAIL_BODY 812 Figure 1: Received message in a mail drop 814 The downgraded message is shown in Figure 2. "Return-Path:", 815 "From:", "To:" and "Cc:" header fields are rewritten. "Subject:" and 816 "X-Unknown-Header:" header fields are encoded using [RFC2047]. 817 "Message-Id:" header field is encapsulated as 818 "Downgraded-Message-Id:" header field. 820 Return-Path: =?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :; 821 Received: from ... by ... 822 Received: from ... by ... 823 From: =?UTF-8?Q?DISPLAY-LOCAL?= 824 =?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :; 825 To: =?UTF-8?Q?DISPLAY-REMOTE1?= 826 =?UTF-8?Q?NON-ASCII-REMOTE1@example.net?= :;, 827 =?UTF-8?Q?DISPLAY-REMOTE2?= 828 =?UTF-8?Q?NON-ASCII-REMOTE2@example.com?= :;, 829 Cc: =?UTF-8?Q?DISPLAY-REMOTE3?= 830 =?UTF-8?Q?NON-ASCII-REMOTE3@example.org?= :; 831 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 832 Date: Mon, 30 Jul 2012 01:23:45 -0000 833 Downgraded-Message-Id: =?UTF-8?Q?MESSAGE_ID?= 834 Mime-Version: 1.0 835 Content-Type: text/plain; charset="UTF-8" 836 Content-Transfer-Encoding: 8bit 837 X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?= 839 MAIL_BODY 841 Figure 2: Downgraded message 843 Appendix B. Change History 845 [[RFC Editor: Please remove this section prior to publication.]] 847 This section is used for tracking the update of this document. Will 848 be removed after finalize. 850 B.1. Version 00 852 o Initial version 854 o Imported header field downgrading from RFC 5504 856 B.2. Version 01 858 o same as Version 00 860 B.3. Version 02 862 o Added updating RFC 5322 to allow syntax in From: and 863 Sender 865 o Added GROUP Downgrading 867 B.4. Version 03 869 o Replaced with 871 o Added updating RFC 5322 to allow syntax in From: and 872 Sender 874 o Added one sentence in Security considerations 876 o Updated IANA considerations 878 B.5. Version 04 880 o Removed "Internationalized Address removed" from GROUP and MAILBOX 881 downgrading 883 o Updated "Updating RFC 5322" 885 o Compacted new header field definition 887 o Compacted security considerations 889 o Updated IANA considerations to remove obsoleting header fields 890 that are registered by RFC 5504 892 o Added a discussion of alternate downgrading models for the POP and 893 IMAP cases. 895 o Incorporated a large number of editorial changes to improve 896 clarity. 898 B.6. Version 05 900 o Some text corrections 902 o Terminology change: only to use non-ASCII address, non-ASCII 903 message, non-ASCII string and imported them from RFC 6530 and RFC 904 6532 906 o Replace "non-ASCII character" with "non-ASCII string" 908 o Removed 5.1.1. RECEIVED Downgrading 910 B.7. Version 06 912 o Removed "Updating RFC 5322" 913 o Added reference to draft-leiba-5322upd-from-group 915 B.8. Version 07 917 o Updated by WGLC comments 919 o Fixed Received downgrading and added to refer "RFC 6531", "RFC 920 5890", "RFC 5891" 922 o Added Domain downgrading for Received, Group and Mailbox 924 o Swapped section 3 and 4 926 B.9. Version 08 928 o Updated by IETF Last call and IESG comments 930 o Removed "Address Header Fields with Typed Addresses" and added 931 "Delivery Status Notification downgrading" in MIME downgrading 933 o Added a space between display-name and ENCODED_WORD. 935 o Moved "ENCAPSULATION: A Last Resort" from section 4 to section 936 3.1.10. 938 o Updated address header fields downgrading 940 o Updated introduction, security considerations and iana 941 considerations 943 Author's Address 945 Kazunori Fujiwara 946 Japan Registry Services Co., Ltd. 947 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 948 Chiyoda-ku, Tokyo 101-0065 949 Japan 951 Phone: +81 3 5215 8451 952 EMail: fujiwara@jprs.co.jp