idnits 2.17.1 draft-ietf-eai-downgraded-display-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 (Sep 8, 2009) is 5315 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530) ** Obsolete normative reference: RFC 5335 (Obsoleted by RFC 6532) ** Obsolete normative reference: RFC 5504 (Obsoleted by RFC 6530) -- Obsolete informational reference (is this intentional?): RFC 5336 (Obsoleted by RFC 6531) -- Obsolete informational reference (is this intentional?): RFC 5337 (Obsoleted by RFC 6533) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Email Address Internationalization K. Fujiwara 3 (EAI) JPRS 4 Internet-Draft Sep 8, 2009 5 Intended status: Experimental 6 Expires: March 12, 2010 8 Displaying Downgraded Messages for Email Address Internationalization 9 draft-ietf-eai-downgraded-display-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 12, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes a method for displaying downgraded messages 48 which originally contained internationalized E-mail addresses or 49 internationalized header fields. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Consideration of displaying downgraded message . . . . . . . . 4 56 4. Displaying downgraded message . . . . . . . . . . . . . . . . 4 57 5. Security considerations . . . . . . . . . . . . . . . . . . . 6 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 60 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 7 61 8.1. draft-fujiwara-eai-downgraded-display: Version 00 . . . . 7 62 8.2. draft-ietf-eai-downgraded-display: Version 00 . . . . . . 7 63 8.3. draft-ietf-eai-downgraded-display: Version 01 . . . . . . 7 64 8.4. draft-ietf-eai-downgraded-display: Version 02 . . . . . . 7 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9 69 A.1. Displaying example . . . . . . . . . . . . . . . . . . . . 12 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 The Email Address Internationalization (UTF8SMTP) extension document 75 set [RFC4952] [RFC5336] [RFC5335] [RFC5337] expands Email address 76 structure, syntax and Email header format. To avoid rejection of 77 internationalized Email messages, the downgrading mechanism [RFC5504] 78 converts an internationalized message to a traditional Email message 79 when a server in the delivery path does not support the UTF8SMTP 80 extension. The downgraded message is a traditional Email message, 81 except the message has "Downgraded-" header fields. 83 A perfect reverse-function of the downgrading does not exist because 84 the encoding defined in [RFC2047] is not exactly reversible and 85 Received header field downgrading may remove FOR clause information. 86 The restoration of the downgrading should be done once at the final 87 destination of the downgraded message such as MUAs or IMAP servers. 88 This document describes the restoration methods as displaying 89 downgraded messages in MUAs. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 Specialized terms used in this specification are defined in the EAI 98 overview [RFC4952] or in [RFC5321][RFC5322], MIME documents [RFC2045] 99 [RFC2047] [RFC2183] [RFC2231]. 101 This document depends on [RFC5335] and [RFC5504]. Key words used in 102 these document are used in this document, too. 104 The term "non-ASCII" is an UTF-8 string which contains at least one 105 non-ASCII character. 107 The term "address header field" is used for a header field which 108 contains elements which is defined in [RFC5322]. "Address 109 header fields" contain "From", "Sender", "Reply-To", "To", "Cc", 110 "Bcc", "Resent-From", "Resent-Sender", "Resent-To", "Resent-Cc", 111 "Return-Path" header fields. 113 An "UTF8SMTP message" is an Email messages expanded by [RFC5335]. 115 The term "MIME decode" is used for both "encoded-word" decoding 116 defined by [RFC2047] and MIME parameter value decoding defined by 117 [RFC2231]. 119 3. Consideration of displaying downgraded message 121 Displaying downgraded message is mostly performed by MIME decoding 122 according to [RFC2047] and [RFC2231]. As a result of MIME decoding, 123 the header of the message still contains "Downgraded-" header fields, 124 but the header field bodies are MIME decoded. These decoded 125 "Downgraded-" header fields contain the original header field name 126 and the original header field values. The recipient can read them. 127 But the recipient's MUA cannot use the original header fields 128 automatically. 130 Additionally, A MUA can process "Downgraded-" header fields. 132 The easiest way to process "Downgraded-" header fields is to remove 133 "Downgraded-" from the decoded "Downgraded-" header fields' names. 134 Then, the "address header fields" may be displayed twice, one is from 135 downgraded header field and the other is from decoded "Downgraded-" 136 header field. Although it is very easy, it MUST NOT be used because 137 of the following reasons. 138 o [RFC5322] section 3.6 defines number of times each field may occur 139 in the header section of a message and the maximum number for 140 "From", "Sender", "To", "Cc", "Bcc" header fields is 1. It 141 violates [RFC5322]. 142 o Users cannot distinguish which is the original downgraded header 143 field and which is the generated header field. 144 o The "Downgraded-" header field and corresponding header field may 145 not have relations. 147 4. Displaying downgraded message 149 A MUA MAY decode and re-generate the original header fields of the 150 message. This procedure can be used to reverse the Downgrade process 151 but will not construct exactly the original header fields in all 152 cases. 154 Displaying downgraded message is implemented by the following steps. 156 Input: 157 The input to this procedure is the header of the message as 158 received. Copy the entire header into an edit space. 160 Step 1: 161 Select the "Address Header Fields' Preservation Header Fields" 162 described in Section 3.2 of [RFC5504] in the edit space. These 163 header fields are "Downgraded-From", "Downgraded-Sender", 164 "Downgraded-To", "Downgraded-Cc", "Downgraded-Bcc", "Downgraded- 165 Reply-To", "Downgraded-Resent-From", "Downgraded-Resent-Sender", 166 "Downgraded-Resent-To", "Downgraded-Resent-Cc", "Downgraded- 167 Resent-Bcc", "Downgraded-Resent-Reply-To", "Downgraded-Return- 168 Path" and "Downgraded-Disposition-Notification-To" header fields. 170 Step 2: 171 For each header field from the output of Step 1, generate a new 172 header field where the field name is the original header field 173 name and the field value is the result of MIME decoding header 174 field value. 176 Step 3: 177 Apply "Email Header Fields Downgrading" defined in section 5 of 178 [RFC5504] to the output of Step 2 without re-generating 179 "Downgraded-" header fields and copy the output into a new space 180 (hereafter, call it as a "comparison space"). 182 Step 4: 183 Compare the header fields in the comparison space with the header 184 fields of the same name in the edit space. Before this 185 comparison, canonicalize each header field described below. 187 1. Unfold all header field continuation lines as described in 188 [RFC5322]. 189 2. Insert a space character before and after 190 separator "," if there is no space character. 191 3. Insert a space character before and after if there 192 is no space character. 193 4. Decode each whose charset is 'UTF-8'. 194 5. Convert all sequences of one or more WSP characters to a 195 single space character. WSP characters here include those 196 before and after a line folding boundary. 197 6. Delete all WSP characters at the end of each unfolded header 198 field value. 199 7. Delete any WSP characters remaining before and after the colon 200 separating the header field name from the header field value. 201 The colon separator MUST be retained. 203 For each header field, if the same header fields exist in the 204 comparison space and in the edit space, remove the original header 205 field in the edit space and the generated header field in the 206 comparison space. 208 Remaining header fields in the comparison space may be bogus or 209 broken "Address Header Fields' Preservation Header Fields" origin. 211 Step 5: 212 Decode all MIME encoded header fields according to [RFC2047] and 213 [RFC2231] in the edit space. 215 Step 6: 216 For each "Unknown Header Fields' Preservation Header Fields" 217 described in section 3.3 of [RFC5504] and "Address Header Fields' 218 Preservation Header Fields", generate a new header field where the 219 field name is the original header field name and the field value 220 is the result of MIME decoding header field value, then replace 221 the original "Downgraded-" header field by the generated header 222 field in the edit space. "Envelope Information Preservation 223 Header Fields" are not targets of this step. 225 The output of this procedure is an UTF8SMTP header in the edit space. 226 It will closely resemble the original header. 228 After this procedure, the MUA may decode MIME body part header fields 229 according to [RFC2047] and [RFC2231]. 231 5. Security considerations 233 While information in any email header should usually treated with 234 some suspicion, current email systems commonly employ various 235 mechanisms and protocols to make the information more trustworthy. 236 For example, an organization's boundary MTA can modify "From:" lines 237 so that messages arriving from outside the organization are easily 238 distinguishable from internal emails. As a result of rewriting, the 239 "Downgraded-From" header field may not be decoded. 241 A MUA may emphasize bogus or broken "Downgraded-" header fields in 242 step 4 of Section 4. 244 Hiding the information from the actual header fields when using the 245 "Downgraded-" header fields does not cause loss of information if the 246 comparison done in step 4 of Section 4 is successful. To ensure that 247 no information is lost, a MUA SHOULD have a function that uses the 248 actual message that was received (with/without MIME decoding) to 249 render the message. 251 See "Security considerations" section in [RFC5504] and [RFC4952] for 252 more discussion. 254 6. IANA Considerations 256 This document makes no requests for IANA action. This section can be 257 removed by the RFC Editor before publication. 259 7. Acknowledgements 261 This document was separated from [RFC5504]. Both documents were 262 developed in the EAI WG. Significant comments and suggestions were 263 received from John Klensin, Harald Alvestrand, Chris Newman, Randall 264 Gellens, Charles Lindsey, Marcos Sanz, Alexey Melnikov, Frank 265 Ellermann, Edward Lewis, S. Moonesamy and JET members. 267 8. Change History 269 This section is used for tracking the update of this document. Will 270 be removed after finalize. 272 8.1. draft-fujiwara-eai-downgraded-display: Version 00 274 o Initial version 275 o It is separated from Appendix A of draft-ietf-eai-downgrade-05.txt 277 8.2. draft-ietf-eai-downgraded-display: Version 00 279 o Submitted as a working group draft 281 8.3. draft-ietf-eai-downgraded-display: Version 01 283 o Prohibited and removed Displaying Technique 1 284 o Added new texts to Security Considerations 286 8.4. draft-ietf-eai-downgraded-display: Version 02 288 o updated by comments from Chair's review and AD's review 289 o Fixed references 290 o Rewrote section 4 to be more comprehensible 291 o Added bogus or broken "Downgraded-" header fields 292 o Added sentences in Security considerations 294 9. References 295 9.1. Normative References 297 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 298 Extensions (MIME) Part One: Format of Internet Message 299 Bodies", RFC 2045, November 1996. 301 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 302 Part Three: Message Header Extensions for Non-ASCII Text", 303 RFC 2047, November 1996. 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, March 1997. 308 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 309 Presentation Information in Internet Messages: The 310 Content-Disposition Header Field", RFC 2183, August 1997. 312 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 313 Word Extensions: 314 Character Sets, Languages, and Continuations", RFC 2231, 315 November 1997. 317 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 318 Internationalized Email", RFC 4952, July 2007. 320 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 321 October 2008. 323 [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, 324 September 2008. 326 [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for 327 Email Address Internationalization", RFC 5504, March 2009. 329 9.2. Informative References 331 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 332 October 2008. 334 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 335 Email Addresses", RFC 5336, September 2008. 337 [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery 338 Status and Disposition Notifications", RFC 5337, 339 September 2008. 341 Appendix A. Examples 343 This section shows a example of displaying downgraded message. 344 First, an example of the original UTF8SMTP message and its downgraded 345 message are shown. They are the same as "Example 1" of [RFC5504]. 346 The example UTF8SMTP message is shown in Figure 1. 348 Message-Id: MESSAGE_ID 349 Mime-Version: 1.0 350 Content-Type: text/plain; charset="UTF-8" 351 Content-Transfer-Encoding: 8bit 352 Subject: NON-ASCII-SUBJECT 353 From: DISPLAY-local > 355 To: DISPLAY-remote1 > 357 Cc: DISPLAY-remote2 358 Date: DATE 360 MAIL_BODY 362 Figure 1: Original message 364 Delivered downgraded message is shown in Figure 2. Return-Path 365 header will be added by the final destination MTA. 367 Return-Path: 368 Downgraded-Mail-From: =?UTF-8?Q?>?= 370 Downgraded-Rcpt-To: =?UTF-8?Q?>?= 372 Message-Id: MESSAGE_ID 373 Mime-Version: 1.0 374 Content-Type: text/plain; charset="UTF-8" 375 Content-Transfer-Encoding: 8bit 376 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 377 From: =?UTF-8?Q?DISPLAY-local?= 378 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 380 To: =?UTF-8?Q?DISPLAY-remote1?= 381 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= 382 =?UTF-8?Q?>?= 383 Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 384 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; 385 Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= 386 =?UTF-8?Q??= 387 Date: DATE 389 MAIL_BODY 391 Figure 2: Downgraded message 393 Figure 3 shows MIME decoded message of Figure 2. The recipient can 394 read the original From, To, Cc header fields as Downgraded-From, 395 Downgraded-To, Downgraded-Cc header fields. 397 Return-Path: 398 Downgraded-Mail-From: > 400 Downgraded-Rcpt-To: > 402 Message-Id: MESSAGE_ID 403 Mime-Version: 1.0 404 Content-Type: text/plain; charset="UTF-8" 405 Content-Transfer-Encoding: 8bit 406 Subject: NON-ASCII-SUBJECT 407 From: DISPLAY-local 408 Downgraded-From: DISPLAY-local > 410 To: DISPLAY-remote1 411 Downgraded-To: DISPLAY-remote1 > 413 Cc: DISPLAY-remote2 Internationalized address 414 NON-ASCII-remote2@example.org removed:; 415 Downgraded-Cc: DISPLAY-remote2 416 Date: DATE 418 MAIL_BODY 420 Figure 3: MIME decoded message 422 A.1. Displaying example 424 This example shows processes of 'Displaying downgraded message' for 425 Figure 2. 427 First, perform Step 1. 429 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 431 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= 432 =?UTF-8?Q?>?= 433 Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= 434 =?UTF-8?Q??= 436 Figure 4: Displaying: Output of Step 1 438 Then, perform Step 2. 440 From: DISPLAY-local > 442 To: DISPLAY-remote1 > 444 Cc: DISPLAY-remote2 446 Figure 5: Displaying: Output of Step 2 448 Perform Step 3. 450 From: =?UTF-8?Q?DISPLAY-local?= 451 To: =?UTF-8?Q?DISPLAY-remote1?= 452 Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 453 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; 455 Figure 6: Displaying: Output of Step 3 457 Perform Step 4. "From", "To", "Cc" header fields are removed in 458 Figure 7. 460 Return-Path: 461 Downgraded-Mail-From: =?UTF-8?Q?>?= 463 Downgraded-Rcpt-To: =?UTF-8?Q?>?= 465 Message-Id: MESSAGE_ID 466 Mime-Version: 1.0 467 Content-Type: text/plain; charset="UTF-8" 468 Content-Transfer-Encoding: 8bit 469 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 470 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 472 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1?_?= 473 =?UTF-8?Q?>?= 474 Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= 475 =?UTF-8?Q??= 476 Date: DATE 478 MAIL_BODY 480 Figure 7: Displaying: Output of Step 4 482 Perform Step 5 and 6. 484 Return-Path: 485 Downgraded-Mail-From: > 487 Downgraded-Rcpt-To: 488 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: NON-ASCII-SUBJECT 494 From: DISPLAY-local > 496 To: DISPLAY-remote1 > 498 Cc: DISPLAY-remote2 499 Date: DATE 501 MAIL_BODY 503 Figure 8: Decoded message 505 As a result, in this simple example, all original header fields are 506 displayed in the original form. Differences between Figure 1 and 507 Figure 8 are Return-Path, Downgraded-Mail-From, Downgraded-Rcpt-To 508 header fields only. 510 Author's Address 512 Kazunori Fujiwara 513 Japan Registry Services Co., Ltd. 514 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 515 Chiyoda-ku, Tokyo 101-0065 516 Japan 518 Phone: +81-3-5215-8451 519 Email: fujiwara@jprs.co.jp