idnits 2.17.1
draft-ietf-eai-popimap-downgrade-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 1 character in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 11, 2011) is 4665 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'CFWS' is mentioned on line 335, but not defined
== Outdated reference: A later version (-12) exists of
draft-ietf-eai-frmwrk-4952bis-10
== Outdated reference: A later version (-13) exists of
draft-ietf-eai-rfc5335bis-11
== Outdated reference: A later version (-06) exists of
draft-ietf-eai-rfc5337bis-dsn-02
-- Obsolete informational reference (is this intentional?): RFC 5504
(Obsoleted by RFC 6530)
Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 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 July 11, 2011
5 Intended status: Standards Track
6 Expires: January 12, 2012
8 Post-delivery Message Downgrading for Internationalized Email Messages
9 draft-ietf-eai-popimap-downgrade-02.txt
11 Abstract
13 The Email Address Internationalization (UTF8SMTP) extension allows
14 UTF-8 characters in mail header fields. POP and IMAP servers support
15 internationalized email messages. If a POP/IMAP client does not
16 support Email Address Internationalization, POP/IMAP servers cannot
17 send Internationalized Email Headers to the client and cannot remove
18 the message. To avoid the situation, this document describes a
19 conversion mechanism for internationalized Email messages to be
20 traditional message format.
22 Status of This Memo
24 This Internet-Draft is submitted to IETF in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF), its areas, and its working groups. Note that
29 other groups may also distribute working documents as Internet-
30 Drafts.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 The list of current Internet-Drafts can be accessed at
38 http://www.ietf.org/ietf/1id-abstracts.txt.
40 The list of Internet-Draft Shadow Directories can be accessed at
41 http://www.ietf.org/shadow.html.
43 This Internet-Draft will expire on January 12, 2012.
45 Copyright Notice
47 Copyright (c) 2011 IETF Trust and the persons identified as the
48 document authors. All rights reserved.
50 This document is subject to BCP 78 and the IETF Trust's Legal
51 Provisions Relating to IETF Documents
52 (http://trustee.ietf.org/license-info) in effect on the date of
53 publication of this document. Please review these documents
54 carefully, as they describe your rights and restrictions with respect
55 to this document. Code Components extracted from this document must
56 include Simplified BSD License text as described in Section 4.e of
57 the Trust Legal Provisions and are provided without warranty as
58 described in the BSD License.
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
64 3. Updating RFC 5322 . . . . . . . . . . . . . . . . . . . . . . 4
65 4. New Header Fields Definition . . . . . . . . . . . . . . . . . 5
66 4.1. Unknown Header Fields' Preservation Header Fields . . . . 5
67 5. Email Header Fields Downgrading . . . . . . . . . . . . . . . 6
68 5.1. Downgrading Method for Each ABNF Element . . . . . . . . . 6
69 5.1.1. RECEIVED Downgrading . . . . . . . . . . . . . . . . . 7
70 5.1.2. UNSTRUCTURED Downgrading . . . . . . . . . . . . . . . 7
71 5.1.3. WORD Downgrading . . . . . . . . . . . . . . . . . . . 7
72 5.1.4. COMMENT Downgrading . . . . . . . . . . . . . . . . . 7
73 5.1.5. MIME-VALUE Downgrading . . . . . . . . . . . . . . . . 7
74 5.1.6. DISPLAY-NAME Downgrading . . . . . . . . . . . . . . . 7
75 5.1.7. GROUP Downgrading . . . . . . . . . . . . . . . . . . 7
76 5.1.8. MAILBOX Downgrading . . . . . . . . . . . . . . . . . 8
77 5.1.9. ENCAPSULATION Downgrading . . . . . . . . . . . . . . 8
78 5.1.10. TYPED-ADDRESS Downgrading . . . . . . . . . . . . . . 8
79 5.2. Downgrading Method for Each Header Field . . . . . . . . . 8
80 5.2.1. Address Header Fields That Contain
s . . . . 9
81 5.2.2. Address Header Fields with Typed Addresses . . . . . . 9
82 5.2.3. Downgrading Non-ASCII in Comments . . . . . . . . . . 9
83 5.2.4. Received Header Field . . . . . . . . . . . . . . . . 10
84 5.2.5. MIME Content Header Fields . . . . . . . . . . . . . . 10
85 5.2.6. Non-ASCII in . . . . . . . . . . . . . 10
86 5.2.7. Non-ASCII in . . . . . . . . . . . . . . . . 10
87 5.2.8. Other Header Fields . . . . . . . . . . . . . . . . . 10
88 6. MIME Body-Part Header Field Downgrading . . . . . . . . . . . 11
89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
90 8. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 12
91 8.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 12
92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
95 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
96 11.2. Informative References . . . . . . . . . . . . . . . . . . 14
97 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
98 A.1. Downgrading Example . . . . . . . . . . . . . . . . . . . 14
100 1. Introduction
102 Traditional mail systems, which are defined by [RFC5322], allow ASCII
103 characters in mail header field values. The UTF8SMTP extension
104 ([I-D.ietf-eai-frmwrk-4952bis] and [I-D.ietf-eai-rfc5335bis] allows
105 UTF-8 characters in mail header field values.
107 If a header field contains non-ASCII characters, POP/IMAP servers
108 cannot send Internationalized Email Headers to the client and cannot
109 remove the message. This message downgrading mechanism converts mail
110 header fields to an all-ASCII representation. The POP/IMAP servers
111 can use the downgrading mechanism and send the Internationalized
112 Email message as a traditional form.
114 [I-D.ietf-eai-rfc5335bis] allows UTF-8 characters to be used in mail
115 header fields and MIME header fields. The message downgrading
116 mechanism specified here describes the conversion method from the
117 internationalized email messages that are defined in
118 [I-D.ietf-eai-frmwrk-4952bis], and [I-D.ietf-eai-rfc5335bis] to the
119 traditional email messages defined in [RFC5322].
121 There is no good way to convert "From:" and "Sender:" header fields,
122 the draft need to update [RFC5322] to allow empty "From:" and
123 "Sender:" header fields and it is described in Section 3.
125 Message Downgrading may be implemented in POP server and IMAP server
126 only.
128 This document tries to define the message downgrading process
129 clearly.
131 Downgrading consists of the following four parts:
133 o Updating RFC 5322
135 o New header field definitions
137 o Email header field downgrading
139 o MIME header field downgrading
141 In Section 4 of this document, header fields starting with
142 "Downgraded-" are introduced. They preserve the original header
143 fields.
145 Email header field downgrading is described in Section 5. It
146 generates ASCII-only header fields.
148 MIME header fields are expanded in [I-D.ietf-eai-rfc5335bis]. MIME
149 header field downgrading is described in Section 6. It generates
150 ASCII-only MIME header fields.
152 Displaying downgraded messages that originally contained
153 internationalized header fields is out of scope of this document. A
154 POP/IMAP client which does not support UTF8 extension does not know
155 internationalized message format described in
156 [I-D.ietf-eai-rfc5335bis].
158 2. Terminology
160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
162 document are to be interpreted as described in RFC 2119 [RFC2119].
164 All specialized terms used in this specification are defined in the
165 Email Address Internationalization (EAI) overview
166 [I-D.ietf-eai-frmwrk-4952bis], in the mail message specifications
167 [RFC5322], or in the MIME documents [RFC2045] [RFC2047] [RFC2183]
168 [RFC2231]. The terms "ASCII address", "internationalized email
169 address", "non-ASCII address", "i18mail address", "UTF8SMTP",
170 "message", and "mailing list" are used with the definitions from
171 [I-D.ietf-eai-frmwrk-4952bis].
173 This document depends on [I-D.ietf-eai-rfc5335bis]. Key words used
174 in those documents are used in this document, too.
176 The term "non-ASCII" refers to a UTF-8 string that contains at least
177 one non-ASCII character.
179 A "UTF8SMTP message" is an email message expanded by
180 [I-D.ietf-eai-rfc5335bis].
182 3. Updating RFC 5322
184 "From:" header field or "Sender:" header field may contain non-ASCII
185 addresses in internationalized Email messages. These non-ASCII
186 addresses are not allowed in [RFC5322]. The draft proposes that the
187 pop/imap downgrading uses syntax and encodes non-ASCII
188 addresses into with empty described in
189 Section 5.
191 This specification redefines "From:", "Sender:", "Resent-From:" and
192 "Resent-Sender:" header fields defined in Section 3.6.2 and 3.6.6 of
193 [RFC5322] to allow in the header fields.
195 from = "From:" address-list CRLF
196 resent-from = "Resent-From:" address-list CRLF
197 sender = "Sender:" address CRLF
198 resent-sender = "Resent-Sender:" address CRLF
200 [[Note in Draft: There are still outstanding questions about the use
201 of group syntax that the WG should resolve, or confirm that it is
202 willing to live with and figure out how to describe in the document,
203 at IETF 81. They include
205 1. RFC 5322 does not allow group syntax in From and Sender header
206 fields. Existing MUAs may become very confused when they see
207 group syntax in originator fields.
209 2. Use of group syntax in this way will essentially make it
210 impossible to reply to a message.
212 3. "Reply-To:" header field allows the group syntax in [RFC5322].
213 Is it correct ?
215 4. The ABNF syntax here is not yet complete.
217 5. Should the document explicitly recommend the use of comments,
218 possibly with encoded words, to document the original non-ASCII
219 mailboxes?
221 Suggestion made to the WG for more in depth discussion. ]]
223 4. New Header Fields Definition
225 New header fields starting with "Downgraded-" are defined here to
226 preserve those mail header field values that contain UTF-8
227 characters. During downgrading, one new "Downgraded-" header field
228 is added for each mail header field that cannot be passed as-is to a
229 POP/IMAP client that does not support UTF8 extension. The original
230 mail header field is removed or rewritten. Only those mail header
231 fields that contain non-ASCII characters are affected. The result of
232 this process is a message that is compliant with existing email
233 specifications [RFC5322]. The original internationalized information
234 can be retrieved by examining the "Downgraded-" header fields that
235 were added.
237 4.1. Unknown Header Fields' Preservation Header Fields
239 The unknown header fields' preservation header fields are defined to
240 encapsulate those original header fields that contain non-ASCII
241 characters and are not otherwise provided for in this specification.
243 The encapsulation header field name is the concatenation of
244 "Downgraded-" and the original name. The value field holds the
245 original header field value.
247 The header field syntax is specified as follows:
249 fields =/ unknown-downgraded-headers ":" unstructured CRLF
251 unknown-downgraded-headers = "Downgraded-" original-header-field-name
253 original-header-field-name = field-name
255 field-name = 1*ftext
257 ftext = %d33-57 / ; Any character except
258 %d59-126 ; controls, SP, and ":".
260 To encapsulate a header field in a "Downgraded-" header field:
262 1. Generate a new "Downgraded-" header field whose value is the
263 original header field value.
265 2. Treat the generated header field content as if it were
266 unstructured, and then apply [RFC2047] encoding with charset
267 UTF-8 as necessary so the result is ASCII.
269 3. Remove the original header field.
271 5. Email Header Fields Downgrading
273 This section defines the conversion method to ASCII for each header
274 field that may contain non-ASCII characters.
276 [I-D.ietf-eai-rfc5335bis] expands "Received:" header fields;
277 [RFC5322] describes ABNF elements , , ,
278 ; [RFC2045] describes ABNF element .
280 5.1. Downgrading Method for Each ABNF Element
282 Header field downgrading is defined below for each ABNF element.
283 Downgrading an unknown header field is also defined as ENCAPSULATION
284 downgrading. Converting the header field terminates when no non-
285 ASCII characters remain in the header field.
287 5.1.1. RECEIVED Downgrading
289 If the header field name is "Received:" and the FOR clause contains a
290 non-ASCII address, remove the FOR clause from the header field.
291 Other parts (not counting s) should not contain non-ASCII
292 values.
294 5.1.2. UNSTRUCTURED Downgrading
296 If the header field has an field that contains non-
297 ASCII characters, apply [RFC2047] encoding with charset UTF-8.
299 5.1.3. WORD Downgrading
301 If the header field has any fields that contain non-ASCII
302 characters, apply [RFC2047] encoding with charset UTF-8.
304 5.1.4. COMMENT Downgrading
306 If the header field has any fields that contain non-ASCII
307 characters, apply [RFC2047] encoding with charset UTF-8.
309 5.1.5. MIME-VALUE Downgrading
311 If the header field has any elements defined by [RFC2045] and
312 the elements contain non-ASCII characters, encode the
313 elements according to [RFC2231] with charset UTF-8 and leave the
314 language information empty. If the element is and it contains outside the DQUOTE, remove the
316 before this conversion.
318 5.1.6. DISPLAY-NAME Downgrading
320 If the header field has any ( or ) elements
321 and they have elements that contain non-ASCII
322 characters, encode the elements according to [RFC2047]
323 with charset UTF-8. DISPLAY-NAME downgrading is the same algorithm
324 as WORD downgrading.
326 5.1.7. GROUP Downgrading
328 is defined in Section 3.4 of [RFC5322]. The elements
329 may contain s which contain non-ASCII addresses.
331 If the header field has any elements which contain
332 elements that contain non-ASCII addresses, rewrite each
333 element as
335 "Internationalized_Address_Removed" display-name ENCODED_WORD ":;" [CFWS]
337 where the is the original encoded
338 according to [RFC2047].
340 5.1.8. MAILBOX Downgrading
342 The elements have no equivalent format for non-ASCII
343 addresses. If the header field has any elements that
344 contain non-ASCII characters, rewrite each element to
345 ASCII-only format. The element that contains non-ASCII
346 characters is one of two formats.
348 [ Display-name ] "<" Utf8-addr-spec ">"
350 Utf8-addr-spec
352 Rewrite both as:
353 [ Display-name ] "Internationalized Address " Encoded-word
354 " Removed:;"
355 where the is the original encoded
356 according to [RFC2047].
358 5.1.9. ENCAPSULATION Downgrading
360 If the header field contains non-ASCII characters and is such that no
361 rule is given above, encapsulate it in a "Downgraded-" header field
362 as described in Section 4.1 as a last resort.
364 Applying this procedure to "Received:" header field is prohibited.
366 5.1.10. TYPED-ADDRESS Downgrading
368 If the header field contains and the contains raw non-ASCII characters, it is in utf-8-address form.
370 Convert it to utf-8-addr-xtext form. Those forms are described in
371 [I-D.ietf-eai-rfc5337bis-dsn]. COMMENT downgrading is also performed
372 in this case. If the address type is unrecognized and the header
373 field contains non-ASCII characters, then fall back to using
374 ENCAPSULATION downgrading on the entire header field.
376 5.2. Downgrading Method for Each Header Field
378 Header fields are listed in [RFC4021]. This section describes the
379 downgrading method for each header field.
381 If the whole mail header field does not contain non-ASCII characters,
382 email header field downgrading is not required. Each header field's
383 downgrading method is described below.
385 5.2.1. Address Header Fields That Contain s
387 From:
388 Sender:
389 To:
390 Cc:
391 Bcc:
392 Reply-To:
393 Resent-From:
394 Resent-Sender:
395 Resent-To:
396 Resent-Cc:
397 Resent-Bcc:
398 Resent-Reply-To:
399 Return-Path:
400 Disposition-Notification-To:
402 If the header field contains elements that contain non-ASCII
403 addresses, perform COMMENT downgrading, DISPLAY-NAME downgrading, and
404 GROUP downgrading.
406 If the header field contains elements that contain non-
407 ASCII addresses, perform COMMENT downgrading, DISPLAY-NAME
408 downgrading, and MAILBOX downgrading.
410 5.2.2. Address Header Fields with Typed Addresses
412 Original-Recipient:
413 Final-Recipient:
415 If the header field contains non-ASCII characters, perform TYPED-
416 ADDRESS downgrading.
418 5.2.3. Downgrading Non-ASCII in Comments
420 Date:
421 Message-ID:
422 Resent-Message-ID:
423 In-Reply-To:
424 References:
426 Resent-Date:
427 Resent-Message-ID:
428 MIME-Version:
429 Content-ID:
430 Content-Transfer-Encoding:
431 Content-Language:
432 Accept-Language:
433 Auto-Submitted:
435 These header fields do not contain non-ASCII characters except in
436 comments. If the header field contains UTF-8 characters in comments,
437 perform COMMENT downgrading.
439 5.2.4. Received Header Field
441 Received:
443 Perform COMMENT downgrading and RECEIVED downgrading.
445 5.2.5. MIME Content Header Fields
447 Content-Type:
448 Content-Disposition:
450 Perform MIME-VALUE downgrading and COMMENT downgrading.
452 5.2.6. Non-ASCII in
454 Subject:
455 Comments:
456 Content-Description:
458 Perform UNSTRUCTURED downgrading.
460 5.2.7. Non-ASCII in
462 Keywords:
464 Perform WORD downgrading.
466 5.2.8. Other Header Fields
468 For all other header fields that contain non-ASCII characters, are
469 user-defined, and are missing from this document or future defined
470 header fields, perform ENCAPSULATION downgrading.
472 If the software understands the header field's structure and a
473 downgrading algorithm other than ENCAPSULATION is applicable, that
474 software SHOULD use that algorithm; ENCAPSULATION downgrading is used
475 as a last resort.
477 Mailing list header fields (those that start in "List-") are part of
478 this category.
480 6. MIME Body-Part Header Field Downgrading
482 MIME body-part header fields may contain non-ASCII characters
483 [I-D.ietf-eai-rfc5335bis]. This section defines the conversion
484 method to ASCII-only header fields for each MIME header field that
485 contains non-ASCII characters. Parse the message body's MIME
486 structure at all levels and check each MIME header field to see
487 whether it contains non-ASCII characters. If the header field
488 contains non-ASCII characters in the header field value, the header
489 field is a target of the MIME body-part header field's downgrading.
490 Each MIME header field's downgrading method is described below.
491 COMMENT downgrading, MIME-VALUE downgrading, and UNSTRUCTURED
492 downgrading are described in Section 5.
494 Content-ID:
495 The "Content-ID:" header field does not contain non-ASCII
496 characters except in comments. If the header field contains UTF-8
497 characters in comments, perform COMMENT downgrading.
499 Content-Type:
501 Content-Disposition: Perform MIME-VALUE downgrading and COMMENT
502 downgrading.
504 Content-Description: Perform UNSTRUCTURED downgrading.
506 7. Security Considerations
508 A downgraded message's header fields contain ASCII characters only.
509 But they still contain MIME-encapsulated header fields that contain
510 non-ASCII UTF-8 characters. Furthermore, the body part may contain
511 UTF-8 characters. Implementations parsing Internet messages need to
512 accept UTF-8 body parts and UTF-8 header fields that are MIME-
513 encoded. Thus, this document inherits the security considerations of
514 MIME-encoded header fields ([RFC2047] and [RFC3629]).
516 Rewriting header fields increases the opportunities for undetected
517 spoofing by malicious senders. However, rewritten header fields are
518 preserved into Downgraded-* header fields, and parsing Downgraded-*
519 header fields enables the detection of spoofing caused by
520 downgrading.
522 The techniques described here invalidate methods that depend on
523 digital signatures over any part of the message, which includes the
524 top-level header fields and body-part header fields. Depending on
525 the specific message being downgraded, the following techniques are
526 likely to break: DomainKeys Identified Mail (DKIM), and possibly
527 S/MIME and Pretty Good Privacy (PGP). The two obvious mitigations
528 are to stick to 7-bit transport when using these techniques (as most/
529 all of them presently require) or to make sure to have UTF8SMTP end-
530 to-end when needed.
532 While information in any email header field should usually be treated
533 with some suspicion, current email systems commonly employ various
534 mechanisms and protocols to make the information more trustworthy.
535 Currently, information in the new Downgraded-* header fields is
536 usually not inspected by these mechanisms, and may be even less
537 trustworthy than the traditional header fields. Note that the
538 Downgraded-* header fields could have been inserted with malicious
539 intent (and with content unrelated to the traditional header fields).
541 See the "Security Considerations" section in
542 [I-D.ietf-eai-frmwrk-4952bis] for more discussion.
544 8. Implementation Notes
546 8.1. RFC 2047 Encoding
548 While [RFC2047] has a specific algorithm to deal with whitespace in
549 adjacent encoded words, there are a number of deployed
550 implementations that fail to implement the algorithm correctly. As a
551 result, whitespace behavior is somewhat unpredictable in practice
552 when multiple encoded words are used. While RFC 5322 states that
553 implementations SHOULD limit lines to not more than 78 characters,
554 implementations MAY choose to allow overly long encoded words in
555 order to work around faulty [RFC2047] implementations.
556 Implementations that choose to do so SHOULD have an optional
557 mechanism to limit line length to 78 characters.
559 9. IANA Considerations
561 IANA is requested to refuse registration of all field names that
562 start with "Downgraded-". For unknown header fields, use the
563 downgrading method described in Section 4.1 to avoid conflicts with
564 existing IETF activity (Email Address Internationalization).
566 10. Acknowledgements
568 This document draws heavily from the experimental in-transit message
569 downgrading procedure described in RFC 5504 [RFC5504]. The
570 contribution of the co-author of that earlier document, Y. Yoneya,
571 are gratefully acknowledged.
573 11. References
575 11.1. Normative References
577 [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and
578 Framework for Internationalized
579 Email",
580 draft-ietf-eai-frmwrk-4952bis-10 (work
581 in progress), September 2010.
583 [I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., and N. Freed,
584 "Internationalized Email Headers",
585 draft-ietf-eai-rfc5335bis-11 (work in
586 progress), July 2011.
588 [I-D.ietf-eai-rfc5337bis-dsn] Hansen, T., Newman, C., and A.
589 Melnikov, "Internationalized Delivery
590 Status and Disposition Notifications",
591 draft-ietf-eai-rfc5337bis-dsn-02 (work
592 in progress), April 2011.
594 [RFC2045] Freed, N. and N. Borenstein,
595 "Multipurpose Internet Mail Extensions
596 (MIME) Part One: Format of Internet
597 Message Bodies", RFC 2045,
598 November 1996.
600 [RFC2047] Moore, K., "MIME (Multipurpose
601 Internet Mail Extensions) Part Three:
602 Message Header Extensions for Non-
603 ASCII Text", RFC 2047, November 1996.
605 [RFC2119] Bradner, S., "Key words for use in
606 RFCs to Indicate Requirement Levels",
607 BCP 14, RFC 2119, March 1997.
609 [RFC2183] Troost, R., Dorner, S., and K. Moore,
610 "Communicating Presentation
611 Information in Internet Messages: The
612 Content-Disposition Header Field",
613 RFC 2183, August 1997.
615 [RFC2231] Freed, N. and K. Moore, "MIME
616 Parameter Value and Encoded Word
617 Extensions: Character Sets, Languages,
618 and Continuations", RFC 2231,
619 November 1997.
621 [RFC3629] Yergeau, F., "UTF-8, a transformation
622 format of ISO 10646", STD 63,
623 RFC 3629, November 2003.
625 [RFC4021] Klyne, G. and J. Palme, "Registration
626 of Mail and MIME Header Fields",
627 RFC 4021, March 2005.
629 [RFC5322] Resnick, P., Ed., "Internet Message
630 Format", RFC 5322, October 2008.
632 11.2. Informative References
634 [RFC5504] Fujiwara, K. and Y. Yoneya,
635 "Downgrading Mechanism for Email
636 Address Internationalization",
637 RFC 5504, March 2009.
639 Appendix A. Examples
641 A.1. Downgrading Example
643 This appendix shows an message downgrading example. Consider a
644 received mail message where:
646 o The sender address is a non-ASCII address,
647 "NON-ASCII-local@example.com". Its display-name is "DISPLAY-
648 local".
650 o The "To:" header field contains two non-ASCII addresses,
651 "NON-ASCII-remote1@example.net" and
652 "NON-ASCII-remote2@example.com" Its display-names are "DISPLAY-
653 remote1" and "DISPLAY-remote2".
655 o The "Cc:" header field contains a non-ASCII address,
656 "NON-ASCII-remote3@example.org". Its display-name is "DISPLAY-
657 remote3".
659 o Four display names contain non-ASCII characters.
661 o The Subject header field is "NON-ASCII-SUBJECT", which contains
662 non-ASCII characters.
664 o There is an unknown header field "X-Unknown-Header" which contains
665 non-ASCII characters.
667 Return-Path:
668 Received: from ... by ... for
669 Received: from ... by ... for
670 From: DISPLAY-local
671 To: DISPLAY-remote1 ,
672 DISPLAY-remote2
673 Cc: DISPLAY-remote3
674 Subject: NON-ASCII-SUBJECT
675 Date: DATE
676 Message-Id: MESSAGE_ID
677 Mime-Version: 1.0
678 Content-Type: text/plain; charset="UTF-8"
679 Content-Transfer-Encoding: 8bit
680 X-Unknown-Header: NON-ASCII-CHARACTERS
682 MAIL_BODY
684 Figure 1: Received message in a mail drop
686 The downgraded message is shown in Figure 2. "Return-Path:",
687 "From:", "To:" and "Cc:" header fields are rewritten. "X-Unknown-
688 Header:" is encapsulated as "Downgraded-X-Unknown-Header:".
690 Return-Path: Internationalized address
691 =?UTF-8?Q?NON-ASCII-local@example.com?= removed:;
692 Received: from ... by ...
693 Received: from ... by ...
694 From: =?UTF-8?Q?DISPLAY-local?= Internationalized address
695 =?UTF-8?Q?NON-ASCII-local@example.com?= removed:;
696 To: =?UTF-8?Q?DISPLAY-remote1?= Internationalized address
697 =?UTF-8?Q?NON-ASCII-remote1@example.net?= removed:;,
698 =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
699 =?UTF-8?Q?NON-ASCII-remote2@example.com?= removed:;,
700 Cc: =?UTF-8?Q?DISPLAY-remote3?= Internationalized address
701 =?UTF-8?Q?NON-ASCII-remote3@example.org?= removed:;
702 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
703 Date: DATE
704 Message-Id: MESSAGE_ID
705 Mime-Version: 1.0
706 Content-Type: text/plain; charset="UTF-8"
707 Content-Transfer-Encoding: 8bit
708 Downgraded-X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?=
710 MAIL_BODY
712 Figure 2: Downgraded message
714 Author's Address
716 Kazunori Fujiwara
717 Japan Registry Services Co., Ltd.
718 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
719 Chiyoda-ku, Tokyo 101-0065
720 Japan
722 Phone: +81 3 5215 8451
723 EMail: fujiwara@jprs.co.jp