idnits 2.17.1 draft-ietf-eai-downgraded-display-01.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 (March 9, 2009) is 5520 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 5336 (Obsoleted by RFC 6531) ** Obsolete normative reference: RFC 5337 (Obsoleted by RFC 6533) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 2 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 March 9, 2009 5 Intended status: Experimental 6 Expires: September 10, 2009 8 Displaying Downgraded Messages for Email Address Internationalization 9 draft-ietf-eai-downgraded-display-01.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 September 10, 2009. 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 how to display downgraded messages which 48 originally contain 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 . . . . . . . . . . . . . . . . . . . . . 6 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 60 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 6 61 8.1. draft-fujiwara-eai-downgraded-display: Version 00 . . . . 6 62 8.2. draft-ietf-eai-downgraded-display: Version 00 . . . . . . 6 63 8.3. draft-ietf-eai-downgraded-display: Version 01 . . . . . . 6 64 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 65 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 66 A.1. Displaying example . . . . . . . . . . . . . . . . . . . . 11 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 1. Introduction 71 The Email Address Internationalization (UTF8SMTP) extension document 72 set [RFC4952] [RFC5336] [RFC5335] [RFC5337] expands Email address 73 structure, syntax and Email header format. To avoid bouncing 74 internationalized Email messages, the downgrading mechanism 75 [I-D.ietf-eai-downgrade] converts an internationalized message to a 76 traditional Email message when a server in the delivery path does not 77 support the UTF8SMTP extension. The downgraded message is a 78 traditional Email message, except the message has "Downgraded-" 79 header fields. 81 A perfect reverse-function of the downgrading does not exist because 82 the encoding defined in [RFC2047] is not exactly reversible and 83 Received header field downgrading may remove FOR clause information. 84 The restoration of the downgrading should be done once at the final 85 destination of the downgraded message such as MUAs or IMAP servers. 86 This document describes the restoration methods as displaying 87 downgraded messages in MUAs. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 Specialized terms used in this specification are defined in the EAI 96 overview [RFC4952] or in [RFC5321][RFC5322], MIME documents [RFC2045] 97 [RFC2047] [RFC2183] [RFC2231]. 99 This document depends on [RFC5335] and [I-D.ietf-eai-downgrade]. Key 100 words used in these document are used in this document, too. 102 The term "non-ASCII" is an UTF-8 string which contains at least one 103 non-ASCII character. 105 The term "address header field" is used for a header field which 106 contains elements which is defined in [RFC5322]. "Address 107 header fields" contain "From", "Sender", "Reply-To", "To", "Cc", 108 "Bcc", "Resent-From", "Resent-Sender", "Resent-To", "Resent-Cc", 109 "Return-Path" header fields. 111 An "UTF8SMTP message" is an Email messages expanded by [RFC5335]. 113 The term "MIME decode" is used for both "encoded-word" decoding 114 defined by [RFC2047] and MIME parameter value decoding defined by 115 [RFC2231]. 117 3. Consideration of displaying downgraded message 119 Displaying downgraded message is mostly performed by MIME decoding 120 according to [RFC2047] and [RFC2231]. Result of MIME decoding, the 121 header of the message still contains Downgraded-*: header fields, but 122 the header field bodies are MIME decoded. These decoded 123 "Downgraded-" header fields contain the original header field name 124 and the original header field values. The recipient can read them. 125 But the recipient's MUA cannot use the original header fields 126 automatically. 128 Additionally, MUAs can process "Downgraded-" header fields. 130 The easiest way to process "Downgraded-" header fields is to remove 131 "Downgraded-" from the decoded "Downgraded-" header fields' name. 132 Then, the "address header fields" may be displayed twice, one is from 133 downgraded header field and the other is from decoded "Downgraded-" 134 header field. Although it is very easy, it MUST NOT be used because 135 of the following reasons. 136 o [RFC5322] section 3.6 defines number of times each field may occur 137 in the header section of a message and the maximum number for 138 "From", "Sender", "To", "Cc", "Bcc" header fields is 1. It 139 violates [RFC5322]. 140 o Users cannot distinguish which is the original downgraded header 141 field and which is the generated header field. 142 o The Downgraded-* header field and corresponding header field may 143 not have relations. 145 The following way is to remove "Downgraded-" from the decoded 146 "Downgraded-" header fields' name and remove the corresponding header 147 field at the same time. 149 4. Displaying downgraded message 151 MUAs may decode and re-generate the original header fields of the 152 message. This procedure may reconstruct the original message from 153 the downgraded message. But it is not guaranteed. 155 Displaying downgraded message is implemented by the following steps. 157 Step 1: Select Address header field preservation headers described 158 in Section 3.2 of [I-D.ietf-eai-downgrade]. Target header fields 159 are "Downgraded-From", "Downgraded-Sender", "Downgraded-To", 160 "Downgraded-Cc", "Downgraded-Bcc", "Downgraded-Reply-To", 161 "Downgraded-Resent-From", "Downgraded-Resent-Sender", "Downgraded- 162 Resent-To", "Downgraded-Resent-Cc", "Downgraded-Resent-Bcc", 163 "Downgraded-Resent-Reply-To", "Downgraded-Return-Path" and 164 "Downgraded-Disposition-Notification-To" header fields. 166 Step 2: Generate new header field which field name is the original 167 header field name and the field value is the MIME decoded header 168 field value from the output of Step 1. 170 Step 3: Apply Email header fields downgrading defined in section 5 171 of [I-D.ietf-eai-downgrade] to the output of Step 2 without re- 172 generating "Downgraded-" header fields. 174 Step 4: Compare the output of Step 3 and the original header 175 fields. If the same header fields exist for the output of Step 3 176 and the original header fields, remove the same header fields from 177 the original header fields. This step outputs the original header 178 fields which is modified by this step 4. Before this comparison, 179 a canonicalization described below is useful. 181 1. Unfold all header field continuation lines as described in 182 [RFC5322]. 183 2. Insert a space character before and after 184 separator "," if there is no space character. 185 3. Insert a space character before and after if there 186 is no space character. 187 4. Decode each whose charset is 'UTF-8'. 188 5. Convert all sequences of one or more WSP characters to a 189 single space character. WSP characters here include those 190 before and after a line folding boundary. 191 6. Delete all WSP characters at the end of each unfolded header 192 field value. 193 7. Delete any WSP characters remaining before and after the colon 194 separating the header field name from the header field value. 195 The colon separator MUST be retained. 197 Step 5: Decode MIME encoded header fields and MIME body part header 198 fields according to [RFC2047] and [RFC2231]. 200 Step 6: For each "Downgraded-" header field except the address 201 header field preservation headers and the envelope information 202 preservation headers described in [I-D.ietf-eai-downgrade] section 203 3, generate new header field which field name is the original 204 header field name and the field value is the decoded header field 205 value, then replace the original "Downgraded-" header field by the 206 generated header field. 208 Don't change "Downgraded-Mail-From" and "Downgraded-Rcpt-To" 209 header fields because they do not have their original header 210 fields. Don't change the address header field preservation header 211 if it doesn't have the corresponding downgraded header field. 213 5. Security considerations 215 While displaying downgraded message changes the header fields of the 216 message and it may lose the original information, MUAs should have a 217 function to read the original received message (with/without MIME 218 decoding). 220 While information in any email header should usually treated with 221 some suspicion, current email systems commonly employ various 222 mechanisms and protocols to make the information more trustworthy. 223 For example, an organization's boundary MTA can modify From: lines so 224 that messages arriving from outside the organization are easily 225 distinguishable from internal emails. As a result of rewriting, the 226 Downgraded-From header field may not be decoded. 228 See "Security considerations" section in [I-D.ietf-eai-downgrade] and 229 [RFC4952] for more discussion. 231 6. IANA Considerations 233 7. Acknowledgements 235 8. Change History 237 This section is used for tracking the update of this document. Will 238 be removed after finalize. 240 8.1. draft-fujiwara-eai-downgraded-display: Version 00 242 o Initial version 243 o It is separated from Appendix A of draft-ietf-eai-downgrade-05.txt 245 8.2. draft-ietf-eai-downgraded-display: Version 00 247 o Submitted as a working group draft 249 8.3. draft-ietf-eai-downgraded-display: Version 01 251 o Prohibited and removed Displaying Technique 1 252 o Added new texts to Security Considerations 254 9. Normative References 256 [I-D.ietf-eai-downgrade] 257 Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for 258 Email Address Internationalization", 259 draft-ietf-eai-downgrade-12 (work in progress), 260 March 2009. 262 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 263 Extensions (MIME) Part One: Format of Internet Message 264 Bodies", RFC 2045, November 1996. 266 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 267 Part Three: Message Header Extensions for Non-ASCII Text", 268 RFC 2047, November 1996. 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, March 1997. 273 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 274 Presentation Information in Internet Messages: The 275 Content-Disposition Header Field", RFC 2183, August 1997. 277 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 278 Word Extensions: 279 Character Sets, Languages, and Continuations", RFC 2231, 280 November 1997. 282 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 283 Internationalized Email", RFC 4952, July 2007. 285 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 286 October 2008. 288 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 289 October 2008. 291 [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, 292 September 2008. 294 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 295 Email Addresses", RFC 5336, September 2008. 297 [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery 298 Status and Disposition Notifications", RFC 5337, 299 September 2008. 301 Appendix A. Examples 303 This section shows a example of displaying downgraded message. 305 First, an example of the original UTF8SMTP message and its downgraded 306 message are shown. They are the same as "Example 1" of 307 [I-D.ietf-eai-downgrade]. The example UTF8SMTP message is shown in 308 Figure 1. 310 Message-Id: MESSAGE_ID 311 Mime-Version: 1.0 312 Content-Type: text/plain; charset="UTF-8" 313 Content-Transfer-Encoding: 8bit 314 Subject: NON-ASCII-SUBJECT 315 From: DISPLAY-local > 317 To: DISPLAY-remote1 > 319 Cc: DISPLAY-remote2 320 Date: DATE 322 MAIL_BODY 324 Figure 1: Original message 326 Delivered downgraded message is shown in Figure 2. Return-Path 327 header will be added by the final destination MTA. 329 Return-Path: 330 Downgraded-Mail-From: =?UTF-8?Q?>?= 332 Downgraded-Rcpt-To: =?UTF-8?Q?>?= 334 Message-Id: MESSAGE_ID 335 Mime-Version: 1.0 336 Content-Type: text/plain; charset="UTF-8" 337 Content-Transfer-Encoding: 8bit 338 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 339 From: =?UTF-8?Q?DISPLAY-local?= 340 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 342 To: =?UTF-8?Q?DISPLAY-remote1?= 343 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= 344 =?UTF-8?Q?>?= 345 Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 346 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; 347 Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= 348 =?UTF-8?Q??= 349 Date: DATE 351 MAIL_BODY 353 Figure 2: Downgraded message 355 Figure 3 shows MIME decoded message of Figure 2. The recipient can 356 read the original From, To, Cc header fields as Downgraded-From, 357 Downgraded-To, Downgraded-Cc header fields. 359 Return-Path: 360 Downgraded-Mail-From: > 362 Downgraded-Rcpt-To: > 364 Message-Id: MESSAGE_ID 365 Mime-Version: 1.0 366 Content-Type: text/plain; charset="UTF-8" 367 Content-Transfer-Encoding: 8bit 368 Subject: NON-ASCII-SUBJECT 369 From: DISPLAY-local 370 Downgraded-From: DISPLAY-local > 372 To: DISPLAY-remote1 373 Downgraded-To: DISPLAY-remote1 > 375 Cc: DISPLAY-remote2 Internationalized address 376 NON-ASCII-remote2@example.org removed:; 377 Downgraded-Cc: DISPLAY-remote2 378 Date: DATE 380 MAIL_BODY 382 Figure 3: MIME decoded message 384 A.1. Displaying example 386 This example shows displaying process of 'Displaying technique' for 387 Figure 2. 389 First, perform Step 1. 391 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 393 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= 394 =?UTF-8?Q?>?= 395 Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= 396 =?UTF-8?Q??= 398 Figure 4: Displaying: Output of Step 1 400 Then, perform Step 2. 402 From: DISPLAY-local > 404 To: DISPLAY-remote1 > 406 Cc: DISPLAY-remote2 408 Figure 5: Displaying: Output of Step 2 410 Perform Step 3. 412 From: =?UTF-8?Q?DISPLAY-local?= 413 To: =?UTF-8?Q?DISPLAY-remote1?= 414 Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 415 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; 417 Figure 6: Displaying: Output of Step 3 419 Perform Step 4. "From", "To", "Cc" header fields are removed in 420 Figure 7. 422 Return-Path: 423 Downgraded-Mail-From: =?UTF-8?Q?>?= 425 Downgraded-Rcpt-To: =?UTF-8?Q?>?= 427 Message-Id: MESSAGE_ID 428 Mime-Version: 1.0 429 Content-Type: text/plain; charset="UTF-8" 430 Content-Transfer-Encoding: 8bit 431 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 432 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 434 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1?_?= 435 =?UTF-8?Q?>?= 436 Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= 437 =?UTF-8?Q??= 438 Date: DATE 440 MAIL_BODY 442 Figure 7: Displaying: Output of Step 4 444 Perform Step 5 and 6. 446 Return-Path: 447 Downgraded-Mail-From: > 449 Downgraded-Rcpt-To: 450 451 Message-Id: MESSAGE_ID 452 Mime-Version: 1.0 453 Content-Type: text/plain; charset="UTF-8" 454 Content-Transfer-Encoding: 8bit 455 Subject: NON-ASCII-SUBJECT 456 From: DISPLAY-local > 458 To: DISPLAY-remote1 > 460 Cc: DISPLAY-remote2 461 Date: DATE 463 MAIL_BODY 465 Figure 8: Decoded message 467 As a result, in this simple example, all original header fields are 468 displayed in the original form. Differences between Figure 1 and 469 Figure 8 are Return-Path, Downgraded-Mail-From, Downgraded-Rcpt-To 470 header fields only. 472 Author's Address 474 Kazunori Fujiwara 475 Japan Registry Services Co., Ltd. 476 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 477 Chiyoda-ku, Tokyo 101-0065 478 Japan 480 Phone: +81 3 5215 8451 481 Email: fujiwara@jprs.co.jp