idnits 2.17.1 draft-ietf-eai-popimap-downgrade-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Oct 15, 2010) is 4914 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) == Unused Reference: 'RFC2979' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'RFC3864' is defined on line 565, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-eai-frmwrk-4952bis-10 == Outdated reference: A later version (-13) exists of draft-ietf-eai-rfc5335bis-02 ** Downref: Normative reference to an Informational RFC: RFC 2979 ** Obsolete normative reference: RFC 5337 (Obsoleted by RFC 6533) -- Obsolete informational reference (is this intentional?): RFC 5504 (Obsoleted by RFC 6530) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 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 15, 2010 5 Intended status: Standards Track 6 Expires: April 18, 2011 8 Post-delivery Message Downgrading for Internationalized Email Messages 9 draft-ietf-eai-popimap-downgrade-00.txt 11 Abstract 13 The Email Address Internationalization (UTF8SMTP) extension allows 14 UTF-8 characters in mail header fields. POP and IMAP servers support 15 internationalized email messages. If a POP/IMAP client does not 16 support Email Address Internationalization, POP/IMAP servers cannot 17 send Internationalized Email Headers to the client and cannot remove 18 the message. To avoid the situation, this document describes a 19 conversion mechanism for internationalized Email messages to be 20 traditional message format. 22 Status of This Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on April 18, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. New Header Fields Definition . . . . . . . . . . . . . . . . . 4 65 3.1. Unknown Header Fields' Preservation Header Fields . . . . 5 66 4. Email Header Fields Downgrading . . . . . . . . . . . . . . . 5 67 4.1. Downgrading Method for Each ABNF Element . . . . . . . . . 5 68 4.1.1. RECEIVED Downgrading . . . . . . . . . . . . . . . . . 6 69 4.1.2. UNSTRUCTURED Downgrading . . . . . . . . . . . . . . . 6 70 4.1.3. WORD Downgrading . . . . . . . . . . . . . . . . . . . 6 71 4.1.4. COMMENT Downgrading . . . . . . . . . . . . . . . . . 6 72 4.1.5. MIME-VALUE Downgrading . . . . . . . . . . . . . . . . 6 73 4.1.6. DISPLAY-NAME Downgrading . . . . . . . . . . . . . . . 6 74 4.1.7. MAILBOX Downgrading . . . . . . . . . . . . . . . . . 6 75 4.1.8. ENCAPSULATION Downgrading . . . . . . . . . . . . . . 7 76 4.1.9. TYPED-ADDRESS Downgrading . . . . . . . . . . . . . . 7 77 4.2. Downgrading Method for Each Header Field . . . . . . . . . 7 78 4.2.1. Address Header Fields That Contain
s . . . . 7 79 4.2.2. Address Header Fields with Typed Addresses . . . . . . 8 80 4.2.3. Downgrading Non-ASCII in Comments . . . . . . . . . . 8 81 4.2.4. Received Header Field . . . . . . . . . . . . . . . . 9 82 4.2.5. MIME Content Header Fields . . . . . . . . . . . . . . 9 83 4.2.6. Non-ASCII in . . . . . . . . . . . . . 9 84 4.2.7. Non-ASCII in . . . . . . . . . . . . . . . . 9 85 4.2.8. Other Header Fields . . . . . . . . . . . . . . . . . 9 86 5. MIME Body-Part Header Field Downgrading . . . . . . . . . . . 10 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 7. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 11 89 7.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 11 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 95 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 96 A.1. Downgrading Example . . . . . . . . . . . . . . . . . . . 13 98 1. Introduction 100 Traditional mail systems, which are defined by [RFC5322], allow ASCII 101 characters in mail header field values. The UTF8SMTP extension 102 ([I-D.ietf-eai-frmwrk-4952bis] and [I-D.ietf-eai-rfc5335bis] allows 103 UTF-8 characters in mail header field values. 105 If a header field contains non-ASCII characters, POP/IMAP servers 106 cannot send Internationalized Email Headers to the client and cannot 107 remove the message. This message downgrading mechanism converts mail 108 header fields to an all-ASCII representation. The POP/IMAP servers 109 can use the downgrading mechanism and send the Internationalized 110 Email message as a traditional form. 112 [I-D.ietf-eai-rfc5335bis] allows UTF-8 characters to be used in mail 113 header fields and MIME header fields. The message downgrading 114 mechanism specified here converts mail header fields and MIME header 115 fields to ASCII. 117 This document does not change any protocols except by defining new 118 header fields. It describes the conversion method from the 119 internationalized email messages that are defined in 120 [I-D.ietf-eai-frmwrk-4952bis], and [I-D.ietf-eai-rfc5335bis] to the 121 traditional email messages defined in [RFC5322]. 123 Message Downgrading may be implemented in POP server and IMAP server 124 only. 126 This document tries to define the message downgrading process 127 clearly. 129 Downgrading consists of the following three parts: 131 o New header field definitions 133 o Email header field downgrading 135 o MIME header field downgrading 137 In Section 3 of this document, header fields starting with 138 "Downgraded-" are introduced. They preserve the original header 139 fields. 141 Email header field downgrading is described in Section 4. It 142 generates ASCII-only header fields. 144 MIME header fields are expanded in [I-D.ietf-eai-rfc5335bis]. MIME 145 header field downgrading is described in Section 5. It generates 146 ASCII-only MIME header fields. 148 Displaying downgraded messages that originally contained 149 internationalized header fields is out of scope of this document. A 150 POP/IMAP client which does not support UTF8 extension does not know 151 internationalized message format described in 152 [I-D.ietf-eai-rfc5335bis]. 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 All specialized terms used in this specification are defined in the 161 Email Address Internationalization (EAI) overview 162 [I-D.ietf-eai-frmwrk-4952bis], in the mail message specifications 163 [RFC5322], or in the MIME documents [RFC2045] [RFC2047] [RFC2183] 164 [RFC2231]. The terms "ASCII address", "internationalized email 165 address", "non-ASCII address", "i18mail address", "UTF8SMTP", 166 "message", and "mailing list" are used with the definitions from 167 [I-D.ietf-eai-frmwrk-4952bis]. 169 This document depends on [I-D.ietf-eai-rfc5335bis]. Key words used 170 in those documents are used in this document, too. 172 The term "non-ASCII" refers to a UTF-8 string that contains at least 173 one non-ASCII character. 175 A "UTF8SMTP message" is an email message expanded by 176 [I-D.ietf-eai-rfc5335bis]. 178 3. New Header Fields Definition 180 New header fields starting with "Downgraded-" are defined here to 181 preserve those mail header field values that contain UTF-8 182 characters. During downgrading, one new "Downgraded-" header field 183 is added for each mail header field that cannot be passed as-is to a 184 POP/IMAP client that does not support UTF8 extension. The original 185 mail header field is removed or rewritten. Only those mail header 186 fields that contain non-ASCII characters are affected. The result of 187 this process is a message that is compliant with existing email 188 specifications [RFC5322]. The original internationalized information 189 can be retrieved by examining the "Downgraded-" header fields that 190 were added. 192 3.1. Unknown Header Fields' Preservation Header Fields 194 The unknown header fields' preservation header fields are defined to 195 encapsulate those original header fields that contain non-ASCII 196 characters and are not otherwise provided for in this specification. 197 The encapsulation header field name is the concatenation of 198 "Downgraded-" and the original name. The value field holds the 199 original header field value. 201 The header field syntax is specified as follows: 203 fields =/ unknown-downgraded-headers ":" unstructured CRLF 205 unknown-downgraded-headers = "Downgraded-" original-header-field-name 207 original-header-field-name = field-name 209 field-name = 1*ftext 211 ftext = %d33-57 / ; Any character except 212 %d59-126 ; controls, SP, and ":". 214 To encapsulate a header field in a "Downgraded-" header field: 216 1. Generate a new "Downgraded-" header field whose value is the 217 original header field value. 219 2. Treat the generated header field content as if it were 220 unstructured, and then apply [RFC2047] encoding with charset 221 UTF-8 as necessary so the result is ASCII. 223 3. Remove the original header field. 225 4. Email Header Fields Downgrading 227 This section defines the conversion method to ASCII for each header 228 field that may contain non-ASCII characters. 230 [I-D.ietf-eai-rfc5335bis] expands "Received:" header fields; 231 [RFC5322] describes ABNF elements , , , 232 ; [RFC2045] describes ABNF element . 234 4.1. Downgrading Method for Each ABNF Element 236 Header field downgrading is defined below for each ABNF element. 237 Downgrading an unknown header field is also defined as ENCAPSULATION 238 downgrading. Converting the header field terminates when no non- 239 ASCII characters remain in the header field. 241 4.1.1. RECEIVED Downgrading 243 If the header field name is "Received:" and the FOR clause contains a 244 non-ASCII address, remove the FOR clause from the header field. 245 Other parts (not counting s) should not contain non-ASCII 246 values. 248 4.1.2. UNSTRUCTURED Downgrading 250 If the header field has an field that contains non- 251 ASCII characters, apply [RFC2047] encoding with charset UTF-8. 253 4.1.3. WORD Downgrading 255 If the header field has any fields that contain non-ASCII 256 characters, apply [RFC2047] encoding with charset UTF-8. 258 4.1.4. COMMENT Downgrading 260 If the header field has any fields that contain non-ASCII 261 characters, apply [RFC2047] encoding with charset UTF-8. 263 4.1.5. MIME-VALUE Downgrading 265 If the header field has any elements defined by [RFC2045] and 266 the elements contain non-ASCII characters, encode the 267 elements according to [RFC2231] with charset UTF-8 and leave the 268 language information empty. If the element is and it contains outside the DQUOTE, remove the 270 before this conversion. 272 4.1.6. DISPLAY-NAME Downgrading 274 If the header field has any
( or ) elements 275 and they have elements that contain non-ASCII 276 characters, encode the elements according to [RFC2047] 277 with charset UTF-8. DISPLAY-NAME downgrading is the same algorithm 278 as WORD downgrading. 280 4.1.7. MAILBOX Downgrading 282 The elements have no equivalent format for non-ASCII 283 addresses. If the header field has any elements that 284 contain non-ASCII characters, rewrite each element to 285 ASCII-only format. The element that contains non-ASCII 286 characters is one of two formats. 288 [ Display-name ] "<" Utf8-addr-spec ">" 290 Utf8-addr-spec 292 Rewrite both as: 293 [ Display-name ] "Internationalized Address " Encoded-word 294 " Removed:;" 295 where the is the original encoded 296 according to [RFC2047]. 298 [[ Note: If the original non-ASCII address is a part of a group 299 address, this rewriting may conflict the original DISPLAY-NAME. This 300 problem need to be fixed. ]] 302 4.1.8. ENCAPSULATION Downgrading 304 If the header field contains non-ASCII characters and is such that no 305 rule is given above, encapsulate it in a "Downgraded-" header field 306 as described in Section 3.1 as a last resort. 308 Applying this procedure to "Received:" header field is prohibited. 310 4.1.9. TYPED-ADDRESS Downgrading 312 If the header field contains and the contains raw non-ASCII characters, it is in utf-8-address form. 314 Convert it to utf-8-addr-xtext form. Those forms are described in 315 [RFC5337]. COMMENT downgrading is also performed in this case. If 316 the address type is unrecognized and the header field contains non- 317 ASCII characters, then fall back to using ENCAPSULATION downgrading 318 on the entire header field. 320 4.2. Downgrading Method for Each Header Field 322 Header fields are listed in [RFC4021]. This section describes the 323 downgrading method for each header field. 325 If the whole mail header field does not contain non-ASCII characters, 326 email header field downgrading is not required. Each header field's 327 downgrading method is described below. 329 4.2.1. Address Header Fields That Contain
s 330 From: 331 Sender: 332 To: 333 Cc: 334 Bcc: 335 Reply-To: 336 Resent-From: 337 Resent-Sender: 338 Resent-To: 339 Resent-Cc: 340 Resent-Bcc: 341 Resent-Reply-To: 342 Return-Path: 343 Disposition-Notification-To: 345 If the header field contains elements that contain non- 346 ASCII addresses, perform COMMENT downgrading, DISPLAY-NAME 347 downgrading, and MAILBOX downgrading. 349 [[ Note: RFC 5322 does not allow group syntax in "From:", "Resent- 350 From:", "Sender:", "Resent-Sender:", but proposed method uses group 351 syntax. This problem need to be fixed. ]] 353 4.2.2. Address Header Fields with Typed Addresses 355 Original-Recipient: 356 Final-Recipient: 358 If the header field contains non-ASCII characters, perform TYPED- 359 ADDRESS downgrading. 361 4.2.3. Downgrading Non-ASCII in Comments 363 Date: 364 Message-ID: 365 Resent-Message-ID: 366 In-Reply-To: 367 References: 368 Resent-Date: 369 Resent-Message-ID: 370 MIME-Version: 371 Content-ID: 372 Content-Transfer-Encoding: 373 Content-Language: 375 Accept-Language: 376 Auto-Submitted: 378 These header fields do not contain non-ASCII characters except in 379 comments. If the header field contains UTF-8 characters in comments, 380 perform COMMENT downgrading. 382 4.2.4. Received Header Field 384 Received: 386 Perform COMMENT downgrading and RECEIVED downgrading. 388 4.2.5. MIME Content Header Fields 390 Content-Type: 391 Content-Disposition: 393 Perform MIME-VALUE downgrading and COMMENT downgrading. 395 4.2.6. Non-ASCII in 397 Subject: 398 Comments: 399 Content-Description: 401 Perform UNSTRUCTURED downgrading. 403 4.2.7. Non-ASCII in 405 Keywords: 407 Perform WORD downgrading. 409 4.2.8. Other Header Fields 411 For all other header fields that contain non-ASCII characters, are 412 user-defined, and are missing from this document or future defined 413 header fields, perform ENCAPSULATION downgrading. 415 If the software understands the header field's structure and a 416 downgrading algorithm other than ENCAPSULATION is applicable, that 417 software SHOULD use that algorithm; ENCAPSULATION downgrading is used 418 as a last resort. 420 Mailing list header fields (those that start in "List-") are part of 421 this category. 423 5. MIME Body-Part Header Field Downgrading 425 MIME body-part header fields may contain non-ASCII characters 426 [I-D.ietf-eai-rfc5335bis]. This section defines the conversion 427 method to ASCII-only header fields for each MIME header field that 428 contains non-ASCII characters. Parse the message body's MIME 429 structure at all levels and check each MIME header field to see 430 whether it contains non-ASCII characters. If the header field 431 contains non-ASCII characters in the header field value, the header 432 field is a target of the MIME body-part header field's downgrading. 433 Each MIME header field's downgrading method is described below. 434 COMMENT downgrading, MIME-VALUE downgrading, and UNSTRUCTURED 435 downgrading are described in Section 4. 437 Content-ID: 438 The "Content-ID:" header field does not contain non-ASCII 439 characters except in comments. If the header field contains UTF-8 440 characters in comments, perform COMMENT downgrading. 442 Content-Type: 444 Content-Disposition: Perform MIME-VALUE downgrading and COMMENT 445 downgrading. 447 Content-Description: Perform UNSTRUCTURED downgrading. 449 6. Security Considerations 451 A downgraded message's header fields contain ASCII characters only. 452 But they still contain MIME-encapsulated header fields that contain 453 non-ASCII UTF-8 characters. Furthermore, the body part may contain 454 UTF-8 characters. Implementations parsing Internet messages need to 455 accept UTF-8 body parts and UTF-8 header fields that are MIME- 456 encoded. Thus, this document inherits the security considerations of 457 MIME-encoded header fields ([RFC2047] and [RFC3629]). 459 Rewriting header fields increases the opportunities for undetected 460 spoofing by malicious senders. However, rewritten header fields are 461 preserved into Downgraded-* header fields, and parsing Downgraded-* 462 header fields enables the detection of spoofing caused by 463 downgrading. 465 The techniques described here invalidate methods that depend on 466 digital signatures over any part of the message, which includes the 467 top-level header fields and body-part header fields. Depending on 468 the specific message being downgraded, the following techniques are 469 likely to break: DomainKeys Identified Mail (DKIM), and possibly 470 S/MIME and Pretty Good Privacy (PGP). The two obvious mitigations 471 are to stick to 7-bit transport when using these techniques (as most/ 472 all of them presently require) or to make sure to have UTF8SMTP end- 473 to-end when needed. 475 While information in any email header field should usually be treated 476 with some suspicion, current email systems commonly employ various 477 mechanisms and protocols to make the information more trustworthy. 478 Currently, information in the new Downgraded-* header fields is 479 usually not inspected by these mechanisms, and may be even less 480 trustworthy than the traditional header fields. Note that the 481 Downgraded-* header fields could have been inserted with malicious 482 intent (and with content unrelated to the traditional header fields). 484 See the "Security Considerations" section in 485 [I-D.ietf-eai-frmwrk-4952bis] for more discussion. 487 7. Implementation Notes 489 7.1. RFC 2047 Encoding 491 While [RFC2047] has a specific algorithm to deal with whitespace in 492 adjacent encoded words, there are a number of deployed 493 implementations that fail to implement the algorithm correctly. As a 494 result, whitespace behavior is somewhat unpredictable in practice 495 when multiple encoded words are used. While RFC 5322 states that 496 implementations SHOULD limit lines to not more than 78 characters, 497 implementations MAY choose to allow overly long encoded words in 498 order to work around faulty [RFC2047] implementations. 499 Implementations that choose to do so SHOULD have an optional 500 mechanism to limit line length to 78 characters. 502 8. IANA Considerations 504 IANA is requested to refuse registration of all field names that 505 start with "Downgraded-". For unknown header fields, use the 506 downgrading method described in Section 3.1 to avoid conflicts with 507 existing IETF activity (Email Address Internationalization). 509 9. Acknowledgements 511 This document draws heavily from the experimental in-transit message 512 downgrading procedure described in RFC 5504 [RFC5504]. The 513 contribution of the co-author of that earlier document, Y. Yoneya, 514 are gratefully acknowledged. 516 10. References 517 10.1. Normative References 519 [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and 520 Framework for Internationalized 521 Email", 522 draft-ietf-eai-frmwrk-4952bis-10 (work 523 in progress), September 2010. 525 [I-D.ietf-eai-rfc5335bis] Yang, A. and S. Steele, 526 "Internationalized Email Headers", 527 draft-ietf-eai-rfc5335bis-02 (work in 528 progress), August 2010. 530 [RFC2045] Freed, N. and N. Borenstein, 531 "Multipurpose Internet Mail Extensions 532 (MIME) Part One: Format of Internet 533 Message Bodies", RFC 2045, 534 November 1996. 536 [RFC2047] Moore, K., "MIME (Multipurpose 537 Internet Mail Extensions) Part Three: 538 Message Header Extensions for Non- 539 ASCII Text", RFC 2047, November 1996. 541 [RFC2119] Bradner, S., "Key words for use in 542 RFCs to Indicate Requirement Levels", 543 BCP 14, RFC 2119, March 1997. 545 [RFC2183] Troost, R., Dorner, S., and K. Moore, 546 "Communicating Presentation 547 Information in Internet Messages: The 548 Content-Disposition Header Field", 549 RFC 2183, August 1997. 551 [RFC2231] Freed, N. and K. Moore, "MIME 552 Parameter Value and Encoded Word 553 Extensions: Character Sets, Languages, 554 and Continuations", RFC 2231, 555 November 1997. 557 [RFC2979] Freed, N., "Behavior of and 558 Requirements for Internet Firewalls", 559 RFC 2979, October 2000. 561 [RFC3629] Yergeau, F., "UTF-8, a transformation 562 format of ISO 10646", STD 63, 563 RFC 3629, November 2003. 565 [RFC3864] Klyne, G., Nottingham, M., and J. 566 Mogul, "Registration Procedures for 567 Message Header Fields", BCP 90, 568 RFC 3864, September 2004. 570 [RFC4021] Klyne, G. and J. Palme, "Registration 571 of Mail and MIME Header Fields", 572 RFC 4021, March 2005. 574 [RFC5322] Resnick, P., Ed., "Internet Message 575 Format", RFC 5322, October 2008. 577 [RFC5337] Newman, C. and A. Melnikov, 578 "Internationalized Delivery Status and 579 Disposition Notifications", RFC 5337, 580 September 2008. 582 10.2. Informative References 584 [RFC5504] Fujiwara, K. and Y. Yoneya, 585 "Downgrading Mechanism for Email 586 Address Internationalization", 587 RFC 5504, March 2009. 589 Appendix A. Examples 591 A.1. Downgrading Example 593 This appendix shows an message downgrading example. Consider a 594 received mail message where: 596 o The sender address is a non-ASCII address, 597 "NON-ASCII-local@example.com". Its display-name is "DISPLAY- 598 local". 600 o The "To:" header field contains two non-ASCII addresses, 601 "NON-ASCII-remote1@example.net" and 602 "NON-ASCII-remote2@example.com" Its display-names are "DISPLAY- 603 remote1" and "DISPLAY-remote2". 605 o The "Cc:" header field contains a non-ASCII address, 606 "NON-ASCII-remote3@example.org". Its display-name is "DISPLAY- 607 remote3". 609 o Four display names contain non-ASCII characters. 611 o The Subject header field is "NON-ASCII-SUBJECT", which contains 612 non-ASCII characters. 614 o There is an unknown header field "X-Unknown-Header" which contains 615 non-ASCII characters. 617 Return-Path: 618 Received: from ... by ... for 619 Received: from ... by ... for 620 From: DISPLAY-local 621 To: DISPLAY-remote1 , 622 DISPLAY-remote2 623 Cc: DISPLAY-remote3 624 Subject: NON-ASCII-SUBJECT 625 Date: DATE 626 Message-Id: MESSAGE_ID 627 Mime-Version: 1.0 628 Content-Type: text/plain; charset="UTF-8" 629 Content-Transfer-Encoding: 8bit 630 X-Unknown-Header: NON-ASCII-CHARACTERS 632 MAIL_BODY 634 Figure 1: Received message in a mail drop 636 The downgraded message is shown in Figure 2. "Return-Path:", 637 "From:", "To:" and "Cc:" header fields are rewritten. "X-Unknown- 638 Header:" is encapsulated as "Downgraded-X-Unknown-Header:". 640 Return-Path: Internationalized address 641 =?UTF-8?Q?NON-ASCII-local@example.com?= removed:; 642 Received: from ... by ... 643 Received: from ... by ... 644 From: =?UTF-8?Q?DISPLAY-local?= Internationalized address 645 =?UTF-8?Q?NON-ASCII-local@example.com?= removed:; 646 To: =?UTF-8?Q?DISPLAY-remote1?= Internationalized address 647 =?UTF-8?Q?NON-ASCII-remote1@example.net?= removed:;, 648 =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 649 =?UTF-8?Q?NON-ASCII-remote2@example.com?= removed:;, 650 Cc: =?UTF-8?Q?DISPLAY-remote3?= Internationalized address 651 =?UTF-8?Q?NON-ASCII-remote3@example.org?= removed:; 652 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 653 Date: DATE 654 Message-Id: MESSAGE_ID 655 Mime-Version: 1.0 656 Content-Type: text/plain; charset="UTF-8" 657 Content-Transfer-Encoding: 8bit 658 Downgraded-X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?= 660 MAIL_BODY 662 Figure 2: Downgraded message 664 Author's Address 666 Kazunori Fujiwara 667 Japan Registry Services Co., Ltd. 668 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 669 Chiyoda-ku, Tokyo 101-0065 670 Japan 672 Phone: +81 3 5215 8451 673 EMail: fujiwara@jprs.co.jp