idnits 2.17.1 draft-ietf-eai-downgrade-08.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 1049. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1060. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1067. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1073. 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 (July 14, 2008) is 5757 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 210, but not defined ** 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 (~~), 2 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 July 14, 2008 6 Expires: January 15, 2009 8 Downgrading mechanism for Email Address Internationalization 9 draft-ietf-eai-downgrade-08.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 January 15, 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 . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Path element downgrading . . . . . . . . . . . . . . . . 7 61 4.2. ORCPT downgrading . . . . . . . . . . . . . . . . . . . . 8 62 5. Email header fields downgrading . . . . . . . . . . . . . . . 8 63 5.1. Downgrading method for each header field . . . . . . . . 9 64 6. MIME body part headers downgrading . . . . . . . . . . . . . . 11 65 7. Security considerations . . . . . . . . . . . . . . . . . . . 12 66 8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 13 67 8.1. Trivial downgrading . . . . . . . . . . . . . . . . . . . 13 68 8.2. 7bit transport consideration . . . . . . . . . . . . . . 13 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 71 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16 72 11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . 16 73 11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . 16 74 11.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . 16 75 11.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . 16 76 11.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . 16 77 11.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . 17 78 11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . 17 79 11.8. draft-ietf-eai-downgrade: Version 05 . . . . . . . . . . 17 80 11.9. draft-ietf-eai-downgrade: Version 06 . . . . . . . . . . 17 81 11.10. draft-ietf-eai-downgrade: Version 07 . . . . . . . . . . 18 82 11.11. draft-ietf-eai-downgrade: Version 08 . . . . . . . . . . 18 83 12. Normative References . . . . . . . . . . . . . . . . . . . . . 18 84 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 85 A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 19 86 A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 88 Intellectual Property and Copyright Statements . . . . . . . . . . 25 90 1. Introduction 92 Traditional mail systems which are defined by [RFC2821] and [RFC2822] 93 allow ASCII characters in SMTP envelope and mail header field values. 94 The UTF8SMTP extension [RFC4952], [I-D.ietf-eai-utf8headers] and 95 [I-D.ietf-eai-smtpext] allows UTF-8 characters in SMTP envelope and 96 mail header field values. 98 If an envelope address or header field contains non-ASCII characters, 99 the message cannot be delivered unless every system in the delivery 100 path supports UTF8SMTP. This document describes a downgrading 101 mechanism to avoid rejection of such messages when a server which 102 does not support the UTF8SMTP extension is encountered. Downgrading 103 mechanism converts envelope and header fields to an all-ASCII 104 representation. 106 [I-D.ietf-eai-utf8headers] allows UTF-8 characters to be used in mail 107 header fields and MIME header fields. The downgrading mechanism 108 specified here converts mail header fields and MIME header fields to 109 ASCII. 111 This document does not change any protocols except by defining new 112 header fields. It describes the conversion method from the 113 internationalized email envelopes/messages which are defined in 114 [RFC4952] [I-D.ietf-eai-utf8headers] [I-D.ietf-eai-smtpext] to the 115 traditional email envelopes/messages which are defined in [RFC2821] 116 [RFC2822]. 118 [I-D.ietf-eai-smtpext] section 2.2 defines when downgrading occurs. 119 If the SMTP client has an UTF8SMTP envelope or an internationalized 120 message and the SMTP server doesn't support the UTF8SMTP SMTP 121 extension, then the SMTP client MUST NOT send a UTF8SMTP envelope or 122 an internationalized message to the SMTP server. The section shows 4 123 choices. The fourth 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 [I-D.ietf-eai-utf8headers]. 150 The MIME header fields downgrading is described in Section 6. It 151 generates ASCII 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 [RFC2821][RFC2822], 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 [I-D.ietf-eai-smtpext], 167 [I-D.ietf-eai-utf8headers], and [I-D.ietf-eai-dsn]. Key words used 168 in these document are used in this document, too. 170 The term "non-ASCII" is an UTF-8 string which contains at least one 171 non-ASCII character. 173 An "UTF8SMTP envelope" has Email originator/recipient addresses 174 expanded by [I-D.ietf-eai-smtpext] and [I-D.ietf-eai-dsn]. 176 An "UTF8SMTP message" is Email messages expanded by 177 [I-D.ietf-eai-utf8headers]. 179 3. New header fields definition 181 New header fields starting with "Downgraded-" are defined here to 182 preserve those original envelope and header values which contain 183 UTF-8 characters. During downgrading, one new "Downgraded-" header 184 field is added for each original envelope or header field which 185 cannot be passed as-is to a server which does not support UTF8SMTP. 186 The original envelope or header field is removed or rewritten. Only 187 those envelope and header fields which contain non-ASCII characters 188 are affected. The result of this process is a message which is 189 compliant with existing email specifications [RFC2821] and [RFC2822]. 190 The original internationalized information can be retrieved by 191 examining the "Downgraded-" header fields which were added. Even 192 though the information is not lost, the original message cannot be 193 perfectly reconstructed. Hence, downgrading is a one-way process. 194 However, an internationalized client might use the information in the 195 "Downgraded-" header fields when processing a downgraded message, for 196 example, such as displaying or composing a reply. 198 3.1. Envelope information preservation headers 200 Two headers "Downgraded-Mail-From:" and "Downgraded-Rcpt-To:" are 201 defined to preserve SMTP envelope downgraded information. SMTP 202 envelope downgraded information consists of the original non-ASCII 203 address and the downgraded all-ASCII address. The header field 204 syntax is specified as follows: 206 fields =/ downgradedmailfrom / downgradedrcptto 207 downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">" 1*[FWS] 208 "<" Mailbox ">" [FWS] CRLF 209 downgradedrcptto = "Downgraded-Rcpt-To:" [FWS] "<" uPath ">" 1*[FWS] 210 "<" Mailbox ">" [FWS] CRLF 212 Original non-ASCII address is defined in 213 [I-D.ietf-eai-smtpext]; it is treated as unstructured in this header 214 and it is encoded according to [RFC2047]. is defined in 215 [RFC2821], section 4.1.2. 217 3.2. Address header field preservation headers 219 The address header fields preservation headers are defined to 220 preserve the original header field. Their value field holds the 221 original header field value. Any original header field value is 222 treated as an and it MUST be encoded according to 223 [RFC2047] with charset='UTF-8'. The header field syntax is specified 224 as follows: 226 fields =/ known-downgraded-headers ":" unstructued CRLF 227 known-downgraded-headers = "Downgraded-" original-headers 228 original-headers = "From" / "To" / "Cc" / "Bcc" / 229 "Sender" / "Reply-To" / 230 "Resent-From" / "Resent-Sender" / 231 "Resent-To" / "Resent-Cc" / "Return-Path" 233 Preserving a header field in a downgraded header field is defined as: 234 1. Generate new downgraded header field whose value is the original 235 header field value. 236 2. Encode the generated header according to [RFC2047] with 237 charset='UTF-8'. 239 3.3. Unknown header fields preservation headers 241 The unknown header fields preservation headers are defined to 242 encapsulate those original header field which contains non-ASCII 243 characters and are not otherwise provided for in the this 244 specification. The encapsulation header field name is the 245 concatenation of "Downgraded-" and the original name. The value 246 field holds the original header field value. 248 Any original header field value is treated as an unstructured value 249 and it MUST be encoded according to [RFC2047] with charset='UTF-8'. 250 The header field syntax is specified as follows: 252 fields =/ unknown-downgraded-headers ":" unstructued 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 whose value is the original 265 header field value. 266 2. Encode the generated header field value according to [RFC2047] 267 with charset='UTF-8'. To preserve space characters, the whole 268 header field value which include space characters SHOULD be 269 encoded. 271 3. Remove the original header field. 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 [I-D.ietf-eai-smtpext]. A SMTP command 285 is downgradable if the contains non-ASCII address and the 286 command has an ALT-ADDRESS parameter which specifies an ASCII 287 address. Since only non-ASCII addresses are downgradable, specifying 288 an ALT-ADDRESS value for an all-ASCII address is invalid for use with 289 this 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" address and the address contains non-ASCII characters, the 325 ORCPT parameter MUST be converted to utf-8-addr-xtext form or utf-8- 326 addr-unitext form which are described in [I-D.ietf-eai-dsn]. 328 5. Email header fields downgrading 330 This section defines the conversion method to ASCII for each header 331 field which may contain non-ASCII characters. 333 [I-D.ietf-eai-utf8headers] expands Received: header fields, [RFC2822] 334 ABNF elements , , , , [RFC2045] 335 ABNF element . 337 Header field downgrading is defined below for each ABNF element. 338 Downgrading an unknown header field is also defined as ENCAPSULATION 339 downgrading. Converting the header field terminates when no non- 340 ASCII characters remain in the header field. 342 RECEIVED downgrading: If the header field name is "Received:" and 343 the FOR clause contains a non-ASCII addresses, remove the FOR 344 clause from the header field. The other part does not contain 345 non-ASCII values. 347 UNSTRUCTURED downgrading: If the header field has an 348 field which contains non-ASCII characters, encode the field 349 according to [RFC2047] with charset='UTF-8'. To preserve space 350 characters, the whole header field value which include space 351 characters SHOULD be encoded. 353 WORD downgrading: If the header field has any fields which 354 contains non-ASCII characters, encode the fields according to 355 [RFC2047] with charset='UTF-8'. 357 COMMENT downgrading: If the header field has any fields 358 which contains non-ASCII characters, encode the fields according 359 to [RFC2047] with charset='UTF-8'. 361 MIME-VALUE downgrading: If the header field has any 362 elements defined by [RFC2045] and the elements contain non-ASCII 363 characters, encode the elements by [RFC2231] with 364 charset='UTF-8' and the Language information empty. If the 365 element is and it contains outside 366 the DQUOTE, remove the before this conversion. 368 DISPLAY-NAME downgrading: If the header field has any 369 elements and they have elements which contain non- 370 ASCII characters, encode the elements according to 371 [RFC2047] with charset='UTF-8'. 373 MAILBOX downgrading: The elements have no equivalent 374 format for non-ASCII addresses. If the header field has any 375 elements which contain non-ASCII characters, preserve 376 the header field in each Address header field preservation header 377 defined in Section 3.2, and rewrite each element to 378 ASCII only format. The element which contains non-ASCII 379 characters is one of three formats. 381 * [ Display-name ] "<" Utf8-addr-spec 1*FCS "<" Addr-spec ">>" 383 Rewrite it as 385 [ Display-name ] "<" Addr-spec ">" 387 * [ Display-name ] "<" Utf8-addr-spec ">" 388 * Utf8-addr-spec 390 Rewrite both as 391 [ Display-name ] "Internationalized Address " Encoded-word 392 " Removed:;" 394 where the is the original 395 encoded according to [RFC2047]. 397 ENCAPSULATION downgrading: if the header field contains non-ASCII 398 characters and for which no rule is given above, encapsulate it in 399 a Downgraded header field described in Section 3.3 as a last 400 resort. 402 5.1. Downgrading method for each header field 404 Header fields are listed in [RFC4021]. This section describes the 405 downgrading method for each header field. 407 If the whole mail header field does not contain non-ASCII characters, 408 email header field downgrading is not required. Each header field's 409 downgrading method is described below. 411 o Address header fields which contain s 413 From: 414 Sender: 415 Reply-To: 416 To: 417 Cc: 418 Bcc: 419 Resent-From: 420 Resent-Sender: 421 Resent-To: 422 Resent-Cc: 423 Return-Path: 425 If the header field contains elements which contains 426 non-ASCII addresses, preserve the header field in a downgraded 427 header before the conversion. Then perform COMMENT downgrading, 428 DISPLAY-NAME downgrading and MAILBOX downgrading. 430 o Downgrading Non-ASCII in comments 432 Date: 433 Message-ID: 434 In-Reply-To: 435 References: 436 Resent-Date: 437 Resent-Message-ID: 438 MIME-Version: 439 Content-ID: 441 These header fields do not contain non-ASCII characters except in 442 comments. If the header contains UTF-8 characters in comments, 443 perform COMMENT downgrading. 445 o Trace header fields 447 Received: 449 perform COMMENT downgrading and perform RECEIVED downgrading. 451 o MIME Content header fields 452 Content-Type: 453 Content-Disposition: 455 Perform MIME-VALUE downgrading. 457 o Non-ASCII in 459 Subject: 460 Comments: 461 Content-Description: 463 Perform UNSTRUCTURED downgrading. 465 o Non-ASCII in or 467 Keywords: 469 Perform WORD downgrading. 471 o Other header fields 473 All other header fields which contains non-ASCII characters are 474 user-defined, missing from this draft or future defined header 475 fields. Perform ENCAPSULATION downgrading as a last resort. 477 6. MIME body part headers downgrading 479 MIME body part header fields may contain non-ASCII characters 480 [I-D.ietf-eai-utf8headers]. This section defines the conversion 481 method to ASCII only header fields for each MIME header field which 482 contains non-ASCII characters. Parse the message body's MIME 483 structure for all levels and check each MIME header field whether it 484 contains non-ASCII characters. If the header field contains non- 485 ASCII characters in the header value, the header is a target of the 486 MIME body part headers downgrading. Each MIME header field's 487 downgrading method is described below. COMMENT downgrading, MIME- 488 VALUE downgrading, UNSTRUCTURED downgrading are described in 489 Section 5. 491 Content-ID: 492 The Content-ID: header does not contain non-ASCII characters 493 except in comments. If the header contains UTF-8 characters in 494 comments, perform COMMENT downgrading. 496 Content-Type: 497 Content-Disposition: 498 Perform MIME-VALUE downgrading. 500 Content-Description: 501 Perform UNSTRUCTURED downgrading. 503 7. Security considerations 505 o A Downgraded message's header fields contain ASCII characters 506 only. But they still contain MIME encapsulated header fields 507 which contains non-ASCII UTF-8 characters. Furthermore, the body 508 part may contain UTF-8 characters. Implementations parsing 509 Internet messages need to accept UTF-8 body parts and UTF-8 header 510 fields which are MIME encoded. 511 o Rewriting headers increases the opportunities for undetected 512 spoofing. 514 o Addresses that do not appear in the message headers may appear in 515 the RCPT commands to an SMTP server for a number of reasons. 516 Copying information from the Envelope into headers risks 517 inadvertent information disclosure (see [RFC2821] and Section 4). 519 o The techniques described here invalidates methods that depend on 520 digital signatures over the envelope or any part of the message 521 which includes the top-level header or body part headers. 522 Depending on the specific message being downgraded, DKIM 523 especially, but also possibly S/MIME, PGP, and similar techniques 524 are all likely to break. 526 o Many gateways and servers on the Internet will discard headers 527 with which they are not familiar. To the extent to which the 528 downgrade procedures depend on new headers (e.g., "Downgraded-") 529 to avoid information loss, the risk of having those headers 530 dropped and its implications must be identified. In particular, 531 if the Downgraded headers are dropped, there is no possibility of 532 reconstructing the original information at any point (before, 533 during, or after delivery). 535 See "Security considerations" section in [RFC4952] for more 536 discussion. 538 8. Implementation notes 540 8.1. Trivial downgrading 542 Downgrading is an alternative to avoid the rejection of messages 543 which require UTF8SMTP support by a server which does not provide 544 this. Implementing the full specification of this document is 545 desirable, but a partial implementation is also possible. 547 If a partial downgrading implementation confronts an unsupported 548 downgrading target, the implementation MUST NOT send the message to a 549 server which does not support UTF8SMTP. Instead, it MUST reject the 550 message or generate a notification of non-deliverability. 552 A partial downgrading, Trivial downgrading is discussed. It does not 553 support non-ASCII addresses in SMTP envelope and address header 554 fields, unknown header fields downgrading, the MIME body part headers 555 downgrading. It supports 556 o some simple header fields downgrading: Subject 557 o comments and display name downgrading: From, To, Cc 558 o trace header field downgrading: Received 560 Otherwise, the downgrading fails. 562 Trivial downgrading targets mail messages which are generated by 563 UTF8SMTP aware MUAs and contain non-ASCII characters in comments, 564 display names, unstructured parts without using non-ASCII E-mail 565 addresses. This mail message does not contain non-ASCII E-mail 566 addresses in the SMTP Envelope and its header fields. But it is not 567 deliverable via a UTF8SMTP un-aware SMTP server. Implementing full 568 specification downgrading may be hard, but trivial downgrading saves 569 mail messages without using non-ASCII addresses. 571 8.2. 7bit transport consideration 573 The SMTP client may encounter a SMTP server which does not support 574 the 8BITMIME SMTP extension [RFC1652]. The server does not support 575 "8bit" or "binary" data. Implementers need to consider converting 576 "8bit" data to "base64" or "quoted-printable" encoded form and adjust 577 the "Content-Transfer-Encoding" header field accordingly. If the 578 body contains multiple MIME parts, this conversion must be performed 579 for each MIME part according to [RFC2045]. 581 9. IANA Considerations 583 IANA is requested to register the following header fields in the 584 Permanent Message Header Field Repository, in accordance with the 585 procedures set out in [RFC3864]. 587 Header field name: Downgraded-Mail-From 588 Applicable protocol: mail 589 Status: experimental 590 Author/change controller: IETF 591 Specification document(s): This document (Section 3) 593 Header field name: Downgraded-Rcpt-To 594 Applicable protocol: mail 595 Status: experimental 596 Author/change controller: IETF 597 Specification document(s): This document (Section 3) 599 Header field name: Downgraded-From 600 Applicable protocol: mail 601 Status: experimental 602 Author/change controller: IETF 603 Specification document(s): This document (Section 3) 605 Header field name: Downgraded-Sender 606 Applicable protocol: mail 607 Status: experimental 608 Author/change controller: IETF 609 Specification document(s): This document (Section 3) 611 Header field name: Downgraded-To 612 Applicable protocol: mail 613 Status: experimental 614 Author/change controller: IETF 615 Specification document(s): This document (Section 3) 617 Header field name: Downgraded-Cc 618 Applicable protocol: mail 619 Status: experimental 620 Author/change controller: IETF 621 Specification document(s): This document (Section 3) 623 Header field name: Downgraded-Reply-To 624 Applicable protocol: mail 625 Status: experimental 626 Author/change controller: IETF 627 Specification document(s): This document (Section 3) 628 Header field name: Downgraded-Bcc 629 Applicable protocol: mail 630 Status: experimental 631 Author/change controller: IETF 632 Specification document(s): This document (Section 3) 634 Header field name: Downgraded-Resent-From 635 Applicable protocol: mail 636 Status: experimental 637 Author/change controller: IETF 638 Specification document(s): This document (Section 3) 640 Header field name: Downgraded-Resent-To 641 Applicable protocol: mail 642 Status: experimental 643 Author/change controller: IETF 644 Specification document(s): This document (Section 3) 646 Header field name: Downgraded-Resent-Cc 647 Applicable protocol: mail 648 Status: experimental 649 Author/change controller: IETF 650 Specification document(s): This document (Section 3) 652 Header field name: Downgraded-Resent-Sender 653 Applicable protocol: mail 654 Status: experimental 655 Author/change controller: IETF 656 Specification document(s): This document (Section 3) 658 Header field name: Downgraded-Return-Path 659 Applicable protocol: mail 660 Status: experimental 661 Author/change controller: IETF 662 Specification document(s): This document (Section 3) 664 Furthermore, IANA is requested to reserve all the field names that 665 start with "Downgraded-" for unknown header fields downgrading 666 described in Section 3.3, in accordance with the procedures set out 667 in [RFC3864]. 669 Header field name: Names which starts by "Downgraded-" 670 Applicable protocol: mail 671 Status: experimental 672 Author/change controller: IETF 673 Specification document(s): This document (Section 3) 675 10. Acknowledgements 677 Significant comments and suggestions were received from John Klensin, 678 Harald Alvestrand, Chris Newman, Randall Gellens, Charles Lindsey, 679 Marcos Sanz, Alexey Melnikov, Frank Ellermann, Edward Lewis, S. 680 Moonesamy and JET members. 682 11. Change History 684 This section is used for tracking the update of this document. Will 685 be removed after finalize. 687 11.1. draft-yoneya-ima-downgrade: Version 00 689 o Initial version 690 o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00 692 11.2. draft-yoneya-ima-downgrade: Version 01 694 o Document structure was changed 695 o Followed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02 696 o Downgrading requirements were added 697 o SMTP DATA encapsulation method was proposed 698 o Downgrading examples was provided 700 11.3. draft-ietf-eai-downgrade: Version 00 702 o Followed draft-yeh-ima-utf8headers-01 and 703 draft-ietf-eai-smtpext-00 704 o No header downgrading method was proposed 705 o Header encapsulation method was proposed 707 11.4. draft-ietf-eai-downgrade: Version 01 709 o Followed draft-ietf-eai-utf8headers-00 710 o Header conversion and encapsulation method was merged 711 o Header conversion method was defined in detail 713 11.5. draft-ietf-eai-downgrade: Version 02 714 o Followed draft-ietf-eai-utf8headers-01 and 715 draft-ietf-eai-smtpext-01 716 o Specification about algorithmic generated address is removed 717 o No header downgrading method was removed 718 o SMTP DATA encapsulation method was removed 720 11.6. draft-ietf-eai-downgrade: Version 03 722 o Followed draft-ietf-eai-utf8headers-03 and 723 draft-ietf-eai-smtpext-03 724 o Downgraded: and Envelope-Downgraded: headers definition was added 725 o Mail header fields downgrading method was refined 726 o Examples in Appendix A were refined 728 11.7. draft-ietf-eai-downgrade: Version 04 730 o Followed draft-ietf-eai-utf8headers-06, draft-ietf-eai-smtpext-07 731 and draft-ietf-eai-dsn-02 732 o Downgrading requirements and conditions were moved to 733 Introduction. 734 o Descriptions about upgrading were removed. 735 o SPF and DKIM discussion were removed. 736 o Added many header fields downgrading. 737 o Allow address literal rewriting without alternate ASCII address in 738 header fields. 739 o Added MIME body part headers downgrading. 740 o Added ORCPT downgrading. 742 11.8. draft-ietf-eai-downgrade: Version 05 744 o fixed examples 745 * ALT-ADDRESS parameter mistake 746 * RFC2047(x) notation was changed to encoded-word format 747 o Added implementation consideration section and trivial downgrading 748 o Downgraded: and Envelope-Downgraded: headers are separated for 749 each original headers. 750 o Removed list-* header fields downgrading 751 o Changed the way of writing the header field downgrading section 753 11.9. draft-ietf-eai-downgrade: Version 06 755 o Moved decoding downgraded messages as a separate document 756 o Added a text to UNSTRUCTURED downgrading 757 o Added "replacing SMTP connection" if necessary to SMTP 758 downgrading. 759 o fixed examples 761 11.10. draft-ietf-eai-downgrade: Version 07 763 o Fixed some typos 764 o Added a text about 7bit transport 766 11.11. draft-ietf-eai-downgrade: Version 08 768 o Comments from the working group last call (wording) 770 12. Normative References 772 [I-D.ietf-eai-dsn] 773 Newman, C. and A. Melnikov, "Internationalized Delivery 774 Status and Disposition Notifications", 775 draft-ietf-eai-dsn-06 (work in progress), January 2008. 777 [I-D.ietf-eai-smtpext] 778 Yao, J. and W. MAO, "SMTP extension for internationalized 779 email address", draft-ietf-eai-smtpext-13 (work in 780 progress), July 2008. 782 [I-D.ietf-eai-utf8headers] 783 Yang, A., "Internationalized Email Headers", 784 draft-ietf-eai-utf8headers-12 (work in progress), 785 July 2008. 787 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 788 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 789 RFC 1652, July 1994. 791 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 792 Extensions (MIME) Part One: Format of Internet Message 793 Bodies", RFC 2045, November 1996. 795 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 796 Part Three: Message Header Extensions for Non-ASCII Text", 797 RFC 2047, November 1996. 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, March 1997. 802 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 803 Presentation Information in Internet Messages: The 804 Content-Disposition Header Field", RFC 2183, August 1997. 806 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 807 Word Extensions: 809 Character Sets, Languages, and Continuations", RFC 2231, 810 November 1997. 812 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 813 April 2001. 815 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 816 April 2001. 818 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 819 Extension for Delivery Status Notifications (DSNs)", 820 RFC 3461, January 2003. 822 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 823 Procedures for Message Header Fields", BCP 90, RFC 3864, 824 September 2004. 826 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 827 Header Fields", RFC 4021, March 2005. 829 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 830 Internationalized Email", RFC 4952, July 2007. 832 Appendix A. Examples 834 A.1. Downgrading example 1 836 This section shows an SMTP Downgrading example. Consider a mail 837 message where: 838 o The sender address is "NON-ASCII-local@example.com" which is a 839 non-ASCII address. Its ASCII alternative is 840 "ASCII-local@example.com" and its display-name is "DISPLAY-local". 841 o The "To:" address is "NON-ASCII-remote1@example.net" which is a 842 non-ASCII address. Its ASCII alternative is 843 "ASCII-remote1@example.net" and its display-name is "DISPLAY- 844 remote1". 845 o The "Cc:" address is a non-ASCII address 846 "NON-ASCII-remote2@example.org" without alternative ASCII address. 847 Its display-name is "DISPLAY-remote2". 848 o Three display-names contain non-ASCII characters. 849 o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII 850 characters. 851 o Assuming the "To:" recipient's MTA (example.net) does not support 852 UTF8SMTP. 853 o assuming the "Cc:" recipient's MTA (example.org) supports 854 UTF8SMTP. 855 The example SMTP envelope/message is shown in Figure 1. In this 856 example, the "To:" recipient's session is the focus. 858 MAIL FROM: 859 ALT-ADDRESS=ASCII-local@example.com 860 RCPT TO: 861 ALT-ADDRESS=ASCII-remote1@example.net 862 RCPT TO: 863 ------------------------------------------------------------- 864 Message-Id: MESSAGE_ID 865 Mime-Version: 1.0 866 Content-Type: text/plain; charset="UTF-8" 867 Content-Transfer-Encoding: 8bit 868 Subject: NON-ASCII-SUBJECT 869 From: DISPLAY-local > 871 To: DISPLAY-remote1 > 873 Cc: DISPLAY-remote2 874 Date: DATE 876 MAIL_BODY 878 Figure 1: Original envelope/message (example 1) 880 In this example, there are two SMTP recipients, one is "To:", the 881 other is "Cc:". The SMTP downgrading treats To: session downgrading. 882 Figure 2 shows SMTP downgraded example. 884 MAIL FROM: 885 RCPT TO: 886 ------------------------------------------------------------- 887 Downgraded-Mail-From: =?UTF-8?Q?_?= 888 =?UTF-8?Q??= 889 Downgraded-Rcpt-To: =?UTF-8?Q?_?= 890 =?UTF-8?Q??= 891 Message-Id: MESSAGE_ID 892 Mime-Version: 1.0 893 Content-Type: text/plain; charset="UTF-8" 894 Content-Transfer-Encoding: 8bit 895 Subject: NON-ASCII-SUBJECT 896 From: DISPLAY-local > 898 To: DISPLAY-remote1 > 900 Cc: DISPLAY-remote2 901 Date: DATE 903 MAIL_BODY 905 Figure 2: SMTP Downgraded envelope/message (example 1) 907 After SMTP downgrading, header fields downgrading is performed. 908 Final downgraded message is shown in Figure 3. Return-Path header 909 will be added by the final destination MTA. 911 Return-Path: 912 Downgraded-Mail-From: =?UTF-8?Q?_?= 913 =?UTF-8?Q??= 914 Downgraded-Rcpt-To: =?UTF-8?Q?_?= 915 =?UTF-8?Q??= 916 Message-Id: MESSAGE_ID 917 Mime-Version: 1.0 918 Content-Type: text/plain; charset="UTF-8" 919 Content-Transfer-Encoding: 8bit 920 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 921 From: =?UTF-8?Q?DISPLAY-local?= 922 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 924 To: =?UTF-8?Q?DISPLAY-remote1?= 925 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= 926 =?UTF-8?Q?>?= 927 Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 928 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; 929 Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= 930 =?UTF-8?Q??= 931 Date: DATE 933 MAIL_BODY 935 Figure 3: Downgraded message (example 1) 937 A.2. Downgrading example 2 939 In many cases, the sender wants to use non-ASCII address and the 940 recipient is a traditional mail user. The SMTP server handing mail 941 for the recipient and/or the recipient's MUA does not support 942 UTF8SMTP extension. Consider a mail message where: 943 o The sender address is "NON-ASCII-local@example.com" which is a 944 non-ASCII address. Its ASCII alternative is 945 "ASCII-local@example.com". It has a display-name "DISPLAY-local" 946 which contains non-ASCII characters. 947 o The "To:" address is "ASCII-remote1@example.net" which is ASCII 948 only. It has a display-name "DISPLAY-remote1" which contains non- 949 ASCII characters. 950 o The "Subject:" header is "NON-ASCII-SUBJECT" which contains non- 951 ASCII characters. 952 The second example envelope/message is shown in Figure 4. 954 MAIL From: 955 ALT-ADDRESS=ASCII-local@example.com 956 RCPT TO: 957 ------------------------------------------------------------- 958 Message-Id: MESSAGE_ID 959 Mime-Version: 1.0 960 Content-Type: text/plain; charset="UTF-8" 961 Content-Transfer-Encoding: 8bit 962 Subject: NON-ASCII-SUBJECT 963 From: DISPLAY-local > 965 To: DISPLAY-remote1 966 Date: DATE 968 MAIL_BODY 970 Figure 4: Original message (example 2) 972 In this example, SMTP session is downgradable. Figure 5 shows SMTP 973 downgraded envelope/message. 975 MAIL From: 976 RCPT TO: 977 ------------------------------------------------------------- 978 Downgraded-Mail-From: =?UTF-8?Q?_?= 979 ?=UTF8?Q??= 980 Message-Id: MESSAGE_ID 981 Mime-Version: 1.0 982 Content-Type: text/plain; charset="UTF-8" 983 Content-Transfer-Encoding: 8bit 984 Subject: NON-ASCII-SUBJECT 985 From: DISPLAY-local > 987 To: DISPLAY-remote1 988 Date: DATE 990 MAIL_BODY 992 Figure 5: SMTP Downgraded envelope/message (example 2) 994 After SMTP downgrading, header fields downgrading is performed. The 995 downgraded example is shown in Figure 6. 997 Return-Path: 998 Downgraded-Mail-From: =?UTF-8?Q?_?= 999 =?UTF8?Q??= 1000 Message-Id: MESSAGE_ID 1001 Mime-Version: 1.0 1002 Content-Type: text/plain; charset="UTF-8" 1003 Content-Transfer-Encoding: 8bit 1004 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 1005 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 1007 From: =?UTF-8?Q?DISPLAY-local?= 1008 To: =?UTF-8?Q?DISPLAY-remote1?= 1009 Date: DATE 1011 MAIL_BODY 1013 Figure 6: Downgraded message (example 2) 1015 Authors' Addresses 1017 Kazunori Fujiwara (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: fujiwara@jprs.co.jp 1026 Yoshiro YONEYA (editor) 1027 JPRS 1028 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 1029 Chiyoda-ku, Tokyo 101-0065 1030 Japan 1032 Phone: +81 3 5215 8451 1033 Email: yone@jprs.co.jp 1035 Full Copyright Statement 1037 Copyright (C) The IETF Trust (2008). 1039 This document is subject to the rights, licenses and restrictions 1040 contained in BCP 78, and except as set forth therein, the authors 1041 retain all their rights. 1043 This document and the information contained herein are provided on an 1044 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1045 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1046 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1047 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1048 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1049 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1051 Intellectual Property 1053 The IETF takes no position regarding the validity or scope of any 1054 Intellectual Property Rights or other rights that might be claimed to 1055 pertain to the implementation or use of the technology described in 1056 this document or the extent to which any license under such rights 1057 might or might not be available; nor does it represent that it has 1058 made any independent effort to identify any such rights. Information 1059 on the procedures with respect to rights in RFC documents can be 1060 found in BCP 78 and BCP 79. 1062 Copies of IPR disclosures made to the IETF Secretariat and any 1063 assurances of licenses to be made available, or the result of an 1064 attempt made to obtain a general license or permission for the use of 1065 such proprietary rights by implementers or users of this 1066 specification can be obtained from the IETF on-line IPR repository at 1067 http://www.ietf.org/ipr. 1069 The IETF invites any interested party to bring to its attention any 1070 copyrights, patents or patent applications, or other proprietary 1071 rights that may cover technology that may be required to implement 1072 this standard. Please address the information to the IETF at 1073 ietf-ipr@ietf.org.