idnits 2.17.1 draft-ietf-eai-downgrade-04.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 902. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 913. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 926. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 6, 2007) is 6129 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 202, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-eai-dsn-02 == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-07 == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-05 ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 3 errors (**), 0 flaws (~~), 6 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 July 6, 2007 6 Expires: January 7, 2008 8 Downgrading mechanism for Email Address Internationalization 9 draft-ietf-eai-downgrade-04.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 7, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Traditional mail systems handle only US-ASCII characters in SMTP 43 envelope and mail header fields. The Email Address 44 Internationalization (UTF8SMTP) allows UTF-8 characters in SMTP 45 envelope and mail header fields. To deliver internationalized Email 46 messages to/via UTF8SMTP non-compliant environment, some sort of 47 converting mechanism is required. This document describes 48 downgrading mechanism for Email Address Internationalization. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. New header fields definition . . . . . . . . . . . . . . . . . 4 55 4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Email header fields downgrading . . . . . . . . . . . . . . . 6 57 6. MIME body part headers downgrading . . . . . . . . . . . . . . 9 58 7. Security considerations . . . . . . . . . . . . . . . . . . . 10 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 61 10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11 62 10.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . 11 63 10.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . 11 64 10.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . 11 65 10.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . 12 66 10.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . 12 67 10.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . 12 68 10.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . 12 69 11. Normative References . . . . . . . . . . . . . . . . . . . . . 12 70 Appendix A. Displaying downgraded message . . . . . . . . . . . . 14 71 A.1. Displaying technique 1 . . . . . . . . . . . . . . . . . 14 72 A.2. Displaying technique 2 . . . . . . . . . . . . . . . . . 14 73 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 14 74 B.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 14 75 B.2. Displaying example (Displaying technique 1) . . . . . . . 17 76 B.3. Displaying example (Displaying technique 2) . . . . . . . 17 77 B.4. Downgrading example 2 . . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 79 Intellectual Property and Copyright Statements . . . . . . . . . . 22 81 1. Introduction 83 Traditional mail systems which are defined by [RFC2821] and [RFC2822] 84 allow US-ASCII characters in SMTP envelope and mail header field 85 values. The UTF8SMTP proposals [I-D.ietf-eai-framework], 86 [I-D.ietf-eai-utf8headers] and [I-D.ietf-eai-smtpext] allow UTF-8 87 characters in SMTP envelope and mail header field values. 89 Delivering non-ASCII mail addresses from a sender to recipients 90 requires all components on the mail delivery route are UTF8SMTP 91 compliant. Otherwise, non-ASCII mail address can't be delivered. To 92 solve the problem, this document describes downgrading mechanism that 93 enables delivering non-ASCII mail addresses to traditional mail 94 system by converting them to corresponding US-ASCII representation. 95 And more, [I-D.ietf-eai-utf8headers] expands that mail header fields 96 and MIME header fields are allowed to use any UTF-8 characters. This 97 downgrading mechanism targets mail header fields and MIME header 98 fields to be converted to US-ASCII only to send to UTF8SMTP non- 99 compliant receivers. 101 [I-D.ietf-eai-smtpext] section 2.2 defines when downgrading occurs. 102 Mail clients (MUAs, MSAs, MTAs) try to deliver Email messages to SMTP 103 servers by static setting or DNS MX resource records resolution. If 104 the SMTP client has an UTF8SMTP envelope or an UTF8SMTP message and 105 the SMTP client detects that SMTP server doesn't support "UTF8SMTP" 106 option at EHLO, then the SMTP client MUST NOT send the UTF8SMTP 107 envelope or UTF8SMTP message to the SMTP server. The section shows 4 108 choices. The second choice "reject or generate a notification of 109 non-deliverability" is always allowed. The fourth choice is 110 downgrading. 112 Downgrading may be implemented in MUAs, MSAs, MTAs, MDAs which 113 generates or receives UTF8SMTP envelopes or UTF8SMTP messages and may 114 send them to non-UTF8SMTP compliant systems. 116 This document tries to define the downgrading process clearly and it 117 preserves the original information as much as possible. 119 Downgrading in UTF8SMTP consists of the following four parts: 120 o New header fields definition 121 o SMTP downgrading 122 o Email header fields downgrading 123 o MIME header fields downgrading 124 Before sending to traditional SMTP server, the downgrading process 125 need to perform SMTP downgrading, Email header fields downgrading, 126 and MIME header fields downgrading. 128 In Section 3, two header fields are introduced. One is "Envelope- 129 Downgraded:", it preserves the original envelope information. The 130 other is "Downgraded:", it preserves the original header fields which 131 contains non-ASCII email addresses or which does not have clear 132 downgrading definition. 134 The SMTP downgradin is described in Section 4. It generates US-ASCII 135 only envelope information from an UTF8SMTP envelope. 137 The Email header fields downgrading is described in Section 5. It 138 generates US-ASCII only header fields. 140 The MIME header fields are expanded in [I-D.ietf-eai-utf8headers]. 141 The MIME header fields downgrading is described in Section 6. It 142 generates US-ASCII only MIME header fields. 144 2. Terminology 146 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 147 and "MAY" in this document are to be interpreted as described in RFC 148 2119 [RFC2119]. 150 All specialized terms used in this specification are defined in the 151 EAI overview [I-D.ietf-eai-framework] or in [RFC2821][RFC2822], MIME 152 documents [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII 153 address", "internationalized email address", "non-ASCII address", 154 "i18mail address", "UTF8SMTP", "message" and "mailing list" are used 155 with the definitions from [I-D.ietf-eai-framework] document. 157 This document depends on [I-D.ietf-eai-smtpext], 158 [I-D.ietf-eai-utf8headers], and [I-D.ietf-eai-dsn]. Key words used 159 in these document are used in this document, too. 161 The term "non-ASCII" is an UTF-8 string which contains at least one 162 non-ASCII character. 164 An "UTF8SMTP envelope" has Email originator/recipient addresses 165 expanded by [I-D.ietf-eai-smtpext] and [I-D.ietf-eai-dsn]. 167 An "UTF8SMTP message" is Email messages expanded by 168 [I-D.ietf-eai-utf8headers]. 170 3. New header fields definition 172 A generic encapsulation header "Downgraded:" is defined to preserve 173 the original header field. It has two value fields. The former 174 value field holds the original header field name. The latter value 175 field holds the original header field value. Any original header 176 field value is treated as an unstructured value. The latter value 177 field of this header MUST be encoded by [RFC2047] section 5(1) method 178 with charset='UTF-8' same as a 'Subject' header. The header field 179 syntax is specified as follows: 181 fields =/ downgraded 182 downgraded = "Downgraded:" [FWS] field-name ":" unstructured CRLF 184 Encapsulating a header in a Downgraded: header is defined as: 185 1. Generate new Downgraded: header whose former value is the 186 original header field name and latter value is the original 187 header fleid value. 188 2. Encode the generated header by [RFC2047] section 5(1) method with 189 charset='UTF-8'. 190 3. Replace the original header field as the generated header field. 192 Another new header "Envelope-Downgraded:" is defined to preserve SMTP 193 envelope downgraded information. SMTP envelope downgraded 194 information consists of the original non-ASCII address and the 195 downgraded all-ASCII address. The non-ASCII address is encoded by 196 [RFC2047] with charset='UTF-8'. The header field syntax is specified 197 as follows: 199 fields =/ edowngraded 200 edowngraded = "Envelope-Downgraded:" [FWS] edowngraded-field ":" 201 [FWS] "<" uPath ">" [FWS] 202 "<" Mailbox ">" [FWS] CRLF 203 edowngraded-field = "From" / "To" 205 Original non-ASCII address is defined in 206 [I-D.ietf-eai-smtpext]. is defined in [RFC2821], section 207 4.1.2. The "Envelope-Downgraded:" header field is encoded by 208 [RFC2047] in the downgraded message. 210 4. SMTP Downgrading 212 Target of downgrading elements in SMTP envelope are below: 214 o MAIL FROM: 215 o RCPT TO: 216 o ORCPT parameter 218 Downgrading in SMTP envelope uses ALT-ADDRESS parameter defined in 219 [I-D.ietf-eai-smtpext]. An address is downgradable if the address is 220 US-ASCII address or the address has US-ASCII address specified by 221 ALT-ADDRESS parameter. 223 If each recipient address and the return address is downgradable, the 224 SMTP to the recipient is downgradable. 226 Even if no downgrading is performed for envelope from/to, MUA/MTA 227 MUST downgrade message header fields and MIME header fields in the 228 message body including non-ASCII characters. This is described in 229 Section 5 and Section 6. 231 MTA replaces non-ASCII mail address with specified alternative US- 232 ASCII address when downgrading. Before replacing, decode the ALT- 233 ADDRESS parameter value because it is encoded as xtest [RFC3461]. 234 Also MTA preserves original information using "Envelope-Downgraded" 235 header defined in Section 3 with From or To field name. The non- 236 ASCII mail addresses are encoded by [RFC2047] and put into "Envelope- 237 Downgraded" header. 239 Not to disclose whole recipient addresses, MUA/MTA MUST NOT add 240 "Envelope-Downgraded: To:" header if the SMTP downgrading targets 241 multiple recipients. See Section 7 for more detail. 243 While the recipient address downgrading, the "RCPT TO" command may 244 have an ORCPT parameter. The ORCPT parameter is used for DSN 245 [RFC3461]. If the ORCPT parameter contains "utf-8" address type 246 address and the address contains non-ASCII characters, the ORCPT 247 parameter MUST be converted to utf-8-addr-xtext form or utf-8-addr- 248 unitext form which is described in [I-D.ietf-eai-dsn]. 250 5. Email header fields downgrading 252 This section defines conversion method to US-ASCII for each header 253 field which may contain non-ASCII characters. Header fields are 254 listed in [RFC4021]. If the whole mail header field does not contain 255 non-ASCII characters, email header field downgrading is not required. 256 If the header field contains non-ASCII characters, convert the header 257 field. Each header field's downgrading method is described below. 259 o Downgrading Address header fields 261 From: 262 Sender: 264 Reply-To: 265 To: 266 Cc: 267 Bcc: 268 Resent-From: 269 Resent-Sender: 270 Resent-To: 271 Resent-Cc: 273 The header field value is composed of single or multiple / fields defined in 275 [I-D.ietf-eai-utf8headers]. 276 If the header has no or which 277 contains non-ASCII characters, only "display-name" part or 278 comments contain non-ASCII characters, the "display-name" or 279 comments are encoded by [RFC2047] with charset='UTF-8'. 280 Otherwise, preserve the header field in "Downgraded:" header, 281 generate US-ASCII only address header, and replace the original 282 header field with the generated US-ASCII only header field. New 283 header generation method are shown in below. 285 Extract every field and downgrade each // 286 . 288 If the non-ASCII address is in form, then rewrite 289 it as "Internationalized Address utf8-addr-spec-encoded 290 Removed:;". "utf8-addr-spec" is encoded to "utf8-addr-spec- 291 encoded" by [RFC2047]. 293 The field may contain multiple fields. The 294 fields are encoded by [RFC2047] with charset='UTF-8', if 295 necessary. 297 is defined as "display-name " in 298 [I-D.ietf-eai-utf8headers]. The "display-name" field is encoded 299 by [RFC2047] with charset='UTF-8', if necessary. 301 The may contain comments. Before processing, remove 302 comments from the . 304 UTF8SMTP defined in [I-D.ietf-eai-utf8headers] 305 consists of 3 forms. Downgrading method is defined for each form. 307 * 308 is used as is. 309 * 310 Non-ASCII mail address without sender-specified US-ASCII 311 address is replaced as 312 "Internationalized Address non-ASCII-encoded Removed:;". 313 non-ASCII address is encoded to "non-ASCII-encoded" by 314 [RFC2047]. 315 * > 316 Non-ASCII mail address with sender-specified US-ASCII address 317 MUST be replaced as "display-name ". 319 o Downgrading Non-ASCII in comments 321 Date: 322 Message-ID: 323 In-Reply-To: 324 References: 325 Resent-Date: 326 Resent-Message-ID: 327 MIME-Version: 328 Content-ID: 330 These header fields do not contain non-ASCII characters except in 331 comments. If the header contains UTF-8 characters in comments, 332 encode the header by [RFC2047] with charset='UTF-8'. 334 o Trace header 336 Received: 338 If the FOR clause contains non-ASCII addresses, remove the FOR 339 clause in the header. The other part does not contain non-ASCII 340 values. 342 o MIME Content header 344 Content-Type: 345 Content-Disposition: 347 Encode the header by [RFC2231] with charset='UTF-8'. 349 o Unstructured text headers and structured text headers 351 Subject: 352 Comments: 353 Keywords: 354 Content-Description: 356 Encode the header by [RFC2047] with charset='UTF-8'. 358 o URI headers 360 List-Archive: 361 List-Help: 362 List-Owner: 363 List-Post: 364 List-Subscribe: 365 List-Unsubscribe: 367 If the header contains UTF-8 characters in comments, encode the 368 header by [RFC2047] with charset='UTF-8'. If the header contains 369 UTF-8 characters in URI, Encode the URI by [RFC3987]. 371 o Other target headers 372 All other headers which contains non-ASCII characters are 373 preserved in Downgraded: header and removed. 375 o ASCII only headers 377 Content-Transfer-Encoding: 379 This header is not target of downgrading. 381 Downgraded header fields should be inserted or replaced at the same 382 position of the original header field. 384 6. MIME body part headers downgrading 386 MIME body part header fields may contain non-ASCII characters 387 [I-D.ietf-eai-utf8headers]. This section defines conversion method 388 to US-ASCII for each MIME header field which may contain non-ASCII 389 characters. Parse the message body's MIME structure for all level 390 and check all MIME header fields whether contains non-ASCII 391 characters. If the header contains non-ASCII characters in the 392 header value, the header is a target of the MIME body part headers 393 downgrading. Each MIME header field's downgrading method is 394 described below: 396 Content-ID: 397 The Content-ID: header does not contain non-ASCII characters 398 except in comments. If the header contains UTF-8 characters in 399 comments, encode the header by [RFC2047] with charset='UTF-8'. 401 Content-Type: 402 Content-Disposition: 403 Encode the header by [RFC2231] with charset='UTF-8'. 405 Content-Description: 406 Encode the header by [RFC2047] with charset='UTF-8'. 408 Content-Transfer-Encoding: 409 This header does not contain non-ASCII characters. 411 7. Security considerations 413 o Rewriting headers increases the opportunities for undetected 414 spoofing. 415 o Recipients addresses can be undisclosed if those addresses are 416 listed on Bcc or group address. Those undisclosed addresses are 417 used only in the Envelope. Copying information from the Envelope 418 into headers creates some risk of inadvertent information 419 disclosure (not just about addresses). 420 o It is likely that the techniques suggested here will invalidate 421 methods that depend on signatures over headers or the envelope. 422 "Issues" does talk about that, but, because this document strongly 423 implies that one can downgrade and then upgrade again with no risk 424 of loss of information, the topic should be explored further. 425 o Many gateways and servers on the Internet will discard headers 426 with which they are not familiar. To the extent to which the 427 downgrade procedures depend on new headers (e.g., "Downgraded") to 428 avoid information loss, then the risk of having those headers 429 dropped and its implications must be identified. In particular, 430 it appears to me that, if the Downgraded headers are dropped, 431 there is no possibility of reconstructing the original information 432 at any point (before, during, or after delivery). 434 See "Security considerations" section in [I-D.ietf-eai-framework] for 435 more discussion. 437 8. IANA Considerations 439 IANA is requested to register the following header fields in the 440 Permanent Message Header Field Repository, in accordance with the 441 procedures set out in [RFC3864]. 443 Header field name: Downgraded 444 Applicable protocol: mail 445 Status: experimental 446 Author/change controller: IETF 447 Specification document(s): This document (Section 3) 449 Header field name: Envelope-Downgraded 450 Applicable protocol: mail 451 Status: experimental 452 Author/change controller: IETF 453 Specification document(s): This document (Section 3) 455 9. Acknowledgements 457 Significant comments and suggestions were received from John Klensin, 458 Harald Alvestrand, Chris Newman, Charles Lindsey, Marcos Sanz, Alexey 459 Melnikov, Frank Ellermann and JET members. 461 10. Change History 463 This section is used for tracking the update of this document. Will 464 be removed after finalize. 466 10.1. draft-yoneya-ima-downgrade: Version 00 468 o Initial version 469 o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00 471 10.2. draft-yoneya-ima-downgrade: Version 01 473 o Document structure was changed 474 o Followed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02 475 o Downgrading requirements were added 476 o SMTP DATA encapsulation method was proposed 477 o Downgrading examples was provided 479 10.3. draft-ietf-eai-downgrade: Version 00 481 o Followed draft-yeh-ima-utf8headers-01 and 482 draft-ietf-eai-smtpext-00 483 o No header downgrading method was proposed 484 o Header encapsulation method was proposed 486 10.4. draft-ietf-eai-downgrade: Version 01 488 o Followed draft-ietf-eai-utf8headers-00 489 o Header conversion and encapsulation method was merged 490 o Header conversion method was defined in detail 492 10.5. draft-ietf-eai-downgrade: Version 02 494 o Followed draft-ietf-eai-utf8headers-01 and 495 draft-ietf-eai-smtpext-01 496 o Specification about algorithmic generated address is removed 497 o No header downgrading method was removed 498 o SMTP DATA encapsulation method was removed 500 10.6. draft-ietf-eai-downgrade: Version 03 502 o Followed draft-ietf-eai-utf8headers-03 and 503 draft-ietf-eai-smtpext-03 504 o Downgraded: and Envelope-Downgraded: headers definition was added 505 o Mail header downgrading method was refined 506 o Examples in Appendix A were refined 508 10.7. draft-ietf-eai-downgrade: Version 04 510 o Followed draft-ietf-eai-utf8headers-06, draft-ietf-eai-smtpext-07 511 and draft-ietf-eai-dsn-02 512 o Downgrading requirements and conditions were moved to 513 Introduction. 514 o Descriptions about upgrading were removed. 515 o SPF and DKIM discussion were removed. 516 o Added many header fields downgrading. 517 o Allow address literal rewriting without alternate US-ASCII address 518 in header fields. 519 o Added MIME body part headers downgrading. 520 o Added ORCPT downgrading. 522 11. Normative References 524 [I-D.ietf-eai-dsn] 525 Newman, C. and A. Melnikov, "International Delivery and 526 Disposition Notifications", draft-ietf-eai-dsn-02 (work in 527 progress), July 2007. 529 [I-D.ietf-eai-framework] 530 Klensin, J. and Y. Ko, "Overview and Framework for 531 Internationalized Email", draft-ietf-eai-framework-05 532 (work in progress), February 2007. 534 [I-D.ietf-eai-smtpext] 535 Yao, J. and W. Mao, "SMTP extension for internationalized 536 email address", draft-ietf-eai-smtpext-07 (work in 537 progress), June 2007. 539 [I-D.ietf-eai-utf8headers] 540 Yeh, J., "Internationalized Email Headers", 541 draft-ietf-eai-utf8headers-05 (work in progress), 542 April 2007. 544 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 545 Extensions (MIME) Part One: Format of Internet Message 546 Bodies", RFC 2045, November 1996. 548 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 549 Part Three: Message Header Extensions for Non-ASCII Text", 550 RFC 2047, November 1996. 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, March 1997. 555 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 556 Presentation Information in Internet Messages: The 557 Content-Disposition Header Field", RFC 2183, August 1997. 559 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 560 Word Extensions: 561 Character Sets, Languages, and Continuations", RFC 2231, 562 November 1997. 564 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 565 April 2001. 567 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 568 April 2001. 570 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 571 Extension for Delivery Status Notifications (DSNs)", 572 RFC 3461, January 2003. 574 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 575 Procedures for Message Header Fields", BCP 90, RFC 3864, 576 September 2004. 578 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 579 Identifiers (IRIs)", RFC 3987, January 2005. 581 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 582 Header Fields", RFC 4021, March 2005. 584 Appendix A. Displaying downgraded message 586 Displaying downgraded message is mostly retrieved by MIME decoding 587 [RFC2047][RFC2231]. Result of MIME decoding, downgraded address 588 header fields and undefined header fields are still in Downgraded: 589 headers, but it is MIME decoded. This decoded Downgraded: headers 590 contain the original headers and the recipient can read them. But 591 the recipient's MUA cannot use the original header fields 592 automatically. 594 Additionally, MUAs can decode Downgraded: header. It is described in 595 Appendix A.1 and Appendix A.2. 597 A.1. Displaying technique 1 599 MUA can remove 'Downgraded:' from decoded 'Downgraded:' header 600 fields. With this technique, The address header fields may be 601 displayed twice, one is ASCII-only downgraded header field and the 602 other is from decoded Downgraded: header. 604 A.2. Displaying technique 2 606 MUA can decode and regenerate headers which contains the original 607 non-ASCII addresses. It is described below: 608 o For each Downgraded: header, generate new header which field-name 609 is the second field of the Downgraded: header and the header value 610 is the third field of the Downgraded: header. 611 * If the header is an address header described in Section 5, 612 + Generate ASCII only header defined in Section 5 from the 613 decoded header. 614 + Remove the header field which is the same with the generated 615 ASCII only header from the header fields. If the headers 616 contain [RFC2047] encoded part, decode it before comparison. 618 Appendix B. Examples 620 B.1. Downgrading example 1 622 This section shows an SMTP Downgrading example. Consider a 623 downgradable mail message. 624 o The sender address is "NON-ASCII-FROM" which is non-ASCII address. 625 Its ASCII alternative is "ASCII-FROM". 627 o The "To" address is "NON-ASCII-TO" which is non-ASCII address. 628 Its ASCII alternative is "ASCII-TO". 629 o The "CC" address is non-ASCII address "NON-ASCII-CC" without 630 alternative US-ASCII address. 631 o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII 632 characters. 634 Original UTF8SMTP message SMTP session 636 MAIL From: ALT-ADDRESS 637 RCPT TO: ALT-ADDRESS 638 RCPT TO: 639 ------------------------------------------------------------- 640 Message-Id: MESSAGE_ID 641 Mime-Version: 1.0 642 Content-Type: text/plain; charset="UTF-8" 643 Content-Transfer-Encoding: 8bit 644 Subject: NON-ASCII-SUBJECT 645 From: > 646 To: > 647 CC: 648 Date: DATE 650 MAIL_BODY 652 Figure 3: Original UTF8SMTP message 654 In this example, there are two SMTP recipients, one is To:, the other 655 is CC:. In this example, assume the Cc: recipient's MTA supports 656 UTF8SMTP and the To: recipient's MTA does not support UTF8SMTP. The 657 SMTP downgrading treats To: session downgrading. Figure 4 shows SMTP 658 downgraded example. 660 MAIL From: 661 RCPT TO: 662 ------------------------------------------------------------- 663 Envelope-Downgraded: From: 664 Envelope-Downgraded: To: 665 Message-Id: MESSAGE_ID 666 Mime-Version: 1.0 667 Content-Type: text/plain; charset="UTF-8" 668 Content-Transfer-Encoding: 8bit 669 Subject: NON-ASCII-SUBJECT 670 From: > 671 To: > 672 CC: 673 Date: DATE 675 MAIL_BODY 677 Figure 4: SMTP Downgraded UTF8SMTP message 679 After SMTP downgrading, header downgrading is performed. Final 680 downgraded messages are shown in Figure 5. Return-Path header will 681 be added the destination MTA. 683 Result of the header downgrading. 685 Return-Path: 686 Envelope-Downgraded: From: 687 Envelope-Downgraded: To: 688 Message-Id: MESSAGE_ID 689 Mime-Version: 1.0 690 Content-Type: text/plain; charset="UTF-8" 691 Content-Transfer-Encoding: 8bit 692 Subject: RFC2047(UTF-8_SUBJECT) 693 Downgraded: From: RFC2047(>) 694 From: 695 Downgraded: To: RFC2047(>) 696 To: 697 Downgraded: CC: RFC2047() 698 CC: Internationalized address RFC2047(NON-ASCII-CC) removed:; 699 Date: DATE 701 MAIL_BODY 703 Figure 5: Header downgraded message 705 RFC2047() stands for [RFC2047] encoding. 707 B.2. Displaying example (Displaying technique 1) 709 This example shows MIME decoded message of Figure 5. 711 Result of MIME decoding. 713 Return-Path: 714 Envelope-Downgraded: From: 715 Envelope-Downgraded: To: 716 Message-Id: MESSAGE_ID 717 Mime-Version: 1.0 718 Content-Type: text/plain; charset="UTF-8" 719 Content-Transfer-Encoding: 8bit 720 Subject: UTF-8_SUBJECT 721 Downgraded: From: > 722 From: 723 Downgraded: To: > 724 To: 725 Downgraded: CC: 726 CC: Internationalized address NON-ASCII-CC removed:; 727 Date: DATE 729 MAIL_BODY 731 Figure 6: MIME decoded message 733 B.3. Displaying example (Displaying technique 2) 735 This example shows displaying process of Appendix A.2 for Figure 5. 737 First, check 'Downgraded:' header existence. 739 Select 'Downgraded:' headers. 741 Downgraded: From: > 742 Downgraded: To: > 743 Downgraded: CC: 745 Figure 7: Displaying technique 2: selecting Downgraded headers 747 Apply address header downgrading to the decoded header. 749 From: 750 To: 751 CC: Internationalized address RFC2047(NON-ASCII-CC) removed:; 753 Figure 8: Displaying technique 2: downgraded decoded Downgraded 754 headers 756 Remove the header line which is the same with the downgraded line. 757 If the headers contain [RFC2047] encoded part, decode it before 758 comparison. 760 Return-Path: 761 Envelope-Downgraded: From: 762 Envelope-Downgraded: To: 763 Message-Id: MESSAGE_ID 764 Mime-Version: 1.0 765 Content-Type: text/plain; charset="UTF-8" 766 Content-Transfer-Encoding: 8bit 767 Subject: UTF-8_SUBJECT 768 Downgraded: From: > 769 Downgraded: To: > 770 Downgraded: CC: > 771 Date: DATE 773 MAIL_BODY 775 Figure 9: Displaying technique 2: Removing duplicated headers 777 Decode each 'Downgraded' header and replace it with its decoded 778 header. If each mail header has [RFC2047] encoded part and which 779 encoding is "UTF-8", it is a downgraded header, so decode it. 781 Return-Path: 782 Envelope-Downgraded: From: 783 Envelope-Downgraded: To: 784 Message-Id: MESSAGE_ID 785 Mime-Version: 1.0 786 Content-Type: text/plain; charset="UTF-8" 787 Content-Transfer-Encoding: 8bit 788 Subject: UTF-8_SUBJECT 789 From: > 790 To: > 791 CC: > 792 Date: DATE 794 MAIL_BODY 796 Figure 10: Display technique 2: decoded message 798 As a result, in this simple example, all original header fields are 799 displayed in the original form. 801 B.4. Downgrading example 2 803 In many cases, the sender wants to use non-ASCII address and the 804 recipient does not support UTF8SMTP and does not have non-ASCII 805 address. 806 o The sender address is "NON-ASCII-FROM" which is non-ASCII address. 807 Its ASCII alternative is "ASCII-FROM". 808 o The "To" address is "ASCII-TO" which is ASCII only. 809 o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII 810 characters. 812 Original UTF8SMTP message SMTP session 814 MAIL From: ALT-ADDRESS 815 RCPT TO: 816 ------------------------------------------------------------- 817 Message-Id: MESSAGE_ID 818 Mime-Version: 1.0 819 Content-Type: text/plain; charset="UTF-8" 820 Content-Transfer-Encoding: 8bit 821 Subject: NON-ASCII-SUBJECT 822 From: > 823 To: 824 Date: DATE 826 MAIL_BODY 828 Figure 11: Original UTF8SMTP message 2 830 In this example, SMTP session is downgradable. Figure 12 shows SMTP 831 downgraded example. 833 MAIL From: 834 RCPT TO: 835 ------------------------------------------------------------- 836 Envelope-Downgraded: From: 837 Message-Id: MESSAGE_ID 838 Mime-Version: 1.0 839 Content-Type: text/plain; charset="UTF-8" 840 Content-Transfer-Encoding: 8bit 841 Subject: NON-ASCII-SUBJECT 842 From: > 843 To: 844 Date: DATE 846 MAIL_BODY 848 Figure 12: SMTP Downgraded UTF8SMTP message 2 850 After SMTP downgrading, header downgrading is performed. The 851 downgraded example is shown in Figure 13. 853 Envelope-Downgraded: From: 854 Message-Id: MESSAGE_ID 855 Mime-Version: 1.0 856 Content-Type: text/plain; charset="UTF-8" 857 Content-Transfer-Encoding: 8bit 858 Subject: RFC2047(UTF-8_SUBJECT) 859 Downgraded: From: RFC2047(>) 860 From: 861 To: 862 Date: DATE 864 MAIL_BODY 866 Figure 13: Header downgraded message 2 868 Authors' Addresses 870 Yoshiro YONEYA (editor) 871 JPRS 872 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 873 Chiyoda-ku, Tokyo 101-0065 874 Japan 876 Phone: +81 3 5215 8451 877 Email: yone@jprs.co.jp 879 Kazunori Fujiwara (editor) 880 JPRS 881 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 882 Chiyoda-ku, Tokyo 101-0065 883 Japan 885 Phone: +81 3 5215 8451 886 Email: fujiwara@jprs.co.jp 888 Full Copyright Statement 890 Copyright (C) The IETF Trust (2007). 892 This document is subject to the rights, licenses and restrictions 893 contained in BCP 78, and except as set forth therein, the authors 894 retain all their rights. 896 This document and the information contained herein are provided on an 897 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 898 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 899 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 900 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 901 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 902 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 904 Intellectual Property 906 The IETF takes no position regarding the validity or scope of any 907 Intellectual Property Rights or other rights that might be claimed to 908 pertain to the implementation or use of the technology described in 909 this document or the extent to which any license under such rights 910 might or might not be available; nor does it represent that it has 911 made any independent effort to identify any such rights. Information 912 on the procedures with respect to rights in RFC documents can be 913 found in BCP 78 and BCP 79. 915 Copies of IPR disclosures made to the IETF Secretariat and any 916 assurances of licenses to be made available, or the result of an 917 attempt made to obtain a general license or permission for the use of 918 such proprietary rights by implementers or users of this 919 specification can be obtained from the IETF on-line IPR repository at 920 http://www.ietf.org/ipr. 922 The IETF invites any interested party to bring to its attention any 923 copyrights, patents or patent applications, or other proprietary 924 rights that may cover technology that may be required to implement 925 this standard. Please address the information to the IETF at 926 ietf-ipr@ietf.org. 928 Acknowledgment 930 Funding for the RFC Editor function is provided by the IETF 931 Administrative Support Activity (IASA).