idnits 2.17.1 draft-ietf-eai-downgrade-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2009) is 5533 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 233, but not defined == Missing Reference: 'CFWS' is mentioned on line 234, but not defined ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530) ** Obsolete normative reference: RFC 5335 (Obsoleted by RFC 6532) ** Obsolete normative reference: RFC 5336 (Obsoleted by RFC 6531) ** Obsolete normative reference: RFC 5337 (Obsoleted by RFC 6533) == Outdated reference: A later version (-03) exists of draft-ietf-eai-downgraded-display-00 == Outdated reference: A later version (-01) exists of draft-ietf-eai-dsnbis-00 Summary: 6 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, Ed. 3 (EAI) Y. YONEYA, Ed. 4 Internet-Draft JPRS 5 Intended status: Experimental March 2, 2009 6 Expires: September 3, 2009 8 Downgrading mechanism for Email Address Internationalization 9 draft-ietf-eai-downgrade-12.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 3, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Traditional mail systems handle only ASCII characters in SMTP 48 envelope and mail header fields. The Email Address 49 Internationalization (UTF8SMTP) extension allows UTF-8 characters in 50 SMTP envelope and mail header fields. To avoid rejecting 51 internationalized Email messages when a server in the delivery path 52 does not support the UTF8SMTP extension, some sort of converting 53 mechanism is required. This document describes a downgrading 54 mechanism for Email Address Internationalization. Note that this is 55 a way to downgrade, not tunnel. There is no associated up-conversion 56 mechanism, although internationalized email clients might use 57 original internationalized addresses or other data when displaying or 58 replying to downgraded messages. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. New header fields definition . . . . . . . . . . . . . . . . . 5 65 3.1. Envelope information preservation header fields . . . . . 6 66 3.2. Address header field preservation header fields . . . . . 6 67 3.3. Unknown header fields preservation header fields . . . . 7 68 4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Path element downgrading . . . . . . . . . . . . . . . . 8 70 4.2. ORCPT downgrading . . . . . . . . . . . . . . . . . . . . 9 71 5. Email header fields downgrading . . . . . . . . . . . . . . . 9 72 5.1. Downgrading method for each ABNF element . . . . . . . . 9 73 5.1.1. RECEIVED downgrading . . . . . . . . . . . . . . . . . 9 74 5.1.2. UNSTRUCTURED downgrading . . . . . . . . . . . . . . . 9 75 5.1.3. WORD downgrading . . . . . . . . . . . . . . . . . . . 10 76 5.1.4. COMMENT downgrading . . . . . . . . . . . . . . . . . 10 77 5.1.5. MIME-VALUE downgrading . . . . . . . . . . . . . . . . 10 78 5.1.6. DISPLAY-NAME downgrading . . . . . . . . . . . . . . . 10 79 5.1.7. MAILBOX downgrading . . . . . . . . . . . . . . . . . 10 80 5.1.8. ENCAPSULATION downgrading . . . . . . . . . . . . . . 11 81 5.1.9. TYPED-ADDRESS downgrading . . . . . . . . . . . . . . 11 82 5.2. Downgrading method for each header field . . . . . . . . 11 83 5.2.1. Address header fields which contain
s . . . . 11 84 5.2.2. Address header fields with typed addresses . . . . . . 12 85 5.2.3. Downgrading Non-ASCII in comments . . . . . . . . . . 12 86 5.2.4. Received header field . . . . . . . . . . . . . . . . 12 87 5.2.5. MIME Content header fields . . . . . . . . . . . . . . 12 88 5.2.6. Non-ASCII in . . . . . . . . . . . . . 13 89 5.2.7. Non-ASCII in . . . . . . . . . . . . . . . . 13 90 5.2.8. Other header fields . . . . . . . . . . . . . . . . . 13 91 6. MIME body part header fields downgrading . . . . . . . . . . . 13 92 7. Security considerations . . . . . . . . . . . . . . . . . . . 14 93 8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 15 94 8.1. RFC 2047 encoding . . . . . . . . . . . . . . . . . . . . 15 95 8.2. Trivial downgrading . . . . . . . . . . . . . . . . . . . 16 96 8.3. 7bit transport consideration . . . . . . . . . . . . . . 16 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 99 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 19 100 11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . 19 101 11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . 19 102 11.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . 20 103 11.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . 20 104 11.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . 20 105 11.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . 20 106 11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . 20 107 11.8. draft-ietf-eai-downgrade: Version 05 . . . . . . . . . . 20 108 11.9. draft-ietf-eai-downgrade: Version 06 . . . . . . . . . . 21 109 11.10. draft-ietf-eai-downgrade: Version 07 . . . . . . . . . . 21 110 11.11. draft-ietf-eai-downgrade: Version 08 . . . . . . . . . . 21 111 11.12. draft-ietf-eai-downgrade: Version 09 . . . . . . . . . . 21 112 11.13. draft-ietf-eai-downgrade: Version 10 . . . . . . . . . . 21 113 11.14. draft-ietf-eai-downgrade: Version 11 . . . . . . . . . . 21 114 11.15. draft-ietf-eai-downgrade: Version 12 . . . . . . . . . . 21 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 116 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 117 12.2. Informative References . . . . . . . . . . . . . . . . . 23 118 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 23 119 A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 23 120 A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 26 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 123 1. Introduction 125 Traditional mail systems which are defined by [RFC5321] and [RFC5322] 126 allow ASCII characters in SMTP envelope and mail header field values. 127 The UTF8SMTP extension [RFC4952], [RFC5335] and [RFC5336] allows 128 UTF-8 characters in SMTP envelope and mail header field values. 130 If an envelope address or header field contains non-ASCII characters, 131 the message cannot be delivered unless every system in the delivery 132 path supports UTF8SMTP. This document describes a downgrading 133 mechanism to avoid rejection of such messages when a server which 134 does not support the UTF8SMTP extension is encountered. Downgrading 135 mechanism converts envelope and header fields to an all-ASCII 136 representation. 138 [RFC5335] allows UTF-8 characters to be used in mail header fields 139 and MIME header fields. The downgrading mechanism specified here 140 converts mail header fields and MIME header fields to ASCII. 142 This document does not change any protocols except by defining new 143 header fields. It describes the conversion method from the 144 internationalized email envelopes/messages which are defined in 145 [RFC4952] [RFC5335] [RFC5336] to the traditional email envelopes/ 146 messages which are defined in [RFC5321] [RFC5322]. 148 [RFC5336] section 2.2 defines when downgrading occurs. If the SMTP 149 client has an UTF8SMTP envelope or an internationalized message and 150 the SMTP server doesn't support the UTF8SMTP SMTP extension, then the 151 SMTP client MUST NOT send a UTF8SMTP envelope or an internationalized 152 message to the SMTP server. The section shows 4 choices. The fourth 153 choice is downgrading, as described here. 155 Downgrading may be implemented in MUAs, MSAs, MTAs which act as the 156 SMTP client, or in MDAs, POP servers, IMAP servers which store or 157 offer UTF8SMTP envelopes or internationalized messages to non- 158 UTF8SMTP compliant systems which include message stores. 160 This document tries to define the downgrading process clearly and it 161 preserves the original information as much as possible. 163 Downgrading in UTF8SMTP consists of the following four parts: 164 o New header fields definition 165 o SMTP downgrading 166 o Email header fields downgrading 167 o MIME header fields downgrading 169 In Section 3, many header fields starting with "Downgraded-" are 170 introduced. They preserve the original envelope information and the 171 original header fields. 173 The SMTP downgrading is described in Section 4. It generates ASCII 174 only envelope information from an UTF8SMTP envelope. 176 The Email header fields downgrading is described in Section 5. It 177 generates ASCII only header fields. 179 The MIME header fields are expanded in [RFC5335]. The MIME header 180 fields downgrading is described in Section 6. It generates ASCII 181 only MIME header fields. 183 Displaying downgraded messages which originally contain 184 internationalized E-mail addresses or internationalized header fields 185 is described in an another document 186 ([I-D.ietf-eai-downgraded-display]). 188 2. Terminology 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC 2119 [RFC2119]. 194 All specialized terms used in this specification are defined in the 195 EAI overview [RFC4952] or in [RFC5321][RFC5322], MIME documents 196 [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address", 197 "internationalized email address", "non-ASCII address", "i18mail 198 address", "UTF8SMTP", "message" and "mailing list" are used with the 199 definitions from [RFC4952] document. 201 This document depends on [RFC5335], [RFC5336], and [RFC5337]. Key 202 words used in these document are used in this document, too. 204 The term "non-ASCII" is an UTF-8 string which contains at least one 205 non-ASCII character. 207 An "UTF8SMTP envelope" has Email originator/recipient addresses 208 expanded by [RFC5336] and [RFC5337]. 210 An "UTF8SMTP message" is Email messages expanded by [RFC5335]. 212 3. New header fields definition 214 New header fields starting with "Downgraded-" are defined here to 215 preserve those original envelope and header field values which 216 contain UTF-8 characters. During downgrading, one new "Downgraded-" 217 header field is added for each original envelope or header field 218 which cannot be passed as-is to a server which does not support 219 UTF8SMTP. The original envelope or header field is removed or 220 rewritten. Only those envelope and header fields which contain non- 221 ASCII characters are affected. The result of this process is a 222 message which is compliant with existing email specifications 223 [RFC5321] and [RFC5322]. The original internationalized information 224 can be retrieved by examining the "Downgraded-" header fields which 225 were added. 227 3.1. Envelope information preservation header fields 229 SMTP envelope downgraded information 230 consists of the original non-ASCII address and the downgraded all- 231 ASCII address. 233 downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox 234 FWS "<" Mailbox ">" ">" [CFWS] 236 is defined in [RFC5336]; and are defined 237 in [RFC5321], section 4.1.2. 239 Two header fields "Downgraded-Mail-From:" and "Downgraded-Rcpt-To:" 240 are defined to preserve SMTP envelope downgraded information. The 241 header field syntax is specified as follows: 243 fields =/ downgradedmailfrom / downgradedrcptto 244 downgradedmailfrom = "Downgraded-Mail-From:" unstructured CRLF 245 downgradedrcptto = "Downgraded-Rcpt-To:" unstructured CRLF 247 The unstructured content is downgraded-envelope-addr treated as if it 248 were unstructured with [RFC2047] encoding (and charset UTF-8) as 249 needed. 251 3.2. Address header field preservation header fields 253 The address header fields preservation header fields are defined to 254 preserve the original header field. Their value field holds the 255 original header field value. The header field syntax is specified as 256 follows: 258 fields =/ known-downgraded-headers ":" unstructured CRLF 259 known-downgraded-headers = "Downgraded-" original-headers 260 original-headers = "From" / "Sender" / 261 "To" / "Cc" / "Bcc" / 262 "Reply-To" / 263 "Resent-From" / "Resent-Sender" / 264 "Resent-To" / "Resent-Cc" / "Resent-Bcc" / 265 "Resent-Reply-To" / 266 "Return-Path" / 267 "Disposition-Notification-To" 269 Preserving a header field in a downgraded header field is defined as: 270 1. Generate new downgraded header field whose value is the original 271 header field value. 272 2. Treat the generated header field content as if it were 273 unstructured, and then apply [RFC2047] encoding with charset 274 UTF-8 as necessary so the result is ASCII. 276 3.3. Unknown header fields preservation header fields 278 The unknown header fields preservation header fields are defined to 279 encapsulate those original header fields which contain non-ASCII 280 characters and are not otherwise provided for in the this 281 specification. The encapsulation header field name is the 282 concatenation of "Downgraded-" and the original name. The value 283 field holds the original header field value. 285 The header field syntax is specified as follows: 287 fields =/ unknown-downgraded-headers ":" unstructured CRLF 288 unknown-downgraded-headers = "Downgraded-" original-header-field-name 289 original-header-field-name = field-name 291 field-name = 1*ftext 293 ftext = %d33-57 / ; Any character except 294 %d59-126 ; controls, SP, and 295 ; ":". 297 Encapsulating a header field in a "Downgraded-" header field is 298 defined as: 299 1. Generate new "Downgraded-" header field whose value is the 300 original header field value. 302 2. Treat the generated header field content as if it were 303 unstructured, and then apply [RFC2047] encoding with charset 304 UTF-8 as necessary so the result is ASCII. 305 3. Remove the original header field. 307 4. SMTP Downgrading 309 Target of downgrading elements in SMTP envelope are below: 311 o of MAIL FROM command 312 o of RCPT TO command 313 o ORCPT parameter of RCPT TO command 315 4.1. Path element downgrading 317 Downgrading the of MAIL FROM and RCPT TO commands uses ALT- 318 ADDRESS parameter defined in [RFC5336]. A SMTP command is 319 downgradable if the contains non-ASCII address and the command 320 has an ALT-ADDRESS parameter which specifies an ASCII address. Since 321 only non-ASCII addresses are downgradable, specifying an ALT-ADDRESS 322 value for an all-ASCII address is invalid for use with this 323 specification, and no interpretation is assigned to it. This 324 restriction allows for future extension of the specification even 325 though no such extensions are currently anticipated. 327 Note that even if no downgrading is performed on the envelope, 328 message header fields and message body MIME header fields that 329 contain non-ASCII characters MUST be downgraded. This is described 330 in Section 5 and Section 6. 332 When downgrading, replace each which contains non-ASCII mail 333 address with its specified alternative ASCII address and preserve the 334 original information using "Downgraded-Mail-From" and "Downgraded- 335 Rcpt-To" header fields as defined in Section 3. Before replacing, 336 decode the ALT-ADDRESS parameter value because it is encoded as xtext 337 [RFC3461]. 339 To avoid disclosing recipient addresses, the downgrading process MUST 340 NOT add "Downgraded-Rcpt-To:" header field if the SMTP downgrading 341 targets multiple recipients. See Section 7 for more detail. 343 As a result of the recipient address downgrading, the domain part of 344 the recipient address prior to downgrading might be different from 345 the domain part of the new recipient address. If the result of 346 address resolution for the domain part of the new recipient address 347 contains the server at the connection destination of the SMTP session 348 for the recipient address prior to downgrading, the SMTP connection 349 is valid for the new recipient address. Otherwise, the downgrading 350 process MUST NOT send the downgraded message to the new recipient 351 address via the connection and MUST try to send the downgraded 352 message to the new recipient address. 354 4.2. ORCPT downgrading 356 The "RCPT TO" command can have an ORCPT parameter if the DSN 357 extension [RFC3461] is supported. If the ORCPT parameter contains an 358 "utf-8" type address and the address contains raw non-ASCII 359 characters, the address MUST be converted to utf-8-addr-xtext form. 360 Those forms are described in [RFC5337] and clarified by successor 361 documents such as [I-D.ietf-eai-dsnbis]. 363 Before converting to utf-8-addr-xtext form, remove xtext encoding. 365 5. Email header fields downgrading 367 This section defines the conversion method to ASCII for each header 368 field which may contain non-ASCII characters. 370 [RFC5335] expands Received: header fields, [RFC5322] ABNF elements 371 , , , , [RFC2045] ABNF element 372 . 374 5.1. Downgrading method for each ABNF element 376 Header field downgrading is defined below for each ABNF element. 377 Downgrading an unknown header field is also defined as ENCAPSULATION 378 downgrading. Converting the header field terminates when no non- 379 ASCII characters remain in the header field. 381 5.1.1. RECEIVED downgrading 383 If the header field name is "Received:" and the FOR clause contains a 384 non-ASCII addresses, remove the FOR clause from the header field. 385 Other parts (not counting s) should not contain non-ASCII 386 values. 388 5.1.2. UNSTRUCTURED downgrading 390 If the header field has an field which contains non- 391 ASCII characters, apply [RFC2047] encoding with charset UTF-8. 393 5.1.3. WORD downgrading 395 If the header field has any fields which contains non-ASCII 396 characters, apply [RFC2047] encoding with charset UTF-8. 398 5.1.4. COMMENT downgrading 400 If the header field has any fields which contains non-ASCII 401 characters, apply [RFC2047] encoding with charset UTF-8. 403 5.1.5. MIME-VALUE downgrading 405 If the header field has any elements defined by [RFC2045] and 406 the elements contain non-ASCII characters, encode the 407 elements by [RFC2231] with charset UTF-8 and the Language information 408 empty. If the element is and it contains 409 outside the DQUOTE, remove the before this conversion. 411 5.1.6. DISPLAY-NAME downgrading 413 If the header field has any
( and ) 414 elements and they have elements which contain non- 415 ASCII characters, encode the elements according to 416 [RFC2047] with charset UTF-8. DISPLAY-NAME downgrading is the same 417 algorithm as WORD downgrading. 419 5.1.7. MAILBOX downgrading 421 The elements have no equivalent format for non-ASCII 422 addresses. If the header field has any elements which 423 contain non-ASCII characters, preserve the header field in each 424 Address header field preservation header field defined in 425 Section 3.2, and rewrite each element to ASCII only format. 426 The element which contains non-ASCII characters is one of 427 three formats. 429 o [ Display-name ] "<" Utf8-addr-spec 1*FCS "<" Addr-spec ">>" 431 Rewrite it as 433 [ Display-name ] "<" Addr-spec ">" 435 o [ Display-name ] "<" Utf8-addr-spec ">" 436 o Utf8-addr-spec 438 Rewrite both as 439 [ Display-name ] "Internationalized Address " Encoded-word 440 " Removed:;" 441 where the is the original encoded 442 according to [RFC2047]. 444 5.1.8. ENCAPSULATION downgrading 446 if the header field contains non-ASCII characters and for which no 447 rule is given above, encapsulate it in a Downgraded header field 448 described in Section 3.3 as a last resort. 450 Applying this procedure to "Received" header field is prohibited. 452 5.1.9. TYPED-ADDRESS downgrading 454 If the header field contains and the contains raw non-ASCII characters, it is utf-8-address form and 456 convert it to utf-8-addr-xtext form as described in Section 4.2. 457 COMMENT downgrading is also performed in this case. If the address 458 type is unrecognized and the header field contains non-ASCII 459 characters, then fall back to using ENCAPSULATION downgrading on the 460 entire header field. 462 5.2. Downgrading method for each header field 464 Header fields are listed in [RFC4021]. This section describes the 465 downgrading method for each header field. 467 If the whole mail header field does not contain non-ASCII characters, 468 email header field downgrading is not required. Each header field's 469 downgrading method is described below. 471 5.2.1. Address header fields which contain
s 473 From: 474 Sender: 475 To: 476 Cc: 477 Bcc: 478 Reply-To: 479 Resent-From: 480 Resent-Sender: 481 Resent-To: 482 Resent-Cc: 483 Resent-Bcc: 484 Resent-Reply-To: 486 Return-Path: 487 Disposition-Notification-To: 489 If the header field contains elements which contains non- 490 ASCII addresses, preserve the header field in a downgraded header 491 field before the conversion. Then perform COMMENT downgrading, 492 DISPLAY-NAME downgrading and MAILBOX downgrading. 494 5.2.2. Address header fields with typed addresses 496 Original-Recipient: 497 Final-Recipient: 499 If the header field contains non-ASCII characters, perform TYPED- 500 ADDRESS downgrading. 502 5.2.3. Downgrading Non-ASCII in comments 504 Date: 505 Message-ID: 506 Resent-Message-ID: 507 In-Reply-To: 508 References: 509 Resent-Date: 510 Resent-Message-ID: 511 MIME-Version: 512 Content-ID: 513 Content-Transfer-Encoding: 514 Content-Language: 515 Accept-Language: 516 Auto-Submitted: 518 These header fields do not contain non-ASCII characters except in 519 comments. If the header field contains UTF-8 characters in comments, 520 perform COMMENT downgrading. 522 5.2.4. Received header field 524 Received: 526 perform COMMENT downgrading and RECEIVED downgrading. 528 5.2.5. MIME Content header fields 529 Content-Type: 530 Content-Disposition: 532 Perform MIME-VALUE downgrading and COMMENT downgrading. 534 5.2.6. Non-ASCII in 536 Subject: 537 Comments: 538 Content-Description: 540 Perform UNSTRUCTURED downgrading. 542 5.2.7. Non-ASCII in 544 Keywords: 546 Perform WORD downgrading. 548 5.2.8. Other header fields 550 All other header fields which contains non-ASCII characters are user- 551 defined, missing from this draft or future defined header fields. 552 Perform ENCAPSULATION downgrading. 554 If the software understands the header field's structure and a 555 downgrading algorithm other than ENCAPSULATION is applicable, that 556 software SHOULD use that algorithm; ENCAPSULATION downgrading is used 557 as a last resort. 559 Mailing list header fields (those that start in "List-") are part of 560 this category. 562 6. MIME body part header fields downgrading 564 MIME body part header fields may contain non-ASCII characters 565 [RFC5335]. This section defines the conversion method to ASCII only 566 header fields for each MIME header field which contains non-ASCII 567 characters. Parse the message body's MIME structure for all levels 568 and check each MIME header field whether it contains non-ASCII 569 characters. If the header field contains non-ASCII characters in the 570 header field value, the header field is a target of the MIME body 571 part header fields downgrading. Each MIME header field's downgrading 572 method is described below. COMMENT downgrading, MIME-VALUE 573 downgrading, UNSTRUCTURED downgrading are described in Section 5. 575 Content-ID: 576 The Content-ID: header field does not contain non-ASCII characters 577 except in comments. If the header field contains UTF-8 characters 578 in comments, perform COMMENT downgrading. 580 Content-Type: 581 Content-Disposition: 582 Perform MIME-VALUE downgrading and COMMENT downgrading. 584 Content-Description: 585 Perform UNSTRUCTURED downgrading. 587 7. Security considerations 589 A Downgraded message's header fields contain ASCII characters only. 590 But they still contain MIME encapsulated header fields which contains 591 non-ASCII UTF-8 characters. Furthermore, the body part may contain 592 UTF-8 characters. Implementations parsing Internet messages need to 593 accept UTF-8 body parts and UTF-8 header fields which are MIME 594 encoded. Thus it inherits the security considerations of MIME 595 encoded header fields [RFC2047] and [RFC3629]. 597 Rewriting header fields increases the opportunities for undetected 598 spoofing by the malicious senders. However rewritten header fields 599 are preserved into Downgraded-* header fields and parsing 600 Downgraded-* header fields enables detecting spoofing caused by 601 downgrading. 603 Addresses that do not appear in the message header fields may appear 604 in the RCPT commands to an SMTP server for a number of reasons. 605 Copying information from the Envelope into header fields risks 606 inadvertent information disclosure (see [RFC5321] and Section 4). 607 Mitigating inadvertent information disclosure is discussed in same 608 place. 610 The techniques described here invalidates methods that depend on 611 digital signatures over the envelope or any part of the message which 612 includes the top-level header fields or body part header fields. 613 Depending on the specific message being downgraded, DKIM especially, 614 but also possibly S/MIME, PGP, and similar techniques are all likely 615 to break. The two obvious mitigations are to stick to 7-bit 616 transport when using these techniques (as most/all of them presently 617 require), or make sure you have UTF8SMTP end-to-end when needed. 619 Many gateways and servers on the Internet will discard header fields 620 with which they are not familiar. To the extent to which the 621 downgrade procedures depend on new header fields (e.g., 622 "Downgraded-") to avoid information loss, the risk of having those 623 header fields dropped and its implications must be identified. In 624 particular, if the Downgraded header fields are dropped, there is no 625 possibility of reconstructing the original information at any point 626 (before, during, or after delivery). Such gateways violate [RFC2979] 627 and can be upgraded to correct the problem. 629 Even though the information is not lost, the original message cannot 630 be perfectly reconstructed because some downgrading methods remove 631 information (see Section 5.1.1 and Section 5.1.5). Hence, 632 downgrading is a one-way process. 634 While information in any email header field should usually treated 635 with some suspicion, current email systems commonly employ various 636 mechanisms and protocols to make the information more trustworthy. 637 Currently, information in the new Downgraded-* header fields is 638 usually not inspected by these mechanisms, and may be even less 639 trustworthy than the traditional header fields. Note that the 640 Downgraded-* header fields could have been inserted with malicious 641 intent. (and with content unrelated to the traditional header 642 fields). 644 If an internationalized MUA would simply try to "upgrade" the message 645 for display purposes (that is, display the information in the 646 Downgraded-* header fields instead of the traditional header fields), 647 the effectiveness of the deployed mechanisms and protocols is likely 648 to be reduced, and the user may be exposed to additional risks. More 649 guidance on how to display downgraded messages will be given in 650 [I-D.ietf-eai-downgraded-display]. 652 Concerns about the trustworthiness of the Downgraded-* header fields 653 are not limited to displaying and replying in MUAs, and should be 654 carefully considered before using them for other purposes as well. 656 See "Security considerations" section in [RFC4952] for more 657 discussion. 659 8. Implementation notes 661 8.1. RFC 2047 encoding 663 While [RFC2047] has a specific algorithm to deal with whitespace in 664 adjacent encoded-words, there are a number of deployed 665 implementations that fail to implement the algorithm correctly. As a 666 result, whitespace behavior is somewhat unpredictable in practice 667 when multiple encoded words are used. While RFC 5322 states that 668 implementations SHOULD limit lines to not more than 78 characters, 669 implementations MAY choose to allow overlong encoded words in order 670 to work around faulty [RFC2047] implementations. Implementations 671 that choose to do so SHOULD have an optional mechanism to limit line 672 length to 78 characters. 674 8.2. Trivial downgrading 676 Downgrading is an alternative to avoid the rejection of messages 677 which require UTF8SMTP support by a server which does not provide 678 this. Implementing the full specification of this document is 679 desirable, but a partial implementation is also possible. 681 If a partial downgrading implementation confronts an unsupported 682 downgrading target, the implementation MUST NOT send the message to a 683 server which does not support UTF8SMTP. Instead, it MUST reject the 684 message or generate a notification of non-deliverability. 686 A partial downgrading, Trivial downgrading is discussed. It does not 687 support non-ASCII addresses in SMTP envelope and address header 688 fields, unknown header fields downgrading, the MIME body part header 689 fields downgrading. It supports 690 o some simple header fields downgrading: Subject 691 o comments and display name downgrading: From, To, Cc 692 o trace header field downgrading: Received 694 Otherwise, the downgrading fails. 696 Trivial downgrading targets mail messages which are generated by 697 UTF8SMTP aware MUAs and contain non-ASCII characters in comments, 698 display names, unstructured parts without using non-ASCII E-mail 699 addresses. This mail message does not contain non-ASCII E-mail 700 addresses in the SMTP Envelope and its header fields. But it is not 701 deliverable via a UTF8SMTP un-aware SMTP server. Implementing full 702 specification downgrading may be hard, but trivial downgrading saves 703 mail messages without using non-ASCII addresses. 705 8.3. 7bit transport consideration 707 The SMTP client may encounter a SMTP server which does not support 708 the 8BITMIME SMTP extension [RFC1652]. The server does not support 709 "8bit" or "binary" data. Implementers need to consider converting 710 "8bit" data to "base64" or "quoted-printable" encoded form and adjust 711 the "Content-Transfer-Encoding" header field accordingly. If the 712 body contains multiple MIME parts, this conversion MUST be performed 713 for each MIME part. 715 9. IANA Considerations 717 IANA is requested to register the following header fields in the 718 Permanent Message Header Field Repository, in accordance with the 719 procedures set out in [RFC3864]. 721 Header field name: Downgraded-Mail-From 722 Applicable protocol: mail 723 Status: experimental 724 Author/change controller: IETF 725 Specification document(s): This document (Section 3) 727 Header field name: Downgraded-Rcpt-To 728 Applicable protocol: mail 729 Status: experimental 730 Author/change controller: IETF 731 Specification document(s): This document (Section 3) 733 Header field name: Downgraded-From 734 Applicable protocol: mail 735 Status: experimental 736 Author/change controller: IETF 737 Specification document(s): This document (Section 3) 739 Header field name: Downgraded-Sender 740 Applicable protocol: mail 741 Status: experimental 742 Author/change controller: IETF 743 Specification document(s): This document (Section 3) 745 Header field name: Downgraded-To 746 Applicable protocol: mail 747 Status: experimental 748 Author/change controller: IETF 749 Specification document(s): This document (Section 3) 751 Header field name: Downgraded-Cc 752 Applicable protocol: mail 753 Status: experimental 754 Author/change controller: IETF 755 Specification document(s): This document (Section 3) 757 Header field name: Downgraded-Bcc 758 Applicable protocol: mail 759 Status: experimental 760 Author/change controller: IETF 761 Specification document(s): This document (Section 3) 763 Header field name: Downgraded-Reply-To 764 Applicable protocol: mail 765 Status: experimental 766 Author/change controller: IETF 767 Specification document(s): This document (Section 3) 769 Header field name: Downgraded-Resent-From 770 Applicable protocol: mail 771 Status: experimental 772 Author/change controller: IETF 773 Specification document(s): This document (Section 3) 775 Header field name: Downgraded-Resent-Sender 776 Applicable protocol: mail 777 Status: experimental 778 Author/change controller: IETF 779 Specification document(s): This document (Section 3) 781 Header field name: Downgraded-Resent-To 782 Applicable protocol: mail 783 Status: experimental 784 Author/change controller: IETF 785 Specification document(s): This document (Section 3) 787 Header field name: Downgraded-Resent-Cc 788 Applicable protocol: mail 789 Status: experimental 790 Author/change controller: IETF 791 Specification document(s): This document (Section 3) 793 Header field name: Downgraded-Resent-Bcc 794 Applicable protocol: mail 795 Status: experimental 796 Author/change controller: IETF 797 Specification document(s): This document (Section 3) 799 Header field name: Downgraded-Resent-Reply-To 800 Applicable protocol: mail 801 Status: experimental 802 Author/change controller: IETF 803 Specification document(s): This document (Section 3) 805 Header field name: Downgraded-Return-Path 806 Applicable protocol: mail 807 Status: experimental 808 Author/change controller: IETF 809 Specification document(s): This document (Section 3) 811 Header field name: Downgraded-Disposition-Notification-To 812 Applicable protocol: mail 813 Status: experimental 814 Author/change controller: IETF 815 Specification document(s): This document (Section 3) 817 Furthermore, IANA is requested to refuse registration of all the 818 field names that start with "Downgraded-" for unknown header fields 819 downgrading described in Section 3.3 to avoid conflicts with existing 820 IETF activity (Email Address Internationalization). 822 10. Acknowledgements 824 Significant comments and suggestions were received from John Klensin, 825 Harald Alvestrand, Chris Newman, Randall Gellens, Charles Lindsey, 826 Marcos Sanz, Alexey Melnikov, Frank Ellermann, Edward Lewis, S. 827 Moonesamy and JET members. 829 11. Change History 831 This section is used for tracking the update of this document. Will 832 be removed after finalize. 834 11.1. draft-yoneya-ima-downgrade: Version 00 836 o Initial version 837 o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00 839 11.2. draft-yoneya-ima-downgrade: Version 01 841 o Document structure was changed 842 o Followed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02 843 o Downgrading requirements were added 844 o SMTP DATA encapsulation method was proposed 845 o Downgrading examples was provided 847 11.3. draft-ietf-eai-downgrade: Version 00 849 o Followed draft-yeh-ima-utf8headers-01 and 850 draft-ietf-eai-smtpext-00 851 o No header field downgrading method was proposed 852 o Header encapsulation method was proposed 854 11.4. draft-ietf-eai-downgrade: Version 01 856 o Followed draft-ietf-eai-utf8headers-00 857 o Header conversion and encapsulation method was merged 858 o Header conversion method was defined in detail 860 11.5. draft-ietf-eai-downgrade: Version 02 862 o Followed draft-ietf-eai-utf8headers-01 and 863 draft-ietf-eai-smtpext-01 864 o Specification about algorithmic generated address is removed 865 o No header field downgrading method was removed 866 o SMTP DATA encapsulation method was removed 868 11.6. draft-ietf-eai-downgrade: Version 03 870 o Followed draft-ietf-eai-utf8headers-03 and 871 draft-ietf-eai-smtpext-03 872 o Downgraded: and Envelope-Downgraded: headers definition was added 873 o Mail header fields downgrading method was refined 874 o Examples in Appendix A were refined 876 11.7. draft-ietf-eai-downgrade: Version 04 878 o Followed draft-ietf-eai-utf8headers-06, draft-ietf-eai-smtpext-07 879 and draft-ietf-eai-dsn-02 880 o Downgrading requirements and conditions were moved to 881 Introduction. 882 o Descriptions about upgrading were removed. 883 o SPF and DKIM discussion were removed. 884 o Added many header fields downgrading. 885 o Allow address literal rewriting without alternate ASCII address in 886 header fields. 887 o Added MIME body part headers downgrading. 888 o Added ORCPT downgrading. 890 11.8. draft-ietf-eai-downgrade: Version 05 892 o fixed examples 893 * ALT-ADDRESS parameter mistake 894 * RFC2047(x) notation was changed to encoded-word format 895 o Added implementation consideration section and trivial downgrading 896 o Downgraded: and Envelope-Downgraded: headers are separated for 897 each original headers. 898 o Removed list-* header fields downgrading 899 o Changed the way of writing the header field downgrading section 901 11.9. draft-ietf-eai-downgrade: Version 06 903 o Moved decoding downgraded messages as a separate document 904 o Added a text to UNSTRUCTURED downgrading 905 o Added "replacing SMTP connection" if necessary to SMTP 906 downgrading. 907 o fixed examples 909 11.10. draft-ietf-eai-downgrade: Version 07 911 o Fixed some typos 912 o Added a text about 7bit transport 914 11.11. draft-ietf-eai-downgrade: Version 08 916 o Comments from the working group last call (wording) 918 11.12. draft-ietf-eai-downgrade: Version 09 920 o References 922 11.13. draft-ietf-eai-downgrade: Version 10 924 o Comments from AD Review 926 11.14. draft-ietf-eai-downgrade: Version 11 928 o IETF Last call: Comments from Gen-ART and IANA 929 o Added new downgraded header field definitions for Resent-Reply-To, 930 Recent-Bcc and Disposition-Notification-To 931 o Separated "Email header fields downgrading" section into 932 subsections 933 o Updated ORCPT and TYPED-ADDRESS downgrading 935 11.15. draft-ietf-eai-downgrade: Version 12 937 o Comments from IESG 938 o rewrite all 'header' to 'header field'. 940 12. References 942 12.1. Normative References 944 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 945 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 946 RFC 1652, July 1994. 948 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 949 Extensions (MIME) Part One: Format of Internet Message 950 Bodies", RFC 2045, November 1996. 952 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 953 Part Three: Message Header Extensions for Non-ASCII Text", 954 RFC 2047, November 1996. 956 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 957 Requirement Levels", BCP 14, RFC 2119, March 1997. 959 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 960 Presentation Information in Internet Messages: The 961 Content-Disposition Header Field", RFC 2183, August 1997. 963 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 964 Word Extensions: 965 Character Sets, Languages, and Continuations", RFC 2231, 966 November 1997. 968 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 969 Firewalls", RFC 2979, October 2000. 971 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 972 Extension for Delivery Status Notifications (DSNs)", 973 RFC 3461, January 2003. 975 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 976 10646", STD 63, RFC 3629, November 2003. 978 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 979 Procedures for Message Header Fields", BCP 90, RFC 3864, 980 September 2004. 982 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 983 Header Fields", RFC 4021, March 2005. 985 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 986 Internationalized Email", RFC 4952, July 2007. 988 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 989 October 2008. 991 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 992 October 2008. 994 [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, 995 September 2008. 997 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 998 Email Addresses", RFC 5336, September 2008. 1000 [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery 1001 Status and Disposition Notifications", RFC 5337, 1002 September 2008. 1004 12.2. Informative References 1006 [I-D.ietf-eai-downgraded-display] 1007 Fujiwara, K., "Displaying Downgraded Messages for Email 1008 Address Internationalization", 1009 draft-ietf-eai-downgraded-display-00 (work in progress), 1010 October 2008. 1012 [I-D.ietf-eai-dsnbis] 1013 Newman, C. and A. Melnikov, "Internationalized Delivery 1014 Status and Disposition Notifications", 1015 draft-ietf-eai-dsnbis-00 (work in progress), 1016 December 2008. 1018 Appendix A. Examples 1020 A.1. Downgrading example 1 1022 This section shows an SMTP Downgrading example. Consider a mail 1023 message where: 1024 o The sender address is "NON-ASCII-local@example.com" which is a 1025 non-ASCII address. Its ASCII alternative is 1026 "ASCII-local@example.com" and its display-name is "DISPLAY-local". 1027 o The "To:" address is "NON-ASCII-remote1@example.net" which is a 1028 non-ASCII address. Its ASCII alternative is 1029 "ASCII-remote1@example.net" and its display-name is "DISPLAY- 1030 remote1". 1031 o The "Cc:" address is a non-ASCII address 1032 "NON-ASCII-remote2@example.org" without alternative ASCII address. 1033 Its display-name is "DISPLAY-remote2". 1035 o Three display-names contain non-ASCII characters. 1036 o The Subject header field is "NON-ASCII-SUBJECT" which contains 1037 non-ASCII characters. 1038 o Assuming the "To:" recipient's MTA (example.net) does not support 1039 UTF8SMTP. 1040 o assuming the "Cc:" recipient's MTA (example.org) supports 1041 UTF8SMTP. 1042 The example SMTP envelope/message is shown in Figure 1. In this 1043 example, the "To:" recipient's session is the focus. 1045 MAIL FROM: 1046 ALT-ADDRESS=ASCII-local@example.com 1047 RCPT TO: 1048 ALT-ADDRESS=ASCII-remote1@example.net 1049 RCPT TO: 1050 ------------------------------------------------------------- 1051 Message-Id: MESSAGE_ID 1052 Mime-Version: 1.0 1053 Content-Type: text/plain; charset="UTF-8" 1054 Content-Transfer-Encoding: 8bit 1055 Subject: NON-ASCII-SUBJECT 1056 From: DISPLAY-local > 1058 To: DISPLAY-remote1 > 1060 Cc: DISPLAY-remote2 1061 Date: DATE 1063 MAIL_BODY 1065 Figure 1: Original envelope/message (example 1) 1067 In this example, there are two SMTP recipients, one is "To:", the 1068 other is "Cc:". The SMTP downgrading treats To: session downgrading. 1069 Figure 2 shows SMTP downgraded example. 1071 MAIL FROM: 1072 RCPT TO: 1073 ------------------------------------------------------------- 1074 Downgraded-Mail-From: =?UTF-8?Q?>?= 1076 Downgraded-Rcpt-To: =?UTF-8?Q?>?= 1078 Message-Id: MESSAGE_ID 1079 Mime-Version: 1.0 1080 Content-Type: text/plain; charset="UTF-8" 1081 Content-Transfer-Encoding: 8bit 1082 Subject: NON-ASCII-SUBJECT 1083 From: DISPLAY-local > 1085 To: DISPLAY-remote1 > 1087 Cc: DISPLAY-remote2 1088 Date: DATE 1090 MAIL_BODY 1092 Figure 2: SMTP Downgraded envelope/message (example 1) 1094 After SMTP downgrading, header fields downgrading is performed. 1095 Final downgraded message is shown in Figure 3. Return-Path header 1096 field will be added by the final destination MTA. 1098 Return-Path: 1099 Downgraded-Mail-From: =?UTF-8?Q?>?= 1101 Downgraded-Rcpt-To: =?UTF-8?Q?>?= 1103 Message-Id: MESSAGE_ID 1104 Mime-Version: 1.0 1105 Content-Type: text/plain; charset="UTF-8" 1106 Content-Transfer-Encoding: 8bit 1107 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 1108 From: =?UTF-8?Q?DISPLAY-local?= 1109 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 1111 To: =?UTF-8?Q?DISPLAY-remote1?= 1112 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= 1113 =?UTF-8?Q?>?= 1114 Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 1115 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; 1116 Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= 1117 =?UTF-8?Q??= 1118 Date: DATE 1120 MAIL_BODY 1122 Figure 3: Downgraded message (example 1) 1124 A.2. Downgrading example 2 1126 In many cases, the sender wants to use non-ASCII address and the 1127 recipient is a traditional mail user. The SMTP server handing mail 1128 for the recipient and/or the recipient's MUA does not support 1129 UTF8SMTP extension. Consider a mail message where: 1130 o The sender address is "NON-ASCII-local@example.com" which is a 1131 non-ASCII address. Its ASCII alternative is 1132 "ASCII-local@example.com". It has a display-name "DISPLAY-local" 1133 which contains non-ASCII characters. 1134 o The "To:" address is "ASCII-remote1@example.net" which is ASCII 1135 only. It has a display-name "DISPLAY-remote1" which contains non- 1136 ASCII characters. 1137 o The "Subject:" header field is "NON-ASCII-SUBJECT" which contains 1138 non-ASCII characters. 1139 The second example envelope/message is shown in Figure 4. 1141 MAIL From: 1142 ALT-ADDRESS=ASCII-local@example.com 1143 RCPT TO: 1144 ------------------------------------------------------------- 1145 Message-Id: MESSAGE_ID 1146 Mime-Version: 1.0 1147 Content-Type: text/plain; charset="UTF-8" 1148 Content-Transfer-Encoding: 8bit 1149 Subject: NON-ASCII-SUBJECT 1150 From: DISPLAY-local > 1152 To: DISPLAY-remote1 1153 Date: DATE 1155 MAIL_BODY 1157 Figure 4: Original message (example 2) 1159 In this example, SMTP session is downgradable. Figure 5 shows SMTP 1160 downgraded envelope/message. 1162 MAIL From: 1163 RCPT TO: 1164 ------------------------------------------------------------- 1165 Downgraded-Mail-From: =?UTF-8?Q?>?= 1167 Message-Id: MESSAGE_ID 1168 Mime-Version: 1.0 1169 Content-Type: text/plain; charset="UTF-8" 1170 Content-Transfer-Encoding: 8bit 1171 Subject: NON-ASCII-SUBJECT 1172 From: DISPLAY-local > 1174 To: DISPLAY-remote1 1175 Date: DATE 1177 MAIL_BODY 1179 Figure 5: SMTP Downgraded envelope/message (example 2) 1181 After SMTP downgrading, header fields downgrading is performed. The 1182 downgraded example is shown in Figure 6. 1184 Return-Path: 1185 Downgraded-Mail-From: =?UTF-8?Q?>?= 1187 Message-Id: MESSAGE_ID 1188 Mime-Version: 1.0 1189 Content-Type: text/plain; charset="UTF-8" 1190 Content-Transfer-Encoding: 8bit 1191 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 1192 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 1194 From: =?UTF-8?Q?DISPLAY-local?= 1195 To: =?UTF-8?Q?DISPLAY-remote1?= 1196 Date: DATE 1198 MAIL_BODY 1200 Figure 6: Downgraded message (example 2) 1202 Authors' Addresses 1204 Kazunori Fujiwara (editor) 1205 Japan Registry Services Co., Ltd. 1206 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 1207 Chiyoda-ku, Tokyo 101-0065 1208 Japan 1210 Phone: +81 3 5215 8451 1211 Email: fujiwara@jprs.co.jp 1213 Yoshiro YONEYA (editor) 1214 Japan Registry Services Co., Ltd. 1215 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 1216 Chiyoda-ku, Tokyo 101-0065 1217 Japan 1219 Phone: +81 3 5215 8451 1220 Email: yone@jprs.co.jp