idnits 2.17.1 draft-ietf-eai-downgrade-02.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 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 656. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 669. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 95: '...F-8 characters in mail headers MUST be...' RFC 2119 keyword, line 147: '... Downgrading MUST be performed in ea...' RFC 2119 keyword, line 161: '...ltiple recipients. Downgrading SHOULD...' RFC 2119 keyword, line 168: '...II addresses, it MUST decide to bounce...' RFC 2119 keyword, line 172: '... MUST downgrade mail headers includi...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (Aug 16, 2006) is 6462 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-eai-framework-01 == 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-01 == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-01 ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 6 errors (**), 0 flaws (~~), 5 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 Aug 16, 2006 6 Expires: February 17, 2007 8 Downgrading mechanism for Email Address Internationalization (EAI) 9 draft-ietf-eai-downgrade-02.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 February 17, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Traditional mail systems handle only US-ASCII characters in SMTP 43 envelope and mail headers. The Email Address Internationalization 44 (EAI) is implemented by allowing UTF-8 characters in SMTP envelope 45 and mail headers. To deliver Non-ASCII mail address through EAI 46 incompliant environment, some sort of converting mechanism (i.e. 47 downgrading) is required. This document describes requirements for 48 downgrading, SMTP Downgrading, SMTP DATA/Header Downgrading and 49 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. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. SMTP DATA/Header Downgrading . . . . . . . . . . . . . . . . . 5 60 5.1. Header conversion . . . . . . . . . . . . . . . . . . . . 6 61 5.1.1. Downgrading address headers . . . . . . . . . . . . . 7 62 6. Implementation consideration . . . . . . . . . . . . . . . . . 8 63 6.1. MUA . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Security considerations . . . . . . . . . . . . . . . . . . . 8 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . . 8 69 10.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . . 9 70 10.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . . 9 71 10.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . . 9 72 10.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . . 9 73 11. Normative References . . . . . . . . . . . . . . . . . . . . . 9 74 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 75 A.1. SMTP Downgrading Example . . . . . . . . . . . . . . . . . 10 76 A.2. Header conversion downgrading example . . . . . . . . . . 12 77 A.3. Header conversion upgrading example . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 79 Intellectual Property and Copyright Statements . . . . . . . . . . 17 81 1. Introduction 83 Traditional mail systems which are defined by [RFC2821] and [RFC2822] 84 allow US-ASCII characters in SMTP envelope and mail headers in body 85 part. The EAI proposal [I-D.ietf-eai-framework], 86 [I-D.ietf-eai-utf8headers] and [I-D.ietf-eai-smtpext] allows UTF-8 87 characters in SMTP envelope and mail headers in body part. 89 Carrying Non-ASCII mail address from sender to recipients requires 90 all components on the mail delivery route are EAI compliant. 91 Otherwise Non-ASCII mail address can't be delivered. To solve the 92 problem, this document describes downgrading mechanism that enables 93 delivering Non-ASCII mail address by converting it to corresponding 94 US-ASCII representation on current mail delivery system. Not only 95 SMTP envelope, but also UTF-8 characters in mail headers MUST be 96 converted to US-ASCII. 98 Downgrading in EAI consists from following two parts: 99 o SMTP Downgrading 100 o SMTP DATA/Header Downgrading 102 Decoding downgraded envelope/message is called 'Upgrading' in this 103 document. Each downgrading mechanism has corresponding upgrading 104 mechanism. 106 In this document, requirements for downgrading is described in 107 section Section 3, SMTP Downgrading is described in Section 4, and 108 SMTP DATA/Header Downgrading is described in Section 5. 110 2. Terminology 112 Terminology for this document is defined in [I-D.ietf-eai-framework]. 114 3. Downgrade Requirements 116 3.1. Timing and conditions of downgrading 118 Followings are timing and conditions of downgrading. 120 Timing: SMTP client detects that SMTP server doesn't support 121 "UTF8SMTP" option at EHLO. [I-D.ietf-eai-smtpext] 122 Conditions: SMTP client detects that UTF-8 is included in the SMTP 123 envelope or mail headers in the SMTP DATA. 125 Note: If the UTF8SMTP header exists, downgrading will be performed. 126 If UTF-8 characters exist in mail headers without the UTF8SMTP 127 header, this is a protocol error, and handling of this situation is 128 outside the scope of this specification. 130 3.2. Requirements 132 Followings are requirements of downgrading. 134 1. Downgrading must be performed only once. 135 2. Upgrading must be performed at minimized place such as final 136 destination like recipient MUA. 137 3. Downgrading and upgrading must be automated. 138 4. Downgrading and upgrading should be easy and lightweight as it is 139 possible to do with MTA like 8BITMIME encapsulation. 140 5. Downgrade and upgrade method must be defined clearly. 141 6. Downgrading and upgrading should preserve all header information. 142 7. Downgrading must support SPF and DKIM. 143 8. Downgrading occurrence must be recorded. 145 4. SMTP Downgrading 147 Downgrading MUST be performed in each SMTP session. Target of 148 downgrading elements in SMTP envelope are below: 150 o MAIL FROM: 151 o RCPT TO: 153 Downgrading in SMTP envelope uses ALT-ADDRESS parameter proposed in 154 [I-D.ietf-eai-smtpext]. An address is downgradable if the address is 155 all-ASCII address or the address has all-ASCII address specified by 156 ALT-ADDRESS parameter. 158 If the return address in the envelope ("MAIL FROM:") is not 159 downgradable, downgrading fails. 161 One SMTP session may contain multiple recipients. Downgrading SHOULD 162 be performed for each SMTP recipient address. First, split a 163 multiple recipients session to each sessions. If the recipient 164 address is downgradable, the SMTP session to the recipient is 165 downgradable. 167 When MUA/MTA is transferring mail and finding its envelope contains 168 Non-ASCII addresses, it MUST decide to bounce or downgrade if 169 receiving MTA is EAI incompliant. 171 Even if no downgrading is performed for envelope from/to, MUA/MTA 172 MUST downgrade mail headers including UTF-8 or bounce. This is 173 described in next section. 175 MTA replaces Non-ASCII mail address with specified alternative US- 176 ASCII address. Then appends replaced information with EAI- 177 Downgraded-From: and EAI-Downgraded-To: header in mail header 178 (outgoing SMTP DATA). 180 EAI-Downgraded-From: 181 EAI-Downgraded-To: 183 Note that when downgrading, not to disclose whole recipient address, 184 MUA/MTA SHOULD make SMTP connection per each recipient address. 186 Also note that by appending EAI-Downgraded-From/To: headers, MUA/MTA 187 MUST perform SMTP DATA/Header Downgrading. This is described in next 188 section. 190 Case study: SPF check 192 SPF checks domainname of the envelope from and SMTP connection IP 193 address. If ALT-ADDRESS domainname is Punycode/IDNA form of Non- 194 ASCII domainname, it will be compatible with current SPF. In this 195 case, SPF check will be performed correctly. Otherwise, more 196 detailed consideration is required. 198 NOTE: ORCPT 200 ESMTP ORCPT parameter is used for Delivery Status Notifications 201 (DSNs) [RFC3461]. ORCPT parameters contain mail addresses. After 202 extending ORCPT parameter to support Non-ASCII mail addresses, ORCPT 203 parameter downgrading should be defined here. 205 5. SMTP DATA/Header Downgrading 207 Target and non-target of downgrading elements in mail headers (SMTP 208 data) are below: 210 Originator address(es): Non-ASCII mail addresses in From:, 211 Reply-To:, Sender: and their Resent- headers MUST be target of 212 downgrading. 213 Destination address(es): Non-ASCII mail addresses in To:, CC:, Bcc: 214 and their Resent- headers MUST be target of downgrading. 215 IDs: IDs such as Message-ID:, Date:, In-Reply-To: and References: 216 MUST NOT be target of downgrading. 217 Trace headers: Received: headers MUST NOT be target of downgrading 218 because they do not contain Non-ASCII mail addresses. 220 other headers: UTF-8 in other headers MUST be target of downgrading. 221 UTF8SMTP header: Identification of internationalized email header 222 requires special consideration. 224 5.1. Header conversion 226 This section defines conversion method to US-ASCII for each header 227 which may contain Non-ASCII characters. Each header has its own 228 downgrading method. 230 To preserve all header information, define generic encapsulation 231 header: "Downgraded: HeaderName: HeaderValue". The header value is 232 encoded by [RFC2047] with UTF-8 tag. 234 Downgrading: 235 * Check if the mail has 'UTF8SMTP' header and its value is 236 "UTF8". Otherwise, downgrading is not required. 237 * Check each header whether it contains UTF-8 characters or not. 238 If the header contains UTF-8 characters, 239 + If the header is an address header which is described in 240 Section 5.1.1, 241 - Preserve the header in 'Downgraded' header. 242 - Downgrade the header defined in Section 5.1.1. 243 + The other header case, encode the header by [RFC2047] with 244 UTF-8 tag. 245 * Change 'UTF8SMTP' header value to "Downgraded". 246 Upgrading: 247 * Check if the mail has 'UTF8SMTP' header and its value is 248 "Downgraded". Otherwise, upgrading is not required. 249 * Decode all 'Downgraded' headers. 250 + Decode header value field string which is [RFC2047] encoded. 251 + If the header is address header described in Section 5.1.1, 252 - Apply address header downgrading to the decoded header. 253 - Remove the header line which is the same with the 254 downgraded line. 255 + Remove the 'Downgraded' header. 256 + Add decoded header to mail header. 257 * If each mail header has [RFC2047] encoded part and which 258 encoding is "UTF-8", it is a downgraded header, so decode it. 259 * Change 'UTF8SMTP' header value to "UTF8". 261 Followings are pros and cons of this method. 263 Pros: 264 * EAI incompliant MUA displays the downgraded mail body except 265 original Non-ASCII mail addresses. 267 * EAI incompliant MUA displays and handles the sender specified 268 alternative address (ALT-ADDRESS). 269 * EAI compliant MUA displays and handles original headers. 270 Cons: 271 * Implementation and processing cost is not so easy and 272 lightweight because MUA/MTA must parse each header and encode 273 it by defined method. 274 * Hard to preserve whole information AS IS. The address headers 275 are preserved but the other headers which is [RFC2047] encoded 276 with UTF-8 tag are not distinguished that it is downgraded or 277 it is encoded by sender's MUA. Also, restoration order of the 278 downgraded headers is not guaranteed. Therefore, to check DKIM 279 requires special consideration. 281 [[Reference to [I-D.ietf-eai-scenarios] and evaluation of each case 282 should be described here.]] 284 5.1.1. Downgrading address headers 286 This section targets From:, Sender:, Reply-To:, To:, CC:, Bcc:, 287 Resent-From:, Resent-To:, Resent-CC:, Resent-Bcc:, Resent-sender: 288 headers which contains Originator/Destination address(es). 290 The header value is composed of single or multiple mailbox/angle-addr 291 fields defined in [I-D.ietf-eai-utf8headers]. 293 If the header contains UTF-8 characters, downgrading method is 294 follows. 295 1. Extract every field and downgrade mailbox/angle-addr described 296 below. 297 2. By mailbox/angle-addr downgrading, if the field became empty, the 298 field should be removed. 299 3. If all header field is removed, remove the header. 300 4. If From header is removed, generate new From: header from 301 envelope-from address. 303 EAI angle-addr defined in [I-D.ietf-eai-utf8headers] consists of 3 304 forms. Downgrading method is defined for each form. 305 1. 306 US-ASCII mail address case, preserve it. 307 2. 308 Non-ASCII mail address without ALT-ADDRESS parameter case, 309 remove this angle-addr. 310 3. 311 Non-ASCII mail address with sender-specified US-ASCII address 312 case, replace it as . 314 "mailbox" is defined as "DISPLAY NAME angle-addr" in 316 [I-D.ietf-eai-utf8headers]. The "DISPLAY NAME" field should be 317 encoded by [RFC2047] with UTF-8 tag, if necessary. If the angle-addr 318 is removed, remove the field including "DISPLAY NAME". 320 6. Implementation consideration 322 6.1. MUA 324 EAI compliant MUA MUST implement downgrading mechanism for sending. 326 MUA MAY encode UTF-8 in Subject header with the same encoding of body 327 part while downgrading. 329 EAI compliant MUA MUST upgrade downgraded mail and MUST show Non- 330 ASCII mail addresses on display. 332 7. Security considerations 334 See the extended security considerations discussion in 335 [I-D.ietf-eai-framework] 337 8. IANA Considerations 339 IANA is requested to add the "EAI-Downgraded-From:", 340 "EAI-Downgraded-To:" and "Downgraded:" new headers to the registry 341 with the entries pointing to this specification for its definition. 343 9. Acknowledgements 345 John Klensin, Harald Alvestrand, Chris Newman, Charles Lindsey, 346 Marcos Sanz, Alexey Melnikov and JET members. 348 10. Change History 350 This section is used for tracking the update of this document. Will 351 be removed after finalize. 353 10.1. draft-yoneya-ima-downgrade: Version 00 355 o Initial version 356 o Fllowed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00 358 10.2. draft-yoneya-ima-downgrade: Version 01 360 o Document structure was changed 361 o Fllowed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02 362 o Downgrading requirements were added 363 o SMTP DATA encapsulation method was proposed 364 o Downgrading examples was provided 366 10.3. draft-ietf-eai-downgrade: Version 00 368 o Fllowed draft-yeh-ima-utf8headers-01 and draft-ietf-eai-smtpext-00 369 o No header downgrading method was proposed 370 o Header encapsulation method was proposed 372 10.4. draft-ietf-eai-downgrade: Version 01 374 o Followed draft-ietf-eai-utf8headers-00 375 o Header conversion and encapsulation method was merged 376 o Header conversion method was defined in detail 378 10.5. draft-ietf-eai-downgrade: Version 02 380 o Followed draft-ietf-eai-utf8headers-01 and 381 draft-ietf-eai-smtpext-01 382 o Specification about algorithmic generated address is removed 383 o No header downgrading method was removed 384 o SMTP DATA encapsulation method was removed 386 11. Normative References 388 [I-D.ietf-eai-framework] 389 Klensin, J. and Y. Ko, "Overview and Framework for 390 Internationalized Email", draft-ietf-eai-framework-01 391 (work in progress), June 2006. 393 [I-D.ietf-eai-scenarios] 394 Alvestrand, H., "UTF-8 Mail: Scenarios", 395 draft-ietf-eai-scenarios-01 (work in progress), June 2006. 397 [I-D.ietf-eai-smtpext] 398 Yao, J. and W. Mao, "SMTP extension for internationalized 399 email address", draft-ietf-eai-smtpext-01 (work in 400 progress), July 2006. 402 [I-D.ietf-eai-utf8headers] 403 Yeh, J., "Internationalized Email Headers", 404 draft-ietf-eai-utf8headers-01 (work in progress), 405 August 2006. 407 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 408 Part Three: Message Header Extensions for Non-ASCII Text", 409 RFC 2047, November 1996. 411 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 412 April 2001. 414 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 415 April 2001. 417 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 418 Extension for Delivery Status Notifications (DSNs)", 419 RFC 3461, January 2003. 421 Appendix A. Examples 423 A.1. SMTP Downgrading Example 425 This section shows a SMTP Downgrading example. Consider a 426 downgradable mail message. 427 o The sender address is "NON-ASCII-FROM" which is Non-ASCII address. 428 Its ASCII alternative is "ASCII-FROM". 429 o The "To" address is "NON-ASCII-TO" which is Non-ASCII address. 430 Its ASCII alternative is "ASCII-TO". 431 o The "CC" address is "NON-ASCII-CC" which is Non-ASCII address. It 432 has no ASCII alternative address. 433 o The Subject header is "UTF8-Subject" which contains Non-ASCII 434 characters. 436 Original EAI message SMTP session 438 MAIL From: ALT-ADDRESS 439 RCPT TO: ALT-ADDRESS 440 RCPT TO: 441 ------------------------------------------------------------- 442 UTF8SMTP: UTF8 443 Message-Id: MESSAGE_ID 444 Mime-Version: 1.0 445 Content-Type: text/plain; charset="UTF-8" 446 Content-Transfer-Encoding: 8bit 447 Subject: UTF8-SUBJECT 448 From: 449 To: 450 CC: 451 Date: DATE 453 MAIL_BODY 455 Figure 1: Original EAI message 457 In this example, there are two sessions, one is To:, the other is 458 CC:. The CC: session does not contain ASCII alternative address, it 459 is not downgradable and bounced. The To: session can be downgraded 460 to the next example Figure 2. 462 After SMTP Downgrading 464 MAIL From: 465 RCPT TO: 466 ------------------------------------------------------------- 467 EAI-Downgraded-From: 468 EAI-Downgraded-To: 469 UTF8SMTP: UTF8 470 Message-Id: MESSAGE_ID 471 Mime-Version: 1.0 472 Content-Type: text/plain; charset="UTF-8" 473 Content-Transfer-Encoding: 8bit 474 Subject: UTF8-SUBJECT 475 From: 476 To: 477 CC: 478 Date: DATE 480 MAIL_BODY 482 Figure 2: SMTP Downgraded EAI message 484 A.2. Header conversion downgrading example 486 Original EAI message 488 UTF8SMTP: UTF8 489 Message-Id: MESSAGE_ID 490 Mime-Version: 1.0 491 Content-Type: text/plain; charset="UTF-8" 492 Content-Transfer-Encoding: 8bit 493 Subject: UTF-8_SUBJECT 494 From: 495 To: 496 CC: 497 Date: DATE 499 MAIL_BODY 501 Figure 3: Original EAI message 503 SMTP Downgrading adds EAI-Downgraded-From: and EAI-Downgraded-To: 504 headers. 506 EAI-Downgraded-From: 507 EAI-Downgraded-To: 509 Figure 4: Headers added by SMTP Downgrading 511 Result of the header conversion downgrading. 513 EAI-Downgraded-From: 514 MIME( 515 EAI-Downgraded-To: 516 MIME( 517 UTF8SMTP: Downgraded 518 Message-Id: MESSAGE_ID 519 Mime-Version: 1.0 520 Content-Type: text/plain; charset="UTF-8" 521 Content-Transfer-Encoding: 8bit 522 Subject: MIME(UTF-8_SUBJECT) 523 Downgraded: From: MIME() 524 From: 525 Downgraded: To: MIME() 526 To: 527 Downgraded: CC: MIME() 528 Date: DATE 530 MAIL_BODY 532 Figure 5: Header conversion downgraded message 534 MIME() stands for [RFC2047] encoding. 536 A.3. Header conversion upgrading example 538 This example shows upgrading process of Figure 5. 540 First, check 'UTF8SMTP:' header. Its value is "Downgraded", it is 541 EAI downgraded message. 543 Decode all 'Downgraded:' headers. 545 Downgraded: From: MIME() 546 Downgraded: To: MIME() 547 Downgraded: CC: MIME() 549 Figure 6: Upgrading: selecting Downgraded headers 551 Decode header value field string which is [RFC2047] encoded. 553 From: 554 To: 555 CC: 557 Figure 7: Upgrading: upgraded Downgraded headers 559 Apply address header downgrading to the decoded header. 561 From: 562 To: 564 Figure 8: Upgrading: downgraded upgraded Downgraded headers 566 Remove the header line which is the same with the downgraded line. 568 EAI-Downgraded-From: 569 MIME( 570 EAI-Downgraded-To: 571 MIME( 572 UTF8SMTP: Downgraded 573 Message-Id: MESSAGE_ID 574 Mime-Version: 1.0 575 Content-Type: text/plain; charset="UTF-8" 576 Content-Transfer-Encoding: 8bit 577 Subject: MIME(UTF-8_SUBJECT) 578 Downgraded: From: MIME() 579 Downgraded: To: MIME() 580 Downgraded: CC: MIME() 581 Date: DATE 583 MAIL_BODY 585 Figure 9: Upgrading: Removing duplicated headers 587 Remove the 'Downgraded' header and add decoded Downgraded headers If 588 each mail header has [RFC2047] encoded part and which encoding is 589 "UTF-8", it is a downgraded header, so decode it. Change 'UTF8SMTP' 590 header value to "UTF8". 592 EAI-Downgraded-From: 593 EAI-Downgraded-To: 594 UTF8SMTP: UTF8 595 Message-Id: MESSAGE_ID 596 Mime-Version: 1.0 597 Content-Type: text/plain; charset="UTF-8" 598 Content-Transfer-Encoding: 8bit 599 Subject: UTF-8_SUBJECT 600 From: 601 To: MIME( 602 CC: MIME( 603 Date: DATE 605 MAIL_BODY 607 Figure 10: Header conversion upgraded message 609 As a result, in this example, all headers are preserved. 611 Authors' Addresses 613 Yoshiro YONEYA (editor) 614 JPRS 615 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 616 Chiyoda-ku, Tokyo 101-0065 617 Japan 619 Phone: +81 3 5215 8451 620 Email: yone@jprs.co.jp 622 Kazunori Fujiwara (editor) 623 JPRS 624 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 625 Chiyoda-ku, Tokyo 101-0065 626 Japan 628 Phone: +81 3 5215 8451 629 Email: fujiwara@jprs.co.jp 631 Full Copyright Statement 633 Copyright (C) The Internet Society (2006). 635 This document is subject to the rights, licenses and restrictions 636 contained in BCP 78, and except as set forth therein, the authors 637 retain all their rights. 639 This document and the information contained herein are provided on an 640 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 641 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 642 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 643 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 644 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 645 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 Intellectual Property 649 The IETF takes no position regarding the validity or scope of any 650 Intellectual Property Rights or other rights that might be claimed to 651 pertain to the implementation or use of the technology described in 652 this document or the extent to which any license under such rights 653 might or might not be available; nor does it represent that it has 654 made any independent effort to identify any such rights. Information 655 on the procedures with respect to rights in RFC documents can be 656 found in BCP 78 and BCP 79. 658 Copies of IPR disclosures made to the IETF Secretariat and any 659 assurances of licenses to be made available, or the result of an 660 attempt made to obtain a general license or permission for the use of 661 such proprietary rights by implementers or users of this 662 specification can be obtained from the IETF on-line IPR repository at 663 http://www.ietf.org/ipr. 665 The IETF invites any interested party to bring to its attention any 666 copyrights, patents or patent applications, or other proprietary 667 rights that may cover technology that may be required to implement 668 this standard. Please address the information to the IETF at 669 ietf-ipr@ietf.org. 671 Acknowledgment 673 Funding for the RFC Editor function is provided by the IETF 674 Administrative Support Activity (IASA).