idnits 2.17.1 draft-ietf-eai-downgrade-07.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 1040. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1051. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1058. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1064. 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 (March 13, 2008) is 5859 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 211, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-11 == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-09 ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530) Summary: 5 errors (**), 0 flaws (~~), 4 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 March 13, 2008 6 Expires: September 14, 2008 8 Downgrading mechanism for Email Address Internationalization 9 draft-ietf-eai-downgrade-07.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 September 14, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Traditional mail systems handle only ASCII characters in SMTP 43 envelope and mail header fields. The Email Address 44 Internationalization (UTF8SMTP) extension allows UTF-8 characters in 45 SMTP envelope and mail header fields. To avoid bouncing 46 internationalized Email messages when a server in the delivery path 47 does not support the UTF8SMTP extension, some sort of converting 48 mechanism is required. This document describes a downgrading 49 mechanism for Email Address Internationalization. Note that this is 50 a way to downgrade, not tunnel. There is no associated up-conversion 51 mechanism, although internationalized email clients might use 52 original internationalized addresses or other data when displaying or 53 replying to downgraded messages. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. New header fields definition . . . . . . . . . . . . . . . . . 5 60 3.1. Envelope information preservation headers . . . . . . . . 5 61 3.2. Address header field preservation headers . . . . . . . . 5 62 3.3. Unknown header fields preservation headers . . . . . . . 6 63 4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Email header fields downgrading . . . . . . . . . . . . . . . 8 65 5.1. Downgrading method for each header field . . . . . . . . 9 66 6. MIME body part headers downgrading . . . . . . . . . . . . . . 11 67 7. Security considerations . . . . . . . . . . . . . . . . . . . 12 68 8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 12 69 8.1. Trivial downgrading . . . . . . . . . . . . . . . . . . . 12 70 8.2. 7bit transport consideration . . . . . . . . . . . . . . 13 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 73 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16 74 11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . 16 75 11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . 16 76 11.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . 16 77 11.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . 16 78 11.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . 16 79 11.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . 16 80 11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . 17 81 11.8. draft-ietf-eai-downgrade: Version 05 . . . . . . . . . . 17 82 11.9. draft-ietf-eai-downgrade: Version 06 . . . . . . . . . . 17 83 11.10. draft-ietf-eai-downgrade: Version 07 . . . . . . . . . . 17 84 12. Normative References . . . . . . . . . . . . . . . . . . . . . 17 85 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 86 A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 19 87 A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 89 Intellectual Property and Copyright Statements . . . . . . . . . . 25 91 1. Introduction 93 Traditional mail systems which are defined by [RFC2821] and [RFC2822] 94 allow ASCII characters in SMTP envelope and mail header field values. 95 The UTF8SMTP extension [RFC4952], [I-D.ietf-eai-utf8headers] and 96 [I-D.ietf-eai-smtpext] allows UTF-8 characters in SMTP envelope and 97 mail header field values. 99 If an envelope address or header field contains non-ASCII characters, 100 the message cannot be delivered unless every system in the delivery 101 path supports UTF8SMTP. To avoid bouncing such messages when a 102 server is encountered which does not support the UTF8SMTP extension, 103 this document describes a downgrading mechanism. Downgrading a 104 message converts envelope and header fields to an all-ASCII 105 representation. 107 [I-D.ietf-eai-utf8headers] allows UTF-8 characters to be used in mail 108 header fields and MIME header fields. The downgrading mechanism 109 specified here converts mail header fields and MIME header fields to 110 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] [I-D.ietf-eai-utf8headers] [I-D.ietf-eai-smtpext] to the 116 traditional email envelopes/messages which are defined in [RFC2821] 117 [RFC2822]. 119 [I-D.ietf-eai-smtpext] section 2.2 defines when downgrading occurs. 120 If the SMTP client has an UTF8SMTP envelope or an internationalized 121 message and the SMTP server doesn't support the UTF8SMTP SMTP 122 extension, then the SMTP client MUST NOT send a UTF8SMTP envelope or 123 an internationalized message to the SMTP server. The section shows 4 124 choices. The fourth choice is downgrading, as described here. 126 Downgrading may be implemented in MUAs, MSAs, MTAs which act as the 127 SMTP client, or in MDAs, POP servers, IMAP servers which store or 128 offer UTF8SMTP envelopes or internationalized messages to non- 129 UTF8SMTP compliant systems which include message stores. 131 This document tries to define the downgrading process clearly and it 132 preserves the original information as much as possible. 134 Downgrading in UTF8SMTP consists of the following four parts: 135 o New header fields definition 136 o SMTP downgrading 137 o Email header fields downgrading 138 o MIME header fields downgrading 140 In Section 3, many header fields starting with "downgraded" are 141 introduced. They preserve the original envelope information and the 142 original header fields. 144 The SMTP downgrading is described in Section 4. It generates ASCII 145 only envelope information from an UTF8SMTP envelope. 147 The Email header fields downgrading is described in Section 5. It 148 generates ASCII only header fields. 150 The MIME header fields are expanded in [I-D.ietf-eai-utf8headers]. 151 The MIME header fields downgrading is described in Section 6. It 152 generates ASCII only MIME header fields. 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 All specialized terms used in this specification are defined in the 161 EAI overview [RFC4952] or in [RFC2821][RFC2822], MIME documents 162 [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address", 163 "internationalized email address", "non-ASCII address", "i18mail 164 address", "UTF8SMTP", "message" and "mailing list" are used with the 165 definitions from [RFC4952] document. 167 This document depends on [I-D.ietf-eai-smtpext], 168 [I-D.ietf-eai-utf8headers], and [I-D.ietf-eai-dsn]. Key words used 169 in these document are used in this document, too. 171 The term "non-ASCII" is an UTF-8 string which contains at least one 172 non-ASCII character. 174 An "UTF8SMTP envelope" has Email originator/recipient addresses 175 expanded by [I-D.ietf-eai-smtpext] and [I-D.ietf-eai-dsn]. 177 An "UTF8SMTP message" is Email messages expanded by 178 [I-D.ietf-eai-utf8headers]. 180 3. New header fields definition 182 New header fields starting with "Downgraded-" are defined here to 183 preserve those original envelope and header values which contain 184 UTF-8 characters. During downgrading, one new "Downgraded-" header 185 field is added for each original envelope or header field which 186 cannot be passed as-is to a server which does not support UTF8SMTP. 187 The original envelope or header field is removed or rewritten. Only 188 those envelope and header fields which contain non-ASCII characters 189 are affected. The result of this process is a message which is 190 compliant with existing email specifications [RFC2821] and [RFC2822]. 191 The original internationalized information can be retrieved by 192 examining the "Downgraded-" header fields which were added. Even 193 though the information is not lost, the original message cannot be 194 perfectly reconstructed. Hence, downgrading is a one-way process. 195 However, an internationalized client might use the information in the 196 "Downgraded-" header fields when processing a downgraded message, for 197 example, such as displaying or composing a reply. 199 3.1. Envelope information preservation headers 201 Two headers "Downgraded-Mail-From:" and "Downgraded-Rcpt-To:" are 202 defined to preserve SMTP envelope downgraded information. SMTP 203 envelope downgraded information consists of the original non-ASCII 204 address and the downgraded all-ASCII address. The header field 205 syntax is specified as follows: 207 fields =/ downgradedmailfrom / downgradedrcptto 208 downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">" 1*[FWS] 209 "<" Mailbox ">" [FWS] CRLF 210 downgradedrcptto = "Downgraded-Rcpt-To:" [FWS] "<" uPath ">" 1*[FWS] 211 "<" Mailbox ">" [FWS] CRLF 213 Original non-ASCII address is defined in 214 [I-D.ietf-eai-smtpext]; it is treated as unstructured in this header 215 and it is encoded according to [RFC2047]. is defined in 216 [RFC2821], section 4.1.2. 218 3.2. Address header field preservation headers 220 The address header fields preservation headers are defined to 221 preserve the original header field. Their value field holds the 222 original header field value. Any original header field value is 223 treated as an and it MUST be encoded according to 224 [RFC2047] with charset='UTF-8'. The header field syntax is specified 225 as follows: 227 fields =/ known-downgraded-headers ":" unstructued 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. Encode the generated header according to [RFC2047] with 238 charset='UTF-8'. 240 3.3. Unknown header fields preservation headers 242 The unknown header fields preservation headers are defined to 243 encapsulate those original header field which contains non-ASCII 244 characters and are not otherwise provided for in the this 245 specification. The encapsulation header field name is the 246 concatenation of "Downgraded-" and the original name. The value 247 field holds the original header field value. 249 Any original header field value is treated as an unstructured value 250 and it MUST be encoded according to [RFC2047] with charset='UTF-8'. 251 The header field syntax is specified as follows: 253 fields =/ unknown-downgraded-headers ":" unstructued CRLF 254 unknown-downgraded-headers = "Downgraded-" original-header-field-name 255 original-header-field-name = field-name 257 field-name = 1*ftext 259 ftext = %d33-57 / ; Any character except 260 %d59-126 ; controls, SP, and 261 ; ":". 263 Encapsulating a header field in a "Downgraded-" header field is 264 defined as: 265 1. Generate new "Downgraded-" header whose value is the original 266 header field value. 267 2. Encode the generated header field value according to [RFC2047] 268 with charset='UTF-8'. To preserve space characters, the whole 269 header field value which include space characters SHOULD be 270 encoded. 272 3. Remove the original header field. 274 4. SMTP Downgrading 276 Target of downgrading elements in SMTP envelope are below: 278 o MAIL FROM: 279 o RCPT TO: 280 o ORCPT parameter 282 Downgrading the SMTP envelope uses ALT-ADDRESS parameter defined in 283 [I-D.ietf-eai-smtpext]. An address is downgradable if the address is 284 non-ASCII address and has ASCII address specified by ALT-ADDRESS 285 parameter. Since only non-ASCII addresses are downgradable, 286 specifying an ALT-ADDRESS value for an all-ASCII address is invalid 287 for use with this specification, and no interpretation is assigned to 288 it. This restriction allows for future extension of the 289 specification even though no such extensions are currently 290 anticipated. 292 Note that even if no downgrading is performed on the envelope, 293 message header fields and message body MIME header fields that 294 contain non-ASCII characters MUST be downgraded. This is described 295 in Section 5 and Section 6. 297 When downgrading, replace each non-ASCII mail address in the envelope 298 with its specified alternative ASCII address and preserve the 299 original information using "Downgraded-Mail-From" and "Downgraded- 300 Rcpt-To" header fields as defined in Section 3. Before replacing, 301 decode the ALT-ADDRESS parameter value because it is encoded as xtext 302 [RFC3461]. 304 To avoid disclosing recipient addresses, the downgrading process MUST 305 NOT add "Downgraded-Rcpt-To:" header if the SMTP downgrading targets 306 multiple recipients. See Section 7 for more detail. 308 The "RCPT TO" command may have an ORCPT parameter when the recipient 309 address is downgraded. The ORCPT parameter is used for DSN 310 [RFC3461]. If the ORCPT parameter contains an "utf-8" address and 311 the address contains non-ASCII characters, the ORCPT parameter MUST 312 be converted to utf-8-addr-xtext form or utf-8-addr-unitext form 313 which are described in [I-D.ietf-eai-dsn]. 315 As a result of the recipient address replacement, the domain part of 316 the original recipient address may not equal to the domain part of 317 the new recipient address. If the result of address resolution for 318 the domain part of the new recipient address contains the server at 319 the connection destination of the SMTP session for the original 320 recipient address, the SMTP connection is valid for the new recipient 321 address. Otherwise, the downgrading process MUST NOT send the 322 downgraded message to the new recipient address via the connection 323 and MUST try to send the downgraded message to the new recipient 324 address. 326 5. Email header fields downgrading 328 This section defines the conversion method to ASCII for each header 329 field which may contain non-ASCII characters. 331 [I-D.ietf-eai-utf8headers] expands Received: header fields, [RFC2822] 332 ABNF elements , , , , [RFC2045] 333 ABNF element . 335 Header field downgrading is defined below for each ABNF element. 336 Downgrading an unknown header field is also defined as ENCAPSULATION 337 downgrading. Converting the header field terminates when no non- 338 ASCII characters remain in the header field. 340 RECEIVED downgrading: If the header field name is "Received:" and 341 the FOR clause contains a non-ASCII addresses, remove the FOR 342 clause from the header field. The other part does not contain 343 non-ASCII values. 345 UNSTRUCTURED downgrading: If the header field has an 346 field which contains non-ASCII characters, encode the field 347 according to [RFC2047] with charset='UTF-8'. To preserve space 348 characters, the whole header field value which include space 349 characters SHOULD be encoded. 351 WORD downgrading: If the header field has any fields which 352 contains non-ASCII characters, encode the fields according to 353 [RFC2047] with charset='UTF-8'. 355 COMMENT downgrading: If the header field has any fields 356 which contains non-ASCII characters, encode the fields according 357 to [RFC2047] with charset='UTF-8'. 359 MIME-VALUE downgrading: If the header field has any 360 elements defined by [RFC2045] and the elements contain non-ASCII 361 characters, encode the elements by [RFC2231] with 362 charset='UTF-8' and the Language information empty. If the 363 element is and it contains outside 364 the DQUOTE, remove the before this conversion. 366 DISPLAY-NAME downgrading: If the header field has any 367 elements and they have elements which contain non- 368 ASCII characters, encode the elements according to 369 [RFC2047] with charset='UTF-8'. 371 MAILBOX downgrading: The elements have no equivalent 372 format for non-ASCII addresses. If the header field has any 373 elements which contain non-ASCII characters, preserve 374 the header field in each Address header field preservation header 375 defined in Section 3.2, and rewrite each element to 376 ASCII only format. The element which contains non-ASCII 377 characters is one of three formats. 379 * [ Display-name ] "<" Utf8-addr-spec 1*FCS "<" Addr-spec ">>" 381 Rewrite it as 383 [ Display-name ] "<" Addr-spec ">" 385 * [ Display-name ] "<" Utf8-addr-spec ">" 386 * Utf8-addr-spec 388 Rewrite both as 389 [ Display-name ] "Internationalized Address " Encoded-word 390 " Removed:;" 392 where the is the original 393 encoded according to [RFC2047]. 395 ENCAPSULATION downgrading: if the header field contains non-ASCII 396 characters and for which no rule is given above, encapsulate it in 397 a Downgraded header field described in Section 3.3 as a last 398 resort. 400 5.1. Downgrading method for each header field 402 Header fields are listed in [RFC4021]. This section describes the 403 downgrading method for each header field. 405 If the whole mail header field does not contain non-ASCII characters, 406 email header field downgrading is not required. Each header field's 407 downgrading method is described below. 409 o Address header fields which contain s 410 From: 411 Sender: 412 Reply-To: 413 To: 414 Cc: 415 Bcc: 416 Resent-From: 417 Resent-Sender: 418 Resent-To: 419 Resent-Cc: 420 Return-Path: 422 If the header field contains elements which contains 423 non-ASCII addresses, preserve the header field in a downgraded 424 header before the conversion. Then perform COMMENT downgrading, 425 DISPLAY-NAME downgrading and MAILBOX downgrading. 427 o Downgrading Non-ASCII in comments 429 Date: 430 Message-ID: 431 In-Reply-To: 432 References: 433 Resent-Date: 434 Resent-Message-ID: 435 MIME-Version: 436 Content-ID: 438 These header fields do not contain non-ASCII characters except in 439 comments. If the header contains UTF-8 characters in comments, 440 perform COMMENT downgrading. 442 o Trace header fields 444 Received: 446 perform COMMENT downgrading and perform RECEIVED downgrading. 448 o MIME Content header fields 450 Content-Type: 451 Content-Disposition: 453 Perform MIME-VALUE downgrading. 455 o Non-ASCII in 456 Subject: 457 Comments: 458 Content-Description: 460 Perform UNSTRUCTURED downgrading. 462 o Non-ASCII in or 464 Keywords: 466 Perform WORD downgrading. 468 o Other header fields 470 All other header fields which contains non-ASCII characters are 471 user-defined, missing from this draft or future defined header 472 fields. Perform ENCAPSULATION downgrading as a last resort. 474 6. MIME body part headers downgrading 476 MIME body part header fields may contain non-ASCII characters 477 [I-D.ietf-eai-utf8headers]. This section defines the conversion 478 method to ASCII only header fields for each MIME header field which 479 contains non-ASCII characters. Parse the message body's MIME 480 structure for all levels and check each MIME header field whether it 481 contains non-ASCII characters. If the header field contains non- 482 ASCII characters in the header value, the header is a target of the 483 MIME body part headers downgrading. Each MIME header field's 484 downgrading method is described below. COMMENT downgrading, MIME- 485 VALUE downgrading, UNSTRUCTURED downgrading are described in 486 Section 5. 488 Content-ID: 489 The Content-ID: header does not contain non-ASCII characters 490 except in comments. If the header contains UTF-8 characters in 491 comments, perform COMMENT downgrading. 493 Content-Type: 494 Content-Disposition: 495 Perform MIME-VALUE downgrading. 497 Content-Description: 498 Perform UNSTRUCTURED downgrading. 500 7. Security considerations 502 o A Downgraded message's header fields contain ASCII characters 503 only. But they still contain MIME encapsulated header fields 504 which contains non-ASCII UTF-8 characters. And more, the body 505 part may contain UTF-8 message. The recipients need to accept 506 UTF-8 mail body and UTF-8 header fields which is MIME encoded. 507 o Rewriting headers increases the opportunities for undetected 508 spoofing. 510 o Recipients addresses can be undisclosed if those addresses are 511 listed on Bcc or group address. Those undisclosed addresses are 512 used only in the Envelope. Copying information from the Envelope 513 into headers risks inadvertent information disclosure (not just 514 about addresses). See Section 4 for instructions on recipient 515 address handling. 517 o The techniques described here invalidates methods that depend on 518 digital signatures over the envelope or any part of the message 519 which includes the top-level header or body part headers. 520 Depending on the specific message being downgraded, DKIM 521 especially, but also possibly S/MIME, PGP, and similar techniques 522 are all likely to break. 524 o Many gateways and servers on the Internet will discard headers 525 with which they are not familiar. To the extent to which the 526 downgrade procedures depend on new headers (e.g., "Downgraded") to 527 avoid information loss, then the risk of having those headers 528 dropped and its implications must be identified. In particular, 529 it appears to me that, if the Downgraded headers are dropped, 530 there is no possibility of reconstructing the original information 531 at any point (before, during, or after delivery). 533 See "Security considerations" section in [RFC4952] for more 534 discussion. 536 8. Implementation notes 538 8.1. Trivial downgrading 540 Downgrading is an alternative to rejection for delivering messages 541 which require UTF8SMTP support to a server which does not provide 542 this. Implementing the full specification of this document is 543 desirable, but a partial implementation is also possible. 545 If a partial downgrading implementation confronts an unsupported 546 downgrading target, the implementation MUST NOT send the message to 547 server which does not support UTF8SMTP. Instead, it MUST reject the 548 message or generate a notification of non-deliverability. 550 A partial downgrading, Trivial downgrading is discussed. It does not 551 support non-ASCII addresses in SMTP envelope and address header 552 fields, unknown header fields downgrading, the MIME body part headers 553 downgrading. It supports 554 o some simple header fields downgrading: Subject 555 o comments and display name downgrading: From, To, CC 556 o trace header field downgrading: Received 558 Otherwise, the downgrading fails. 560 Trivial downgrading targets mail messages which are generated by 561 UTF8SMTP aware MUAs and contain non-ASCII characters in comments, 562 display names, unstructured parts without using non-ASCII E-mail 563 addresses. This E-mail message does not contain non-ASCII addresses 564 in SMTP Envelope and its header fields. But it is not deliverable 565 via UTF8SMTP un-aware MTA. Implementing full spec downgrading may be 566 hard, but trivial downgrading saves mail messages without using non- 567 ASCII addresses. 569 8.2. 7bit transport consideration 571 The SMTP client may confront a SMTP server which does not support the 572 8BITMIME SMTP extension [RFC1652]. The server does not support 573 "8bit" or "binary" data. Implementers need to consider to replace 574 "8bit" data to be "base64" or "quoted-printable" encoded form and 575 reflect it to "Content-Transfer-Encoding" header field. If the body 576 contains multiple MIME parts, this conversion must be performed for 577 each MIME part according to [RFC2045]. 579 9. IANA Considerations 581 IANA is requested to register the following header fields in the 582 Permanent Message Header Field Repository, in accordance with the 583 procedures set out in [RFC3864]. 585 Header field name: Downgraded-Mail-From 586 Applicable protocol: mail 587 Status: experimental 588 Author/change controller: IETF 589 Specification document(s): This document (Section 3) 591 Header field name: Downgraded-Rcpt-To 592 Applicable protocol: mail 593 Status: experimental 594 Author/change controller: IETF 595 Specification document(s): This document (Section 3) 597 Header field name: Downgraded-From 598 Applicable protocol: mail 599 Status: experimental 600 Author/change controller: IETF 601 Specification document(s): This document (Section 3) 603 Header field name: Downgraded-Sender 604 Applicable protocol: mail 605 Status: experimental 606 Author/change controller: IETF 607 Specification document(s): This document (Section 3) 609 Header field name: Downgraded-To 610 Applicable protocol: mail 611 Status: experimental 612 Author/change controller: IETF 613 Specification document(s): This document (Section 3) 615 Header field name: Downgraded-Cc 616 Applicable protocol: mail 617 Status: experimental 618 Author/change controller: IETF 619 Specification document(s): This document (Section 3) 621 Header field name: Downgraded-Reply-To 622 Applicable protocol: mail 623 Status: experimental 624 Author/change controller: IETF 625 Specification document(s): This document (Section 3) 627 Header field name: Downgraded-Bcc 628 Applicable protocol: mail 629 Status: experimental 630 Author/change controller: IETF 631 Specification document(s): This document (Section 3) 632 Header field name: Downgraded-Resent-From 633 Applicable protocol: mail 634 Status: experimental 635 Author/change controller: IETF 636 Specification document(s): This document (Section 3) 638 Header field name: Downgraded-Resent-To 639 Applicable protocol: mail 640 Status: experimental 641 Author/change controller: IETF 642 Specification document(s): This document (Section 3) 644 Header field name: Downgraded-Resent-Cc 645 Applicable protocol: mail 646 Status: experimental 647 Author/change controller: IETF 648 Specification document(s): This document (Section 3) 650 Header field name: Downgraded-Resent-Sender 651 Applicable protocol: mail 652 Status: experimental 653 Author/change controller: IETF 654 Specification document(s): This document (Section 3) 656 Header field name: Downgraded-Return-Path 657 Applicable protocol: mail 658 Status: experimental 659 Author/change controller: IETF 660 Specification document(s): This document (Section 3) 662 And more, IANA is requested to reserve all the field names that start 663 by "Downgraded-" for unknown header fields downgrading described in 664 Section 3.3, in accordance with the procedures set out in [RFC3864]. 666 Header field name: Names which starts by "Downgraded-" 667 Applicable protocol: mail 668 Status: experimental 669 Author/change controller: IETF 670 Specification document(s): This document (Section 3) 672 10. Acknowledgements 674 Significant comments and suggestions were received from John Klensin, 675 Harald Alvestrand, Chris Newman, Randall Gellens, Charles Lindsey, 676 Marcos Sanz, Alexey Melnikov, Frank Ellermann, Edward Lewis, S. 677 Moonesamy and JET members. 679 11. Change History 681 This section is used for tracking the update of this document. Will 682 be removed after finalize. 684 11.1. draft-yoneya-ima-downgrade: Version 00 686 o Initial version 687 o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00 689 11.2. draft-yoneya-ima-downgrade: Version 01 691 o Document structure was changed 692 o Followed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02 693 o Downgrading requirements were added 694 o SMTP DATA encapsulation method was proposed 695 o Downgrading examples was provided 697 11.3. draft-ietf-eai-downgrade: Version 00 699 o Followed draft-yeh-ima-utf8headers-01 and 700 draft-ietf-eai-smtpext-00 701 o No header downgrading method was proposed 702 o Header encapsulation method was proposed 704 11.4. draft-ietf-eai-downgrade: Version 01 706 o Followed draft-ietf-eai-utf8headers-00 707 o Header conversion and encapsulation method was merged 708 o Header conversion method was defined in detail 710 11.5. draft-ietf-eai-downgrade: Version 02 712 o Followed draft-ietf-eai-utf8headers-01 and 713 draft-ietf-eai-smtpext-01 714 o Specification about algorithmic generated address is removed 715 o No header downgrading method was removed 716 o SMTP DATA encapsulation method was removed 718 11.6. draft-ietf-eai-downgrade: Version 03 720 o Followed draft-ietf-eai-utf8headers-03 and 721 draft-ietf-eai-smtpext-03 722 o Downgraded: and Envelope-Downgraded: headers definition was added 723 o Mail header fields downgrading method was refined 724 o Examples in Appendix A were refined 726 11.7. draft-ietf-eai-downgrade: Version 04 728 o Followed draft-ietf-eai-utf8headers-06, draft-ietf-eai-smtpext-07 729 and draft-ietf-eai-dsn-02 730 o Downgrading requirements and conditions were moved to 731 Introduction. 732 o Descriptions about upgrading were removed. 733 o SPF and DKIM discussion were removed. 734 o Added many header fields downgrading. 735 o Allow address literal rewriting without alternate ASCII address in 736 header fields. 737 o Added MIME body part headers downgrading. 738 o Added ORCPT downgrading. 740 11.8. draft-ietf-eai-downgrade: Version 05 742 o fixed examples 743 * ALT-ADDRESS parameter mistake 744 * RFC2047(x) notation was changed to encoded-word format 745 o Added implementation consideration section and trivial downgrading 746 o Downgraded: and Envelope-Downgraded: headers are separated for 747 each original headers. 748 o Removed list-* header fields downgrading 749 o Changed the way of writing the header field downgrading section 751 11.9. draft-ietf-eai-downgrade: Version 06 753 o Moved decoding downgraded messages as a separate document 754 o Added a text to UNSTRUCTURED downgrading 755 o Added "replacing SMTP connection" if necessary to SMTP 756 downgrading. 757 o fixed examples 759 11.10. draft-ietf-eai-downgrade: Version 07 761 o Fixed some typos 762 o Added a text about 7bit transport 764 12. Normative References 766 [I-D.ietf-eai-dsn] 767 Newman, C. and A. Melnikov, "Internationalized Delivery 768 Status and Disposition Notifications", 769 draft-ietf-eai-dsn-06 (work in progress), January 2008. 771 [I-D.ietf-eai-smtpext] 772 Yao, J. and W. MAO, "SMTP extension for internationalized 773 email address", draft-ietf-eai-smtpext-11 (work in 774 progress), January 2008. 776 [I-D.ietf-eai-utf8headers] 777 Yeh, J., "Internationalized Email Headers", 778 draft-ietf-eai-utf8headers-09 (work in progress), 779 February 2008. 781 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 782 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 783 RFC 1652, July 1994. 785 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 786 Extensions (MIME) Part One: Format of Internet Message 787 Bodies", RFC 2045, November 1996. 789 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 790 Part Three: Message Header Extensions for Non-ASCII Text", 791 RFC 2047, November 1996. 793 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 794 Requirement Levels", BCP 14, RFC 2119, March 1997. 796 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 797 Presentation Information in Internet Messages: The 798 Content-Disposition Header Field", RFC 2183, August 1997. 800 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 801 Word Extensions: 802 Character Sets, Languages, and Continuations", RFC 2231, 803 November 1997. 805 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 806 April 2001. 808 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 809 April 2001. 811 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 812 Extension for Delivery Status Notifications (DSNs)", 813 RFC 3461, January 2003. 815 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 816 Procedures for Message Header Fields", BCP 90, RFC 3864, 817 September 2004. 819 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 820 Header Fields", RFC 4021, March 2005. 822 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 823 Internationalized Email", RFC 4952, July 2007. 825 Appendix A. Examples 827 A.1. Downgrading example 1 829 This section shows an SMTP Downgrading example. Consider a mail 830 message. 831 o The sender address is "NON-ASCII-local@example.com" which is non- 832 ASCII address. Its ASCII alternative is "ASCII-local@example.com" 833 and its display-name is "DISPLAY-local". 834 o The "To" address is "NON-ASCII-remote1@example.net" which is non- 835 ASCII address. Its ASCII alternative is 836 "ASCII-remote1@example.net" and its display-name is "DISPLAY- 837 remote1". 838 o The "CC" address is non-ASCII address 839 "NON-ASCII-remote2@example.org" without alternative ASCII address. 840 Its display-name is "DISPLAY-remote2". 841 o Three display-names contains non-ASCII characters. 842 o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII 843 characters. 844 o assume To: recipient's MTA (example.net) does not support 845 UTF8SMTP. 846 o assume Cc: recipient's MTA (example.org) supports UTF8SMTP. 847 The example SMTP envelope/message is shown in Figure 4. In this 848 example, the To: recipient's session is focused. 850 MAIL FROM: 851 ALT-ADDRESS=ASCII-local@example.com 852 RCPT TO: 853 ALT-ADDRESS=ASCII-remote1@example.net 854 RCPT TO: 855 ------------------------------------------------------------- 856 Message-Id: MESSAGE_ID 857 Mime-Version: 1.0 858 Content-Type: text/plain; charset="UTF-8" 859 Content-Transfer-Encoding: 8bit 860 Subject: NON-ASCII-SUBJECT 861 From: DISPLAY-local > 863 To: DISPLAY-remote1 > 865 CC: DISPLAY-remote2 866 Date: DATE 868 MAIL_BODY 870 Figure 4: Original envelope/message (example 1) 872 In this example, there are two SMTP recipients, one is To:, the other 873 is CC:. The SMTP downgrading treats To: session downgrading. 874 Figure 5 shows SMTP downgraded example. 876 MAIL FROM: 877 RCPT TO: 878 ------------------------------------------------------------- 879 Downgraded-Mail-From: =?UTF-8?Q?_?= 880 =?UTF-8?Q??= 881 Downgraded-Rcpt-To: =?UTF-8?Q?_?= 882 =?UTF-8?Q??= 883 Message-Id: MESSAGE_ID 884 Mime-Version: 1.0 885 Content-Type: text/plain; charset="UTF-8" 886 Content-Transfer-Encoding: 8bit 887 Subject: NON-ASCII-SUBJECT 888 From: DISPLAY-local > 890 To: DISPLAY-remote1 > 892 CC: DISPLAY-remote2 893 Date: DATE 895 MAIL_BODY 897 Figure 5: SMTP Downgraded envelope/message (example 1) 899 After SMTP downgrading, header fields downgrading is performed. 900 Final downgraded message is shown in Figure 6. Return-Path header 901 will be added by the final destination MTA. 903 Return-Path: 904 Downgraded-Mail-From: =?UTF-8?Q?_?= 905 =?UTF-8?Q??= 906 Downgraded-Rcpt-To: =?UTF-8?Q?_?= 907 =?UTF-8?Q??= 908 Message-Id: MESSAGE_ID 909 Mime-Version: 1.0 910 Content-Type: text/plain; charset="UTF-8" 911 Content-Transfer-Encoding: 8bit 912 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 913 From: =?UTF-8?Q?DISPLAY-local?= 914 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 916 To: =?UTF-8?Q?DISPLAY-remote1?= 917 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= 918 =?UTF-8?Q?>?= 919 CC: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 920 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; 921 Downgraded-CC: =?UTF-8?Q?DISPLAY-remote2_?= 922 =?UTF-8?Q??= 923 Date: DATE 925 MAIL_BODY 927 Figure 6: Downgraded message (example 1) 929 A.2. Downgrading example 2 931 In many cases, the sender wants to use non-ASCII address, the 932 recipient does not support UTF8SMTP and does not have non-ASCII 933 address. 934 o The sender address is "NON-ASCII-local@example.com" which is non- 935 ASCII address. Its ASCII alternative is 936 "ASCII-local@example.com". It has a display-name "DISPLAY-local" 937 which contains non-ASCII characters. 938 o The "To" address is "ASCII-remote1@example.net" which is ASCII 939 only. It has a display-name "DISPLAY-remote1" which contains non- 940 ASCII characters. 941 o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII 942 characters. 943 The second example envelope/message is shown in Figure 7. 945 MAIL From: 946 ALT-ADDRESS=ASCII-local@example.com 947 RCPT TO: 948 ------------------------------------------------------------- 949 Message-Id: MESSAGE_ID 950 Mime-Version: 1.0 951 Content-Type: text/plain; charset="UTF-8" 952 Content-Transfer-Encoding: 8bit 953 Subject: NON-ASCII-SUBJECT 954 From: DISPLAY-local > 956 To: DISPLAY-remote1 957 Date: DATE 959 MAIL_BODY 961 Figure 7: Original message (example 2) 963 In this example, SMTP session is downgradable. Figure 8 shows SMTP 964 downgraded envelope/message. 966 MAIL From: 967 RCPT TO: 968 ------------------------------------------------------------- 969 Downgraded-Mail-From: =?UTF-8?Q?_?= 970 ?=UTF8?Q??= 971 Message-Id: MESSAGE_ID 972 Mime-Version: 1.0 973 Content-Type: text/plain; charset="UTF-8" 974 Content-Transfer-Encoding: 8bit 975 Subject: NON-ASCII-SUBJECT 976 From: DISPLAY-local > 978 To: DISPLAY-remote1 979 Date: DATE 981 MAIL_BODY 983 Figure 8: SMTP Downgraded envelope/message (example 2) 985 After SMTP downgrading, header fields downgrading is performed. The 986 downgraded example is shown in Figure 9. 988 Return-Path: 989 Downgraded-Mail-From: =?UTF-8?Q?_?= 990 =?UTF8?Q??= 991 Message-Id: MESSAGE_ID 992 Mime-Version: 1.0 993 Content-Type: text/plain; charset="UTF-8" 994 Content-Transfer-Encoding: 8bit 995 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 996 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 998 From: =?UTF-8?Q?DISPLAY-local?= 999 To: =?UTF-8?Q?DISPLAY-remote1?= 1000 Date: DATE 1002 MAIL_BODY 1004 Figure 9: Downgraded message (example 2) 1006 Authors' Addresses 1008 Kazunori Fujiwara (editor) 1009 JPRS 1010 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 1011 Chiyoda-ku, Tokyo 101-0065 1012 Japan 1014 Phone: +81 3 5215 8451 1015 Email: fujiwara@jprs.co.jp 1017 Yoshiro YONEYA (editor) 1018 JPRS 1019 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 1020 Chiyoda-ku, Tokyo 101-0065 1021 Japan 1023 Phone: +81 3 5215 8451 1024 Email: yone@jprs.co.jp 1026 Full Copyright Statement 1028 Copyright (C) The IETF Trust (2008). 1030 This document is subject to the rights, licenses and restrictions 1031 contained in BCP 78, and except as set forth therein, the authors 1032 retain all their rights. 1034 This document and the information contained herein are provided on an 1035 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1036 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1037 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1038 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1039 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1040 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1042 Intellectual Property 1044 The IETF takes no position regarding the validity or scope of any 1045 Intellectual Property Rights or other rights that might be claimed to 1046 pertain to the implementation or use of the technology described in 1047 this document or the extent to which any license under such rights 1048 might or might not be available; nor does it represent that it has 1049 made any independent effort to identify any such rights. Information 1050 on the procedures with respect to rights in RFC documents can be 1051 found in BCP 78 and BCP 79. 1053 Copies of IPR disclosures made to the IETF Secretariat and any 1054 assurances of licenses to be made available, or the result of an 1055 attempt made to obtain a general license or permission for the use of 1056 such proprietary rights by implementers or users of this 1057 specification can be obtained from the IETF on-line IPR repository at 1058 http://www.ietf.org/ipr. 1060 The IETF invites any interested party to bring to its attention any 1061 copyrights, patents or patent applications, or other proprietary 1062 rights that may cover technology that may be required to implement 1063 this standard. Please address the information to the IETF at 1064 ietf-ipr@ietf.org. 1066 Acknowledgment 1068 Funding for the RFC Editor function is provided by the IETF 1069 Administrative Support Activity (IASA).