idnits 2.17.1 draft-ietf-eai-downgrade-03.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 722. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 733. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 740. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 746. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 97: '... MUST be converted to US-ASCII....' RFC 2119 keyword, line 136: '... 2. "Upgrading MUST be performed (if...' RFC 2119 keyword, line 184: '... Downgrading MUST be performed for e...' RFC 2119 keyword, line 198: '...ltiple recipients. Downgrading SHOULD...' RFC 2119 keyword, line 205: '...II addresses, it MUST decide to bounce...' (7 more instances...) 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 (Mar 5, 2007) is 6262 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CFWS' is mentioned on line 175, but not defined == Unused Reference: 'I-D.ietf-eai-dsn' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-eai-scenarios' is defined on line 413, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-eai-dsn-00 == Outdated reference: A later version (-03) exists of draft-ietf-eai-scenarios-01 == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-03 == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-03 ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 4 errors (**), 0 flaws (~~), 8 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 Mar 5, 2007 6 Expires: September 6, 2007 8 Downgrading mechanism for Email Address Internationalization 9 draft-ietf-eai-downgrade-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 6, 2007. 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 is implemented by allowing UTF-8 characters in 45 SMTP envelope and mail header fields (UTF8SMTP). To deliver Non- 46 ASCII mail address via UTF8SMTP non-compliant environment, some sort 47 of converting mechanism (i.e. downgrading) is required. This 48 document describes requirements for downgrading, SMTP downgrading, 49 Email header downgrading and implementation consideration. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Downgrade Requirements . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Timing and conditions of downgrading . . . . . . . . . . . 3 57 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Downgraded header . . . . . . . . . . . . . . . . . . . . . . 4 59 5. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Email header Downgrading . . . . . . . . . . . . . . . . . . . 6 61 6.1. Downgrading address headers . . . . . . . . . . . . . . . 7 62 7. Upgrading downgraded header . . . . . . . . . . . . . . . . . 7 63 8. Implementation consideration . . . . . . . . . . . . . . . . . 8 64 9. Security considerations . . . . . . . . . . . . . . . . . . . 8 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 9 68 12.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . . 9 69 12.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . . 9 70 12.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . . 9 71 12.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . . 9 72 12.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . . 9 73 12.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . . 9 74 13. Normative References . . . . . . . . . . . . . . . . . . . . . 10 75 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 76 A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 10 77 A.2. Upgrading example . . . . . . . . . . . . . . . . . . . . 13 78 A.3. Downgrading example 2 . . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 80 Intellectual Property and Copyright Statements . . . . . . . . . . 18 82 1. Introduction 84 Traditional mail systems which are defined by [RFC2821] and [RFC2822] 85 allow US-ASCII characters in SMTP envelope and mail header field 86 bodies. The UTF8SMTP proposal [I-D.ietf-eai-framework], 87 [I-D.ietf-eai-utf8headers] and [I-D.ietf-eai-smtpext] allows UTF-8 88 characters in SMTP envelope and mail header field bodies. 90 Carrying Non-ASCII mail address from sender to recipients requires 91 all components on the mail delivery route are UTF8SMTP compliant. 92 Otherwise Non-ASCII mail address can't be delivered. To solve the 93 problem, this document describes downgrading mechanism that enables 94 delivering Non-ASCII mail address by converting it to corresponding 95 US-ASCII representation on current mail delivery system. Not only 96 SMTP envelope, but also Non-ASCII characters in mail header fields 97 MUST be converted to US-ASCII. 99 Downgrading in UTF8SMTP consists from following two parts: 100 o SMTP Downgrading 101 o Email header Downgrading 103 Decoding downgraded envelope/message is called 'Upgrading' in this 104 document. Each downgrading mechanism has corresponding upgrading 105 mechanism. 107 In this document, requirements for downgrading are described in 108 Section 3, SMTP Downgrading is described in Section 5, and Email 109 header Downgrading is described in Section 6. 111 This document assumes that MIME headers are not extended to use UTF-8 112 characters because it is not clearly defined in 113 [I-D.ietf-eai-utf8headers]. 115 2. Terminology 117 Terminology for this document is defined in [I-D.ietf-eai-framework]. 119 3. Downgrade Requirements 121 3.1. Timing and conditions of downgrading 123 Followings are timing and conditions of downgrading. 125 Timing: SMTP client detects that SMTP server doesn't support 126 "UTF8SMTP" option at EHLO. [I-D.ietf-eai-smtpext] 127 Conditions: SMTP client detects that non-ASCII characters are 128 included in the SMTP envelope or mail header fields in the SMTP 129 DATA. 131 3.2. Requirements 133 Followings are requirements of downgrading. 135 1. Downgrading should be performed only once. 136 2. "Upgrading MUST be performed (if at all) when it is known that a 137 subsequent downgrade will not be needed. This could mean that 138 the upgrading is delayed until the recipient MUA processes the 139 message." 140 3. Downgrading and upgrading must be automated. 141 4. Downgrading and upgrading should be easy and lightweight as it is 142 possible to do with MTA like 8BITMIME encapsulation. 143 5. Downgrade and upgrade method must be defined clearly. 144 6. Downgrading and upgrading should preserve all header information. 145 7. Downgrading should support SPF and DKIM. 146 8. Downgrading occurrence should be recorded. 148 4. Downgraded header 150 To preserve all header information, new generic encapsulation header 151 is required. The new header is required, and it is specified as 152 "Downgraded". It has two fields. The first field is the 153 encapsulated header name. The second field contains the encapsulated 154 header value which is encoded by [RFC2047] with UTF-8 tag. The 155 header field syntax is specified as follows: 157 fields =/ downgraded 158 downgraded = "Downgraded:" [CFWS] field-name ":" dvalue CRLF 159 field-name = 1*ftext 160 ftext = %d33-57 / %d59-126 ; printable ASCII except ":" 161 dvalue = 1*any-ascii 162 any-ascii = %d32-126 164 Any headers can be preserved in Downgraded: header. The "dvalue" 165 field is encoded by [RFC2047]. "Downgraded header decoding" means 166 that generating new header whose header name is "field-name" field 167 that retrieving preserved field-name and dvalue decoded by [RFC2047]. 169 To preserve SMTP envelope downgraded information, another new header 170 is required, and it is specified as "Envelope-Downgraded". Details 171 are described in Section 5. The header field syntax is specified as 172 follows: 174 fields =/ edowngraded 175 edowngraded = "Envelope-Downgraded:" [CFWS] field-name ":" value CRLF 176 field-name = "From" / "To" 177 value = CFWS "<" uPath ">" CFWS "<" Mailbox ">" CFWS 179 ; Mailbox is defined in RFC 2821, section 4.1.2 180 ; uPath is defined in [I-D.ietf-eai-smtpext] 182 5. SMTP Downgrading 184 Downgrading MUST be performed for each SMTP recipient address. 185 Target of downgrading elements in SMTP envelope are below: 187 o MAIL FROM: 188 o RCPT TO: 190 Downgrading in SMTP envelope uses ALT-ADDRESS parameter proposed in 191 [I-D.ietf-eai-smtpext]. An address is downgradable if the address is 192 US-ASCII address or the address has US-ASCII address specified by 193 ALT-ADDRESS parameter. 195 If the return address in the envelope ("MAIL FROM:") is not 196 downgradable, downgrading fails. 198 One SMTP session may contain multiple recipients. Downgrading SHOULD 199 be performed for each SMTP recipient address individually. First, 200 split a multiple recipients session to each sessions. If the 201 recipient address is downgradable, the SMTP session to the recipient 202 is downgradable. 204 When MUA/MTA is transferring mail and finding its envelope contains 205 Non-ASCII addresses, it MUST decide to bounce or downgrade if 206 receiving MTA is UTF8SMTP non-compliant. 208 Even if no downgrading is performed for envelope from/to, MUA/MTA 209 MUST downgrade mail header fields including non-ASCII characters or 210 bounce. This is described in Section 6. 212 Downgrading MTA replaces Non-ASCII mail address with specified 213 alternative US-ASCII address. Also MTA preserves original 214 information using "Envelope-Downgraded" header defined in Section 4 215 with From or To field name. 217 Envelope-Downgraded: From: 218 Envelope-Downgraded: To: 220 Note that when downgrading, not to disclose whole recipient address, 221 MUA/MTA SHOULD make SMTP connection per each recipient address. 223 Also note that by appending "Envelope-Downgraded:" headers, MUA/MTA 224 MUST perform Email header Downgrading described in Section 6. 226 NOTE: ORCPT 228 ESMTP ORCPT parameter is used for Delivery Status Notifications 229 (DSNs) [RFC3461]. ORCPT parameters contain mail addresses. After 230 extending ORCPT parameter to support Non-ASCII mail addresses, ORCPT 231 parameter downgrading should be defined here. 233 Case study: SPF check 235 SPF checks domain name of the envelope from and SMTP connection IP 236 address. If ALT-ADDRESS domain name is Punycode/IDNA form of Non- 237 ASCII domainname, it will be compatible with current SPF. In this 238 case, SPF check will be performed correctly. Otherwise, more 239 detailed consideration is required. 241 6. Email header Downgrading 243 This section defines conversion method to US-ASCII for each header 244 which may contain Non-ASCII characters. If the whole mail header 245 does not contain Non-ASCII characters, email header downgrading is 246 not required. Otherwise, email header downgrading checks each header 247 whether it contains UTF-8 characters or not. If the header contains 248 UTF-8 characters, convert the header in a suitable method for of each 249 header. Each header's downgrading method is described below: 250 From, To, CC, Reply-To, Return-Path: 251 The header field body is composed of single or multiple angle- 252 addr/addr-spec fields defined in [I-D.ietf-eai-utf8headers]. 253 If the header has no 'angle-addr' or 'utf8-addr-spec' which 254 contains UTF-8 characters, only "display-name" part contains UTF-8 255 characters, encode the header by [RFC2047] with UTF-8 tag and 256 replace it. 257 Otherwise, preserve the header in "Downgraded:" header and 258 generate US-ASCII only header defined in Section 6.1, replace the 259 original header with the generated US-ASCII only header. When 260 this address header downgrading fails, this downgrading fails and 261 the mail MUST be bounced. 263 Subject: 264 Encode the header by [RFC2047] with UTF-8 tag and replace it. 265 Message-ID:, Date:, In-Reply-To: 266 "ID"s and "Date"s does not contain UTF-8 characters. 267 Received: 268 If the FOR clause contains UTF-8 addresses, the header must be 269 downgraded. In this case, preserve the header in "Downgraded:" 270 header and remove the FOR clause in the header. 271 other headers: 272 All other headers which contains UTF-8 characters are preserved in 273 Downgraded: header and removed. 275 Downgraded headers should be inserted or replaced at the same 276 position of the original header. 278 6.1. Downgrading address headers 280 This procedure targets "From:", "To:", "CC:", "Reply-To:", "Return- 281 Path:" headers which contains Originator/Destination address(es). 282 1. Extract every field and downgrade each 'mailbox'/'angle- 283 addr'/'utf8-addr-spec'. 285 If the Non-ASCII address is in utf8-addr-spec form, then the 286 header downgrading fails because the form has no alt-address. 288 "mailbox" is defined as "DISPLAY NAME angle-addr" in 289 [I-D.ietf-eai-utf8headers]. The "DISPLAY NAME" field should be 290 encoded by [RFC2047] with UTF-8 tag, if necessary. 292 UTF8SMTP angle-addr defined in [I-D.ietf-eai-utf8headers] 293 consists of 3 forms. Downgrading method is defined for each 294 form. 295 1. 296 US-ASCII is used as is. 297 2. 298 This email header downgrading fails because this header is 299 not downgradable. 300 3. > 301 Non-ASCII mail address with sender-specified US-ASCII address 302 is replaced as . 304 7. Upgrading downgraded header 306 Upgrading downgraded header is described below: 307 o Check if the mail header contains 'Downgraded:' headers. 308 Otherwise, upgrading is not required. 310 o Perform "Downgraded header decoding" for each "Downgraded:" 311 headers and replace the 'Downgraded:' header with its decoded 312 header. 313 * If the decoded header is an address header described in 314 Section 6.1, 315 + Generate ASCII only header described in Section 6.1 from the 316 decoded header. 317 + Remove the header line which is the same with the generated 318 ASCII only header. (REQUIRE HEADER NORMALIZATION) 319 * If the decoded header is a "Received:" header, 320 + Removing the 'FOR' clause from the decoded header generates 321 ASCII only header. 322 + Remove the header line which is the same with the generated 323 header. (REQUIRE HEADER NORMALIZATION) 324 o If each mail header has [RFC2047] encoded part and which encoding 325 is "UTF-8", it may be a downgraded header, so decode it. 327 8. Implementation consideration 329 UTF8SMTP compliant MUA MUST implement downgrading mechanism for 330 sending. 332 MUA MAY encode UTF-8 in Subject header with the same encoding of body 333 part while downgrading. 335 UTF8SMTP compliant MUA MUST upgrade downgraded mail and MUST show 336 Non-ASCII mail addresses on display. 338 9. Security considerations 340 See "Security considerations" section in [I-D.ietf-eai-framework] for 341 more discussion. 343 10. IANA Considerations 345 IANA is requested to add the "Envelope-Downgraded:", and 346 "Downgraded:" new headers to the registry with the entries pointing 347 to this specification for its definition. 349 11. Acknowledgements 351 John Klensin, Harald Alvestrand, Chris Newman, Charles Lindsey, 352 Marcos Sanz, Alexey Melnikov and JET members. 354 12. Change History 356 This section is used for tracking the update of this document. Will 357 be removed after finalize. 359 12.1. draft-yoneya-ima-downgrade: Version 00 361 o Initial version 362 o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00 364 12.2. draft-yoneya-ima-downgrade: Version 01 366 o Document structure was changed 367 o Followed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02 368 o Downgrading requirements were added 369 o SMTP DATA encapsulation method was proposed 370 o Downgrading examples was provided 372 12.3. draft-ietf-eai-downgrade: Version 00 374 o Followed draft-yeh-ima-utf8headers-01 and 375 draft-ietf-eai-smtpext-00 376 o No header downgrading method was proposed 377 o Header encapsulation method was proposed 379 12.4. draft-ietf-eai-downgrade: Version 01 381 o Followed draft-ietf-eai-utf8headers-00 382 o Header conversion and encapsulation method was merged 383 o Header conversion method was defined in detail 385 12.5. draft-ietf-eai-downgrade: Version 02 387 o Followed draft-ietf-eai-utf8headers-01 and 388 draft-ietf-eai-smtpext-01 389 o Specification about algorithmic generated address is removed 390 o No header downgrading method was removed 391 o SMTP DATA encapsulation method was removed 393 12.6. draft-ietf-eai-downgrade: Version 03 395 o Followed draft-ietf-eai-utf8headers-03 and 396 draft-ietf-eai-smtpext-03 397 o Downgraded: and Envelope-Downgraded: headers definition was added 398 o Mail header downgrading method was refined 399 o Examples in Appendix A were refined 401 13. Normative References 403 [I-D.ietf-eai-dsn] 404 Newman, C., "International Delivery and Disposition 405 Notifications", draft-ietf-eai-dsn-00 (work in progress), 406 January 2007. 408 [I-D.ietf-eai-framework] 409 Klensin, J. and Y. Ko, "Overview and Framework for 410 Internationalized Email", draft-ietf-eai-framework-05 411 (work in progress), February 2007. 413 [I-D.ietf-eai-scenarios] 414 Alvestrand, H., "UTF-8 Mail: Scenarios", 415 draft-ietf-eai-scenarios-01 (work in progress), June 2006. 417 [I-D.ietf-eai-smtpext] 418 Yao, J. and W. Mao, "SMTP extension for internationalized 419 email address", draft-ietf-eai-smtpext-03 (work in 420 progress), February 2007. 422 [I-D.ietf-eai-utf8headers] 423 Yeh, J., "Internationalized Email Headers", 424 draft-ietf-eai-utf8headers-03 (work in progress), 425 March 2007. 427 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 428 Part Three: Message Header Extensions for Non-ASCII Text", 429 RFC 2047, November 1996. 431 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 432 April 2001. 434 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 435 April 2001. 437 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 438 Extension for Delivery Status Notifications (DSNs)", 439 RFC 3461, January 2003. 441 Appendix A. Examples 443 A.1. Downgrading example 1 445 This section shows a SMTP Downgrading example. Consider a 446 downgradable mail message. 448 o The sender address is "NON-ASCII-FROM" which is Non-ASCII address. 449 Its ASCII alternative is "ASCII-FROM". 450 o The "To" address is "NON-ASCII-TO" which is Non-ASCII address. 451 Its ASCII alternative is "ASCII-TO". 452 o The "CC" address is "NON-ASCII-CC" which is Non-ASCII address. 453 Its ASCII alternative address is "ASCII-CC". 454 o The Subject header is "UTF8-SUBJECT" which contains Non-ASCII 455 characters. 457 Original UTF8SMTP message SMTP session 459 MAIL From: ALT-ADDRESS 460 RCPT TO: ALT-ADDRESS 461 RCPT TO: ALT-ADDRESS 462 ------------------------------------------------------------- 463 Message-Id: MESSAGE_ID 464 Mime-Version: 1.0 465 Content-Type: text/plain; charset="UTF-8" 466 Content-Transfer-Encoding: 8bit 467 Subject: UTF8-SUBJECT 468 From: > 469 To: > 470 CC: > 471 Date: DATE 473 MAIL_BODY 475 Figure 3: Original UTF8SMTP message 477 In this example, there are two sessions, one is To:, the other is 478 CC:. Both sessions are downgradable. Figure 4 shows To: session 479 downgrading. 481 After SMTP Downgrading 483 MAIL From: 484 RCPT TO: 485 ------------------------------------------------------------- 486 Envelope-Downgraded: From: 487 Envelope-Downgraded: To: 488 Message-Id: MESSAGE_ID 489 Mime-Version: 1.0 490 Content-Type: text/plain; charset="UTF-8" 491 Content-Transfer-Encoding: 8bit 492 Subject: UTF8-SUBJECT 493 From: > 494 To: > 495 CC: > 496 Date: DATE 498 MAIL_BODY 500 Figure 4: SMTP Downgraded UTF8SMTP message 502 After SMTP downgrading, header downgrading is performed. Final 503 downgraded messages are shown in Figure 5. 505 Result of the header downgrading. 507 Downgraded: Envelope-Downgraded: From: 508 MIME() 509 Downgraded: Envelope-Downgraded: To: 510 MIME() 511 Message-Id: MESSAGE_ID 512 Mime-Version: 1.0 513 Content-Type: text/plain; charset="UTF-8" 514 Content-Transfer-Encoding: 8bit 515 Subject: MIME(UTF-8_SUBJECT) 516 Downgraded: From: MIME(>) 517 From: 518 Downgraded: To: MIME(>) 519 To: 520 Downgraded: CC: MIME(>) 521 To: 522 Date: DATE 524 MAIL_BODY 525 Figure 5: Header downgraded message 527 MIME() stands for [RFC2047] encoding. 529 A.2. Upgrading example 531 This example shows upgrading process of Figure 5. 533 First, check 'Downgraded:' header existence. The UTF8SMTP downgraded 534 message has 'Downgraded:' headers. 536 Select 'Downgraded:' headers. 538 Downgraded: Envelope-Downgraded: From: 539 MIME() 540 Downgraded: Envelope-Downgraded: To: 541 MIME() 542 Downgraded: From: MIME(>) 543 Downgraded: To: MIME(>) 544 Downgraded: CC: MIME(>) 546 Figure 6: Upgrading: selecting Downgraded headers 548 This example has five Downgraded headers. 550 Decode 'Downgraded:' headers. 552 Envelope-Downgraded: From: 553 Envelope-Downgraded: To: 554 From: > 555 To: > 556 CC: > 558 Figure 7: Upgrading: upgraded Downgraded headers 560 Apply address header downgrading to the decoded header. 562 From: 563 To: 564 CC: 566 Figure 8: Upgrading: downgraded upgraded Downgraded headers 568 Remove the header line which is the same with the downgraded line. 570 Downgraded: Envelope-Downgraded: From: 571 MIME() 572 Downgraded: Envelope-Downgraded: To: 573 MIME() 574 Message-Id: MESSAGE_ID 575 Mime-Version: 1.0 576 Content-Type: text/plain; charset="UTF-8" 577 Content-Transfer-Encoding: 8bit 578 Subject: MIME(UTF-8_SUBJECT) 579 Downgraded: From: MIME(>) 580 Downgraded: To: MIME(>) 581 Downgraded: CC: MIME(>) 582 Date: DATE 584 MAIL_BODY 586 Figure 9: Upgrading: Removing duplicated headers 588 Decode each 'Downgraded' header and replace it with its decoded 589 header. If each mail header has [RFC2047] encoded part and which 590 encoding is "UTF-8", it is a downgraded header, so decode it. 592 Envelope-Downgraded: From: 593 Envelope-Downgraded: To: 594 Message-Id: MESSAGE_ID 595 Mime-Version: 1.0 596 Content-Type: text/plain; charset="UTF-8" 597 Content-Transfer-Encoding: 8bit 598 Subject: UTF-8_SUBJECT 599 From: > 600 To: > 601 CC: > 602 Date: DATE 604 MAIL_BODY 606 Figure 10: Downgraded header upgraded message 608 As a result, in this simple example, all headers are preserved. 610 A.3. Downgrading example 2 612 In many cases, the sender wants to use Non-ASCII address and the 613 recipient does not support UTF8SMTP and does not have Non-ASCII 614 address. 615 o The sender address is "NON-ASCII-FROM" which is Non-ASCII address. 616 Its ASCII alternative is "ASCII-FROM". 617 o The "To" address is "ASCII-TO" which is ASCII only. 618 o The Subject header is "UTF8-SUBJECT" which contains Non-ASCII 619 characters. 621 Original UTF8SMTP message SMTP session 623 MAIL From: ALT-ADDRESS 624 RCPT TO: 625 ------------------------------------------------------------- 626 Message-Id: MESSAGE_ID 627 Mime-Version: 1.0 628 Content-Type: text/plain; charset="UTF-8" 629 Content-Transfer-Encoding: 8bit 630 Subject: UTF8-SUBJECT 631 From: > 632 To: 633 Date: DATE 635 MAIL_BODY 637 Figure 11: Original UTF8SMTP message 2 639 In this example, SMTP session is downgradable. Figure 12 shows SMTP 640 downgrading. 642 After SMTP Downgrading 644 MAIL From: 645 RCPT TO: 646 ------------------------------------------------------------- 647 Envelope-Downgraded: From: 648 Message-Id: MESSAGE_ID 649 Mime-Version: 1.0 650 Content-Type: text/plain; charset="UTF-8" 651 Content-Transfer-Encoding: 8bit 652 Subject: UTF8-SUBJECT 653 From: > 654 To: 655 Date: DATE 657 MAIL_BODY 659 Figure 12: SMTP Downgraded UTF8SMTP message 2 661 After SMTP downgrading, header downgrading is performed. Final 662 downgraded messages are shown in Figure 13. 664 Result of the header downgrading. 666 Downgraded: Envelope-Downgraded: From: 667 MIME() 668 Message-Id: MESSAGE_ID 669 Mime-Version: 1.0 670 Content-Type: text/plain; charset="UTF-8" 671 Content-Transfer-Encoding: 8bit 672 Subject: MIME(UTF-8_SUBJECT) 673 Downgraded: From: MIME(>) 674 From: 675 To: 676 Date: DATE 678 MAIL_BODY 680 Figure 13: Header downgraded message 2 682 This downgraded message's header part contains ASCII characters only. 683 But it still contains MIME encapsulated subject header which contains 684 UTF-8 characters. And more, the body part contains UTF-8 message. 685 "ascii user" needs to accept UTF-8 mail body and UTF-8 subject which 686 is MIME encoded. 688 Authors' Addresses 690 Yoshiro YONEYA (editor) 691 JPRS 692 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 693 Chiyoda-ku, Tokyo 101-0065 694 Japan 696 Phone: +81 3 5215 8451 697 Email: yone@jprs.co.jp 699 Kazunori Fujiwara (editor) 700 JPRS 701 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 702 Chiyoda-ku, Tokyo 101-0065 703 Japan 705 Phone: +81 3 5215 8451 706 Email: fujiwara@jprs.co.jp 708 Full Copyright Statement 710 Copyright (C) The IETF Trust (2007). 712 This document is subject to the rights, licenses and restrictions 713 contained in BCP 78, and except as set forth therein, the authors 714 retain all their rights. 716 This document and the information contained herein are provided on an 717 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 718 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 719 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 720 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 721 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 722 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 724 Intellectual Property 726 The IETF takes no position regarding the validity or scope of any 727 Intellectual Property Rights or other rights that might be claimed to 728 pertain to the implementation or use of the technology described in 729 this document or the extent to which any license under such rights 730 might or might not be available; nor does it represent that it has 731 made any independent effort to identify any such rights. Information 732 on the procedures with respect to rights in RFC documents can be 733 found in BCP 78 and BCP 79. 735 Copies of IPR disclosures made to the IETF Secretariat and any 736 assurances of licenses to be made available, or the result of an 737 attempt made to obtain a general license or permission for the use of 738 such proprietary rights by implementers or users of this 739 specification can be obtained from the IETF on-line IPR repository at 740 http://www.ietf.org/ipr. 742 The IETF invites any interested party to bring to its attention any 743 copyrights, patents or patent applications, or other proprietary 744 rights that may cover technology that may be required to implement 745 this standard. Please address the information to the IETF at 746 ietf-ipr@ietf.org. 748 Acknowledgment 750 Funding for the RFC Editor function is provided by the IETF 751 Administrative Support Activity (IASA).