idnits 2.17.1
draft-ietf-eai-popimap-downgrade-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The draft header indicates that this document updates RFC5322, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC5322, updated by this document, for
RFC5378 checks: 2006-06-20)
-- 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 (Oct 31, 2011) is 4560 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)
== Outdated reference: A later version (-06) exists of
draft-ietf-eai-rfc5337bis-dsn-05
-- Obsolete informational reference (is this intentional?): RFC 5504
(Obsoleted by RFC 6530)
Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 Oct 31, 2011
5 Updates: 5322 (if approved)
6 Intended status: Standards Track
7 Expires: May 3, 2012
9 Post-delivery Message Downgrading for Internationalized Email Messages
10 draft-ietf-eai-popimap-downgrade-03.txt
12 Abstract
14 The Email Address Internationalization (UTF8SMTP) extension allows
15 UTF-8 characters in mail header fields. POP and IMAP servers support
16 internationalized email messages. If a POP/IMAP client does not
17 support Email Address Internationalization, POP/IMAP servers cannot
18 send Internationalized Email Headers to the client and cannot remove
19 the message. To avoid the situation, this document describes a
20 conversion mechanism for internationalized Email messages to be
21 traditional message format.
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on May 3, 2012.
40 Copyright Notice
42 Copyright (c) 2011 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
59 3. Updating RFC 5322 . . . . . . . . . . . . . . . . . . . . . . 5
60 4. New Header Fields Definition . . . . . . . . . . . . . . . . . 6
61 4.1. Preservation Header Fields . . . . . . . . . . . . . . . . 6
62 5. Email Header Fields Downgrading . . . . . . . . . . . . . . . 7
63 5.1. Downgrading Method for Each ABNF Element . . . . . . . . . 7
64 5.1.1. RECEIVED Downgrading . . . . . . . . . . . . . . . . . 7
65 5.1.2. UNSTRUCTURED Downgrading . . . . . . . . . . . . . . . 7
66 5.1.3. WORD Downgrading . . . . . . . . . . . . . . . . . . . 7
67 5.1.4. COMMENT Downgrading . . . . . . . . . . . . . . . . . 7
68 5.1.5. MIME-VALUE Downgrading . . . . . . . . . . . . . . . . 7
69 5.1.6. DISPLAY-NAME Downgrading . . . . . . . . . . . . . . . 8
70 5.1.7. GROUP Downgrading . . . . . . . . . . . . . . . . . . 8
71 5.1.8. MAILBOX Downgrading . . . . . . . . . . . . . . . . . 8
72 5.1.9. ENCAPSULATION Downgrading . . . . . . . . . . . . . . 9
73 5.1.10. TYPED-ADDRESS Downgrading . . . . . . . . . . . . . . 9
74 5.2. Downgrading Method for Each Header Field . . . . . . . . . 9
75 5.2.1. Address Header Fields That Contain
s . . . . 9
76 5.2.2. Address Header Fields with Typed Addresses . . . . . . 10
77 5.2.3. Downgrading Non-ASCII in Comments . . . . . . . . . . 10
78 5.2.4. Message-ID Header Fields . . . . . . . . . . . . . . . 10
79 5.2.5. Received Header Field . . . . . . . . . . . . . . . . 11
80 5.2.6. MIME Content Header Fields . . . . . . . . . . . . . . 11
81 5.2.7. Non-ASCII in . . . . . . . . . . . . . 11
82 5.2.8. Non-ASCII in . . . . . . . . . . . . . . . . 11
83 5.2.9. Other Header Fields . . . . . . . . . . . . . . . . . 11
84 6. MIME Body-Part Header Field Downgrading . . . . . . . . . . . 12
85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
86 8. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 13
87 8.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 13
88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
89 9.1. Statement about Downgraded- registration . . . . . . . . . 14
90 9.2. Existing Downgraded- registrations . . . . . . . . . . . . 14
91 9.3. Additional header fields . . . . . . . . . . . . . . . . . 14
92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
93 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15
94 11.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 15
95 11.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 15
96 11.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 16
97 11.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 16
98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
99 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
100 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
101 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17
102 A.1. Downgrading Example . . . . . . . . . . . . . . . . . . . 17
104 1. Introduction
106 Traditional mail systems, which are defined by [RFC5322], allow ASCII
107 characters in mail header field values. The UTF8SMTP extension
108 ([I-D.ietf-eai-frmwrk-4952bis] and [I-D.ietf-eai-rfc5335bis] allows
109 UTF-8 characters in mail header field values.
111 If a header field contains non-ASCII characters, POP/IMAP servers
112 cannot send Internationalized Email Headers to the client and cannot
113 remove the message. This message downgrading mechanism converts mail
114 header fields to an all-ASCII representation. The POP/IMAP servers
115 can use the downgrading mechanism and send the Internationalized
116 Email message as a traditional form.
118 [I-D.ietf-eai-rfc5335bis] allows UTF-8 characters to be used in mail
119 header fields and MIME header fields. The message downgrading
120 mechanism specified here describes the conversion method from the
121 internationalized email messages that are defined in
122 [I-D.ietf-eai-frmwrk-4952bis], and [I-D.ietf-eai-rfc5335bis] to the
123 traditional email messages defined in [RFC5322].
125 There is no good way to convert "From:" and "Sender:" header fields,
126 the draft need to update [RFC5322] to allow empty "From:" and
127 "Sender:" header fields and it is described in Section 3.
129 Message Downgrading may be implemented in POP server and IMAP server
130 only.
132 This document tries to define the message downgrading process
133 clearly.
135 Downgrading consists of the following four parts:
137 o Updating RFC 5322
139 o New header field definitions
141 o Email header field downgrading
143 o MIME header field downgrading
145 In Section 4 of this document, header fields starting with
146 "Downgraded-" are introduced. They preserve the original header
147 fields.
149 Email header field downgrading is described in Section 5. It
150 generates ASCII-only header fields.
152 MIME header fields are expanded in [I-D.ietf-eai-rfc5335bis]. MIME
153 header field downgrading is described in Section 6. It generates
154 ASCII-only MIME header fields.
156 Displaying downgraded messages that originally contained
157 internationalized header fields is out of scope of this document. A
158 POP/IMAP client which does not support UTF8 extension does not know
159 internationalized message format described in
160 [I-D.ietf-eai-rfc5335bis].
162 2. Terminology
164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
166 document are to be interpreted as described in RFC 2119 [RFC2119].
168 All specialized terms used in this specification are defined in the
169 Email Address Internationalization (EAI) overview
170 [I-D.ietf-eai-frmwrk-4952bis], in the mail message specifications
171 [RFC5322], or in the MIME documents [RFC2045] [RFC2047] [RFC2183]
172 [RFC2231]. The terms "ASCII address", "internationalized email
173 address", "non-ASCII address", "i18mail address", "UTF8SMTP",
174 "message", and "mailing list" are used with the definitions from
175 [I-D.ietf-eai-frmwrk-4952bis].
177 This document depends on [I-D.ietf-eai-rfc5335bis]. Key words used
178 in those documents are used in this document, too.
180 The term "non-ASCII" refers to a UTF-8 string that contains at least
181 one non-ASCII character.
183 A "UTF8SMTP message" is an email message expanded by
184 [I-D.ietf-eai-rfc5335bis].
186 3. Updating RFC 5322
188 "From:" header field or "Sender:" header field may contain non-ASCII
189 addresses in internationalized Email messages. These non-ASCII
190 addresses are not allowed in [RFC5322]. The draft proposes that the
191 pop/imap downgrading uses syntax and encodes non-ASCII
192 addresses into with empty described in
193 Section 5.
195 This specification redefines "From:", "Sender:", "Resent-From:" and
196 "Resent-Sender:" header fields defined in Section 3.6.2 and 3.6.6 of
197 [RFC5322] to allow in the header fields.
199 from = "From:" address-list CRLF
200 resent-from = "Resent-From:" address-list CRLF
201 sender = "Sender:" address CRLF
202 resent-sender = "Resent-Sender:" address CRLF
204 4. New Header Fields Definition
206 New header fields starting with "Downgraded-" are defined here to
207 preserve those mail header field values that contain UTF-8
208 characters. During downgrading, one new "Downgraded-" header field
209 is added for each mail header field that cannot be passed as-is to a
210 POP/IMAP client that does not support UTF8 extension. The original
211 mail header field is removed. Only those mail header fields that
212 contain non-ASCII characters are affected. The result of this
213 process is a message that is compliant with existing email
214 specifications [RFC5322]. The original internationalized information
215 can be retrieved by examining the "Downgraded-" header fields that
216 were added.
218 4.1. Preservation Header Fields
220 New preservation header fields are defined to preserve information
221 that appeared in non-ASCII text in header fields of the incoming
222 message. The values of the new fields holds the original header
223 field value in encoded form. The revised header field syntax is
224 specified as follows:
226 fields =/ known-downgraded-headers ":"
227 unstructured CRLF
229 known-downgraded-headers = "Downgraded-" original-headers
231 original-headers = "Message-Id" / "Resent-Message-Id" /
232 "In-Reply-To:" / "References:" /
233 "Original-Recipient" / "Final-Recipient"
235 To preserve a header field in a "Downgraded-" header field:
237 1. Generate a new "Downgraded-" header field whose value is the
238 original header field value.
240 2. Treat the generated header field content as if it were
241 unstructured, and then apply [RFC2047] encoding with charset
242 UTF-8 as necessary so that the result is ASCII.
244 3. Remove the original header field.
246 5. Email Header Fields Downgrading
248 This section defines the conversion method to ASCII for each header
249 field that may contain non-ASCII characters.
251 [I-D.ietf-eai-rfc5335bis] expands "Received:" header fields;
252 [RFC5322] describes ABNF elements , , ,
253 ; [RFC2045] describes ABNF element .
255 5.1. Downgrading Method for Each ABNF Element
257 Header field downgrading is defined below for each ABNF element.
258 Converting the header field terminates when no non-ASCII characters
259 remain in the header field.
261 5.1.1. RECEIVED Downgrading
263 If the header field name is "Received:" and the FOR clause contains a
264 non-ASCII address, remove the FOR clause from the header field.
265 Other parts (not counting s) should not contain non-ASCII
266 values.
268 5.1.2. UNSTRUCTURED Downgrading
270 If the header field has an field that contains non-
271 ASCII characters, apply [RFC2047] encoding with charset UTF-8.
273 5.1.3. WORD Downgrading
275 If the header field has any fields that contain non-ASCII
276 characters, apply [RFC2047] encoding with charset UTF-8.
278 5.1.4. COMMENT Downgrading
280 If the header field has any fields that contain non-ASCII
281 characters, apply [RFC2047] encoding with charset UTF-8.
283 5.1.5. MIME-VALUE Downgrading
285 If the header field has any elements defined by [RFC2045] and
286 the elements contain non-ASCII characters, encode the
287 elements according to [RFC2231] with charset UTF-8 and leave the
288 language information empty. If the element is and it contains outside the DQUOTE, remove the
290 before this conversion.
292 5.1.6. DISPLAY-NAME Downgrading
294 If the header field has any ( or ) elements
295 and they have elements that contain non-ASCII
296 characters, encode the elements according to [RFC2047]
297 with charset UTF-8. DISPLAY-NAME downgrading is the same algorithm
298 as WORD downgrading.
300 5.1.7. GROUP Downgrading
302 is defined in Section 3.4 of [RFC5322]. The elements
303 may contain s which contain non-ASCII addresses.
305 If the header field has any elements that contain
306 elements, and those elements in turn contain non-ASCII
307 addresses, rewrite each element as
309 "Internationalized address removed" display-name ENCODED_WORD ":;"
311 where the is the original encoded
312 according to [RFC2047].
314 5.1.8. MAILBOX Downgrading
316 The elements have no equivalent format for non-ASCII
317 addresses. If the header field has any elements that
318 contain non-ASCII characters in their element, rewrite
319 each element to ASCII-only format. The
320 element that contains non-ASCII characters may appear in two forms
321 as:
323 "<" addr-spec ">"
324 addr-spec
326 Rewrite both as:
328 "Internationalized address " ENCODED-WORD " removed:;"
330 where the is the original encoded
331 according to [RFC2047].
333 5.1.9. ENCAPSULATION Downgrading
335 Encapsulate the header field in a "Downgraded-" header field as
336 described in Section 4 as a last resort.
338 Applying this procedure to "Received:" header field is prohibited.
339 ENCAPSULATION Downgrading is allowed for "Message-ID",
340 "In-Reply-To:", "References:", "Original-Recipient" and "Final-
341 Recipient" header fields.
343 5.1.10. TYPED-ADDRESS Downgrading
345 If the header field contains and the contains raw non-ASCII characters, it is in utf-8-address form.
347 Convert it to utf-8-addr-xtext form. Those forms are described in
348 [I-D.ietf-eai-rfc5337bis-dsn]. COMMENT downgrading is also performed
349 in this case. If the address type is unrecognized and the header
350 field contains non-ASCII characters, then fall back to using
351 ENCAPSULATION downgrading on the entire header field.
353 5.2. Downgrading Method for Each Header Field
355 Header fields are listed in [RFC4021]. This section describes the
356 downgrading method for each header field.
358 If the whole mail header field does not contain non-ASCII characters,
359 email header field downgrading is not required. Each header field's
360 downgrading method is described below.
362 5.2.1. Address Header Fields That Contain s
364 From:
365 Sender:
366 To:
367 Cc:
368 Bcc:
369 Reply-To:
370 Resent-From:
371 Resent-Sender:
372 Resent-To:
373 Resent-Cc:
374 Resent-Bcc:
375 Resent-Reply-To:
377 Return-Path:
378 Disposition-Notification-To:
380 If the header field contains elements that contain non-ASCII
381 addresses, perform COMMENT downgrading, DISPLAY-NAME downgrading, and
382 GROUP downgrading.
384 If the header field contains elements that contain non-
385 ASCII addresses, perform COMMENT downgrading, DISPLAY-NAME
386 downgrading, and MAILBOX downgrading.
388 5.2.2. Address Header Fields with Typed Addresses
390 Original-Recipient:
391 Final-Recipient:
393 If the header field contains non-ASCII characters, perform TYPED-
394 ADDRESS downgrading.
396 5.2.3. Downgrading Non-ASCII in Comments
398 Date:
399 Resent-Date:
400 MIME-Version:
401 Content-ID:
402 Content-Transfer-Encoding:
403 Content-Language:
404 Accept-Language:
405 Auto-Submitted:
407 These header fields do not contain non-ASCII characters except in
408 comments. If the header field contains UTF-8 characters in comments,
409 perform COMMENT downgrading.
411 5.2.4. Message-ID Header Fields
413 Message-ID:
414 Resent-Message-ID:
415 In-Reply-To:
416 References:
418 Perform ENCAPSULATION Downgrading.
420 5.2.5. Received Header Field
422 Received:
424 Perform COMMENT downgrading and RECEIVED downgrading.
426 5.2.6. MIME Content Header Fields
428 Content-Type:
429 Content-Disposition:
431 Perform MIME-VALUE downgrading and COMMENT downgrading.
433 5.2.7. Non-ASCII in
435 Subject:
436 Comments:
437 Content-Description:
439 Perform UNSTRUCTURED downgrading.
441 5.2.8. Non-ASCII in
443 Keywords:
445 Perform WORD downgrading.
447 5.2.9. Other Header Fields
449 There are other header fields that contain non-ASCII characters.
450 They are user-defined and missing from this document, or future
451 defined header fields. They are treated as "Optional Fields" and
452 their field value are treated as unstructured described in Section
453 3.6.8 of [RFC5322].
455 Perform UNSTRUCTURED downgrading.
457 If the software understands the header field's structure and a
458 downgrading algorithm other than UNSTRUCTURED is applicable, that
459 software SHOULD use that algorithm; UNSTRUCTURED downgrading is used
460 as a last resort.
462 Mailing list header fields (those that start in "List-") are part of
463 this category.
465 6. MIME Body-Part Header Field Downgrading
467 MIME body-part header fields may contain non-ASCII characters
468 [I-D.ietf-eai-rfc5335bis]. This section defines the conversion
469 method to ASCII-only header fields for each MIME header field that
470 contains non-ASCII characters. Parse the message body's MIME
471 structure at all levels and check each MIME header field to see
472 whether it contains non-ASCII characters. If the header field
473 contains non-ASCII characters in the header field value, the header
474 field is a target of the MIME body-part header field's downgrading.
475 Each MIME header field's downgrading method is described below.
476 COMMENT downgrading, MIME-VALUE downgrading, and UNSTRUCTURED
477 downgrading are described in Section 5.
479 Content-ID:
480 The "Content-ID:" header field does not contain non-ASCII
481 characters except in comments. If the header field contains UTF-8
482 characters in comments, perform COMMENT downgrading.
484 Content-Type:
486 Content-Disposition:
487 Perform MIME-VALUE downgrading and COMMENT downgrading.
489 Content-Description: Perform UNSTRUCTURED downgrading.
491 7. Security Considerations
493 Existing clients do not know new From: and Sender: header fields
494 syntax updated by Section 3 and may get wrong when they confront
495 syntax in From: and Sender: fields.
497 A downgraded message's header fields contain ASCII characters only.
498 But they still contain MIME-encapsulated header fields that contain
499 non-ASCII UTF-8 characters. Furthermore, the body part may contain
500 UTF-8 characters. Implementations parsing Internet messages need to
501 accept UTF-8 body parts and UTF-8 header fields that are MIME-
502 encoded. Thus, this document inherits the security considerations of
503 MIME-encoded header fields ([RFC2047] and [RFC3629]).
505 Rewriting header fields increases the opportunities for undetected
506 spoofing by malicious senders. However, rewritten header fields are
507 preserved into Downgraded-* header fields, and parsing Downgraded-*
508 header fields enables the detection of spoofing caused by
509 downgrading.
511 The techniques described here invalidate methods that depend on
512 digital signatures over any part of the message, which includes the
513 top-level header fields and body-part header fields. Depending on
514 the specific message being downgraded, the following techniques are
515 likely to break: DomainKeys Identified Mail (DKIM), and possibly
516 S/MIME and Pretty Good Privacy (PGP). The two obvious mitigations
517 are to stick to 7-bit transport when using these techniques (as most/
518 all of them presently require) or to make sure to have UTF8SMTP end-
519 to-end when needed.
521 While information in any email header field should usually be treated
522 with some suspicion, current email systems commonly employ various
523 mechanisms and protocols to make the information more trustworthy.
524 Currently, information in the new Downgraded-* header fields is
525 usually not inspected by these mechanisms, and may be even less
526 trustworthy than the traditional header fields. Note that the
527 Downgraded-* header fields could have been inserted with malicious
528 intent (and with content unrelated to the traditional header fields).
530 See the "Security Considerations" section in
531 [I-D.ietf-eai-frmwrk-4952bis] for more discussion.
533 8. Implementation Notes
535 8.1. RFC 2047 Encoding
537 While [RFC2047] has a specific algorithm to deal with whitespace in
538 adjacent encoded words, there are a number of deployed
539 implementations that fail to implement the algorithm correctly. As a
540 result, whitespace behavior is somewhat unpredictable in practice
541 when multiple encoded words are used. While RFC 5322 states that
542 implementations SHOULD limit lines to not more than 78 characters,
543 implementations MAY choose to allow overly long encoded words in
544 order to work around faulty [RFC2047] implementations.
545 Implementations that choose to do so SHOULD have an optional
546 mechanism to limit line length to 78 characters.
548 9. IANA Considerations
550 [[RFC Editor: Please change "should now be" and "should be" to "have
551 been" when the IANA actions are complete.]]
553 [[ Notes in draft: this section is not finished, to be reviewed with
554 IANA. ]]
556 Following instructions in the now-obsolete [RFC5504], IANA has made a
557 series of entries in the the Permanent Message Header Field registry.
558 Those registrations should now be changed as follows:
560 9.1. Statement about Downgraded- registration
562 The statement about refusing any "Downgraded-" registrations should
563 be updated to refer to this document and to provide for registering
564 such fields as specified in Section 9.3.
566 [[ Note in draft: The restriction may become useless if unknown
567 header fields may be treated as unstructured. ]]
569 9.2. Existing Downgraded- registrations
571 Individual existing registrations for
573 Downgraded-Bcc
574 Downgraded-Cc
575 Downgraded-Disposition-Notification-To
576 Downgraded-From
577 Downgraded-Mail-From
578 Downgraded-Rcpt-To
579 Downgraded-Reply-To
580 Downgraded-Resent-Bcc
581 Downgraded-Resent-Cc
582 Downgraded-Resent-From
583 Downgraded-Resent-Reply-To
584 Downgraded-Resent-Sender
585 Downgraded-Resent-To
586 Downgraded-Return-Path
587 Downgraded-Sender
588 Downgraded-To
590 should be updated to replace "experimental" with "obsoleted" and to
591 reference this document.
593 9.3. Additional header fields
595 The following header fields should be registered in the Permanent
596 Message Header Field registry, in accordance with the procedures set
597 out in [RFC3864].
599 Header field name: Downgraded-Message-Id
600 Applicable protocol: mail
601 Status: standard
602 Author/change controller: IETF
603 Specification document(s): This document (Section 4)
604 Header field name: Downgraded-In-Reply-To
605 Applicable protocol: mail
606 Status: standard
607 Author/change controller: IETF
608 Specification document(s): This document (Section 4)
610 Header field name: Downgraded-References
611 Applicable protocol: mail
612 Status: standard
613 Author/change controller: IETF
614 Specification document(s): This document (Section 4)
616 Header field name: Downgraded-Original-Recipient
617 Applicable protocol: mail
618 Status: standard
619 Author/change controller: IETF
620 Specification document(s): This document (Section 4)
622 Header field name: Downgraded-Final-Recipient
623 Applicable protocol: mail
624 Status: standard
625 Author/change controller: IETF
626 Specification document(s): This document (Section 4)
628 10. Acknowledgements
630 This document draws heavily from the experimental in-transit message
631 downgrading procedure described in RFC 5504 [RFC5504]. The
632 contribution of the co-author of that earlier document, Y. Yoneya,
633 are gratefully acknowledged.
635 11. Change History
637 This section is used for tracking the update of this document. Will
638 be removed after finalize.
640 11.1. Version 00
642 o Initial version
644 o Imported header field downgrading from RFC 5504
646 11.2. Version 01
648 o same as Version 00
650 11.3. Version 02
652 o Added updating RFC 5322 to allow syntax in From: and
653 Sender
655 o Added GROUP Downgrading
657 11.4. Version 03
659 o Replaced with
661 o Added updating RFC 5322 to allow syntax in From: and
662 Sender
664 o Added one sentence in Security considerations
666 o Updated IANA considerations
668 12. References
670 12.1. Normative References
672 [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and
673 Framework for Internationalized
674 Email",
675 draft-ietf-eai-frmwrk-4952bis-12 (work
676 in progress), October 2011.
678 [I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., and N. Freed,
679 "Internationalized Email Headers",
680 draft-ietf-eai-rfc5335bis-13 (work in
681 progress), October 2011.
683 [I-D.ietf-eai-rfc5337bis-dsn] Hansen, T., Newman, C., and A.
684 Melnikov, "Internationalized Delivery
685 Status and Disposition Notifications",
686 draft-ietf-eai-rfc5337bis-dsn-05 (work
687 in progress), October 2011.
689 [RFC2045] Freed, N. and N. Borenstein,
690 "Multipurpose Internet Mail Extensions
691 (MIME) Part One: Format of Internet
692 Message Bodies", RFC 2045,
693 November 1996.
695 [RFC2047] Moore, K., "MIME (Multipurpose
696 Internet Mail Extensions) Part Three:
697 Message Header Extensions for Non-
698 ASCII Text", RFC 2047, November 1996.
700 [RFC2183] Troost, R., Dorner, S., and K. Moore,
701 "Communicating Presentation
702 Information in Internet Messages: The
703 Content-Disposition Header Field",
704 RFC 2183, August 1997.
706 [RFC2231] Freed, N. and K. Moore, "MIME
707 Parameter Value and Encoded Word
708 Extensions: Character Sets, Languages,
709 and Continuations", RFC 2231,
710 November 1997.
712 [RFC5322] Resnick, P., Ed., "Internet Message
713 Format", RFC 5322, October 2008.
715 [RFC3629] Yergeau, F., "UTF-8, a transformation
716 format of ISO 10646", STD 63,
717 RFC 3629, November 2003.
719 [RFC4021] Klyne, G. and J. Palme, "Registration
720 of Mail and MIME Header Fields",
721 RFC 4021, March 2005.
723 [RFC2119] Bradner, S., "Key words for use in
724 RFCs to Indicate Requirement Levels",
725 BCP 14, RFC 2119, March 1997.
727 [RFC3864] Klyne, G., Nottingham, M., and J.
728 Mogul, "Registration Procedures for
729 Message Header Fields", BCP 90,
730 RFC 3864, September 2004.
732 12.2. Informative References
734 [RFC5504] Fujiwara, K. and Y. Yoneya,
735 "Downgrading Mechanism for Email
736 Address Internationalization",
737 RFC 5504, March 2009.
739 Appendix A. Examples
741 A.1. Downgrading Example
743 This appendix shows an message downgrading example. Consider a
744 received mail message where:
746 o The sender address is a non-ASCII address,
747 "NON-ASCII-local@example.com". Its display-name is "DISPLAY-
748 local".
750 o The "To:" header field contains two non-ASCII addresses,
751 "NON-ASCII-remote1@example.net" and
752 "NON-ASCII-remote2@example.com" Its display-names are "DISPLAY-
753 remote1" and "DISPLAY-remote2".
755 o The "Cc:" header field contains a non-ASCII address,
756 "NON-ASCII-remote3@example.org". Its display-name is "DISPLAY-
757 remote3".
759 o Four display names contain non-ASCII characters.
761 o The Subject header field is "NON-ASCII-SUBJECT", which contains
762 non-ASCII characters.
764 o The "Message-Id:" header field contains "NON-ASCII-MESSAGE_ID",
765 which contains non-ASCII characters.
767 o There is an unknown header field "X-Unknown-Header" which contains
768 non-ASCII characters.
770 Return-Path:
771 Received: from ... by ... for
772 Received: from ... by ... for
773 From: DISPLAY-local
774 To: DISPLAY-remote1 ,
775 DISPLAY-remote2
776 Cc: DISPLAY-remote3
777 Subject: NON-ASCII-SUBJECT
778 Date: DATE
779 Message-Id: NON-ASCII-MESSAGE_ID
780 Mime-Version: 1.0
781 Content-Type: text/plain; charset="UTF-8"
782 Content-Transfer-Encoding: 8bit
783 X-Unknown-Header: NON-ASCII-CHARACTERS
785 MAIL_BODY
787 Figure 1: Received message in a mail drop
789 The downgraded message is shown in Figure 2. "Return-Path:",
790 "From:", "To:" and "Cc:" header fields are rewritten. "Subject:" and
791 "X-Unknown-Header:" header fields are encoded using [RFC2047].
792 "Message-Id:" header field is encapsulated as
793 "Downgraded-Message-Id:" header field.
795 Return-Path: Internationalized address
796 =?UTF-8?Q?NON-ASCII-local@example.com?= removed:;
797 Received: from ... by ...
798 Received: from ... by ...
799 From: =?UTF-8?Q?DISPLAY-local?= Internationalized address
800 =?UTF-8?Q?NON-ASCII-local@example.com?= removed:;
801 To: =?UTF-8?Q?DISPLAY-remote1?= Internationalized address
802 =?UTF-8?Q?NON-ASCII-remote1@example.net?= removed:;,
803 =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
804 =?UTF-8?Q?NON-ASCII-remote2@example.com?= removed:;,
805 Cc: =?UTF-8?Q?DISPLAY-remote3?= Internationalized address
806 =?UTF-8?Q?NON-ASCII-remote3@example.org?= removed:;
807 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
808 Date: DATE
809 Downgraded-Message-Id: =?UTF-8?Q?MESSAGE_ID?=
810 Mime-Version: 1.0
811 Content-Type: text/plain; charset="UTF-8"
812 Content-Transfer-Encoding: 8bit
813 X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?=
815 MAIL_BODY
817 Figure 2: Downgraded message
819 Author's Address
821 Kazunori Fujiwara
822 Japan Registry Services Co., Ltd.
823 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
824 Chiyoda-ku, Tokyo 101-0065
825 Japan
827 Phone: +81 3 5215 8451
828 EMail: fujiwara@wide.ad.jp, fujiwara@jprs.co.jp