idnits 2.17.1 draft-ietf-eai-downgrade-06.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 1022. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1033. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1040. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1046. 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 (February 14, 2008) is 5916 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 209, 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 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530) Summary: 4 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 Y. YONEYA, Ed. 3 (EAI) K. Fujiwara, Ed. 4 Internet-Draft JPRS 5 Intended status: Experimental February 14, 2008 6 Expires: August 17, 2008 8 Downgrading mechanism for Email Address Internationalization 9 draft-ietf-eai-downgrade-06.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 August 17, 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 . . . . . . . . . . . . . . . . . . . 13 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 72 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 73 11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . . 16 74 11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . . 16 75 11.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . . 16 76 11.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . . 16 77 11.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . . 16 78 11.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . . 16 79 11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . . 16 80 11.8. draft-ietf-eai-downgrade: Version 05 . . . . . . . . . . . 17 81 11.9. draft-ietf-eai-downgrade: Version 06 . . . . . . . . . . . 17 82 12. Normative References . . . . . . . . . . . . . . . . . . . . . 17 83 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 84 A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 18 85 A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 21 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 87 Intellectual Property and Copyright Statements . . . . . . . . . . 24 89 1. Introduction 91 Traditional mail systems which are defined by [RFC2821] and [RFC2822] 92 allow ASCII characters in SMTP envelope and mail header field values. 93 The UTF8SMTP extension [RFC4952], [I-D.ietf-eai-utf8headers] and 94 [I-D.ietf-eai-smtpext] allows UTF-8 characters in SMTP envelope and 95 mail header field values. 97 If an envelope address or header field contains non-ASCII characters, 98 the message cannot be delivered unless every system in the delivery 99 path supports UTF8SMTP. To avoid bouncing such messages when a 100 server is encountered which does not support the UTF8SMTP extension, 101 this document describes a downgrading mechanism. Downgrading a 102 message converts envelope and header fields to an all-ASCII 103 representation. 105 [I-D.ietf-eai-utf8headers] allows UTF-8 characters to be used in mail 106 header fields and MIME header fields. The downgrading mechanism 107 specified here converts mail header fields and MIME header fields to 108 ASCII. 110 This document does not change any protocols except by defining new 111 header fields. It describes the conversion method from the 112 internationalized email envelopes/messages which are defined in 113 [RFC4952] [I-D.ietf-eai-utf8headers] [I-D.ietf-eai-smtpext] to the 114 traditional email envelopes/messages which are defined in [RFC2821] 115 [RFC2822]. 117 [I-D.ietf-eai-smtpext] section 2.2 defines when downgrading occurs. 118 If the SMTP client has an UTF8SMTP envelope or an internationalized 119 message and the SMTP server doesn't support the UTF8SMTP SMTP 120 extension, then the SMTP client MUST NOT send a UTF8SMTP envelope or 121 an internationalized message to the SMTP server. The section shows 4 122 choices. The fourth choice is downgrading, as described here. 124 Downgrading may be implemented in MUAs, MSAs, MTAs which act as the 125 SMTP client, or in MDAs, POP servers, IMAP servers which store or 126 offer UTF8SMTP envelopes or internationalized messages to non- 127 UTF8SMTP compliant systems which include message stores. 129 This document tries to define the downgrading process clearly and it 130 preserves the original information as much as possible. 132 Downgrading in UTF8SMTP consists of the following four parts: 133 o New header fields definition 134 o SMTP downgrading 135 o Email header fields downgrading 136 o MIME header fields downgrading 138 In Section 3, many header fields starting with "downgraded" are 139 introduced. They preserve the original envelope information and the 140 original header fields. 142 The SMTP downgrading is described in Section 4. It generates ASCII 143 only envelope information from an UTF8SMTP envelope. 145 The Email header fields downgrading is described in Section 5. It 146 generates ASCII only header fields. 148 The MIME header fields are expanded in [I-D.ietf-eai-utf8headers]. 149 The MIME header fields downgrading is described in Section 6. It 150 generates ASCII only MIME header fields. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 All specialized terms used in this specification are defined in the 159 EAI overview [RFC4952] or in [RFC2821][RFC2822], MIME documents 160 [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address", 161 "internationalized email address", "non-ASCII address", "i18mail 162 address", "UTF8SMTP", "message" and "mailing list" are used with the 163 definitions from [RFC4952] document. 165 This document depends on [I-D.ietf-eai-smtpext], 166 [I-D.ietf-eai-utf8headers], and [I-D.ietf-eai-dsn]. Key words used 167 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 [I-D.ietf-eai-smtpext] and [I-D.ietf-eai-dsn]. 175 An "UTF8SMTP message" is Email messages expanded by 176 [I-D.ietf-eai-utf8headers]. 178 3. New header fields definition 180 New header fields starting with "Downgraded-" are defined here to 181 preserve those original envelope and header values which contain 182 UTF-8 characters. During downgrading, one new "Downgraded-" header 183 field is added for each original envelope or header field which 184 cannot be passed as-is to a server which does not support UTF8SMTP. 185 The original envelope or header field is removed or rewritten. Only 186 those envelope and header fields which contain non-ASCII characters 187 are affected. The result of this process is a message which is 188 compliant with existing email specifications [RFC2821] and [RFC2822]. 189 The original internationalized information can be retrieved by 190 examining the "Downgraded-" header fields which were added. Even 191 though the information is not lost, the original message cannot be 192 perfectly reconstructed. Hence, downgrading is a one-way process. 193 However, an internationalized client might use the information in the 194 "Downgraded-" header fields when processing a downgraded message, for 195 example, such as displaying or composing a reply. 197 3.1. Envelope information preservation headers 199 Two headers "Downgraded-Mail-From:" and "Downgraded-Rcpt-To:" are 200 defined to preserve SMTP envelope downgraded information. SMTP 201 envelope downgraded information consists of the original non-ASCII 202 address and the downgraded all-ASCII address. The header field 203 syntax is specified as follows: 205 fields =/ downgradedmailfrom / downgradedrcptto 206 downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">" 1*[FWS] 207 "<" Mailbox ">" [FWS] CRLF 208 downgradedrcptto = "Downgraded-Rcpt-To:" [FWS] "<" uPath ">" 1*[FWS] 209 "<" Mailbox ">" [FWS] CRLF 211 Original non-ASCII address is defined in 212 [I-D.ietf-eai-smtpext]; it is treated as unstructured in this header 213 and it is encoded according to [RFC2047]. is defined in 214 [RFC2821], section 4.1.2. 216 3.2. Address header field preservation headers 218 The address header fields preservation headers are defined to 219 preserve the original header field. Their value field holds the 220 original header field value. Any original header field value is 221 treated as an and it MUST be encoded according to 222 [RFC2047] with charset='UTF-8'. The header field syntax is specified 223 as follows: 225 fields =/ known-downgraded-headers ":" unstructued CRLF 226 known-downgraded-headers = "Downgraded-" original-headers 227 original-headers = "From" / "To" / "Cc" / "Bcc" / 228 "Sender" / "Reply-To" / 229 "Resent-From" / "Resent-Sender" / 230 "Resent-To" / "Resent-Cc" / "Return-Path" 232 Preserving a header field in a downgraded header field is defined as: 233 1. Generate new downgraded header field whose value is the original 234 header field value. 235 2. Encode the generated header according to [RFC2047] with 236 charset='UTF-8'. 238 3.3. Unknown header fields preservation headers 240 The unknown header fields preservation headers are defined to 241 encapsulate those original header field which contains non-ASCII 242 characters and are not otherwise provided for in the this 243 specification. The encapsulation header field name is the 244 concatenation of "Downgraded-" and the original name. The value 245 field holds the original header field value. 247 Any original header field value is treated as an unstructured value 248 and it MUST be encoded according to [RFC2047] with charset='UTF-8'. 249 The header field syntax is specified as follows: 251 fields =/ unknown-downgraded-headers ":" unstructued CRLF 252 unknown-downgraded-headers = "Downgraded-" original-header-field-name 253 original-header-field-name = field-name 255 field-name = 1*ftext 257 ftext = %d33-57 / ; Any character except 258 %d59-126 ; controls, SP, and 259 ; ":". 261 Encapsulating a header field in a "Downgraded-" header field is 262 defined as: 263 1. Generate new "Downgraded-" header whose value is the original 264 header field value. 265 2. Encode the generated header field value according to [RFC2047] 266 with charset='UTF-8'. To preserve space characters, the whole 267 header field value which include space characters SHOULD be 268 encoded. 270 3. Remove the original header field. 272 4. SMTP Downgrading 274 Target of downgrading elements in SMTP envelope are below: 276 o MAIL FROM: 277 o RCPT TO: 278 o ORCPT parameter 280 Downgrading the SMTP envelope uses ALT-ADDRESS parameter defined in 281 [I-D.ietf-eai-smtpext]. An address is downgradable if the address is 282 non-ASCII address and has ASCII address specified by ALT-ADDRESS 283 parameter. Since only non-ASCII addresses are downgradable, 284 specifying an ALT-ADDRESS value for an all-ASCII address is invalid 285 for use with this specification, and no interpretation is assigned to 286 it. This restriction allows for future extension of the 287 specification even though no such extensions are currently 288 anticipated. 290 Note that even if no downgrading is performed on the envelope, 291 message header fields and message body MIME header fields that 292 contain non-ASCII characters MUST be downgraded. This is described 293 in Section 5 and Section 6. 295 When downgrading, replace each non-ASCII mail address in the envelope 296 with its specified alternative ASCII address and preserve the 297 original information using "Downgraded-Mail-From" and "Downgraded- 298 Rcpt-To" header fields as defined in Section 3. Before replacing, 299 decode the ALT-ADDRESS parameter value because it is encoded as xtest 300 [RFC3461]. 302 To avoid disclosing recipient addresses, the downgrading process MUST 303 NOT add "Downgraded-Rcpt-To:" header if the SMTP downgrading targets 304 multiple recipients. See Section 7 for more detail. 306 The "RCPT TO" command may have an ORCPT parameter when the recipient 307 address is downgraded. The ORCPT parameter is used for DSN 308 [RFC3461]. If the ORCPT parameter contains an "utf-8" address and 309 the address contains non-ASCII characters, the ORCPT parameter MUST 310 be converted to utf-8-addr-xtext form or utf-8-addr-unitext form 311 which are described in [I-D.ietf-eai-dsn]. 313 As a result of the recipient address replacement, the domain part of 314 the original recipient address may not equal to the domain part of 315 the new recipient address. If the result of address resolution for 316 the domain part of the new recipient address contains the server at 317 the connection destination of the SMTP session for the original 318 recipient address, the SMTP connection is valid for the new recipient 319 address. Otherwise, the downgrading process MUST NOT send the 320 downgraded message to the new recipient address via the connection 321 and MUST try to send the downgraded message to the new recipient 322 address. 324 5. Email header fields downgrading 326 This section defines the conversion method to ASCII for each header 327 field which may contain non-ASCII characters. 329 [I-D.ietf-eai-utf8headers] expands Received: header fields, [RFC2822] 330 ABNF elements , , , , [RFC2045] 331 ABNF element . 333 Header field downgrading is defined below for each ABNF element. 334 Downgrading an unknown header field is also defined as ENCAPSULATION 335 downgrading. Converting the header field terminates when no non- 336 ASCII characters remain in the header field. 338 RECEIVED downgrading: If the header field name is "Received:" and 339 the FOR clause contains a non-ASCII addresses, remove the FOR 340 clause from the header field. The other part does not contain 341 non-ASCII values. 343 UNSTRUCTURED downgrading: If the header field has an 344 field which contains non-ASCII characters, encode the field 345 according to [RFC2047] with charset='UTF-8'. To preserve space 346 characters, the whole header field value which include space 347 characters SHOULD be encoded. 349 WORD downgrading: If the header field has any fields which 350 contains non-ASCII characters, encode the fields according to 351 [RFC2047] with charset='UTF-8'. 353 COMMENT downgrading: If the header field has any fields 354 which contains non-ASCII characters, encode the fields according 355 to [RFC2047] with charset='UTF-8'. 357 MIME-VALUE downgrading: If the header field has any 358 elements defined by [RFC2045] and the elements contain non-ASCII 359 characters, encode the elements by [RFC2231] with 360 charset='UTF-8' and the Language information empty. If the 361 element is and it contains outside 362 the DQUOTE, remove the before this conversion. 364 DISPLAY-NAME downgrading: If the header field has any 365 elements and they have elements which contain non- 366 ASCII characters, encode the elements according to 367 [RFC2047] with charset='UTF-8'. 369 MAILBOX downgrading: The elements have no equivalent 370 format for non-ASCII addresses. If the header field has any 371 elements which contain non-ASCII characters, preserve 372 the header field in each Address header field preservation header 373 defined in Section 3.2, and rewrite each element to 374 ASCII only format. The element which contains non-ASCII 375 characters is one of three formats. 377 * [ Display-name ] "<" Utf8-addr-spec 1*FCS "<" Addr-spec ">>" 379 Rewrite it as 381 [ Display-name ] "<" Addr-spec ">" 383 * [ Display-name ] "<" Utf8-addr-spec ">" 384 * Utf8-addr-spec 386 Rewrite both as 387 [ Display-name ] "Internationalized Address " Encoded-word 388 " Removed:;" 390 where the is the original 391 encoded according to [RFC2047]. 393 ENCAPSULATION downgrading: if the header field contains non-ASCII 394 characters and for which no rule is given above, encapsulate it in 395 a Downgraded header field described in Section 3.3 as a last 396 resort. 398 5.1. Downgrading method for each header field 400 Header fields are listed in [RFC4021]. This section describes the 401 downgrading method for each header field. 403 If the whole mail header field does not contain non-ASCII characters, 404 email header field downgrading is not required. Each header field's 405 downgrading method is described below. 407 o Address header fields which contain s 408 From: 409 Sender: 410 Reply-To: 411 To: 412 Cc: 413 Bcc: 414 Resent-From: 415 Resent-Sender: 416 Resent-To: 417 Resent-Cc: 418 Return-Path: 420 If the header field contains elements which contains 421 non-ASCII addresses, preserve the header field in a downgraded 422 header before the conversion. Then perform COMMENT downgrading, 423 DISPLAY-NAME downgrading and MAILBOX downgrading. 425 o Downgrading Non-ASCII in comments 427 Date: 428 Message-ID: 429 In-Reply-To: 430 References: 431 Resent-Date: 432 Resent-Message-ID: 433 MIME-Version: 434 Content-ID: 436 These header fields do not contain non-ASCII characters except in 437 comments. If the header contains UTF-8 characters in comments, 438 perform COMMENT downgrading. 440 o Trace header fields 442 Received: 444 perform COMMENT downgrading and perform RECEIVED downgrading. 446 o MIME Content header fields 448 Content-Type: 449 Content-Disposition: 451 Perform MIME-VALUE downgrading. 453 o Non-ASCII in 454 Subject: 455 Comments: 456 Content-Description: 458 Perform UNSTRUCTURED downgrading. 460 o Non-ASCII in or 462 Keywords: 464 Perform WORD downgrading. 466 o Other header fields 468 All other header fields which contains non-ASCII characters are 469 user-defined, missing from this draft or future defined header 470 fields. Perform ENCAPSULATION downgrading as a last resort. 472 6. MIME body part headers downgrading 474 MIME body part header fields may contain non-ASCII characters 475 [I-D.ietf-eai-utf8headers]. This section defines the conversion 476 method to ASCII only header fields for each MIME header field which 477 contains non-ASCII characters. Parse the message body's MIME 478 structure for all levels and check each MIME header field whether it 479 contains non-ASCII characters. If the header field contains non- 480 ASCII characters in the header value, the header is a target of the 481 MIME body part headers downgrading. Each MIME header field's 482 downgrading method is described below. COMMENT downgrading, MIME- 483 VALUE downgrading, UNSTRUCTURED downgrading are described in 484 Section 5. 486 Content-ID: 487 The Content-ID: header does not contain non-ASCII characters 488 except in comments. If the header contains UTF-8 characters in 489 comments, perform COMMENT downgrading. 491 Content-Type: 492 Content-Disposition: 493 Perform MIME-VALUE downgrading. 495 Content-Description: 496 Perform UNSTRUCTURED downgrading. 498 7. Security considerations 500 o A Downgraded message's header fields contain ASCII characters 501 only. But they still contain MIME encapsulated header fields 502 which contains non-ASCII UTF-8 characters. And more, the body 503 part may contain UTF-8 message. The recipients need to accept 504 UTF-8 mail body and UTF-8 header fields which is MIME encoded. 505 o Rewriting headers increases the opportunities for undetected 506 spoofing. 508 o Recipients addresses can be undisclosed if those addresses are 509 listed on Bcc or group address. Those undisclosed addresses are 510 used only in the Envelope. Copying information from the Envelope 511 into headers risks inadvertent information disclosure (not just 512 about addresses). See Section 4 for instructions on recipient 513 address handling. 515 o The techniques described here invalidates methods that depend on 516 digital signatures over the envelope or any part of the message 517 which includes the top-level header or body part headers. 518 Depending on the specific message being downgraded, DKIM 519 especially, but also possibly S/MIME, PGP, and similar techniques 520 are all likely to break. 522 o Many gateways and servers on the Internet will discard headers 523 with which they are not familiar. To the extent to which the 524 downgrade procedures depend on new headers (e.g., "Downgraded") to 525 avoid information loss, then the risk of having those headers 526 dropped and its implications must be identified. In particular, 527 it appears to me that, if the Downgraded headers are dropped, 528 there is no possibility of reconstructing the original information 529 at any point (before, during, or after delivery). 531 See "Security considerations" section in [RFC4952] for more 532 discussion. 534 8. Implementation notes 536 Downgrading is an alternative to rejection for delivering messages 537 which require UTF8SMTP support to a server which does not provide 538 this. Implementing the full specification of this document is 539 desirable, but a partial implementation is also possible. 541 If a partial downgrading implementation confronts an unsupported 542 downgrading target, the implementation MUST NOT send the message to 543 server which does not support UTF8SMTP. Instead, it MUST reject the 544 message or generate a notification of non-deliverability. 546 8.1. Trivial downgrading 548 A partial downgrading, Trivial downgrading is discussed. It does not 549 support non-ASCII addresses in SMTP envelope and address header 550 fields, unknown header fields downgrading, the MIME body part headers 551 downgrading. It supports 552 o some simple header fields downgrading: Subject 553 o comments and display name downgrading: From, To, CC 554 o trace header field downgrading: Received 556 Otherwise, the downgrading fails. 558 Trivial downgrading targets mail messages which are generated by 559 UTF8SMTP aware MUAs and contain non-ASCII characters in comments, 560 display names, unstructured parts without using non-ASCII E-mail 561 addresses. This E-mail message does not contain non-ASCII addresses 562 in SMTP Envelope and its header fields. But it is not deliverable 563 via UTF8SMTP un-aware MTA. Implementing full spec downgrading may be 564 hard, but trivial downgrading saves mail messages without using non- 565 ASCII addresses. 567 9. IANA Considerations 569 IANA is requested to register the following header fields in the 570 Permanent Message Header Field Repository, in accordance with the 571 procedures set out in [RFC3864]. 573 Header field name: Downgraded-Mail-From 574 Applicable protocol: mail 575 Status: experimental 576 Author/change controller: IETF 577 Specification document(s): This document (Section 3) 579 Header field name: Downgraded-Rcpt-To 580 Applicable protocol: mail 581 Status: experimental 582 Author/change controller: IETF 583 Specification document(s): This document (Section 3) 585 Header field name: Downgraded-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-Sender 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-To 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-Cc 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-Reply-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-Bcc 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-Resent-From 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-Resent-To 628 Applicable protocol: mail 629 Status: experimental 630 Author/change controller: IETF 631 Specification document(s): This document (Section 3) 633 Header field name: Downgraded-Resent-Cc 634 Applicable protocol: mail 635 Status: experimental 636 Author/change controller: IETF 637 Specification document(s): This document (Section 3) 639 Header field name: Downgraded-Resent-Sender 640 Applicable protocol: mail 641 Status: experimental 642 Author/change controller: IETF 643 Specification document(s): This document (Section 3) 645 Header field name: Downgraded-Return-Path 646 Applicable protocol: mail 647 Status: experimental 648 Author/change controller: IETF 649 Specification document(s): This document (Section 3) 651 And more, IANA is requested to reserve all the field names that start 652 by "Downgraded-" for unknown header fields downgrading described in 653 Section 3.3, in accordance with the procedures set out in [RFC3864]. 655 Header field name: Names which starts by "Downgraded-" 656 Applicable protocol: mail 657 Status: experimental 658 Author/change controller: IETF 659 Specification document(s): This document (Section 3) 661 10. Acknowledgements 663 Significant comments and suggestions were received from John Klensin, 664 Harald Alvestrand, Chris Newman, Randall Gellens, Charles Lindsey, 665 Marcos Sanz, Alexey Melnikov, Frank Ellermann, Edward Lewis, S. 666 Moonesamy and JET members. 668 11. Change History 670 This section is used for tracking the update of this document. Will 671 be removed after finalize. 673 11.1. draft-yoneya-ima-downgrade: Version 00 675 o Initial version 676 o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00 678 11.2. draft-yoneya-ima-downgrade: Version 01 680 o Document structure was changed 681 o Followed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02 682 o Downgrading requirements were added 683 o SMTP DATA encapsulation method was proposed 684 o Downgrading examples was provided 686 11.3. draft-ietf-eai-downgrade: Version 00 688 o Followed draft-yeh-ima-utf8headers-01 and 689 draft-ietf-eai-smtpext-00 690 o No header downgrading method was proposed 691 o Header encapsulation method was proposed 693 11.4. draft-ietf-eai-downgrade: Version 01 695 o Followed draft-ietf-eai-utf8headers-00 696 o Header conversion and encapsulation method was merged 697 o Header conversion method was defined in detail 699 11.5. draft-ietf-eai-downgrade: Version 02 701 o Followed draft-ietf-eai-utf8headers-01 and 702 draft-ietf-eai-smtpext-01 703 o Specification about algorithmic generated address is removed 704 o No header downgrading method was removed 705 o SMTP DATA encapsulation method was removed 707 11.6. draft-ietf-eai-downgrade: Version 03 709 o Followed draft-ietf-eai-utf8headers-03 and 710 draft-ietf-eai-smtpext-03 711 o Downgraded: and Envelope-Downgraded: headers definition was added 712 o Mail header fields downgrading method was refined 713 o Examples in Appendix A were refined 715 11.7. draft-ietf-eai-downgrade: Version 04 717 o Followed draft-ietf-eai-utf8headers-06, draft-ietf-eai-smtpext-07 718 and draft-ietf-eai-dsn-02 720 o Downgrading requirements and conditions were moved to 721 Introduction. 722 o Descriptions about upgrading were removed. 723 o SPF and DKIM discussion were removed. 724 o Added many header fields downgrading. 725 o Allow address literal rewriting without alternate ASCII address in 726 header fields. 727 o Added MIME body part headers downgrading. 728 o Added ORCPT downgrading. 730 11.8. draft-ietf-eai-downgrade: Version 05 732 o fixed examples 733 * ALT-ADDRESS parameter mistake 734 * RFC2047(x) notation was changed to encoded-word format 735 o Added implementation consideration section and trivial downgrading 736 o Downgraded: and Envelope-Downgraded: headers are separated for 737 each original headers. 738 o Removed list-* header fields downgrading 739 o Changed the way of writing the header field downgrading section 741 11.9. draft-ietf-eai-downgrade: Version 06 743 o Moved decoding downgraded messages as a separate document 744 o Added a text to UNSTRUCTURED downgrading 745 o Added "replacing SMTP connection" if necessary to SMTP 746 downgrading. 747 o fixed examples 749 12. Normative References 751 [I-D.ietf-eai-dsn] 752 Newman, C. and A. Melnikov, "Internationalized Delivery 753 Status and Disposition Notifications", 754 draft-ietf-eai-dsn-06 (work in progress), January 2008. 756 [I-D.ietf-eai-smtpext] 757 Yao, J. and W. MAO, "SMTP extension for internationalized 758 email address", draft-ietf-eai-smtpext-11 (work in 759 progress), January 2008. 761 [I-D.ietf-eai-utf8headers] 762 Yeh, J., "Internationalized Email Headers", 763 draft-ietf-eai-utf8headers-09 (work in progress), 764 February 2008. 766 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 767 Extensions (MIME) Part One: Format of Internet Message 768 Bodies", RFC 2045, November 1996. 770 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 771 Part Three: Message Header Extensions for Non-ASCII Text", 772 RFC 2047, November 1996. 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, March 1997. 777 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 778 Presentation Information in Internet Messages: The 779 Content-Disposition Header Field", RFC 2183, August 1997. 781 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 782 Word Extensions: 783 Character Sets, Languages, and Continuations", RFC 2231, 784 November 1997. 786 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 787 April 2001. 789 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 790 April 2001. 792 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 793 Extension for Delivery Status Notifications (DSNs)", 794 RFC 3461, January 2003. 796 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 797 Procedures for Message Header Fields", BCP 90, RFC 3864, 798 September 2004. 800 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 801 Header Fields", RFC 4021, March 2005. 803 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 804 Internationalized Email", RFC 4952, July 2007. 806 Appendix A. Examples 808 A.1. Downgrading example 1 810 This section shows an SMTP Downgrading example. Consider a mail 811 message. 813 o The sender address is "NON-ASCII-local@example.com" which is non- 814 ASCII address. Its ASCII alternative is "ASCII-local@example.com" 815 and its display-name is "DISPLAY-local". 816 o The "To" address is "NON-ASCII-remote1@example.net" which is non- 817 ASCII address. Its ASCII alternative is 818 "ASCII-remote1@example.net" and its display-name is "DISPLAY- 819 remote1". 820 o The "CC" address is non-ASCII address 821 "NON-ASCII-remote2@example.org" without alternative ASCII address. 822 Its display-name is "DISPLAY-remote2". 823 o Three display-names contains non-ASCII characters. 824 o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII 825 characters. 826 o assume To: recipient's MTA (example.net) does not support 827 UTF8SMTP. 828 o assume Cc: recipient's MTA (example.org) supports UTF8SMTP. 829 The example SMTP envelope/message is showin in Figure 4. In this 830 example, the To: recipient's session is fucused. 832 MAIL FROM: 833 ALT-ADDRESS=ASCII-local@example.com 834 RCPT TO: 835 ALT-ADDRESS=ASCII-remote1@example.net 836 RCPT TO: 837 ------------------------------------------------------------- 838 Message-Id: MESSAGE_ID 839 Mime-Version: 1.0 840 Content-Type: text/plain; charset="UTF-8" 841 Content-Transfer-Encoding: 8bit 842 Subject: NON-ASCII-SUBJECT 843 From: DISPLAY-local > 845 To: DISPLAY-remote1 > 847 CC: DISPLAY-remote2 848 Date: DATE 850 MAIL_BODY 852 Figure 4: Original envelope/message (example 1) 854 In this example, there are two SMTP recipients, one is To:, the other 855 is CC:. The SMTP downgrading treats To: session downgrading. 856 Figure 5 shows SMTP downgraded example. 858 MAIL FROM: 859 RCPT TO: 860 ------------------------------------------------------------- 861 Downgraded-Mail-From: =?UTF-8?Q?_?= 862 =?UTF-8?Q??= 863 Downgraded-Rcpt-To: =?UTF-8?Q?_?= 864 =?UTF-8?Q??= 865 Message-Id: MESSAGE_ID 866 Mime-Version: 1.0 867 Content-Type: text/plain; charset="UTF-8" 868 Content-Transfer-Encoding: 8bit 869 Subject: NON-ASCII-SUBJECT 870 From: DISPLAY-local > 872 To: DISPLAY-remote1 > 874 CC: DISPLAY-remote2 875 Date: DATE 877 MAIL_BODY 879 Figure 5: SMTP Downgraded envelope/message (example 1) 881 After SMTP downgrading, header fields downgrading is performed. 882 Final downgraded message is shown in Figure 6. Return-Path header 883 will be added by the final destination MTA. 885 Return-Path: 886 Downgraded-Mail-From: =?UTF-8?Q?_?= 887 =?UTF-8?Q??= 888 Downgraded-Rcpt-To: =?UTF-8?Q?_?= 889 =?UTF-8?Q??= 890 Message-Id: MESSAGE_ID 891 Mime-Version: 1.0 892 Content-Type: text/plain; charset="UTF-8" 893 Content-Transfer-Encoding: 8bit 894 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 895 From: =?UTF-8?Q?DISPLAY-local?= 896 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 898 To: =?UTF-8?Q?DISPLAY-remote1?= 899 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= 900 =?UTF-8?Q?>?= 901 CC: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 902 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; 903 Downgraded-CC: =?UTF-8?Q?DISPLAY-remote2_?= 904 =?UTF-8?Q??= 905 Date: DATE 907 MAIL_BODY 909 Figure 6: Downgraded message (example 1) 911 A.2. Downgrading example 2 913 In many cases, the sender wants to use non-ASCII address, the 914 recipient does not support UTF8SMTP and does not have non-ASCII 915 address. 916 o The sender address is "NON-ASCII-local@example.com" which is non- 917 ASCII address. Its ASCII alternative is 918 "ASCII-local@example.com". It has a display-name "DISPLAY-local" 919 which contains non-ASCII characters. 920 o The "To" address is "ASCII-remote1@example.net" which is ASCII 921 only. It has a display-name "DISPLAY-remote1" which contains non- 922 ASCII characters. 923 o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII 924 characters. 925 The second example envelope/message is shown in Figure 7. 927 MAIL From: 928 ALT-ADDRESS=ASCII-local@example.com 929 RCPT TO: 930 ------------------------------------------------------------- 931 Message-Id: MESSAGE_ID 932 Mime-Version: 1.0 933 Content-Type: text/plain; charset="UTF-8" 934 Content-Transfer-Encoding: 8bit 935 Subject: NON-ASCII-SUBJECT 936 From: DISPLAY-local > 938 To: DISPLAY-remote1 939 Date: DATE 941 MAIL_BODY 943 Figure 7: Original message (example 2) 945 In this example, SMTP session is downgradable. Figure 8 shows SMTP 946 downgraded envelope/message. 948 MAIL From: 949 RCPT TO: 950 ------------------------------------------------------------- 951 Downgraded-Mail-From: =?UTF-8?Q?_?= 952 ?=UTF8?Q??= 953 Message-Id: MESSAGE_ID 954 Mime-Version: 1.0 955 Content-Type: text/plain; charset="UTF-8" 956 Content-Transfer-Encoding: 8bit 957 Subject: NON-ASCII-SUBJECT 958 From: DISPLAY-local > 960 To: DISPLAY-remote1 961 Date: DATE 963 MAIL_BODY 965 Figure 8: SMTP Downgraded envelope/message (example 2) 967 After SMTP downgrading, header fields downgrading is performed. The 968 downgraded example is shown in Figure 9. 970 Return-Path: 971 Downgraded-Mail-From: =?UTF-8?Q?_?= 972 =?UTF8?Q??= 973 Message-Id: MESSAGE_ID 974 Mime-Version: 1.0 975 Content-Type: text/plain; charset="UTF-8" 976 Content-Transfer-Encoding: 8bit 977 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 978 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 980 From: =?UTF-8?Q?DISPLAY-local?= 981 To: =?UTF-8?Q?DISPLAY-remote1?= 982 Date: DATE 984 MAIL_BODY 986 Figure 9: Downgraded message (example 2) 988 Authors' Addresses 990 Yoshiro YONEYA (editor) 991 JPRS 992 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 993 Chiyoda-ku, Tokyo 101-0065 994 Japan 996 Phone: +81 3 5215 8451 997 Email: yone@jprs.co.jp 999 Kazunori Fujiwara (editor) 1000 JPRS 1001 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 1002 Chiyoda-ku, Tokyo 101-0065 1003 Japan 1005 Phone: +81 3 5215 8451 1006 Email: fujiwara@jprs.co.jp 1008 Full Copyright Statement 1010 Copyright (C) The IETF Trust (2008). 1012 This document is subject to the rights, licenses and restrictions 1013 contained in BCP 78, and except as set forth therein, the authors 1014 retain all their rights. 1016 This document and the information contained herein are provided on an 1017 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1018 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1019 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1020 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1021 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1022 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1024 Intellectual Property 1026 The IETF takes no position regarding the validity or scope of any 1027 Intellectual Property Rights or other rights that might be claimed to 1028 pertain to the implementation or use of the technology described in 1029 this document or the extent to which any license under such rights 1030 might or might not be available; nor does it represent that it has 1031 made any independent effort to identify any such rights. Information 1032 on the procedures with respect to rights in RFC documents can be 1033 found in BCP 78 and BCP 79. 1035 Copies of IPR disclosures made to the IETF Secretariat and any 1036 assurances of licenses to be made available, or the result of an 1037 attempt made to obtain a general license or permission for the use of 1038 such proprietary rights by implementers or users of this 1039 specification can be obtained from the IETF on-line IPR repository at 1040 http://www.ietf.org/ipr. 1042 The IETF invites any interested party to bring to its attention any 1043 copyrights, patents or patent applications, or other proprietary 1044 rights that may cover technology that may be required to implement 1045 this standard. Please address the information to the IETF at 1046 ietf-ipr@ietf.org. 1048 Acknowledgment 1050 Funding for the RFC Editor function is provided by the IETF 1051 Administrative Support Activity (IASA).