idnits 2.17.1 draft-ietf-eai-downgrade-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1120. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1131. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1138. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1144. 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 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 (Dec 11, 2008) is 5607 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 202, but not defined == Missing Reference: 'CFWS' is mentioned on line 203, 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) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 Dec 11, 2008 6 Expires: June 14, 2009 8 Downgrading mechanism for Email Address Internationalization 9 draft-ietf-eai-downgrade-10.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 14, 2009. 36 Abstract 38 Traditional mail systems handle only ASCII characters in SMTP 39 envelope and mail header fields. The Email Address 40 Internationalization (UTF8SMTP) extension allows UTF-8 characters in 41 SMTP envelope and mail header fields. To avoid rejecting 42 internationalized Email messages when a server in the delivery path 43 does not support the UTF8SMTP extension, some sort of converting 44 mechanism is required. This document describes a downgrading 45 mechanism for Email Address Internationalization. Note that this is 46 a way to downgrade, not tunnel. There is no associated up-conversion 47 mechanism, although internationalized email clients might use 48 original internationalized addresses or other data when displaying or 49 replying to downgraded messages. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. New header fields definition . . . . . . . . . . . . . . . . . 4 56 3.1. Envelope information preservation headers . . . . . . . . 5 57 3.2. Address header field preservation headers . . . . . . . . 5 58 3.3. Unknown header fields preservation headers . . . . . . . 6 59 4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Path element downgrading . . . . . . . . . . . . . . . . 7 61 4.2. ORCPT downgrading . . . . . . . . . . . . . . . . . . . . 7 62 5. Email header fields downgrading . . . . . . . . . . . . . . . 8 63 5.1. Downgrading method for each header field . . . . . . . . 10 64 6. MIME body part headers downgrading . . . . . . . . . . . . . . 12 65 7. Security considerations . . . . . . . . . . . . . . . . . . . 13 66 8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 14 67 8.1. RFC 2047 encoding . . . . . . . . . . . . . . . . . . . . 14 68 8.2. Trivial downgrading . . . . . . . . . . . . . . . . . . . 14 69 8.3. 7bit transport consideration . . . . . . . . . . . . . . 15 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 72 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 17 73 11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . 17 74 11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . 17 75 11.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . 17 76 11.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . 18 77 11.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . 18 78 11.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . 18 79 11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . 18 80 11.8. draft-ietf-eai-downgrade: Version 05 . . . . . . . . . . 18 81 11.9. draft-ietf-eai-downgrade: Version 06 . . . . . . . . . . 19 82 11.10. draft-ietf-eai-downgrade: Version 07 . . . . . . . . . . 19 83 11.11. draft-ietf-eai-downgrade: Version 08 . . . . . . . . . . 19 84 11.12. draft-ietf-eai-downgrade: Version 09 . . . . . . . . . . 19 85 11.13. draft-ietf-eai-downgrade: Version 10 . . . . . . . . . . 19 86 12. Normative References . . . . . . . . . . . . . . . . . . . . . 19 87 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 20 88 A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 20 89 A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 23 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 91 Intellectual Property and Copyright Statements . . . . . . . . . . 26 93 1. Introduction 95 Traditional mail systems which are defined by [RFC5321] and [RFC5322] 96 allow ASCII characters in SMTP envelope and mail header field values. 97 The UTF8SMTP extension [RFC4952], [RFC5335] and [RFC5336] allows 98 UTF-8 characters in SMTP envelope and mail header field values. 100 If an envelope address or header field contains non-ASCII characters, 101 the message cannot be delivered unless every system in the delivery 102 path supports UTF8SMTP. This document describes a downgrading 103 mechanism to avoid rejection of such messages when a server which 104 does not support the UTF8SMTP extension is encountered. Downgrading 105 mechanism converts envelope and header fields to an all-ASCII 106 representation. 108 [RFC5335] allows UTF-8 characters to be used in mail header fields 109 and MIME header fields. The downgrading mechanism specified here 110 converts mail header fields and MIME header fields to ASCII. 112 This document does not change any protocols except by defining new 113 header fields. It describes the conversion method from the 114 internationalized email envelopes/messages which are defined in 115 [RFC4952] [RFC5335] [RFC5336] to the traditional email envelopes/ 116 messages which are defined in [RFC5321] [RFC5322]. 118 [RFC5336] section 2.2 defines when downgrading occurs. If the SMTP 119 client has an UTF8SMTP envelope or an internationalized message and 120 the SMTP server doesn't support the UTF8SMTP SMTP extension, then the 121 SMTP client MUST NOT send a UTF8SMTP envelope or an internationalized 122 message to the SMTP server. The section shows 4 choices. The fourth 123 choice is downgrading, as described here. 125 Downgrading may be implemented in MUAs, MSAs, MTAs which act as the 126 SMTP client, or in MDAs, POP servers, IMAP servers which store or 127 offer UTF8SMTP envelopes or internationalized messages to non- 128 UTF8SMTP compliant systems which include message stores. 130 This document tries to define the downgrading process clearly and it 131 preserves the original information as much as possible. 133 Downgrading in UTF8SMTP consists of the following four parts: 134 o New header fields definition 135 o SMTP downgrading 136 o Email header fields downgrading 137 o MIME header fields downgrading 139 In Section 3, many header fields starting with "Downgraded-" are 140 introduced. They preserve the original envelope information and the 141 original header fields. 143 The SMTP downgrading is described in Section 4. It generates ASCII 144 only envelope information from an UTF8SMTP envelope. 146 The Email header fields downgrading is described in Section 5. It 147 generates ASCII only header fields. 149 The MIME header fields are expanded in [RFC5335]. The MIME header 150 fields downgrading is described in Section 6. It generates ASCII 151 only MIME header fields. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 All specialized terms used in this specification are defined in the 160 EAI overview [RFC4952] or in [RFC5321][RFC5322], MIME documents 161 [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address", 162 "internationalized email address", "non-ASCII address", "i18mail 163 address", "UTF8SMTP", "message" and "mailing list" are used with the 164 definitions from [RFC4952] document. 166 This document depends on [RFC5335], [RFC5336], and [RFC5337]. Key 167 words used in these document are used in this document, too. 169 The term "non-ASCII" is an UTF-8 string which contains at least one 170 non-ASCII character. 172 An "UTF8SMTP envelope" has Email originator/recipient addresses 173 expanded by [RFC5336] and [RFC5337]. 175 An "UTF8SMTP message" is Email messages expanded by [RFC5335]. 177 3. New header fields definition 179 New header fields starting with "Downgraded-" are defined here to 180 preserve those original envelope and header values which contain 181 UTF-8 characters. During downgrading, one new "Downgraded-" header 182 field is added for each original envelope or header field which 183 cannot be passed as-is to a server which does not support UTF8SMTP. 184 The original envelope or header field is removed or rewritten. Only 185 those envelope and header fields which contain non-ASCII characters 186 are affected. The result of this process is a message which is 187 compliant with existing email specifications [RFC5321] and [RFC5322]. 188 The original internationalized information can be retrieved by 189 examining the "Downgraded-" header fields which were added. Even 190 though the information is not lost, the original message cannot be 191 perfectly reconstructed. Hence, downgrading is a one-way process. 192 However, an internationalized client might use the information in the 193 "Downgraded-" header fields when processing a downgraded message, for 194 example, such as displaying or composing a reply. 196 3.1. Envelope information preservation headers 198 SMTP envelope downgraded information 199 consists of the original non-ASCII address and the downgraded all- 200 ASCII address. 202 downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox 203 FWS "<" Mailbox ">" ">" [CFWS] 205 is defined in [RFC5336]; and are defined 206 in [RFC5321], section 4.1.2. 208 Two headers "Downgraded-Mail-From:" and "Downgraded-Rcpt-To:" are 209 defined to preserve SMTP envelope downgraded information. The header 210 field syntax is specified as follows: 212 fields =/ downgradedmailfrom / downgradedrcptto 213 downgradedmailfrom = "Downgraded-Mail-From:" unstructured CRLF 214 downgradedrcptto = "Downgraded-Rcpt-To:" unstructured CRLF 216 The unstructured content is downgraded-envelope-addr treated as if it 217 were unstructured with [RFC2047] encoding (and charset UTF-8) as 218 needed. 220 3.2. Address header field preservation headers 222 The address header fields preservation headers are defined to 223 preserve the original header field. Their value field holds the 224 original header field value. The header field syntax is specified as 225 follows: 227 fields =/ known-downgraded-headers ":" unstructured CRLF 228 known-downgraded-headers = "Downgraded-" original-headers 229 original-headers = "From" / "To" / "Cc" / "Bcc" / 230 "Sender" / "Reply-To" / 231 "Resent-From" / "Resent-Sender" / 232 "Resent-To" / "Resent-Cc" / "Return-Path" 234 Preserving a header field in a downgraded header field is defined as: 235 1. Generate new downgraded header field whose value is the original 236 header field value. 237 2. Treat the generated header field content as if it were 238 unstructured, and then apply [RFC2047] encoding with charset 239 UTF-8 as necessary so the result is ASCII. 241 3.3. Unknown header fields preservation headers 243 The unknown header fields preservation headers are defined to 244 encapsulate those original header fields which contain non-ASCII 245 characters and are not otherwise provided for in the this 246 specification. The encapsulation header field name is the 247 concatenation of "Downgraded-" and the original name. The value 248 field holds the original header field value. 250 The header field syntax is specified as follows: 252 fields =/ unknown-downgraded-headers ":" unstructured CRLF 253 unknown-downgraded-headers = "Downgraded-" original-header-field-name 254 original-header-field-name = field-name 256 field-name = 1*ftext 258 ftext = %d33-57 / ; Any character except 259 %d59-126 ; controls, SP, and 260 ; ":". 262 Encapsulating a header field in a "Downgraded-" header field is 263 defined as: 264 1. Generate new "Downgraded-" header field whose value is the 265 original header field value. 266 2. Treat the generated header field content as if it were 267 unstructured, and then apply [RFC2047] encoding with charset 268 UTF-8 as necessary so the result is ASCII. 269 3. Remove the original header field. 271 Applying this procedure to "Received" header field is prohibited. 273 4. SMTP Downgrading 275 Target of downgrading elements in SMTP envelope are below: 277 o of MAIL FROM command 278 o of RCPT TO command 279 o ORCPT parameter of RCPT TO command 281 4.1. Path element downgrading 283 Downgrading the of MAIL FROM and RCPT TO commands uses ALT- 284 ADDRESS parameter defined in [RFC5336]. A SMTP command is 285 downgradable if the contains non-ASCII address and the command 286 has an ALT-ADDRESS parameter which specifies an ASCII address. Since 287 only non-ASCII addresses are downgradable, specifying an ALT-ADDRESS 288 value for an all-ASCII address is invalid for use with this 289 specification, and no interpretation is assigned to it. This 290 restriction allows for future extension of the specification even 291 though no such extensions are currently anticipated. 293 Note that even if no downgrading is performed on the envelope, 294 message header fields and message body MIME header fields that 295 contain non-ASCII characters MUST be downgraded. This is described 296 in Section 5 and Section 6. 298 When downgrading, replace each which contains non-ASCII mail 299 address with its specified alternative ASCII address and preserve the 300 original information using "Downgraded-Mail-From" and "Downgraded- 301 Rcpt-To" header fields as defined in Section 3. Before replacing, 302 decode the ALT-ADDRESS parameter value because it is encoded as xtext 303 [RFC3461]. 305 To avoid disclosing recipient addresses, the downgrading process MUST 306 NOT add "Downgraded-Rcpt-To:" header if the SMTP downgrading targets 307 multiple recipients. See Section 7 for more detail. 309 As a result of the recipient address downgrading, the domain part of 310 the recipient address prior to downgrading might be different from 311 the domain part of the new recipient address. If the result of 312 address resolution for the domain part of the new recipient address 313 contains the server at the connection destination of the SMTP session 314 for the recipient address prior to downgrading, the SMTP connection 315 is valid for the new recipient address. Otherwise, the downgrading 316 process MUST NOT send the downgraded message to the new recipient 317 address via the connection and MUST try to send the downgraded 318 message to the new recipient address. 320 4.2. ORCPT downgrading 322 The "RCPT TO" command can have an ORCPT parameter if the DSN 323 extension [RFC3461] is supported. If the ORCPT parameter contains an 324 "utf-8" type address and the address contains raw non-ASCII 325 characters, the address MUST be converted to utf-8-addr-unitext form 326 or utf-8-addr-xtext form which are described in [RFC5337]. 328 The utf-8-addr-unitext transformation that needs to occur on the 329 content of ORCPT is to 330 1. remove xtext encoding. 331 2. convert the result of step 1 to utf-8-addr-unitext form where all 332 non-ASCII characters and '\' are represented as 333 EmbeddedUnicodeChar. 334 3. re-apply xtext encoding to the result of step 2. 336 5. Email header fields downgrading 338 This section defines the conversion method to ASCII for each header 339 field which may contain non-ASCII characters. 341 [RFC5335] expands Received: header fields, [RFC5322] ABNF elements 342 , , , , [RFC2045] ABNF element 343 . 345 Header field downgrading is defined below for each ABNF element. 346 Downgrading an unknown header field is also defined as ENCAPSULATION 347 downgrading. Converting the header field terminates when no non- 348 ASCII characters remain in the header field. 350 RECEIVED downgrading: 351 If the header field name is "Received:" and the FOR clause 352 contains a non-ASCII addresses, remove the FOR clause from the 353 header field. Other parts (not counting s) don't contain 354 non-ASCII values. 356 UNSTRUCTURED downgrading: 357 If the header field has an field which contains 358 non-ASCII characters, apply [RFC2047] encoding with charset UTF-8. 360 WORD downgrading: 361 If the header field has any fields which contains non-ASCII 362 characters, apply [RFC2047] encoding with charset UTF-8. 364 COMMENT downgrading: 365 If the header field has any fields which contains non- 366 ASCII characters, apply [RFC2047] encoding with charset UTF-8. 368 MIME-VALUE downgrading: 369 If the header field has any elements defined by [RFC2045] 370 and the elements contain non-ASCII characters, encode the 371 elements by [RFC2231] with charset UTF-8 and the Language 372 information empty. If the element is and 373 it contains outside the DQUOTE, remove the before 374 this conversion. 376 DISPLAY-NAME downgrading: 377 If the header field has any
( and ) 378 elements and they have elements which contain non- 379 ASCII characters, encode the elements according to 380 [RFC2047] with charset UTF-8. DISPLAY-NAME downgrading is the 381 same algorithm as WORD downgrading. 383 MAILBOX downgrading: 384 The elements have no equivalent format for non-ASCII 385 addresses. If the header field has any elements which 386 contain non-ASCII characters, preserve the header field in each 387 Address header field preservation header defined in Section 3.2, 388 and rewrite each element to ASCII only format. The 389 element which contains non-ASCII characters is one of 390 three formats. 392 * [ Display-name ] "<" Utf8-addr-spec 1*FCS "<" Addr-spec ">>" 394 Rewrite it as 396 [ Display-name ] "<" Addr-spec ">" 398 * [ Display-name ] "<" Utf8-addr-spec ">" 399 * Utf8-addr-spec 401 Rewrite both as 402 [ Display-name ] "Internationalized Address " Encoded-word 403 " Removed:;" 405 where the is the original 406 encoded according to [RFC2047]. 408 ENCAPSULATION downgrading: 409 if the header field contains non-ASCII characters and for which no 410 rule is given above, encapsulate it in a Downgraded header field 411 described in Section 3.3 as a last resort. 413 TYPED-ADDRESS downgrading: 414 If the header field contains defined in 415 [RFC5337] and the contains raw non-ASCII 416 characters, it is utf-8-address form and convert it to utf-8-addr- 417 xtext form or utf-8-addr-unitext form. COMMENT downgrading is 418 also performed in this case. If the address type is unrecognized 419 and the header contains non-ASCII characters, then fall back to 420 using ENCAPSULATION downgrading on the entire header. 422 5.1. Downgrading method for each header field 424 Header fields are listed in [RFC4021]. This section describes the 425 downgrading method for each header field. 427 If the whole mail header field does not contain non-ASCII characters, 428 email header field downgrading is not required. Each header field's 429 downgrading method is described below. 431 o Address header fields which contain
s 433 From: 434 Sender: 435 Reply-To: 436 To: 437 Cc: 438 Bcc: 439 Resent-From: 440 Resent-Sender: 441 Resent-To: 442 Resent-Cc: 443 Resent-Bcc: 444 Resent-Reply-To: 445 Return-Path: 446 Disposition-Notification-To: 448 If the header field contains elements which contains 449 non-ASCII addresses, preserve the header field in a downgraded 450 header before the conversion. Then perform COMMENT downgrading, 451 DISPLAY-NAME downgrading and MAILBOX downgrading. 453 o Address header fields with typed addresses 455 Original-Recipient: 457 Final-Recipient: 459 If the header field contains non-ASCII characters, perform TYPED- 460 ADDRESS downgrading. 462 o Downgrading Non-ASCII in comments 464 Date: 465 Message-ID: 466 Resent-Message-ID: 467 In-Reply-To: 468 References: 469 Resent-Date: 470 Resent-Message-ID: 471 MIME-Version: 472 Content-ID: 473 Content-Transfer-Encoding: 474 Content-Language: 475 Accept-Language: 476 Auto-Submitted: 478 These header fields do not contain non-ASCII characters except in 479 comments. If the header contains UTF-8 characters in comments, 480 perform COMMENT downgrading. 482 o Received header field 484 Received: 486 perform COMMENT downgrading and RECEIVED downgrading. 488 o MIME Content header fields 490 Content-Type: 491 Content-Disposition: 493 Perform MIME-VALUE downgrading and COMMENT downgrading. 495 o Non-ASCII in 497 Subject: 498 Comments: 499 Content-Description: 501 Perform UNSTRUCTURED downgrading. 503 o Non-ASCII in 505 Keywords: 507 Perform WORD downgrading. 509 o Other header fields 511 All other header fields which contains non-ASCII characters are 512 user-defined, missing from this draft or future defined header 513 fields. Perform ENCAPSULATION downgrading. 515 If the software understands the header's structure and a 516 downgrading algorithm other than ENCAPSULATION is applicable, that 517 software SHOULD use that algorithm; ENCAPSULATION downgrading is 518 used as a last resort. 520 Any List-* header field containing non-ASCII characters will be 521 turned into Downgraded-List-* header fields. 523 6. MIME body part headers downgrading 525 MIME body part header fields may contain non-ASCII characters 526 [RFC5335]. This section defines the conversion method to ASCII only 527 header fields for each MIME header field which contains non-ASCII 528 characters. Parse the message body's MIME structure for all levels 529 and check each MIME header field whether it contains non-ASCII 530 characters. If the header field contains non-ASCII characters in the 531 header value, the header is a target of the MIME body part headers 532 downgrading. Each MIME header field's downgrading method is 533 described below. COMMENT downgrading, MIME-VALUE downgrading, 534 UNSTRUCTURED downgrading are described in Section 5. 536 Content-ID: 537 The Content-ID: header does not contain non-ASCII characters 538 except in comments. If the header contains UTF-8 characters in 539 comments, perform COMMENT downgrading. 541 Content-Type: 542 Content-Disposition: 543 Perform MIME-VALUE downgrading and COMMENT downgrading. 545 Content-Description: 546 Perform UNSTRUCTURED downgrading. 548 7. Security considerations 550 o A Downgraded message's header fields contain ASCII characters 551 only. But they still contain MIME encapsulated header fields 552 which contains non-ASCII UTF-8 characters. Furthermore, the body 553 part may contain UTF-8 characters. Implementations parsing 554 Internet messages need to accept UTF-8 body parts and UTF-8 header 555 fields which are MIME encoded. Thus it inherits the security 556 considerations of MIME encoded headers [RFC2047] and [RFC3629]. 557 o Rewriting headers increases the opportunities for undetected 558 spoofing. However rewritten header fields are preserved into 559 Downgraded-* header fields and parsing Downgraded-* header fields 560 enables detecting spoofing caused by downgrading. 562 o Addresses that do not appear in the message headers may appear in 563 the RCPT commands to an SMTP server for a number of reasons. 564 Copying information from the Envelope into headers risks 565 inadvertent information disclosure (see [RFC5321] and Section 4). 566 Mitigating inadvertent information disclosure is discussed in same 567 place. 569 o The techniques described here invalidates methods that depend on 570 digital signatures over the envelope or any part of the message 571 which includes the top-level header or body part headers. 572 Depending on the specific message being downgraded, DKIM 573 especially, but also possibly S/MIME, PGP, and similar techniques 574 are all likely to break. The two obvious mitigations are to stick 575 to 7-bit transport when using these techniques (as most/all of 576 them presently require), or make sure you have UTF8SMTP end-to-end 577 when needed. 579 o Many gateways and servers on the Internet will discard headers 580 with which they are not familiar. To the extent to which the 581 downgrade procedures depend on new headers (e.g., "Downgraded-") 582 to avoid information loss, the risk of having those headers 583 dropped and its implications must be identified. In particular, 584 if the Downgraded headers are dropped, there is no possibility of 585 reconstructing the original information at any point (before, 586 during, or after delivery). Such gateways violate [RFC2979] and 587 can be upgraded to correct the problem. 589 See "Security considerations" section in [RFC4952] for more 590 discussion. 592 8. Implementation notes 594 8.1. RFC 2047 encoding 596 While [RFC2047] has a specific algorithm to deal with whitespace in 597 adjacent encoded-words, there are a number of deployed 598 implementations that fail to implement the algorithm correctly. As a 599 result, whitespace behavior is somewhat unpredictable in practice 600 when multiple encoded words are used. While RFC 5322 states that 601 implementations SHOULD limit lines to not more than 78 characters, 602 implementations MAY choose to allow overlong encoded words in order 603 to work around faulty [RFC2047] implementations. Implementations 604 that choose to do so SHOULD have an optional mechanism to limit line 605 length to 78 characters. 607 8.2. Trivial downgrading 609 Downgrading is an alternative to avoid the rejection of messages 610 which require UTF8SMTP support by a server which does not provide 611 this. Implementing the full specification of this document is 612 desirable, but a partial implementation is also possible. 614 If a partial downgrading implementation confronts an unsupported 615 downgrading target, the implementation MUST NOT send the message to a 616 server which does not support UTF8SMTP. Instead, it MUST reject the 617 message or generate a notification of non-deliverability. 619 A partial downgrading, Trivial downgrading is discussed. It does not 620 support non-ASCII addresses in SMTP envelope and address header 621 fields, unknown header fields downgrading, the MIME body part headers 622 downgrading. It supports 623 o some simple header fields downgrading: Subject 624 o comments and display name downgrading: From, To, Cc 625 o trace header field downgrading: Received 627 Otherwise, the downgrading fails. 629 Trivial downgrading targets mail messages which are generated by 630 UTF8SMTP aware MUAs and contain non-ASCII characters in comments, 631 display names, unstructured parts without using non-ASCII E-mail 632 addresses. This mail message does not contain non-ASCII E-mail 633 addresses in the SMTP Envelope and its header fields. But it is not 634 deliverable via a UTF8SMTP un-aware SMTP server. Implementing full 635 specification downgrading may be hard, but trivial downgrading saves 636 mail messages without using non-ASCII addresses. 638 8.3. 7bit transport consideration 640 The SMTP client may encounter a SMTP server which does not support 641 the 8BITMIME SMTP extension [RFC1652]. The server does not support 642 "8bit" or "binary" data. Implementers need to consider converting 643 "8bit" data to "base64" or "quoted-printable" encoded form and adjust 644 the "Content-Transfer-Encoding" header field accordingly. If the 645 body contains multiple MIME parts, this conversion MUST be performed 646 for each MIME part. 648 9. IANA Considerations 650 IANA is requested to register the following header fields in the 651 Permanent Message Header Field Repository, in accordance with the 652 procedures set out in [RFC3864]. 654 Header field name: Downgraded-Mail-From 655 Applicable protocol: mail 656 Status: experimental 657 Author/change controller: IETF 658 Specification document(s): This document (Section 3) 660 Header field name: Downgraded-Rcpt-To 661 Applicable protocol: mail 662 Status: experimental 663 Author/change controller: IETF 664 Specification document(s): This document (Section 3) 666 Header field name: Downgraded-From 667 Applicable protocol: mail 668 Status: experimental 669 Author/change controller: IETF 670 Specification document(s): This document (Section 3) 672 Header field name: Downgraded-Sender 673 Applicable protocol: mail 674 Status: experimental 675 Author/change controller: IETF 676 Specification document(s): This document (Section 3) 678 Header field name: Downgraded-To 679 Applicable protocol: mail 680 Status: experimental 681 Author/change controller: IETF 682 Specification document(s): This document (Section 3) 684 Header field name: Downgraded-Cc 685 Applicable protocol: mail 686 Status: experimental 687 Author/change controller: IETF 688 Specification document(s): This document (Section 3) 690 Header field name: Downgraded-Reply-To 691 Applicable protocol: mail 692 Status: experimental 693 Author/change controller: IETF 694 Specification document(s): This document (Section 3) 696 Header field name: Downgraded-Bcc 697 Applicable protocol: mail 698 Status: experimental 699 Author/change controller: IETF 700 Specification document(s): This document (Section 3) 702 Header field name: Downgraded-Resent-From 703 Applicable protocol: mail 704 Status: experimental 705 Author/change controller: IETF 706 Specification document(s): This document (Section 3) 708 Header field name: Downgraded-Resent-To 709 Applicable protocol: mail 710 Status: experimental 711 Author/change controller: IETF 712 Specification document(s): This document (Section 3) 714 Header field name: Downgraded-Resent-Cc 715 Applicable protocol: mail 716 Status: experimental 717 Author/change controller: IETF 718 Specification document(s): This document (Section 3) 720 Header field name: Downgraded-Resent-Sender 721 Applicable protocol: mail 722 Status: experimental 723 Author/change controller: IETF 724 Specification document(s): This document (Section 3) 725 Header field name: Downgraded-Return-Path 726 Applicable protocol: mail 727 Status: experimental 728 Author/change controller: IETF 729 Specification document(s): This document (Section 3) 731 Furthermore, IANA is requested to refuse registration of all the 732 field names that start with "Downgraded-" for unknown header fields 733 downgrading described in Section 3.3 to avoid conflicts with existing 734 IETF activity (Email Address Internationalization). 736 10. Acknowledgements 738 Significant comments and suggestions were received from John Klensin, 739 Harald Alvestrand, Chris Newman, Randall Gellens, Charles Lindsey, 740 Marcos Sanz, Alexey Melnikov, Frank Ellermann, Edward Lewis, S. 741 Moonesamy and JET members. 743 11. Change History 745 This section is used for tracking the update of this document. Will 746 be removed after finalize. 748 11.1. draft-yoneya-ima-downgrade: Version 00 750 o Initial version 751 o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00 753 11.2. draft-yoneya-ima-downgrade: Version 01 755 o Document structure was changed 756 o Followed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02 757 o Downgrading requirements were added 758 o SMTP DATA encapsulation method was proposed 759 o Downgrading examples was provided 761 11.3. draft-ietf-eai-downgrade: Version 00 763 o Followed draft-yeh-ima-utf8headers-01 and 764 draft-ietf-eai-smtpext-00 765 o No header downgrading method was proposed 766 o Header encapsulation method was proposed 768 11.4. draft-ietf-eai-downgrade: Version 01 770 o Followed draft-ietf-eai-utf8headers-00 771 o Header conversion and encapsulation method was merged 772 o Header conversion method was defined in detail 774 11.5. draft-ietf-eai-downgrade: Version 02 776 o Followed draft-ietf-eai-utf8headers-01 and 777 draft-ietf-eai-smtpext-01 778 o Specification about algorithmic generated address is removed 779 o No header downgrading method was removed 780 o SMTP DATA encapsulation method was removed 782 11.6. draft-ietf-eai-downgrade: Version 03 784 o Followed draft-ietf-eai-utf8headers-03 and 785 draft-ietf-eai-smtpext-03 786 o Downgraded: and Envelope-Downgraded: headers definition was added 787 o Mail header fields downgrading method was refined 788 o Examples in Appendix A were refined 790 11.7. draft-ietf-eai-downgrade: Version 04 792 o Followed draft-ietf-eai-utf8headers-06, draft-ietf-eai-smtpext-07 793 and draft-ietf-eai-dsn-02 794 o Downgrading requirements and conditions were moved to 795 Introduction. 796 o Descriptions about upgrading were removed. 797 o SPF and DKIM discussion were removed. 798 o Added many header fields downgrading. 799 o Allow address literal rewriting without alternate ASCII address in 800 header fields. 801 o Added MIME body part headers downgrading. 802 o Added ORCPT downgrading. 804 11.8. draft-ietf-eai-downgrade: Version 05 806 o fixed examples 807 * ALT-ADDRESS parameter mistake 808 * RFC2047(x) notation was changed to encoded-word format 809 o Added implementation consideration section and trivial downgrading 810 o Downgraded: and Envelope-Downgraded: headers are separated for 811 each original headers. 812 o Removed list-* header fields downgrading 813 o Changed the way of writing the header field downgrading section 815 11.9. draft-ietf-eai-downgrade: Version 06 817 o Moved decoding downgraded messages as a separate document 818 o Added a text to UNSTRUCTURED downgrading 819 o Added "replacing SMTP connection" if necessary to SMTP 820 downgrading. 821 o fixed examples 823 11.10. draft-ietf-eai-downgrade: Version 07 825 o Fixed some typos 826 o Added a text about 7bit transport 828 11.11. draft-ietf-eai-downgrade: Version 08 830 o Comments from the working group last call (wording) 832 11.12. draft-ietf-eai-downgrade: Version 09 834 o References 836 11.13. draft-ietf-eai-downgrade: Version 10 838 o Comments from AD Review 840 12. Normative References 842 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 843 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 844 RFC 1652, July 1994. 846 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 847 Extensions (MIME) Part One: Format of Internet Message 848 Bodies", RFC 2045, November 1996. 850 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 851 Part Three: Message Header Extensions for Non-ASCII Text", 852 RFC 2047, November 1996. 854 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 855 Requirement Levels", BCP 14, RFC 2119, March 1997. 857 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 858 Presentation Information in Internet Messages: The 859 Content-Disposition Header Field", RFC 2183, August 1997. 861 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 862 Word Extensions: 863 Character Sets, Languages, and Continuations", RFC 2231, 864 November 1997. 866 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 867 Firewalls", RFC 2979, October 2000. 869 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 870 Extension for Delivery Status Notifications (DSNs)", 871 RFC 3461, January 2003. 873 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 874 10646", STD 63, RFC 3629, November 2003. 876 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 877 Procedures for Message Header Fields", BCP 90, RFC 3864, 878 September 2004. 880 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 881 Header Fields", RFC 4021, March 2005. 883 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 884 Internationalized Email", RFC 4952, July 2007. 886 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 887 October 2008. 889 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 890 October 2008. 892 [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, 893 September 2008. 895 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 896 Email Addresses", RFC 5336, September 2008. 898 [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery 899 Status and Disposition Notifications", RFC 5337, 900 September 2008. 902 Appendix A. Examples 904 A.1. Downgrading example 1 906 This section shows an SMTP Downgrading example. Consider a mail 907 message where: 909 o The sender address is "NON-ASCII-local@example.com" which is a 910 non-ASCII address. Its ASCII alternative is 911 "ASCII-local@example.com" and its display-name is "DISPLAY-local". 912 o The "To:" address is "NON-ASCII-remote1@example.net" which is a 913 non-ASCII address. Its ASCII alternative is 914 "ASCII-remote1@example.net" and its display-name is "DISPLAY- 915 remote1". 916 o The "Cc:" address is a non-ASCII address 917 "NON-ASCII-remote2@example.org" without alternative ASCII address. 918 Its display-name is "DISPLAY-remote2". 919 o Three display-names contain non-ASCII characters. 920 o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII 921 characters. 922 o Assuming the "To:" recipient's MTA (example.net) does not support 923 UTF8SMTP. 924 o assuming the "Cc:" recipient's MTA (example.org) supports 925 UTF8SMTP. 926 The example SMTP envelope/message is shown in Figure 1. In this 927 example, the "To:" recipient's session is the focus. 929 MAIL FROM: 930 ALT-ADDRESS=ASCII-local@example.com 931 RCPT TO: 932 ALT-ADDRESS=ASCII-remote1@example.net 933 RCPT TO: 934 ------------------------------------------------------------- 935 Message-Id: MESSAGE_ID 936 Mime-Version: 1.0 937 Content-Type: text/plain; charset="UTF-8" 938 Content-Transfer-Encoding: 8bit 939 Subject: NON-ASCII-SUBJECT 940 From: DISPLAY-local > 942 To: DISPLAY-remote1 > 944 Cc: DISPLAY-remote2 945 Date: DATE 947 MAIL_BODY 949 Figure 1: Original envelope/message (example 1) 951 In this example, there are two SMTP recipients, one is "To:", the 952 other is "Cc:". The SMTP downgrading treats To: session downgrading. 953 Figure 2 shows SMTP downgraded example. 955 MAIL FROM: 956 RCPT TO: 957 ------------------------------------------------------------- 958 Downgraded-Mail-From: =?UTF-8?Q?>?= 960 Downgraded-Rcpt-To: =?UTF-8?Q?>?= 962 Message-Id: MESSAGE_ID 963 Mime-Version: 1.0 964 Content-Type: text/plain; charset="UTF-8" 965 Content-Transfer-Encoding: 8bit 966 Subject: NON-ASCII-SUBJECT 967 From: DISPLAY-local > 969 To: DISPLAY-remote1 > 971 Cc: DISPLAY-remote2 972 Date: DATE 974 MAIL_BODY 976 Figure 2: SMTP Downgraded envelope/message (example 1) 978 After SMTP downgrading, header fields downgrading is performed. 979 Final downgraded message is shown in Figure 3. Return-Path header 980 will be added by the final destination MTA. 982 Return-Path: 983 Downgraded-Mail-From: =?UTF-8?Q?>?= 985 Downgraded-Rcpt-To: =?UTF-8?Q?>?= 987 Message-Id: MESSAGE_ID 988 Mime-Version: 1.0 989 Content-Type: text/plain; charset="UTF-8" 990 Content-Transfer-Encoding: 8bit 991 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 992 From: =?UTF-8?Q?DISPLAY-local?= 993 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 995 To: =?UTF-8?Q?DISPLAY-remote1?= 996 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= 997 =?UTF-8?Q?>?= 998 Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 999 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; 1000 Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= 1001 =?UTF-8?Q??= 1002 Date: DATE 1004 MAIL_BODY 1006 Figure 3: Downgraded message (example 1) 1008 A.2. Downgrading example 2 1010 In many cases, the sender wants to use non-ASCII address and the 1011 recipient is a traditional mail user. The SMTP server handing mail 1012 for the recipient and/or the recipient's MUA does not support 1013 UTF8SMTP extension. Consider a mail message where: 1014 o The sender address is "NON-ASCII-local@example.com" which is a 1015 non-ASCII address. Its ASCII alternative is 1016 "ASCII-local@example.com". It has a display-name "DISPLAY-local" 1017 which contains non-ASCII characters. 1018 o The "To:" address is "ASCII-remote1@example.net" which is ASCII 1019 only. It has a display-name "DISPLAY-remote1" which contains non- 1020 ASCII characters. 1021 o The "Subject:" header is "NON-ASCII-SUBJECT" which contains non- 1022 ASCII characters. 1023 The second example envelope/message is shown in Figure 4. 1025 MAIL From: 1026 ALT-ADDRESS=ASCII-local@example.com 1027 RCPT TO: 1028 ------------------------------------------------------------- 1029 Message-Id: MESSAGE_ID 1030 Mime-Version: 1.0 1031 Content-Type: text/plain; charset="UTF-8" 1032 Content-Transfer-Encoding: 8bit 1033 Subject: NON-ASCII-SUBJECT 1034 From: DISPLAY-local > 1036 To: DISPLAY-remote1 1037 Date: DATE 1039 MAIL_BODY 1041 Figure 4: Original message (example 2) 1043 In this example, SMTP session is downgradable. Figure 5 shows SMTP 1044 downgraded envelope/message. 1046 MAIL From: 1047 RCPT TO: 1048 ------------------------------------------------------------- 1049 Downgraded-Mail-From: =?UTF-8?Q?>?= 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 1059 Date: DATE 1061 MAIL_BODY 1063 Figure 5: SMTP Downgraded envelope/message (example 2) 1065 After SMTP downgrading, header fields downgrading is performed. The 1066 downgraded example is shown in Figure 6. 1068 Return-Path: 1069 Downgraded-Mail-From: =?UTF-8?Q?>?= 1071 Message-Id: MESSAGE_ID 1072 Mime-Version: 1.0 1073 Content-Type: text/plain; charset="UTF-8" 1074 Content-Transfer-Encoding: 8bit 1075 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 1076 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 1078 From: =?UTF-8?Q?DISPLAY-local?= 1079 To: =?UTF-8?Q?DISPLAY-remote1?= 1080 Date: DATE 1082 MAIL_BODY 1084 Figure 6: Downgraded message (example 2) 1086 Authors' Addresses 1088 Kazunori Fujiwara (editor) 1089 JPRS 1090 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 1091 Chiyoda-ku, Tokyo 101-0065 1092 Japan 1094 Phone: +81 3 5215 8451 1095 Email: fujiwara@jprs.co.jp 1097 Yoshiro YONEYA (editor) 1098 JPRS 1099 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 1100 Chiyoda-ku, Tokyo 101-0065 1101 Japan 1103 Phone: +81 3 5215 8451 1104 Email: yone@jprs.co.jp 1106 Full Copyright Statement 1108 Copyright (C) The IETF Trust (2008). 1110 This document is subject to the rights, licenses and restrictions 1111 contained in BCP 78, and except as set forth therein, the authors 1112 retain all their rights. 1114 This document and the information contained herein are provided on an 1115 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1116 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1117 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1118 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1119 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1120 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1122 Intellectual Property 1124 The IETF takes no position regarding the validity or scope of any 1125 Intellectual Property Rights or other rights that might be claimed to 1126 pertain to the implementation or use of the technology described in 1127 this document or the extent to which any license under such rights 1128 might or might not be available; nor does it represent that it has 1129 made any independent effort to identify any such rights. Information 1130 on the procedures with respect to rights in RFC documents can be 1131 found in BCP 78 and BCP 79. 1133 Copies of IPR disclosures made to the IETF Secretariat and any 1134 assurances of licenses to be made available, or the result of an 1135 attempt made to obtain a general license or permission for the use of 1136 such proprietary rights by implementers or users of this 1137 specification can be obtained from the IETF on-line IPR repository at 1138 http://www.ietf.org/ipr. 1140 The IETF invites any interested party to bring to its attention any 1141 copyrights, patents or patent applications, or other proprietary 1142 rights that may cover technology that may be required to implement 1143 this standard. Please address the information to the IETF at 1144 ietf-ipr@ietf.org.