idnits 2.17.1
draft-ietf-eai-popimap-downgrade-04.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 (Feb 27, 2012) is 4443 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)
-- Obsolete informational reference (is this intentional?): RFC 5451
(Obsoleted by RFC 7001)
-- Obsolete informational reference (is this intentional?): RFC 5504
(Obsoleted by RFC 6530)
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 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 Feb 27, 2012
5 Updates: 5322 (if approved)
6 Intended status: Standards Track
7 Expires: August 30, 2012
9 Post-delivery Message Downgrading for Internationalized Email Messages
10 draft-ietf-eai-popimap-downgrade-04.txt
12 Abstract
14 The Email Address Internationalization (SMTPUTF8) extension allows
15 UTF-8 characters in mail header fields. Upgraded POP and IMAP
16 servers support internationalized email messages. If a POP/IMAP
17 client does not support Email Address Internationalization, POP/IMAP
18 servers cannot send Internationalized Email Headers to the client and
19 cannot remove the message. To avoid the situation, this document
20 describes a conversion mechanism for internationalized Email messages
21 to be traditional message format. The purpose of post-delivery
22 message downgrading is to enable POP/IMAP servers to deliver
23 internationalized messages to traditional POP/IMAP clients. In the
24 process, message elements requiring internationalized treatment can
25 be removed or recoded and receivers can know they received messages
26 containing such elements even if they cannot receive the elements
27 themselves.
29 Status of This Memo
31 This Internet-Draft is submitted in full conformance with the
32 provisions of BCP 78 and BCP 79.
34 Internet-Drafts are working documents of the Internet Engineering
35 Task Force (IETF). Note that other groups may also distribute
36 working documents as Internet-Drafts. The list of current Internet-
37 Drafts is at http://datatracker.ietf.org/drafts/current/.
39 Internet-Drafts are draft documents valid for a maximum of six months
40 and may be updated, replaced, or obsoleted by other documents at any
41 time. It is inappropriate to use Internet-Drafts as reference
42 material or to cite them other than as "work in progress."
44 This Internet-Draft will expire on August 30, 2012.
46 Copyright Notice
48 Copyright (c) 2012 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (http://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with respect
56 to this document. Code Components extracted from this document must
57 include Simplified BSD License text as described in Section 4.e of
58 the Trust Legal Provisions and are provided without warranty as
59 described in the Simplified BSD License.
61 Table of Contents
63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
64 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4
65 1.2. Possible solutions . . . . . . . . . . . . . . . . . . . . 4
66 1.3. Approach taken in this specification . . . . . . . . . . . 4
67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
68 3. Updating RFC 5322 . . . . . . . . . . . . . . . . . . . . . . 6
69 4. New Header Fields Definition . . . . . . . . . . . . . . . . . 7
70 5. Email Header Fields Downgrading . . . . . . . . . . . . . . . 8
71 5.1. Downgrading Method for Each ABNF Element . . . . . . . . . 8
72 5.1.1. RECEIVED Downgrading . . . . . . . . . . . . . . . . . 8
73 5.1.2. UNSTRUCTURED Downgrading . . . . . . . . . . . . . . . 8
74 5.1.3. WORD Downgrading . . . . . . . . . . . . . . . . . . . 8
75 5.1.4. COMMENT Downgrading . . . . . . . . . . . . . . . . . 8
76 5.1.5. MIME-VALUE Downgrading . . . . . . . . . . . . . . . . 9
77 5.1.6. DISPLAY-NAME Downgrading . . . . . . . . . . . . . . . 9
78 5.1.7. GROUP Downgrading . . . . . . . . . . . . . . . . . . 9
79 5.1.8. MAILBOX Downgrading . . . . . . . . . . . . . . . . . 9
80 5.1.9. ENCAPSULATION Downgrading . . . . . . . . . . . . . . 10
81 5.1.10. TYPED-ADDRESS Downgrading . . . . . . . . . . . . . . 10
82 5.2. Downgrading Method for Each Header Field . . . . . . . . . 10
83 5.2.1. Address Header Fields That Contain
s . . . . 10
84 5.2.2. Address Header Fields with Typed Addresses . . . . . . 11
85 5.2.3. Downgrading Non-ASCII in Comments . . . . . . . . . . 11
86 5.2.4. Message-ID Header Fields . . . . . . . . . . . . . . . 11
87 5.2.5. Received Header Field . . . . . . . . . . . . . . . . 12
88 5.2.6. MIME Content Header Fields . . . . . . . . . . . . . . 12
89 5.2.7. Non-ASCII in . . . . . . . . . . . . . 12
90 5.2.8. Non-ASCII in . . . . . . . . . . . . . . . . 12
91 5.2.9. Other Header Fields . . . . . . . . . . . . . . . . . 12
92 6. MIME Body-Part Header Field Downgrading . . . . . . . . . . . 13
93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
94 8. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 14
95 8.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 14
96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
98 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16
99 11.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 16
100 11.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 16
101 11.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 16
102 11.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 16
103 11.5. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 17
104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
105 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
106 12.2. Informative References . . . . . . . . . . . . . . . . . . 18
107 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18
108 A.1. Downgrading Example . . . . . . . . . . . . . . . . . . . 18
110 1. Introduction
112 1.1. Problem statement
114 Traditional (legacy) mail systems, which are defined by [RFC5322],
115 allow only ASCII characters in mail header field values. The
116 SMTPUTF8 extension ([RFC6530] and [RFC6532] allows UTF-8 characters
117 in those mail header fields.
119 If a header field contains non-ASCII characters, POP/IMAP servers
120 cannot send Internationalized Email Headers to legacy clients and,
121 because they have no obvious or standardized way to explain what is
122 going on to those clients, cannot even safely discard the message.
124 1.2. Possible solutions
126 Discussions leading to this specification concluded that there are
127 four plausible approaches to the problem, with the preferred one
128 depending on the particular circumstances and relationship among the
129 delivery SMTP server, the mail store, the POP or IMAP server, and the
130 users and their MUA clients:
132 1. If the delivery MTA has sufficient knowledge about the POP and/or
133 IMAP servers and clients being used, the message may be rejected
134 as undeliverable.
136 2. The message may be downgraded by the POP or IMAP server, in a way
137 that preserves maximum information at the expense of some
138 complexity.
140 3. Some intermediate downgrading may be applied that balances more
141 information loss against lower complexity and greater ease of
142 implementation.
144 4. The POP or IMAP server may fabricate a message whose intent is to
145 notify the client that an internationalized message is waiting
146 but cannot be delivered until an upgraded client is available.
148 1.3. Approach taken in this specification
150 This specification describes the second of those options. It is
151 worth noticing that, at least in the general case, none of these
152 options preserve sufficient information to guarantee that it is
153 possible to reply to an incoming message without loss of information,
154 so the choice may be considered to be among "least bad" options.
156 This message downgrading mechanism converts mail header fields to an
157 all-ASCII representation. The POP/IMAP servers can use the
158 downgrading mechanism and send the Internationalized Email message as
159 a traditional form. Receivers can know they received some
160 internationalized messages or some unknown/broken messages.
162 [RFC6532] allows UTF-8 characters to be used in mail header fields
163 and MIME header fields. The message downgrading mechanism specified
164 here describes the conversion method from the internationalized email
165 messages that are defined in [RFC6530], and [RFC6532] to the
166 traditional email messages defined in [RFC5322].
168 There is no good way to convert "From:" and "Sender:" header fields,
169 this document updates [RFC5322] by redefining "From:" and "Sender:"
170 header fields in Section 3.
172 This document provides a precise definition of the minimum-
173 information-loss message downgrading process.
175 Downgrading consists of the following three parts:
177 o New header field definitions
179 o Email header field downgrading
181 o MIME header field downgrading
183 In Section 4 of this document, header fields starting with
184 "Downgraded-" are introduced. They preserve the information that
185 appeared in the original header fields.
187 Email header field downgrading is described in Section 5. It
188 generates ASCII-only header fields.
190 MIME header fields are expanded in [RFC6532]. MIME header field
191 downgrading is described in Section 6. It generates ASCII-only MIME
192 header fields.
194 Displaying downgraded messages that originally contained
195 internationalized header fields is out of scope of this document. A
196 POP/IMAP client which does not support UTF8 extension does not know
197 internationalized message format described in [RFC6532].
199 2. Terminology
201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
203 document are to be interpreted as described in RFC 2119 [RFC2119].
205 All specialized terms used in this specification are defined in the
206 Overview and Framework for Internationalized Email [RFC6530], in the
207 mail message specifications [RFC5322], or in the MIME documents
208 [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address",
209 "internationalized email address", "non-ASCII address", "i18mail
210 address", "SMTPUTF8", "message", and "mailing list" are used with the
211 definitions from [RFC6530].
213 This document depends on [RFC6532]. Key words used in those
214 documents are used in this document, too.
216 The term "non-ASCII" refers to a UTF-8 string that contains at least
217 one non-ASCII character.
219 A "SMTPUTF8 message" is an email message expanded by [RFC6532].
221 3. Updating RFC 5322
223 "From:" header field or "Sender:" header field may contain non-ASCII
224 addresses in internationalized Email messages. These non-ASCII
225 addresses are not allowed in [RFC5322]. The draft proposes that the
226 pop/imap downgrading uses syntax and encodes non-ASCII
227 addresses into with empty described in
228 Section 5.
230 This specification redefines "From:", "Sender:", "Resent-From:" and
231 "Resent-Sender:" header fields defined in Section 3.6.2 and 3.6.6 of
232 [RFC5322] to allow in the header fields.
234 from = "From:" address-list CRLF
235 resent-from = "Resent-From:" address-list CRLF
236 sender = "Sender:" address CRLF
237 resent-sender = "Resent-Sender:" address CRLF
239 This adds group syntax to "From" and "Sender" that was previously
240 allowed only in destination fields such as "To" and "cc". It is
241 anticipated that when existing implementations encounter a downgraded
242 field from this set, many will tolerate the appearance of a group,
243 even though [RFC5322] does not permit it. Implementations that do
244 not tolerate it will fail in unpredictable ways, and they might
245 refuse to process such messages.
247 [[ Notes in Draft: If this update is rejected, one possible solution
248 is to rewrite each element in "From" and "Sender" header
249 fields as
250 ENCODED-WORD "<" NO_EXISTING_ADDRESS ">"
252 where the is the original encoded
253 according to [RFC2047] and NO_EXISTING_ADDRESS is an ASCII email
254 address which does not exist, should, as illustrated in the example
255 below, always generate an error and is specified by the administrator
256 of the POP3 or IMAP server.
258 For example, if the local-part of the "From:" address were the
259 Russian (in Cyrillic) equivalent of Ivan, with domain-part
260 "foo.example.net" and the IMAP server being used by the recipient was
261 "imap.example.com", the encoded word from suggested in this note
262 might appear as:
264 From: =?UTF-8?Q?=d0=b8=d0=b2=d0=b0=d0=bd@foo.example.net?=
265
267 That would lead to immediate rejection if a user attempted to reply
268 uncritically to the message.
270 4. New Header Fields Definition
272 New header fields are defined to preserve information that appeared
273 in non-ASCII text in header fields of the incoming message. The
274 values of the new fields holds the original header field value in
275 encoded form. The revised header field syntax is specified as
276 follows:
278 fields =/ downgraded
280 downgraded = "Downgraded-Message-Id:" unstructured CRLF /
281 "Downgraded-Resent-Message-Id:" unstructured CRLF /
282 "Downgraded-In-Reply-To:" unstructured CRLF /
283 "Downgraded-References:" unstructured CRLF /
284 "Downgraded-Original-Recipient:" unstructured CRLF /
285 "Downgraded-Final-Recipient:" unstructured CRLF
287 To preserve a header field in a "Downgraded-" header field:
289 1. Generate a new header field.
291 * The field name is a concatenation of "Downgraded-" and the
292 original field name.
294 * The initial new field value is the original header field
295 value.
297 2. Treat the initial new header field value as if it were
298 unstructured, and then apply [RFC2047] encoding with charset
299 UTF-8 as necessary so that the resulting new header field value
300 is completely in ASCII.
302 3. Remove the original header field.
304 5. Email Header Fields Downgrading
306 This section defines the conversion method to ASCII for each header
307 field that may contain non-ASCII characters.
309 [RFC6532] expands "Received:" header fields; [RFC5322] describes ABNF
310 elements , , , ; [RFC2045]
311 describes ABNF element .
313 5.1. Downgrading Method for Each ABNF Element
315 Header field downgrading is defined below for each ABNF element.
316 Converting the header field terminates when no non-ASCII characters
317 remain in the header field.
319 5.1.1. RECEIVED Downgrading
321 If the header field name is "Received:" and the FOR clause contains a
322 non-ASCII address, remove the FOR clause from the header field.
323 Other parts (not counting s) should not contain non-ASCII
324 values.
326 5.1.2. UNSTRUCTURED Downgrading
328 If the header field has an field that contains non-
329 ASCII characters, apply [RFC2047] encoding with charset UTF-8.
331 5.1.3. WORD Downgrading
333 If the header field has any fields that contain non-ASCII
334 characters, apply [RFC2047] encoding with charset UTF-8.
336 5.1.4. COMMENT Downgrading
338 If the header field has any fields that contain non-ASCII
339 characters, apply [RFC2047] encoding with charset UTF-8.
341 5.1.5. MIME-VALUE Downgrading
343 If the header field has any elements defined by [RFC2045] and
344 the elements contain non-ASCII characters, encode the
345 elements according to [RFC2231] with charset UTF-8 and leave the
346 language information empty. If the element is and it contains outside the DQUOTE, remove the
348 before this conversion.
350 5.1.6. DISPLAY-NAME Downgrading
352 If the header field has any ( or ) elements
353 and they have elements that contain non-ASCII
354 characters, encode the elements according to [RFC2047]
355 with charset UTF-8. DISPLAY-NAME downgrading is the same algorithm
356 as WORD downgrading.
358 5.1.7. GROUP Downgrading
360 is defined in Section 3.4 of [RFC5322]. The elements
361 may contain s which contain non-ASCII addresses.
363 If the header field has any elements that contain
364 elements, and those elements in turn contain non-ASCII
365 addresses, rewrite each element as
367 display-name ENCODED_WORD " :;"
369 where the is the original encoded
370 according to [RFC2047].
372 5.1.8. MAILBOX Downgrading
374 The elements have no equivalent format for non-ASCII
375 addresses. If the header field has any elements that
376 contain non-ASCII characters in their element, rewrite
377 each element to ASCII-only format. The
378 element that contains non-ASCII characters may appear in two forms
379 as:
381 "<" addr-spec ">"
382 addr-spec
384 Rewrite both as:
386 ENCODED-WORD " :;"
388 where the is the original encoded
389 according to [RFC2047].
391 5.1.9. ENCAPSULATION Downgrading
393 Encapsulate the header field in a "Downgraded-" header field as
394 described in Section 4 as a last resort.
396 Applying this procedure to "Received:" header field is prohibited.
397 ENCAPSULATION Downgrading is allowed for "Message-ID",
398 "In-Reply-To:", "References:", "Original-Recipient" and "Final-
399 Recipient" header fields.
401 5.1.10. TYPED-ADDRESS Downgrading
403 If the header field contains and the contains raw non-ASCII characters, it is in utf-8-address form.
405 Convert it to utf-8-addr-xtext form. Those forms are described in
406 [RFC6533]. COMMENT downgrading is also performed in this case. If
407 the address type is unrecognized and the header field contains non-
408 ASCII characters, then fall back to using ENCAPSULATION downgrading
409 on the entire header field.
411 5.2. Downgrading Method for Each Header Field
413 Header fields are listed in [RFC4021]. This section describes the
414 downgrading method for each header field.
416 If the whole mail header field does not contain non-ASCII characters,
417 email header field downgrading is not required. Each header field's
418 downgrading method is described below.
420 5.2.1. Address Header Fields That Contain s
422 From:
423 Sender:
424 To:
425 Cc:
426 Bcc:
427 Reply-To:
429 Resent-From:
430 Resent-Sender:
431 Resent-To:
432 Resent-Cc:
433 Resent-Bcc:
434 Resent-Reply-To:
435 Return-Path:
436 Disposition-Notification-To:
438 If the header field contains elements that contain non-ASCII
439 addresses, perform COMMENT downgrading, DISPLAY-NAME downgrading, and
440 GROUP downgrading.
442 If the header field contains elements that contain non-
443 ASCII addresses, perform COMMENT downgrading, DISPLAY-NAME
444 downgrading, and MAILBOX downgrading.
446 5.2.2. Address Header Fields with Typed Addresses
448 Original-Recipient:
449 Final-Recipient:
451 If the header field contains non-ASCII characters, perform TYPED-
452 ADDRESS downgrading.
454 5.2.3. Downgrading Non-ASCII in Comments
456 Date:
457 Resent-Date:
458 MIME-Version:
459 Content-ID:
460 Content-Transfer-Encoding:
461 Content-Language:
462 Accept-Language:
463 Auto-Submitted:
465 These header fields do not contain non-ASCII characters except in
466 comments. If the header field contains UTF-8 characters in comments,
467 perform COMMENT downgrading.
469 5.2.4. Message-ID Header Fields
470 Message-ID:
471 Resent-Message-ID:
472 In-Reply-To:
473 References:
475 Perform ENCAPSULATION Downgrading.
477 5.2.5. Received Header Field
479 Received:
481 Perform COMMENT downgrading and RECEIVED downgrading.
483 5.2.6. MIME Content Header Fields
485 Content-Type:
486 Content-Disposition:
488 Perform MIME-VALUE downgrading and COMMENT downgrading.
490 5.2.7. Non-ASCII in
492 Subject:
493 Comments:
494 Content-Description:
496 Perform UNSTRUCTURED downgrading.
498 5.2.8. Non-ASCII in
500 Keywords:
502 Perform WORD downgrading.
504 5.2.9. Other Header Fields
506 There are other header fields that contain non-ASCII characters.
507 They are user-defined and missing from this document, or future
508 defined header fields. They are treated as "Optional Fields" and
509 their field value are treated as unstructured described in Section
510 3.6.8 of [RFC5322].
512 Perform UNSTRUCTURED downgrading.
514 If the software understands the header field's structure and a
515 downgrading algorithm other than UNSTRUCTURED is applicable, that
516 software SHOULD use that algorithm; UNSTRUCTURED downgrading is used
517 as a last resort.
519 Mailing list header fields (those that start in "List-") are part of
520 this category.
522 6. MIME Body-Part Header Field Downgrading
524 MIME body-part header fields may contain non-ASCII characters
525 [RFC6532]. This section defines the conversion method to ASCII-only
526 header fields for each MIME header field that contains non-ASCII
527 characters. Parse the message body's MIME structure at all levels
528 and check each MIME header field to see whether it contains non-ASCII
529 characters. If the header field contains non-ASCII characters in the
530 header field value, the header field is a target of the MIME body-
531 part header field's downgrading. Each MIME header field's
532 downgrading method is described below. COMMENT downgrading, MIME-
533 VALUE downgrading, and UNSTRUCTURED downgrading are described in
534 Section 5.
536 Content-ID:
537 The "Content-ID:" header field does not contain non-ASCII
538 characters except in comments. If the header field contains UTF-8
539 characters in comments, perform COMMENT downgrading.
541 Content-Type:
543 Content-Disposition:
544 Perform MIME-VALUE downgrading and COMMENT downgrading.
546 Content-Description: Perform UNSTRUCTURED downgrading.
548 7. Security Considerations
550 The purpose of post-delivery message downgrading is to allow POP/IMAP
551 servers to deliver internationalized messages to traditional POP/IMAP
552 clients and permit them to work with those messages. Users who
553 receive such messages can know that they were internationalized. It
554 does not permit receivers to read the messages in their original form
555 and, in general, will not permit generating replies, at least without
556 significant user intervention.
558 This specification is designed so that MUAs that receive converted
559 messages may be traditional and SMTPUTF8-unaware. The specification
560 assumes that such MUAs have no special provisions for either
561 "Downgraded-" header fields or the new syntax of From and Sender
562 header fields described in Section 3.
564 A downgraded message's header fields contain ASCII characters only.
565 But they still contain MIME-encapsulated header fields that contain
566 non-ASCII UTF-8 characters. Furthermore, the body part may contain
567 UTF-8 characters. Implementations parsing Internet messages need to
568 accept UTF-8 body parts and UTF-8 header fields that are MIME-
569 encoded. Thus, this document inherits the security considerations of
570 MIME-encoded header fields ([RFC2047] and [RFC3629]).
572 Rewriting header fields increases the opportunities for undetected
573 spoofing by malicious senders. However, the rewritten header field
574 values are preserved in equivalent MIME form or in newly defined
575 header fields which traditional MUAs do not care.
577 The techniques described here invalidate methods that depend on
578 digital signatures over any part of the message, which includes the
579 top-level header fields and body-part header fields. Depending on
580 the specific message being downgraded, at least the following
581 techniques are likely to break: DomainKeys Identified Mail (DKIM),
582 and possibly S/MIME and Pretty Good Privacy (PGP). Receivers may
583 know they need to update their MUAs, or they don't care.
585 While information in any email header field should usually be treated
586 with some suspicion, current email systems commonly employ various
587 mechanisms and protocols to make the information more trustworthy.
588 Information in the new Downgraded-* header fields is not inspected by
589 MUAs, and may be even less trustworthy than the traditional header
590 fields. Note that the Downgraded-* header fields could have been
591 inserted with malicious intent (and with content unrelated to the
592 traditional header fields), however traditional MUAs do not parse
593 Downgraded-* header fields.
595 In addition, if an Authentication-Results header field [RFC5451] is
596 present, traditional MUAs may treat that the digital signatures are
597 valid.
599 See the "Security Considerations" section in [RFC6530] for more
600 discussion.
602 8. Implementation Notes
604 8.1. RFC 2047 Encoding
606 While [RFC2047] has a specific algorithm to deal with whitespace in
607 adjacent encoded words, there are a number of deployed
608 implementations that fail to implement the algorithm correctly. As a
609 result, whitespace behavior is somewhat unpredictable in practice
610 when multiple encoded words are used. While RFC 5322 states that
611 implementations SHOULD limit lines to not more than 78 characters,
612 implementations MAY choose to allow overly long encoded words in
613 order to work around faulty [RFC2047] implementations.
614 Implementations that choose to do so SHOULD have an optional
615 mechanism to limit line length to 78 characters.
617 9. IANA Considerations
619 [[RFC Editor: Please change "should now be" and "should be" to "have
620 been" when the IANA actions are complete.]]
622 [[ Notes in draft: this section is not finished, to be reviewed with
623 IANA. ]]
625 [RFC5504] registered many "Downgraded-" header fields and requested
626 that 'IANA will refuse registration of all field names that start
627 with "Downgraded-", to avoid possible conflict with the procedure for
628 unknown header fields' preservation described in Section 3.3 of
629 [RFC5504].' However [RFC6530] obsoleted [RFC5504] and this document
630 does not use all "Downgraded-" header fields registered by [RFC5504].
632 The following header fields should be registered in the Permanent
633 Message Header Field registry, in accordance with the procedures set
634 out in [RFC3864].
636 Header field name: Downgraded-Message-Id
637 Applicable protocol: mail
638 Status: standard
639 Author/change controller: IETF
640 Specification document(s): This document (Section 4)
642 Header field name: Downgraded-In-Reply-To
643 Applicable protocol: mail
644 Status: standard
645 Author/change controller: IETF
646 Specification document(s): This document (Section 4)
648 Header field name: Downgraded-References
649 Applicable protocol: mail
650 Status: standard
651 Author/change controller: IETF
652 Specification document(s): This document (Section 4)
654 Header field name: Downgraded-Original-Recipient
655 Applicable protocol: mail
656 Status: standard
657 Author/change controller: IETF
658 Specification document(s): This document (Section 4)
660 Header field name: Downgraded-Final-Recipient
661 Applicable protocol: mail
662 Status: standard
663 Author/change controller: IETF
664 Specification document(s): This document (Section 4)
666 10. Acknowledgements
668 This document draws heavily from the experimental in-transit message
669 downgrading procedure described in RFC 5504 [RFC5504]. The
670 contribution of the co-author of that earlier document, Y. Yoneya,
671 are gratefully acknowledged. Significant comments and suggestions
672 were received from John Klensin, Barry Leiba, Randall Gellens, Pete
673 Resnick, and other WG participants.
675 11. Change History
677 [[RFC Editor: Please remove this section prior to publication.]]
679 This section is used for tracking the update of this document. Will
680 be removed after finalize.
682 11.1. Version 00
684 o Initial version
686 o Imported header field downgrading from RFC 5504
688 11.2. Version 01
690 o same as Version 00
692 11.3. Version 02
694 o Added updating RFC 5322 to allow syntax in From: and
695 Sender
697 o Added GROUP Downgrading
699 11.4. Version 03
701 o Replaced with
702 o Added updating RFC 5322 to allow syntax in From: and
703 Sender
705 o Added one sentence in Security considerations
707 o Updated IANA considerations
709 11.5. Version 04
711 o Removed "Internationalized Address removed" from GROUP and MAILBOX
712 downgrading
714 o Updated "Updating RFC 5322"
716 o Compacted new header field definition
718 o Compacted security considerations
720 o Updated IANA considerations to remove obsoleting header fields
721 that are registered by RFC 5504
723 o Added a discussion of alternate downgrading models for the POP and
724 IMAP cases.
726 o Incorporated a large number of editorial changes to improve
727 clarity.
729 12. References
731 12.1. Normative References
733 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
734 Internationalized Email", RFC 6530, February 2012.
736 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
737 Email Headers", RFC 6532, February 2012.
739 [RFC6533] Hansen, T., Newman, C., and A. Melnikov,
740 "Internationalized Delivery Status and Disposition
741 Notifications", RFC 6533, February 2012.
743 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
744 Extensions (MIME) Part One: Format of Internet Message
745 Bodies", RFC 2045, November 1996.
747 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
748 Part Three: Message Header Extensions for Non-ASCII Text",
749 RFC 2047, November 1996.
751 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
752 Presentation Information in Internet Messages: The
753 Content-Disposition Header Field", RFC 2183, August 1997.
755 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
756 Word Extensions:
757 Character Sets, Languages, and Continuations", RFC 2231,
758 November 1997.
760 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
761 October 2008.
763 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
764 10646", STD 63, RFC 3629, November 2003.
766 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME
767 Header Fields", RFC 4021, March 2005.
769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
770 Requirement Levels", BCP 14, RFC 2119, March 1997.
772 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
773 Procedures for Message Header Fields", BCP 90, RFC 3864,
774 September 2004.
776 12.2. Informative References
778 [RFC5451] Kucherawy, M., "Message Header Field for Indicating
779 Message Authentication Status", RFC 5451, April 2009.
781 [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for
782 Email Address Internationalization", RFC 5504, March 2009.
784 Appendix A. Examples
786 A.1. Downgrading Example
788 This appendix shows an message downgrading example. Consider a
789 received mail message where:
791 o The sender address is a non-ASCII address,
792 "NON-ASCII-local@example.com". Its display-name is "DISPLAY-
793 local".
795 o The "To:" header field contains two non-ASCII addresses,
796 "NON-ASCII-remote1@example.net" and
797 "NON-ASCII-remote2@example.com" Its display-names are "DISPLAY-
798 remote1" and "DISPLAY-remote2".
800 o The "Cc:" header field contains a non-ASCII address,
801 "NON-ASCII-remote3@example.org". Its display-name is "DISPLAY-
802 remote3".
804 o Four display names contain non-ASCII characters.
806 o The Subject header field is "NON-ASCII-SUBJECT", which contains
807 non-ASCII characters.
809 o The "Message-Id:" header field contains "NON-ASCII-MESSAGE_ID",
810 which contains non-ASCII characters.
812 o There is an unknown header field "X-Unknown-Header" which contains
813 non-ASCII characters.
815 Return-Path:
816 Received: from ... by ... for
817 Received: from ... by ... for
818 From: DISPLAY-local
819 To: DISPLAY-remote1 ,
820 DISPLAY-remote2
821 Cc: DISPLAY-remote3
822 Subject: NON-ASCII-SUBJECT
823 Date: DATE
824 Message-Id: NON-ASCII-MESSAGE_ID
825 Mime-Version: 1.0
826 Content-Type: text/plain; charset="UTF-8"
827 Content-Transfer-Encoding: 8bit
828 X-Unknown-Header: NON-ASCII-CHARACTERS
830 MAIL_BODY
832 Figure 1: Received message in a mail drop
834 The downgraded message is shown in Figure 2. "Return-Path:",
835 "From:", "To:" and "Cc:" header fields are rewritten. "Subject:" and
836 "X-Unknown-Header:" header fields are encoded using [RFC2047].
837 "Message-Id:" header field is encapsulated as
838 "Downgraded-Message-Id:" header field.
840 Return-Path: =?UTF-8?Q?NON-ASCII-local@example.com?= :;
841 Received: from ... by ...
842 Received: from ... by ...
843 From: =?UTF-8?Q?DISPLAY-local?=
844 =?UTF-8?Q?NON-ASCII-local@example.com?= :;
845 To: =?UTF-8?Q?DISPLAY-remote1?=
846 =?UTF-8?Q?NON-ASCII-remote1@example.net?= :;,
847 =?UTF-8?Q?DISPLAY-remote2?=
848 =?UTF-8?Q?NON-ASCII-remote2@example.com?= :;,
849 Cc: =?UTF-8?Q?DISPLAY-remote3?=
850 =?UTF-8?Q?NON-ASCII-remote3@example.org?= :;
851 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
852 Date: DATE
853 Downgraded-Message-Id: =?UTF-8?Q?MESSAGE_ID?=
854 Mime-Version: 1.0
855 Content-Type: text/plain; charset="UTF-8"
856 Content-Transfer-Encoding: 8bit
857 X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?=
859 MAIL_BODY
861 Figure 2: Downgraded message
863 Author's Address
865 Kazunori Fujiwara
866 Japan Registry Services Co., Ltd.
867 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
868 Chiyoda-ku, Tokyo 101-0065
869 Japan
871 Phone: +81 3 5215 8451
872 EMail: fujiwara@wide.ad.jp, fujiwara@jprs.co.jp