idnits 2.17.1 draft-ietf-eai-popimap-downgrade-07.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 (July 31, 2012) is 4284 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-03 -- 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 (~~), 2 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 July 31, 2012 5 Intended status: Standards Track 6 Expires: February 1, 2013 8 Post-delivery Message Downgrading for Internationalized Email Messages 9 draft-ietf-eai-popimap-downgrade-07.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 February 1, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Email Header Fields Downgrading . . . . . . . . . . . . . . . 6 66 3.1. Downgrading Method for Each ABNF Element . . . . . . . . . 6 67 3.1.1. Downgrading . . . . . . . . . . . . . . 6 68 3.1.2. Downgrading . . . . . . . . . . . . . . . . . . 6 69 3.1.3. Downgrading . . . . . . . . . . . . . . . . 6 70 3.1.4. Downgrading . . . . . . . . . . . . . . . 6 71 3.1.5. Downgrading . . . . . . . . . . . . . . 7 72 3.1.6. Downgrading . . . . . . . . . . . . . . . . . 7 73 3.1.7. Downgrading . . . . . . . . . . . . . . . . . 7 74 3.1.8. Downgrading . . . . . . . . . . . . . . . . 7 75 3.1.9. Downgrading . . . . . . . . . . . . . 8 76 3.2. Downgrading Method for Each Header Field . . . . . . . . . 8 77 3.2.1. Address Header Fields That Contain
s . . . . 8 78 3.2.2. Address Header Fields with Typed Addresses . . . . . . 9 79 3.2.3. Downgrading Non-ASCII in Comments . . . . . . . . . . 9 80 3.2.4. Message-ID Header Fields . . . . . . . . . . . . . . . 10 81 3.2.5. Received Header Field . . . . . . . . . . . . . . . . 10 82 3.2.6. MIME Content Header Fields . . . . . . . . . . . . . . 10 83 3.2.7. Non-ASCII in . . . . . . . . . . . . . 10 84 3.2.8. Non-ASCII in . . . . . . . . . . . . . . . . 10 85 3.2.9. List- Header Fields and Other Header Fields . . . . . 11 86 4. ENCAPSULATION: A Last Resort . . . . . . . . . . . . . . . . . 11 87 5. MIME Body-Part Header Field Downgrading . . . . . . . . . . . 12 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 89 7. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 13 90 7.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 13 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 96 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17 97 A.1. Downgrading Example . . . . . . . . . . . . . . . . . . . 17 98 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 19 99 B.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 19 100 B.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 19 101 B.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 19 102 B.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 19 103 B.5. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 19 104 B.6. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 20 105 B.7. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 20 106 B.8. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 20 108 1. Introduction 110 1.1. Problem statement 112 Traditional (legacy) mail systems, which are defined by [RFC5322] and 113 other specifications, allow only ASCII characters in mail header 114 field values. The SMTPUTF8 extension ([RFC6530], [RFC6531] and 115 [RFC6532]) allow raw UTF-8 in those mail header fields. 117 If a header field contains non-ASCII strings, POP/IMAP servers cannot 118 deliver Internationalized Email Headers to legacy clients and, 119 because they have no obvious or standardized way to explain what is 120 going on to those clients, cannot even safely discard the message. 122 1.2. Possible solutions 124 There are four plausible approaches to the problem, with the 125 preferred one depending on the particular circumstances and 126 relationship among the delivery SMTP server, the mail store, the POP 127 or IMAP server, and the users and their MUA clients: 129 1. If the delivery MTA has sufficient knowledge about the POP and/or 130 IMAP servers and clients being used, the message may be rejected 131 as undeliverable. 133 2. The message may be downgraded by the POP or IMAP server, in a way 134 that preserves maximum information at the expense of some 135 complexity. 137 3. Some intermediate downgrading may be applied that balances more 138 information loss against lower complexity and greater ease of 139 implementation. 141 4. The POP or IMAP server may fabricate a message whose intent is to 142 notify the client that an internationalized message is waiting 143 but cannot be delivered until an upgraded client is available. 145 1.3. Approach taken in this specification 147 This specification describes the second of those options. It is 148 worth noticing that, at least in the general case, none of these 149 options preserve sufficient information to guarantee that it is 150 possible to reply to an incoming message without loss of information, 151 so the choice may be considered to be among "least bad" options. 153 This message downgrading mechanism converts mail header fields to an 154 all-ASCII representation. The POP/IMAP servers can use the 155 downgrading mechanism and deliver the Internationalized Email message 156 as a traditional form. Receivers can know they received some 157 internationalized messages or some unknown/broken messages. 159 [RFC6532] allows UTF-8 characters to be used in mail header fields 160 and MIME header fields. [RFC6531] allows UTF-8 characters to be used 161 in some trace header fields. The message downgrading mechanism 162 specified here describes the conversion method from the 163 internationalized messages that are defined in [RFC6530], and 164 [RFC6532] to the traditional email messages defined in [RFC5322]. 166 This document provides a precise definition of the minimum- 167 information-loss message downgrading process. 169 Downgrading consists of the following three parts: 171 o New header field definitions 173 o Email header field downgrading 175 o MIME header field downgrading 177 Email header field downgrading is described in Section 3. It 178 generates ASCII-only header fields. 180 In Section 4 of this document, header fields starting with 181 "Downgraded-" are introduced. They preserve the information that 182 appeared in the original header fields. 184 The definition of MIME header fields in Internationalized Email 185 Messages is described in [RFC6532]. MIME header field downgrading is 186 described in Section 5. It generates ASCII-only MIME header fields. 188 Displaying downgraded messages that originally contained 189 internationalized header fields is out of scope of this document. A 190 POP/IMAP client which does not support UTF8 extensions as defined for 191 POP3 [UTF8 command] and IMAP ["ENABLE UTF8=ACCEPT" command] does not 192 know internationalized message format described in [RFC6532]. 194 2. Terminology 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in RFC 2119 [RFC2119]. 200 All specialized terms used in this specification are defined in the 201 Overview and Framework for Internationalized Email [RFC6530], in the 202 mail message specifications [RFC5322], or in the MIME documents 204 [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "U-label", 205 "A-label" and "IDNA" are used with the definitions from [RFC5890]. 206 The terms "ASCII address", "non-ASCII address", "SMTPUTF8", 207 "message", "internationalized message" are used with the definitions 208 from [RFC6530]. The term "non-ASCII string" is used with the 209 definitions from [RFC6532]. 211 3. Email Header Fields Downgrading 213 This section defines the conversion method to ASCII for each header 214 field that may contain non-ASCII strings. Section 3.1 describes 215 rewriting methods for each ABNF element. Section 3.2 describes 216 rewriting methods for each header field. 218 3.1. Downgrading Method for Each ABNF Element 220 Header field downgrading is defined below for each ABNF element. 221 Converting the header field terminates when no non-ASCII strings 222 remain in the header field. 224 [RFC5322] describes ABNF elements , , , 225 , , . [RFC2045] describes ABNF element 226 . is updated to allow non-ASCII characters in Section 227 3.3 of [RFC6531] and Section 3.2 of [RFC6532]. 229 3.1.1. Downgrading 231 If the header field has an field that contains non- 232 ASCII strings, apply [RFC2047] encoding with charset UTF-8. 234 3.1.2. Downgrading 236 If the header field has any fields that contain non-ASCII 237 strings, apply [RFC2047] encoding with charset UTF-8. 239 3.1.3. Downgrading 241 If the header field has any fields that contain non-ASCII 242 strings, apply [RFC2047] encoding with charset UTF-8. 244 3.1.4. Downgrading 246 If the header field has any elements defined by [RFC2045] and 247 the elements contain non-ASCII strings, encode the elements 248 according to [RFC2231] with charset UTF-8 and leave the language 249 information empty. If the element is and it 250 contains outside the DQUOTE, remove the before this 251 conversion. 253 3.1.5. Downgrading 255 If the header field has any
( or ) elements 256 and they have elements that contain non-ASCII strings, 257 encode the elements according to [RFC2047] with 258 charset UTF-8. DISPLAY-NAME downgrading is the same algorithm as 259 WORD downgrading. 261 3.1.6. Downgrading 263 If the header field has any elements that contain U-labels, 264 rewrite the non-ASCII domain name into ASCII domain name using 265 A-labels as specified in IDNA [RFC5891]. 267 3.1.7. Downgrading 269 is defined in Section 3.4 of [RFC5322]. The elements 270 may contain es which contain non-ASCII addresses. 272 If the header field has any elements that contain 273 elements and one of es contains a non-ASCII , 274 rewrite each element as 276 display-name ENCODED_WORD " :;" 278 where the is the original encoded 279 according to [RFC2047]. 281 Otherwise, the header field does not contain non-ASCII . 282 If the header field contain non-ASCII es, they contain non- 283 ASCII domain names. Rewrite the non-ASCII domain names into ASCII 284 domain names using A-labels as specified in IDNA [RFC5891]. 285 Generated es contain ASCII addresses only. 287 3.1.8. Downgrading 289 If the of the element does not contain non- 290 ASCII characters, the element contains non-ASCII characters. 291 Rewrite the non-ASCII domain name into ASCII domain name using 292 A-labels as specified in IDNA [RFC5891]. 294 Otherwise, the contains non-ASCII characters. The non- 295 ASCII has no equivalent format for ASCII addresses. 296 Rewrite each element to ASCII-only group format following 297 the model above. The element that contains non-ASCII 298 strings may appear in two forms as: 300 "<" addr-spec ">" 301 addr-spec 303 Rewrite both as: 305 ENCODED-WORD " :;" 307 where the is the original encoded 308 according to [RFC2047]. 310 3.1.9. Downgrading 312 If the header field contains and the contains raw non-ASCII strings, it is in utf-8-address form. 314 Convert it to utf-8-addr-xtext form. Those forms are described in 315 [RFC6533]. COMMENT downgrading is also performed in this case. If 316 the address type is unrecognized and the header field contains non- 317 ASCII strings, then fall back to using ENCAPSULATION on the entire 318 header field specified in Section 4. 320 3.2. Downgrading Method for Each Header Field 322 [RFC4021] establishes a registry of header fields. This section 323 describes the downgrading method for each header field. 325 If the whole mail header field does not contain non-ASCII strings, 326 email header field downgrading is not required. Each header field's 327 downgrading method is described below. 329 3.2.1. Address Header Fields That Contain
s 331 From: 332 Sender: 333 To: 334 Cc: 335 Bcc: 336 Reply-To: 337 Resent-From: 338 Resent-Sender: 339 Resent-To: 341 Resent-Cc: 342 Resent-Bcc: 343 Resent-Reply-To: 344 Return-Path: 345 Disposition-Notification-To: 347 If the header field contains elements that contain non-ASCII 348 addresses, perform downgrading, downgrading, 349 and downgrading as described in the corresponding subsections 350 of Section 3.1. Optionally add those words where appropriate to the 351 next paragraph, but I think once will make it clear. 353 If the header field contains elements that contain non- 354 ASCII addresses, perform downgrading, 355 downgrading, and downgrading. 357 This procedure may generate empty elements in "From:", 358 "Sender:" and "Reply-To:" header fields. 359 [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty) 360 elements in "From:", "Sender:" and "Reply-To:" header fields. 362 3.2.2. Address Header Fields with Typed Addresses 364 Original-Recipient: 365 Final-Recipient: 367 If the header field contains non-ASCII strings, perform downgrading. 370 3.2.3. Downgrading Non-ASCII in Comments 372 Date: 373 Resent-Date: 374 MIME-Version: 375 Content-ID: 376 Content-Transfer-Encoding: 377 Content-Language: 378 Accept-Language: 379 Auto-Submitted: 381 These header fields do not contain non-ASCII strings except in 382 comments. If the header field contains UTF-8 characters in comments, 383 perform downgrading. 385 3.2.4. Message-ID Header Fields 387 Message-ID: 388 Resent-Message-ID: 389 In-Reply-To: 390 References: 392 Perform ENCAPSULATION as specified in Section 4. 394 3.2.5. Received Header Field 396 Received: 398 If elements or elements contains U-labels, perform 399 downgrading specified in Section 3.1.6. Comments may 400 contain non-ASCII strings, perform downgrading. 402 After the downgrading and the downgrading, if the 403 FOR clause contains a non-ASCII , remove the "FOR" 404 clause. If the ID clause contains a non-ASCII values, remove the 405 "ID" clause. 407 3.2.6. MIME Content Header Fields 409 Content-Type: 410 Content-Disposition: 412 Perform downgrading and downgrading. 414 3.2.7. Non-ASCII in 416 Subject: 417 Comments: 418 Content-Description: 420 Perform downgrading. 422 3.2.8. Non-ASCII in 424 Keywords: 426 Perform downgrading. 428 3.2.9. List- Header Fields and Other Header Fields 430 There are other header fields that contain non-ASCII strings. They 431 are user-defined and missing from this document, or future defined 432 header fields. They are treated as "Optional Fields" and their field 433 values are treated as unstructured described in Section 3.6.8 of 434 [RFC5322]. 436 Perform downgrading. 438 If the software understands the header field's structure and a 439 downgrading algorithm other than UNSTRUCTURED is applicable, that 440 software SHOULD use that algorithm; UNSTRUCTURED downgrading is used 441 as a last resort. 443 Mailing list header fields (those that start in "List-") are part of 444 this category. 446 4. ENCAPSULATION: A Last Resort 448 As a last resort when header fields cannot be converted as discussed 449 in the previous section, the fields are deleted and replaced by 450 specialized new header fields. Those fields are defined to preserve, 451 in encoded form, as much information as possible from the header 452 field values of the incoming message. The syntax of these new header 453 fields is: 455 fields =/ downgraded 457 downgraded = "Downgraded-Message-Id:" unstructured CRLF / 458 "Downgraded-Resent-Message-Id:" unstructured CRLF / 459 "Downgraded-In-Reply-To:" unstructured CRLF / 460 "Downgraded-References:" unstructured CRLF / 461 "Downgraded-Original-Recipient:" unstructured CRLF / 462 "Downgraded-Final-Recipient:" unstructured CRLF 464 Applying this procedure to "Received:" header field is prohibited. 465 ENCAPSULATION Downgrading is allowed for "Message-ID", 466 "In-Reply-To:", "References:", "Original-Recipient" and "Final- 467 Recipient" header fields. 469 To preserve a header field in a "Downgraded-" header field: 471 1. Generate a new header field. 473 * The field name is a concatenation of "Downgraded-" and the 474 original field name. 476 * The initial new field value is the original header field 477 value. 479 2. Treat the initial new header field value as if it were 480 unstructured, and then apply [RFC2047] encoding with charset 481 UTF-8 as necessary so that the resulting new header field value 482 is completely in ASCII. 484 3. Remove the original header field. 486 5. MIME Body-Part Header Field Downgrading 488 MIME body-part header fields may contain non-ASCII strings [RFC6532]. 489 This section defines the conversion method to ASCII-only header 490 fields for each MIME header field that contains non-ASCII strings. 491 Parse the message body's MIME structure at all levels and check each 492 MIME header field to see whether it contains non-ASCII strings. If 493 the header field contains non-ASCII strings in the header field 494 value, the header field is a target of the MIME body-part header 495 field's downgrading. Each MIME header field's downgrading method is 496 described below. COMMENT downgrading, MIME-VALUE downgrading, and 497 UNSTRUCTURED downgrading are described in Section 3. 499 Content-ID: 500 The "Content-ID:" header field does not contain non-ASCII strings 501 except in comments. If the header field contains UTF-8 characters 502 in comments, perform downgrading. 504 Content-Type: 506 Content-Disposition: 507 Perform downgrading and downgrading. 509 Content-Description: Perform downgrading. 511 6. Security Considerations 513 The purpose of post-delivery message downgrading is to allow POP/IMAP 514 servers to deliver internationalized messages to traditional POP/IMAP 515 clients and permit the clients to display those messages. Users who 516 receive such messages can know that they were internationalized. It 517 does not permit receivers to read the messages in their original form 518 and, in general, will not permit generating replies, at least without 519 significant user intervention. 521 A downgraded message's header fields contain ASCII characters only. 522 But they still contain MIME-encapsulated header fields that contain 523 non-ASCII strings. Furthermore, the body part may contain UTF-8 524 characters. Implementations parsing Internet messages need to accept 525 UTF-8 body parts and UTF-8 header fields that are MIME-encoded. 526 Thus, this document inherits the security considerations of MIME- 527 encoded header fields ([RFC2047] and [RFC3629]). 529 Rewriting header fields increases the opportunities for undetected 530 spoofing by malicious senders. However, the rewritten header field 531 values are preserved in equivalent MIME form or in newly defined 532 header fields for which traditional MUAs have no special processing 533 procedures. 535 The techniques described here invalidate methods that depend on 536 digital signatures over any part of the message, which includes the 537 top-level header fields and body-part header fields. Depending on 538 the specific message being downgraded, at least the following 539 techniques are likely to break: DomainKeys Identified Mail (DKIM), 540 and possibly S/MIME and Pretty Good Privacy (PGP). Receivers may 541 know they need to update their MUAs, or they don't care. 543 While information in any email header field should usually be treated 544 with some suspicion, current email systems commonly employ various 545 mechanisms and protocols to make the information more trustworthy. 546 Information in the new Downgraded-* header fields is not inspected by 547 traditional MUAs, and may be even less trustworthy than the 548 traditional header fields. Note that the Downgraded-* header fields 549 could have been inserted with malicious intent (and with content 550 unrelated to the traditional header fields), however traditional MUAs 551 do not parse Downgraded-* header fields. 553 In addition, if an Authentication-Results header field [RFC5451] is 554 present, traditional MUAs may treat that the digital signatures are 555 valid. 557 See the "Security Considerations" section in 558 [I-D.leiba-5322upd-from-group] and [RFC6530] for more discussion. 560 7. Implementation Notes 562 7.1. RFC 2047 Encoding 564 While [RFC2047] has a specific algorithm to deal with whitespace in 565 adjacent encoded words, there are a number of deployed 566 implementations that fail to implement the algorithm correctly. As a 567 result, whitespace behavior is somewhat unpredictable in practice 568 when multiple encoded words are used. While RFC 5322 states that 569 implementations SHOULD limit lines to not more than 78 characters, 570 implementations MAY choose to allow overly long encoded words in 571 order to work around faulty [RFC2047] implementations. 572 Implementations that choose to do so SHOULD have an optional 573 mechanism to limit line length to 78 characters. 575 8. IANA Considerations 577 [[RFC Editor: Please change "should now be" and "should be" to "have 578 been" when the IANA actions are complete.]] 580 [RFC5504] registered many "Downgraded-" header fields and requested 581 that 'IANA will refuse registration of all field names that start 582 with "Downgraded-", to avoid possible conflict with the procedure for 583 unknown header fields' preservation described in Section 3.3 of 584 [RFC5504].' However [RFC6530] obsoleted [RFC5504] and this document 585 does not use all "Downgraded-" header fields registered by [RFC5504]. 587 The following header fields should be registered in the Permanent 588 Message Header Field registry, in accordance with the procedures set 589 out in [RFC3864]. 591 Header field name: Downgraded-Message-Id 592 Applicable protocol: mail 593 Status: standard 594 Author/change controller: IETF 595 Specification document(s): This document (Section 4) 597 Header field name: Downgraded-In-Reply-To 598 Applicable protocol: mail 599 Status: standard 600 Author/change controller: IETF 601 Specification document(s): This document (Section 4) 603 Header field name: Downgraded-References 604 Applicable protocol: mail 605 Status: standard 606 Author/change controller: IETF 607 Specification document(s): This document (Section 4) 609 Header field name: Downgraded-Original-Recipient 610 Applicable protocol: mail 611 Status: standard 612 Author/change controller: IETF 613 Specification document(s): This document (Section 4) 615 Header field name: Downgraded-Final-Recipient 616 Applicable protocol: mail 617 Status: standard 618 Author/change controller: IETF 619 Specification document(s): This document (Section 4) 621 9. Acknowledgements 623 This document draws heavily from the experimental in-transit message 624 downgrading procedure described in RFC 5504 [RFC5504]. The 625 contribution of the co-author of that earlier document, Y. Yoneya, 626 are gratefully acknowledged. Significant comments and suggestions 627 were received from John Klensin, Barry Leiba, Randall Gellens, Pete 628 Resnick, Martin J. Durst, and other WG participants. 630 10. References 632 10.1. Normative References 634 [RFC2045] Freed, N. and N. Borenstein, 635 "Multipurpose Internet Mail 636 Extensions (MIME) Part One: Format of 637 Internet Message Bodies", RFC 2045, 638 November 1996. 640 [RFC2047] Moore, K., "MIME (Multipurpose 641 Internet Mail Extensions) Part Three: 642 Message Header Extensions for Non- 643 ASCII Text", RFC 2047, November 1996. 645 [RFC2119] Bradner, S., "Key words for use in 646 RFCs to Indicate Requirement Levels", 647 BCP 14, RFC 2119, March 1997. 649 [RFC2183] Troost, R., Dorner, S., and K. Moore, 650 "Communicating Presentation 651 Information in Internet Messages: The 652 Content-Disposition Header Field", 653 RFC 2183, August 1997. 655 [RFC2231] Freed, N. and K. Moore, "MIME 656 Parameter Value and Encoded Word 657 Extensions: Character Sets, Languages 658 , and Continuations", RFC 2231, 659 November 1997. 661 [RFC3629] Yergeau, F., "UTF-8, a transformation 662 format of ISO 10646", STD 63, 663 RFC 3629, November 2003. 665 [RFC3864] Klyne, G., Nottingham, M., and J. 666 Mogul, "Registration Procedures for 667 Message Header Fields", BCP 90, 668 RFC 3864, September 2004. 670 [RFC4021] Klyne, G. and J. Palme, "Registration 671 of Mail and MIME Header Fields", 672 RFC 4021, March 2005. 674 [RFC5322] Resnick, P., Ed., "Internet Message 675 Format", RFC 5322, October 2008. 677 [RFC5890] Klensin, J., "Internationalized 678 Domain Names for Applications (IDNA): 679 Definitions and Document Framework", 680 RFC 5890, August 2010. 682 [RFC5891] Klensin, J., "Internationalized 683 Domain Names in Applications (IDNA): 684 Protocol", RFC 5891, August 2010. 686 [RFC6530] Klensin, J. and Y. Ko, "Overview and 687 Framework for Internationalized 688 Email", RFC 6530, February 2012. 690 [RFC6531] Yao, J. and W. Mao, "SMTP Extension 691 for Internationalized Email", 692 RFC 6531, February 2012. 694 [RFC6532] Yang, A., Steele, S., and N. Freed, 695 "Internationalized Email Headers", 696 RFC 6532, February 2012. 698 [RFC6533] Hansen, T., Newman, C., and A. 699 Melnikov, "Internationalized Delivery 700 Status and Disposition 701 Notifications", RFC 6533, 702 February 2012. 704 [I-D.leiba-5322upd-from-group] Leiba, B., "Update to Internet 705 Message Format to Allow Group Syntax 706 in the 'From:' Header Field", 707 draft-leiba-5322upd-from-group-03 708 (work in progress), July 2012. 710 10.2. Informative References 712 [RFC5451] Kucherawy, M., "Message Header Field 713 for Indicating Message Authentication 714 Status", RFC 5451, April 2009. 716 [RFC5504] Fujiwara, K. and Y. Yoneya, 717 "Downgrading Mechanism for Email 718 Address Internationalization", 719 RFC 5504, March 2009. 721 Appendix A. Examples 723 A.1. Downgrading Example 725 This appendix shows an message downgrading example. Consider a 726 received mail message where: 728 o The sender address is a non-ASCII address, 729 "NON-ASCII-LOCAL@example.com". Its display-name is "DISPLAY- 730 LOCAL". 732 o The "To:" header field contains two non-ASCII addresses, 733 "NON-ASCII-REMOTE1@example.net" and 734 "NON-ASCII-REMOTE2@example.com" Its display-names are "DISPLAY- 735 REMOTE1" and "DISPLAY-REMOTE2". 737 o The "Cc:" header field contains a non-ASCII address, 738 "NON-ASCII-REMOTE3@example.org". Its display-name is "DISPLAY- 739 REMOTE3". 741 o Four display names contain non-ASCII characters. 743 o The Subject header field is "NON-ASCII-SUBJECT", which contains 744 non-ASCII strings. 746 o The "Message-Id:" header field contains "NON-ASCII-MESSAGE_ID", 747 which contains non-ASCII strings. 749 o There is an unknown header field "X-Unknown-Header" which contains 750 non-ASCII strings. 752 Return-Path: 753 Received: from ... by ... for 754 Received: from ... by ... for 755 From: DISPLAY-LOCAL 756 To: DISPLAY-REMOTE1 , 757 DISPLAY-REMOTE2 758 Cc: DISPLAY-REMOTE3 759 Subject: NON-ASCII-SUBJECT 760 Date: Mon, 30 Jul 2012 01:23:45 -0000 761 Message-Id: NON-ASCII-MESSAGE_ID 762 Mime-Version: 1.0 763 Content-Type: text/plain; charset="UTF-8" 764 Content-Transfer-Encoding: 8bit 765 X-Unknown-Header: NON-ASCII-CHARACTERS 767 MAIL_BODY 769 Figure 1: Received message in a mail drop 771 The downgraded message is shown in Figure 2. "Return-Path:", 772 "From:", "To:" and "Cc:" header fields are rewritten. "Subject:" and 773 "X-Unknown-Header:" header fields are encoded using [RFC2047]. 774 "Message-Id:" header field is encapsulated as 775 "Downgraded-Message-Id:" header field. 777 Return-Path: =?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :; 778 Received: from ... by ... 779 Received: from ... by ... 780 From: =?UTF-8?Q?DISPLAY-LOCAL?= 781 =?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :; 782 To: =?UTF-8?Q?DISPLAY-REMOTE1?= 783 =?UTF-8?Q?NON-ASCII-REMOTE1@example.net?= :;, 784 =?UTF-8?Q?DISPLAY-REMOTE2?= 785 =?UTF-8?Q?NON-ASCII-REMOTE2@example.com?= :;, 786 Cc: =?UTF-8?Q?DISPLAY-REMOTE3?= 787 =?UTF-8?Q?NON-ASCII-REMOTE3@example.org?= :; 788 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 789 Date: Mon, 30 Jul 2012 01:23:45 -0000 790 Downgraded-Message-Id: =?UTF-8?Q?MESSAGE_ID?= 791 Mime-Version: 1.0 792 Content-Type: text/plain; charset="UTF-8" 793 Content-Transfer-Encoding: 8bit 794 X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?= 796 MAIL_BODY 797 Figure 2: Downgraded message 799 Appendix B. Change History 801 [[RFC Editor: Please remove this section prior to publication.]] 803 This section is used for tracking the update of this document. Will 804 be removed after finalize. 806 B.1. Version 00 808 o Initial version 810 o Imported header field downgrading from RFC 5504 812 B.2. Version 01 814 o same as Version 00 816 B.3. Version 02 818 o Added updating RFC 5322 to allow syntax in From: and 819 Sender 821 o Added GROUP Downgrading 823 B.4. Version 03 825 o Replaced with 827 o Added updating RFC 5322 to allow syntax in From: and 828 Sender 830 o Added one sentence in Security considerations 832 o Updated IANA considerations 834 B.5. Version 04 836 o Removed "Internationalized Address removed" from GROUP and MAILBOX 837 downgrading 839 o Updated "Updating RFC 5322" 841 o Compacted new header field definition 843 o Compacted security considerations 844 o Updated IANA considerations to remove obsoleting header fields 845 that are registered by RFC 5504 847 o Added a discussion of alternate downgrading models for the POP and 848 IMAP cases. 850 o Incorporated a large number of editorial changes to improve 851 clarity. 853 B.6. Version 05 855 o Some text corrections 857 o Terminology change: only to use non-ASCII address, non-ASCII 858 message, non-ASCII string and imported them from RFC 6530 and RFC 859 6532 861 o Replace "non-ASCII character" with "non-ASCII string" 863 o Removed 5.1.1. RECEIVED Downgrading 865 B.7. Version 06 867 o Removed "Updating RFC 5322" 869 o Added reference to draft-leiba-5322upd-from-group 871 B.8. Version 07 873 o Updated by WGLC comments 875 o Fixed Received downgrading and added to refer "RFC 6531", "RFC 876 5890", "RFC 5891" 878 o Added Domain downgrading for Received, Group and Mailbox 880 o Swapped section 3 and 4 882 Author's Address 884 Kazunori Fujiwara 885 Japan Registry Services Co., Ltd. 886 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 887 Chiyoda-ku, Tokyo 101-0065 888 Japan 890 Phone: +81 3 5215 8451 891 EMail: fujiwara@wide.ad.jp, fujiwara@jprs.co.jp