idnits 2.17.1
draft-ietf-eai-popimap-downgrade-00.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 :
----------------------------------------------------------------------------
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 date (Oct 15, 2010) is 4914 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)
== Unused Reference: 'RFC2979' is defined on line 557, but no explicit
reference was found in the text
== Unused Reference: 'RFC3864' is defined on line 565, but no explicit
reference was found in the text
== 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-02
** Downref: Normative reference to an Informational RFC: RFC 2979
** Obsolete normative reference: RFC 5337 (Obsoleted by RFC 6533)
-- Obsolete informational reference (is this intentional?): RFC 5504
(Obsoleted by RFC 6530)
Summary: 3 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 Oct 15, 2010
5 Intended status: Standards Track
6 Expires: April 18, 2011
8 Post-delivery Message Downgrading for Internationalized Email Messages
9 draft-ietf-eai-popimap-downgrade-00.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 April 18, 2011.
45 Copyright Notice
47 Copyright (c) 2010 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. New Header Fields Definition . . . . . . . . . . . . . . . . . 4
65 3.1. Unknown Header Fields' Preservation Header Fields . . . . 5
66 4. Email Header Fields Downgrading . . . . . . . . . . . . . . . 5
67 4.1. Downgrading Method for Each ABNF Element . . . . . . . . . 5
68 4.1.1. RECEIVED Downgrading . . . . . . . . . . . . . . . . . 6
69 4.1.2. UNSTRUCTURED Downgrading . . . . . . . . . . . . . . . 6
70 4.1.3. WORD Downgrading . . . . . . . . . . . . . . . . . . . 6
71 4.1.4. COMMENT Downgrading . . . . . . . . . . . . . . . . . 6
72 4.1.5. MIME-VALUE Downgrading . . . . . . . . . . . . . . . . 6
73 4.1.6. DISPLAY-NAME Downgrading . . . . . . . . . . . . . . . 6
74 4.1.7. MAILBOX Downgrading . . . . . . . . . . . . . . . . . 6
75 4.1.8. ENCAPSULATION Downgrading . . . . . . . . . . . . . . 7
76 4.1.9. TYPED-ADDRESS Downgrading . . . . . . . . . . . . . . 7
77 4.2. Downgrading Method for Each Header Field . . . . . . . . . 7
78 4.2.1. Address Header Fields That Contain
s . . . . 7
79 4.2.2. Address Header Fields with Typed Addresses . . . . . . 8
80 4.2.3. Downgrading Non-ASCII in Comments . . . . . . . . . . 8
81 4.2.4. Received Header Field . . . . . . . . . . . . . . . . 9
82 4.2.5. MIME Content Header Fields . . . . . . . . . . . . . . 9
83 4.2.6. Non-ASCII in . . . . . . . . . . . . . 9
84 4.2.7. Non-ASCII in . . . . . . . . . . . . . . . . 9
85 4.2.8. Other Header Fields . . . . . . . . . . . . . . . . . 9
86 5. MIME Body-Part Header Field Downgrading . . . . . . . . . . . 10
87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
88 7. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 11
89 7.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 11
90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
94 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
95 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13
96 A.1. Downgrading Example . . . . . . . . . . . . . . . . . . . 13
98 1. Introduction
100 Traditional mail systems, which are defined by [RFC5322], allow ASCII
101 characters in mail header field values. The UTF8SMTP extension
102 ([I-D.ietf-eai-frmwrk-4952bis] and [I-D.ietf-eai-rfc5335bis] allows
103 UTF-8 characters in mail header field values.
105 If a header field contains non-ASCII characters, POP/IMAP servers
106 cannot send Internationalized Email Headers to the client and cannot
107 remove the message. This message downgrading mechanism converts mail
108 header fields to an all-ASCII representation. The POP/IMAP servers
109 can use the downgrading mechanism and send the Internationalized
110 Email message as a traditional form.
112 [I-D.ietf-eai-rfc5335bis] allows UTF-8 characters to be used in mail
113 header fields and MIME header fields. The message downgrading
114 mechanism specified here converts mail header fields and MIME header
115 fields to ASCII.
117 This document does not change any protocols except by defining new
118 header fields. It describes the conversion method from the
119 internationalized email messages that are defined in
120 [I-D.ietf-eai-frmwrk-4952bis], and [I-D.ietf-eai-rfc5335bis] to the
121 traditional email messages defined in [RFC5322].
123 Message Downgrading may be implemented in POP server and IMAP server
124 only.
126 This document tries to define the message downgrading process
127 clearly.
129 Downgrading consists of the following three parts:
131 o New header field definitions
133 o Email header field downgrading
135 o MIME header field downgrading
137 In Section 3 of this document, header fields starting with
138 "Downgraded-" are introduced. They preserve the original header
139 fields.
141 Email header field downgrading is described in Section 4. It
142 generates ASCII-only header fields.
144 MIME header fields are expanded in [I-D.ietf-eai-rfc5335bis]. MIME
145 header field downgrading is described in Section 5. It generates
146 ASCII-only MIME header fields.
148 Displaying downgraded messages that originally contained
149 internationalized header fields is out of scope of this document. A
150 POP/IMAP client which does not support UTF8 extension does not know
151 internationalized message format described in
152 [I-D.ietf-eai-rfc5335bis].
154 2. Terminology
156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
158 document are to be interpreted as described in RFC 2119 [RFC2119].
160 All specialized terms used in this specification are defined in the
161 Email Address Internationalization (EAI) overview
162 [I-D.ietf-eai-frmwrk-4952bis], in the mail message specifications
163 [RFC5322], or in the MIME documents [RFC2045] [RFC2047] [RFC2183]
164 [RFC2231]. The terms "ASCII address", "internationalized email
165 address", "non-ASCII address", "i18mail address", "UTF8SMTP",
166 "message", and "mailing list" are used with the definitions from
167 [I-D.ietf-eai-frmwrk-4952bis].
169 This document depends on [I-D.ietf-eai-rfc5335bis]. Key words used
170 in those documents are used in this document, too.
172 The term "non-ASCII" refers to a UTF-8 string that contains at least
173 one non-ASCII character.
175 A "UTF8SMTP message" is an email message expanded by
176 [I-D.ietf-eai-rfc5335bis].
178 3. New Header Fields Definition
180 New header fields starting with "Downgraded-" are defined here to
181 preserve those mail header field values that contain UTF-8
182 characters. During downgrading, one new "Downgraded-" header field
183 is added for each mail header field that cannot be passed as-is to a
184 POP/IMAP client that does not support UTF8 extension. The original
185 mail header field is removed or rewritten. Only those mail header
186 fields that contain non-ASCII characters are affected. The result of
187 this process is a message that is compliant with existing email
188 specifications [RFC5322]. The original internationalized information
189 can be retrieved by examining the "Downgraded-" header fields that
190 were added.
192 3.1. Unknown Header Fields' Preservation Header Fields
194 The unknown header fields' preservation header fields are defined to
195 encapsulate those original header fields that contain non-ASCII
196 characters and are not otherwise provided for in this specification.
197 The encapsulation header field name is the concatenation of
198 "Downgraded-" and the original name. The value field holds the
199 original header field value.
201 The header field syntax is specified as follows:
203 fields =/ unknown-downgraded-headers ":" unstructured CRLF
205 unknown-downgraded-headers = "Downgraded-" original-header-field-name
207 original-header-field-name = field-name
209 field-name = 1*ftext
211 ftext = %d33-57 / ; Any character except
212 %d59-126 ; controls, SP, and ":".
214 To encapsulate a header field in a "Downgraded-" header field:
216 1. Generate a new "Downgraded-" header field whose value is the
217 original header field value.
219 2. Treat the generated header field content as if it were
220 unstructured, and then apply [RFC2047] encoding with charset
221 UTF-8 as necessary so the result is ASCII.
223 3. Remove the original header field.
225 4. Email Header Fields Downgrading
227 This section defines the conversion method to ASCII for each header
228 field that may contain non-ASCII characters.
230 [I-D.ietf-eai-rfc5335bis] expands "Received:" header fields;
231 [RFC5322] describes ABNF elements , , ,
232 ; [RFC2045] describes ABNF element .
234 4.1. Downgrading Method for Each ABNF Element
236 Header field downgrading is defined below for each ABNF element.
237 Downgrading an unknown header field is also defined as ENCAPSULATION
238 downgrading. Converting the header field terminates when no non-
239 ASCII characters remain in the header field.
241 4.1.1. RECEIVED Downgrading
243 If the header field name is "Received:" and the FOR clause contains a
244 non-ASCII address, remove the FOR clause from the header field.
245 Other parts (not counting s) should not contain non-ASCII
246 values.
248 4.1.2. UNSTRUCTURED Downgrading
250 If the header field has an field that contains non-
251 ASCII characters, apply [RFC2047] encoding with charset UTF-8.
253 4.1.3. WORD Downgrading
255 If the header field has any fields that contain non-ASCII
256 characters, apply [RFC2047] encoding with charset UTF-8.
258 4.1.4. COMMENT Downgrading
260 If the header field has any fields that contain non-ASCII
261 characters, apply [RFC2047] encoding with charset UTF-8.
263 4.1.5. MIME-VALUE Downgrading
265 If the header field has any elements defined by [RFC2045] and
266 the elements contain non-ASCII characters, encode the
267 elements according to [RFC2231] with charset UTF-8 and leave the
268 language information empty. If the element is and it contains outside the DQUOTE, remove the
270 before this conversion.
272 4.1.6. DISPLAY-NAME Downgrading
274 If the header field has any ( or ) elements
275 and they have elements that contain non-ASCII
276 characters, encode the elements according to [RFC2047]
277 with charset UTF-8. DISPLAY-NAME downgrading is the same algorithm
278 as WORD downgrading.
280 4.1.7. MAILBOX Downgrading
282 The elements have no equivalent format for non-ASCII
283 addresses. If the header field has any elements that
284 contain non-ASCII characters, rewrite each element to
285 ASCII-only format. The element that contains non-ASCII
286 characters is one of two formats.
288 [ Display-name ] "<" Utf8-addr-spec ">"
290 Utf8-addr-spec
292 Rewrite both as:
293 [ Display-name ] "Internationalized Address " Encoded-word
294 " Removed:;"
295 where the is the original encoded
296 according to [RFC2047].
298 [[ Note: If the original non-ASCII address is a part of a group
299 address, this rewriting may conflict the original DISPLAY-NAME. This
300 problem need to be fixed. ]]
302 4.1.8. ENCAPSULATION Downgrading
304 If the header field contains non-ASCII characters and is such that no
305 rule is given above, encapsulate it in a "Downgraded-" header field
306 as described in Section 3.1 as a last resort.
308 Applying this procedure to "Received:" header field is prohibited.
310 4.1.9. TYPED-ADDRESS Downgrading
312 If the header field contains and the contains raw non-ASCII characters, it is in utf-8-address form.
314 Convert it to utf-8-addr-xtext form. Those forms are described in
315 [RFC5337]. COMMENT downgrading is also performed in this case. If
316 the address type is unrecognized and the header field contains non-
317 ASCII characters, then fall back to using ENCAPSULATION downgrading
318 on the entire header field.
320 4.2. Downgrading Method for Each Header Field
322 Header fields are listed in [RFC4021]. This section describes the
323 downgrading method for each header field.
325 If the whole mail header field does not contain non-ASCII characters,
326 email header field downgrading is not required. Each header field's
327 downgrading method is described below.
329 4.2.1. Address Header Fields That Contain s
330 From:
331 Sender:
332 To:
333 Cc:
334 Bcc:
335 Reply-To:
336 Resent-From:
337 Resent-Sender:
338 Resent-To:
339 Resent-Cc:
340 Resent-Bcc:
341 Resent-Reply-To:
342 Return-Path:
343 Disposition-Notification-To:
345 If the header field contains elements that contain non-
346 ASCII addresses, perform COMMENT downgrading, DISPLAY-NAME
347 downgrading, and MAILBOX downgrading.
349 [[ Note: RFC 5322 does not allow group syntax in "From:", "Resent-
350 From:", "Sender:", "Resent-Sender:", but proposed method uses group
351 syntax. This problem need to be fixed. ]]
353 4.2.2. Address Header Fields with Typed Addresses
355 Original-Recipient:
356 Final-Recipient:
358 If the header field contains non-ASCII characters, perform TYPED-
359 ADDRESS downgrading.
361 4.2.3. Downgrading Non-ASCII in Comments
363 Date:
364 Message-ID:
365 Resent-Message-ID:
366 In-Reply-To:
367 References:
368 Resent-Date:
369 Resent-Message-ID:
370 MIME-Version:
371 Content-ID:
372 Content-Transfer-Encoding:
373 Content-Language:
375 Accept-Language:
376 Auto-Submitted:
378 These header fields do not contain non-ASCII characters except in
379 comments. If the header field contains UTF-8 characters in comments,
380 perform COMMENT downgrading.
382 4.2.4. Received Header Field
384 Received:
386 Perform COMMENT downgrading and RECEIVED downgrading.
388 4.2.5. MIME Content Header Fields
390 Content-Type:
391 Content-Disposition:
393 Perform MIME-VALUE downgrading and COMMENT downgrading.
395 4.2.6. Non-ASCII in
397 Subject:
398 Comments:
399 Content-Description:
401 Perform UNSTRUCTURED downgrading.
403 4.2.7. Non-ASCII in
405 Keywords:
407 Perform WORD downgrading.
409 4.2.8. Other Header Fields
411 For all other header fields that contain non-ASCII characters, are
412 user-defined, and are missing from this document or future defined
413 header fields, perform ENCAPSULATION downgrading.
415 If the software understands the header field's structure and a
416 downgrading algorithm other than ENCAPSULATION is applicable, that
417 software SHOULD use that algorithm; ENCAPSULATION downgrading is used
418 as a last resort.
420 Mailing list header fields (those that start in "List-") are part of
421 this category.
423 5. MIME Body-Part Header Field Downgrading
425 MIME body-part header fields may contain non-ASCII characters
426 [I-D.ietf-eai-rfc5335bis]. This section defines the conversion
427 method to ASCII-only header fields for each MIME header field that
428 contains non-ASCII characters. Parse the message body's MIME
429 structure at all levels and check each MIME header field to see
430 whether it contains non-ASCII characters. If the header field
431 contains non-ASCII characters in the header field value, the header
432 field is a target of the MIME body-part header field's downgrading.
433 Each MIME header field's downgrading method is described below.
434 COMMENT downgrading, MIME-VALUE downgrading, and UNSTRUCTURED
435 downgrading are described in Section 4.
437 Content-ID:
438 The "Content-ID:" header field does not contain non-ASCII
439 characters except in comments. If the header field contains UTF-8
440 characters in comments, perform COMMENT downgrading.
442 Content-Type:
444 Content-Disposition: Perform MIME-VALUE downgrading and COMMENT
445 downgrading.
447 Content-Description: Perform UNSTRUCTURED downgrading.
449 6. Security Considerations
451 A downgraded message's header fields contain ASCII characters only.
452 But they still contain MIME-encapsulated header fields that contain
453 non-ASCII UTF-8 characters. Furthermore, the body part may contain
454 UTF-8 characters. Implementations parsing Internet messages need to
455 accept UTF-8 body parts and UTF-8 header fields that are MIME-
456 encoded. Thus, this document inherits the security considerations of
457 MIME-encoded header fields ([RFC2047] and [RFC3629]).
459 Rewriting header fields increases the opportunities for undetected
460 spoofing by malicious senders. However, rewritten header fields are
461 preserved into Downgraded-* header fields, and parsing Downgraded-*
462 header fields enables the detection of spoofing caused by
463 downgrading.
465 The techniques described here invalidate methods that depend on
466 digital signatures over any part of the message, which includes the
467 top-level header fields and body-part header fields. Depending on
468 the specific message being downgraded, the following techniques are
469 likely to break: DomainKeys Identified Mail (DKIM), and possibly
470 S/MIME and Pretty Good Privacy (PGP). The two obvious mitigations
471 are to stick to 7-bit transport when using these techniques (as most/
472 all of them presently require) or to make sure to have UTF8SMTP end-
473 to-end when needed.
475 While information in any email header field should usually be treated
476 with some suspicion, current email systems commonly employ various
477 mechanisms and protocols to make the information more trustworthy.
478 Currently, information in the new Downgraded-* header fields is
479 usually not inspected by these mechanisms, and may be even less
480 trustworthy than the traditional header fields. Note that the
481 Downgraded-* header fields could have been inserted with malicious
482 intent (and with content unrelated to the traditional header fields).
484 See the "Security Considerations" section in
485 [I-D.ietf-eai-frmwrk-4952bis] for more discussion.
487 7. Implementation Notes
489 7.1. RFC 2047 Encoding
491 While [RFC2047] has a specific algorithm to deal with whitespace in
492 adjacent encoded words, there are a number of deployed
493 implementations that fail to implement the algorithm correctly. As a
494 result, whitespace behavior is somewhat unpredictable in practice
495 when multiple encoded words are used. While RFC 5322 states that
496 implementations SHOULD limit lines to not more than 78 characters,
497 implementations MAY choose to allow overly long encoded words in
498 order to work around faulty [RFC2047] implementations.
499 Implementations that choose to do so SHOULD have an optional
500 mechanism to limit line length to 78 characters.
502 8. IANA Considerations
504 IANA is requested to refuse registration of all field names that
505 start with "Downgraded-". For unknown header fields, use the
506 downgrading method described in Section 3.1 to avoid conflicts with
507 existing IETF activity (Email Address Internationalization).
509 9. Acknowledgements
511 This document draws heavily from the experimental in-transit message
512 downgrading procedure described in RFC 5504 [RFC5504]. The
513 contribution of the co-author of that earlier document, Y. Yoneya,
514 are gratefully acknowledged.
516 10. References
517 10.1. Normative References
519 [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and
520 Framework for Internationalized
521 Email",
522 draft-ietf-eai-frmwrk-4952bis-10 (work
523 in progress), September 2010.
525 [I-D.ietf-eai-rfc5335bis] Yang, A. and S. Steele,
526 "Internationalized Email Headers",
527 draft-ietf-eai-rfc5335bis-02 (work in
528 progress), August 2010.
530 [RFC2045] Freed, N. and N. Borenstein,
531 "Multipurpose Internet Mail Extensions
532 (MIME) Part One: Format of Internet
533 Message Bodies", RFC 2045,
534 November 1996.
536 [RFC2047] Moore, K., "MIME (Multipurpose
537 Internet Mail Extensions) Part Three:
538 Message Header Extensions for Non-
539 ASCII Text", RFC 2047, November 1996.
541 [RFC2119] Bradner, S., "Key words for use in
542 RFCs to Indicate Requirement Levels",
543 BCP 14, RFC 2119, March 1997.
545 [RFC2183] Troost, R., Dorner, S., and K. Moore,
546 "Communicating Presentation
547 Information in Internet Messages: The
548 Content-Disposition Header Field",
549 RFC 2183, August 1997.
551 [RFC2231] Freed, N. and K. Moore, "MIME
552 Parameter Value and Encoded Word
553 Extensions: Character Sets, Languages,
554 and Continuations", RFC 2231,
555 November 1997.
557 [RFC2979] Freed, N., "Behavior of and
558 Requirements for Internet Firewalls",
559 RFC 2979, October 2000.
561 [RFC3629] Yergeau, F., "UTF-8, a transformation
562 format of ISO 10646", STD 63,
563 RFC 3629, November 2003.
565 [RFC3864] Klyne, G., Nottingham, M., and J.
566 Mogul, "Registration Procedures for
567 Message Header Fields", BCP 90,
568 RFC 3864, September 2004.
570 [RFC4021] Klyne, G. and J. Palme, "Registration
571 of Mail and MIME Header Fields",
572 RFC 4021, March 2005.
574 [RFC5322] Resnick, P., Ed., "Internet Message
575 Format", RFC 5322, October 2008.
577 [RFC5337] Newman, C. and A. Melnikov,
578 "Internationalized Delivery Status and
579 Disposition Notifications", RFC 5337,
580 September 2008.
582 10.2. Informative References
584 [RFC5504] Fujiwara, K. and Y. Yoneya,
585 "Downgrading Mechanism for Email
586 Address Internationalization",
587 RFC 5504, March 2009.
589 Appendix A. Examples
591 A.1. Downgrading Example
593 This appendix shows an message downgrading example. Consider a
594 received mail message where:
596 o The sender address is a non-ASCII address,
597 "NON-ASCII-local@example.com". Its display-name is "DISPLAY-
598 local".
600 o The "To:" header field contains two non-ASCII addresses,
601 "NON-ASCII-remote1@example.net" and
602 "NON-ASCII-remote2@example.com" Its display-names are "DISPLAY-
603 remote1" and "DISPLAY-remote2".
605 o The "Cc:" header field contains a non-ASCII address,
606 "NON-ASCII-remote3@example.org". Its display-name is "DISPLAY-
607 remote3".
609 o Four display names contain non-ASCII characters.
611 o The Subject header field is "NON-ASCII-SUBJECT", which contains
612 non-ASCII characters.
614 o There is an unknown header field "X-Unknown-Header" which contains
615 non-ASCII characters.
617 Return-Path:
618 Received: from ... by ... for
619 Received: from ... by ... for
620 From: DISPLAY-local
621 To: DISPLAY-remote1 ,
622 DISPLAY-remote2
623 Cc: DISPLAY-remote3
624 Subject: NON-ASCII-SUBJECT
625 Date: DATE
626 Message-Id: MESSAGE_ID
627 Mime-Version: 1.0
628 Content-Type: text/plain; charset="UTF-8"
629 Content-Transfer-Encoding: 8bit
630 X-Unknown-Header: NON-ASCII-CHARACTERS
632 MAIL_BODY
634 Figure 1: Received message in a mail drop
636 The downgraded message is shown in Figure 2. "Return-Path:",
637 "From:", "To:" and "Cc:" header fields are rewritten. "X-Unknown-
638 Header:" is encapsulated as "Downgraded-X-Unknown-Header:".
640 Return-Path: Internationalized address
641 =?UTF-8?Q?NON-ASCII-local@example.com?= removed:;
642 Received: from ... by ...
643 Received: from ... by ...
644 From: =?UTF-8?Q?DISPLAY-local?= Internationalized address
645 =?UTF-8?Q?NON-ASCII-local@example.com?= removed:;
646 To: =?UTF-8?Q?DISPLAY-remote1?= Internationalized address
647 =?UTF-8?Q?NON-ASCII-remote1@example.net?= removed:;,
648 =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
649 =?UTF-8?Q?NON-ASCII-remote2@example.com?= removed:;,
650 Cc: =?UTF-8?Q?DISPLAY-remote3?= Internationalized address
651 =?UTF-8?Q?NON-ASCII-remote3@example.org?= removed:;
652 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
653 Date: DATE
654 Message-Id: MESSAGE_ID
655 Mime-Version: 1.0
656 Content-Type: text/plain; charset="UTF-8"
657 Content-Transfer-Encoding: 8bit
658 Downgraded-X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?=
660 MAIL_BODY
662 Figure 2: Downgraded message
664 Author's Address
666 Kazunori Fujiwara
667 Japan Registry Services Co., Ltd.
668 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
669 Chiyoda-ku, Tokyo 101-0065
670 Japan
672 Phone: +81 3 5215 8451
673 EMail: fujiwara@jprs.co.jp