idnits 2.17.1
draft-ietf-eai-downgrade-12.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. See
https://trustee.ietf.org/license-info/.)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 2, 2009) is 5525 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Missing Reference: 'FWS' is mentioned on line 233, but not defined
== Missing Reference: 'CFWS' is mentioned on line 234, but not defined
** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152)
** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530)
** Obsolete normative reference: RFC 5335 (Obsoleted by RFC 6532)
** Obsolete normative reference: RFC 5336 (Obsoleted by RFC 6531)
** Obsolete normative reference: RFC 5337 (Obsoleted by RFC 6533)
== Outdated reference: A later version (-03) exists of
draft-ietf-eai-downgraded-display-00
== Outdated reference: A later version (-01) exists of
draft-ietf-eai-dsnbis-00
Summary: 6 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, Ed.
3 (EAI) Y. YONEYA, Ed.
4 Internet-Draft JPRS
5 Intended status: Experimental March 2, 2009
6 Expires: September 3, 2009
8 Downgrading mechanism for Email Address Internationalization
9 draft-ietf-eai-downgrade-12.txt
11 Status of this Memo
13 This Internet-Draft is submitted to IETF in full conformance with the
14 provisions of BCP 78 and BCP 79.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as Internet-
19 Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on September 3, 2009.
34 Copyright Notice
36 Copyright (c) 2009 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents in effect on the date of
41 publication of this document (http://trustee.ietf.org/license-info).
42 Please review these documents carefully, as they describe your rights
43 and restrictions with respect to this document.
45 Abstract
47 Traditional mail systems handle only ASCII characters in SMTP
48 envelope and mail header fields. The Email Address
49 Internationalization (UTF8SMTP) extension allows UTF-8 characters in
50 SMTP envelope and mail header fields. To avoid rejecting
51 internationalized Email messages when a server in the delivery path
52 does not support the UTF8SMTP extension, some sort of converting
53 mechanism is required. This document describes a downgrading
54 mechanism for Email Address Internationalization. Note that this is
55 a way to downgrade, not tunnel. There is no associated up-conversion
56 mechanism, although internationalized email clients might use
57 original internationalized addresses or other data when displaying or
58 replying to downgraded messages.
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
64 3. New header fields definition . . . . . . . . . . . . . . . . . 5
65 3.1. Envelope information preservation header fields . . . . . 6
66 3.2. Address header field preservation header fields . . . . . 6
67 3.3. Unknown header fields preservation header fields . . . . 7
68 4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 8
69 4.1. Path element downgrading . . . . . . . . . . . . . . . . 8
70 4.2. ORCPT downgrading . . . . . . . . . . . . . . . . . . . . 9
71 5. Email header fields downgrading . . . . . . . . . . . . . . . 9
72 5.1. Downgrading method for each ABNF element . . . . . . . . 9
73 5.1.1. RECEIVED downgrading . . . . . . . . . . . . . . . . . 9
74 5.1.2. UNSTRUCTURED downgrading . . . . . . . . . . . . . . . 9
75 5.1.3. WORD downgrading . . . . . . . . . . . . . . . . . . . 10
76 5.1.4. COMMENT downgrading . . . . . . . . . . . . . . . . . 10
77 5.1.5. MIME-VALUE downgrading . . . . . . . . . . . . . . . . 10
78 5.1.6. DISPLAY-NAME downgrading . . . . . . . . . . . . . . . 10
79 5.1.7. MAILBOX downgrading . . . . . . . . . . . . . . . . . 10
80 5.1.8. ENCAPSULATION downgrading . . . . . . . . . . . . . . 11
81 5.1.9. TYPED-ADDRESS downgrading . . . . . . . . . . . . . . 11
82 5.2. Downgrading method for each header field . . . . . . . . 11
83 5.2.1. Address header fields which contain
s . . . . 11
84 5.2.2. Address header fields with typed addresses . . . . . . 12
85 5.2.3. Downgrading Non-ASCII in comments . . . . . . . . . . 12
86 5.2.4. Received header field . . . . . . . . . . . . . . . . 12
87 5.2.5. MIME Content header fields . . . . . . . . . . . . . . 12
88 5.2.6. Non-ASCII in . . . . . . . . . . . . . 13
89 5.2.7. Non-ASCII in . . . . . . . . . . . . . . . . 13
90 5.2.8. Other header fields . . . . . . . . . . . . . . . . . 13
91 6. MIME body part header fields downgrading . . . . . . . . . . . 13
92 7. Security considerations . . . . . . . . . . . . . . . . . . . 14
93 8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 15
94 8.1. RFC 2047 encoding . . . . . . . . . . . . . . . . . . . . 15
95 8.2. Trivial downgrading . . . . . . . . . . . . . . . . . . . 16
96 8.3. 7bit transport consideration . . . . . . . . . . . . . . 16
97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
99 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 19
100 11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . 19
101 11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . 19
102 11.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . 20
103 11.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . 20
104 11.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . 20
105 11.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . 20
106 11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . 20
107 11.8. draft-ietf-eai-downgrade: Version 05 . . . . . . . . . . 20
108 11.9. draft-ietf-eai-downgrade: Version 06 . . . . . . . . . . 21
109 11.10. draft-ietf-eai-downgrade: Version 07 . . . . . . . . . . 21
110 11.11. draft-ietf-eai-downgrade: Version 08 . . . . . . . . . . 21
111 11.12. draft-ietf-eai-downgrade: Version 09 . . . . . . . . . . 21
112 11.13. draft-ietf-eai-downgrade: Version 10 . . . . . . . . . . 21
113 11.14. draft-ietf-eai-downgrade: Version 11 . . . . . . . . . . 21
114 11.15. draft-ietf-eai-downgrade: Version 12 . . . . . . . . . . 21
115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
116 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
117 12.2. Informative References . . . . . . . . . . . . . . . . . 23
118 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 23
119 A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 23
120 A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 26
121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
123 1. Introduction
125 Traditional mail systems which are defined by [RFC5321] and [RFC5322]
126 allow ASCII characters in SMTP envelope and mail header field values.
127 The UTF8SMTP extension [RFC4952], [RFC5335] and [RFC5336] allows
128 UTF-8 characters in SMTP envelope and mail header field values.
130 If an envelope address or header field contains non-ASCII characters,
131 the message cannot be delivered unless every system in the delivery
132 path supports UTF8SMTP. This document describes a downgrading
133 mechanism to avoid rejection of such messages when a server which
134 does not support the UTF8SMTP extension is encountered. Downgrading
135 mechanism converts envelope and header fields to an all-ASCII
136 representation.
138 [RFC5335] allows UTF-8 characters to be used in mail header fields
139 and MIME header fields. The downgrading mechanism specified here
140 converts mail header fields and MIME header fields to ASCII.
142 This document does not change any protocols except by defining new
143 header fields. It describes the conversion method from the
144 internationalized email envelopes/messages which are defined in
145 [RFC4952] [RFC5335] [RFC5336] to the traditional email envelopes/
146 messages which are defined in [RFC5321] [RFC5322].
148 [RFC5336] section 2.2 defines when downgrading occurs. If the SMTP
149 client has an UTF8SMTP envelope or an internationalized message and
150 the SMTP server doesn't support the UTF8SMTP SMTP extension, then the
151 SMTP client MUST NOT send a UTF8SMTP envelope or an internationalized
152 message to the SMTP server. The section shows 4 choices. The fourth
153 choice is downgrading, as described here.
155 Downgrading may be implemented in MUAs, MSAs, MTAs which act as the
156 SMTP client, or in MDAs, POP servers, IMAP servers which store or
157 offer UTF8SMTP envelopes or internationalized messages to non-
158 UTF8SMTP compliant systems which include message stores.
160 This document tries to define the downgrading process clearly and it
161 preserves the original information as much as possible.
163 Downgrading in UTF8SMTP consists of the following four parts:
164 o New header fields definition
165 o SMTP downgrading
166 o Email header fields downgrading
167 o MIME header fields downgrading
169 In Section 3, many header fields starting with "Downgraded-" are
170 introduced. They preserve the original envelope information and the
171 original header fields.
173 The SMTP downgrading is described in Section 4. It generates ASCII
174 only envelope information from an UTF8SMTP envelope.
176 The Email header fields downgrading is described in Section 5. It
177 generates ASCII only header fields.
179 The MIME header fields are expanded in [RFC5335]. The MIME header
180 fields downgrading is described in Section 6. It generates ASCII
181 only MIME header fields.
183 Displaying downgraded messages which originally contain
184 internationalized E-mail addresses or internationalized header fields
185 is described in an another document
186 ([I-D.ietf-eai-downgraded-display]).
188 2. Terminology
190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
192 document are to be interpreted as described in RFC 2119 [RFC2119].
194 All specialized terms used in this specification are defined in the
195 EAI overview [RFC4952] or in [RFC5321][RFC5322], MIME documents
196 [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address",
197 "internationalized email address", "non-ASCII address", "i18mail
198 address", "UTF8SMTP", "message" and "mailing list" are used with the
199 definitions from [RFC4952] document.
201 This document depends on [RFC5335], [RFC5336], and [RFC5337]. Key
202 words used in these document are used in this document, too.
204 The term "non-ASCII" is an UTF-8 string which contains at least one
205 non-ASCII character.
207 An "UTF8SMTP envelope" has Email originator/recipient addresses
208 expanded by [RFC5336] and [RFC5337].
210 An "UTF8SMTP message" is Email messages expanded by [RFC5335].
212 3. New header fields definition
214 New header fields starting with "Downgraded-" are defined here to
215 preserve those original envelope and header field values which
216 contain UTF-8 characters. During downgrading, one new "Downgraded-"
217 header field is added for each original envelope or header field
218 which cannot be passed as-is to a server which does not support
219 UTF8SMTP. The original envelope or header field is removed or
220 rewritten. Only those envelope and header fields which contain non-
221 ASCII characters are affected. The result of this process is a
222 message which is compliant with existing email specifications
223 [RFC5321] and [RFC5322]. The original internationalized information
224 can be retrieved by examining the "Downgraded-" header fields which
225 were added.
227 3.1. Envelope information preservation header fields
229 SMTP envelope downgraded information
230 consists of the original non-ASCII address and the downgraded all-
231 ASCII address.
233 downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox
234 FWS "<" Mailbox ">" ">" [CFWS]
236 is defined in [RFC5336]; and are defined
237 in [RFC5321], section 4.1.2.
239 Two header fields "Downgraded-Mail-From:" and "Downgraded-Rcpt-To:"
240 are defined to preserve SMTP envelope downgraded information. The
241 header field syntax is specified as follows:
243 fields =/ downgradedmailfrom / downgradedrcptto
244 downgradedmailfrom = "Downgraded-Mail-From:" unstructured CRLF
245 downgradedrcptto = "Downgraded-Rcpt-To:" unstructured CRLF
247 The unstructured content is downgraded-envelope-addr treated as if it
248 were unstructured with [RFC2047] encoding (and charset UTF-8) as
249 needed.
251 3.2. Address header field preservation header fields
253 The address header fields preservation header fields are defined to
254 preserve the original header field. Their value field holds the
255 original header field value. The header field syntax is specified as
256 follows:
258 fields =/ known-downgraded-headers ":" unstructured CRLF
259 known-downgraded-headers = "Downgraded-" original-headers
260 original-headers = "From" / "Sender" /
261 "To" / "Cc" / "Bcc" /
262 "Reply-To" /
263 "Resent-From" / "Resent-Sender" /
264 "Resent-To" / "Resent-Cc" / "Resent-Bcc" /
265 "Resent-Reply-To" /
266 "Return-Path" /
267 "Disposition-Notification-To"
269 Preserving a header field in a downgraded header field is defined as:
270 1. Generate new downgraded header field whose value is the original
271 header field value.
272 2. Treat the generated header field content as if it were
273 unstructured, and then apply [RFC2047] encoding with charset
274 UTF-8 as necessary so the result is ASCII.
276 3.3. Unknown header fields preservation header fields
278 The unknown header fields preservation header fields are defined to
279 encapsulate those original header fields which contain non-ASCII
280 characters and are not otherwise provided for in the this
281 specification. The encapsulation header field name is the
282 concatenation of "Downgraded-" and the original name. The value
283 field holds the original header field value.
285 The header field syntax is specified as follows:
287 fields =/ unknown-downgraded-headers ":" unstructured CRLF
288 unknown-downgraded-headers = "Downgraded-" original-header-field-name
289 original-header-field-name = field-name
291 field-name = 1*ftext
293 ftext = %d33-57 / ; Any character except
294 %d59-126 ; controls, SP, and
295 ; ":".
297 Encapsulating a header field in a "Downgraded-" header field is
298 defined as:
299 1. Generate new "Downgraded-" header field whose value is the
300 original header field value.
302 2. Treat the generated header field content as if it were
303 unstructured, and then apply [RFC2047] encoding with charset
304 UTF-8 as necessary so the result is ASCII.
305 3. Remove the original header field.
307 4. SMTP Downgrading
309 Target of downgrading elements in SMTP envelope are below:
311 o of MAIL FROM command
312 o of RCPT TO command
313 o ORCPT parameter of RCPT TO command
315 4.1. Path element downgrading
317 Downgrading the of MAIL FROM and RCPT TO commands uses ALT-
318 ADDRESS parameter defined in [RFC5336]. A SMTP command is
319 downgradable if the contains non-ASCII address and the command
320 has an ALT-ADDRESS parameter which specifies an ASCII address. Since
321 only non-ASCII addresses are downgradable, specifying an ALT-ADDRESS
322 value for an all-ASCII address is invalid for use with this
323 specification, and no interpretation is assigned to it. This
324 restriction allows for future extension of the specification even
325 though no such extensions are currently anticipated.
327 Note that even if no downgrading is performed on the envelope,
328 message header fields and message body MIME header fields that
329 contain non-ASCII characters MUST be downgraded. This is described
330 in Section 5 and Section 6.
332 When downgrading, replace each which contains non-ASCII mail
333 address with its specified alternative ASCII address and preserve the
334 original information using "Downgraded-Mail-From" and "Downgraded-
335 Rcpt-To" header fields as defined in Section 3. Before replacing,
336 decode the ALT-ADDRESS parameter value because it is encoded as xtext
337 [RFC3461].
339 To avoid disclosing recipient addresses, the downgrading process MUST
340 NOT add "Downgraded-Rcpt-To:" header field if the SMTP downgrading
341 targets multiple recipients. See Section 7 for more detail.
343 As a result of the recipient address downgrading, the domain part of
344 the recipient address prior to downgrading might be different from
345 the domain part of the new recipient address. If the result of
346 address resolution for the domain part of the new recipient address
347 contains the server at the connection destination of the SMTP session
348 for the recipient address prior to downgrading, the SMTP connection
349 is valid for the new recipient address. Otherwise, the downgrading
350 process MUST NOT send the downgraded message to the new recipient
351 address via the connection and MUST try to send the downgraded
352 message to the new recipient address.
354 4.2. ORCPT downgrading
356 The "RCPT TO" command can have an ORCPT parameter if the DSN
357 extension [RFC3461] is supported. If the ORCPT parameter contains an
358 "utf-8" type address and the address contains raw non-ASCII
359 characters, the address MUST be converted to utf-8-addr-xtext form.
360 Those forms are described in [RFC5337] and clarified by successor
361 documents such as [I-D.ietf-eai-dsnbis].
363 Before converting to utf-8-addr-xtext form, remove xtext encoding.
365 5. Email header fields downgrading
367 This section defines the conversion method to ASCII for each header
368 field which may contain non-ASCII characters.
370 [RFC5335] expands Received: header fields, [RFC5322] ABNF elements
371 , , , , [RFC2045] ABNF element
372 .
374 5.1. Downgrading method for each ABNF element
376 Header field downgrading is defined below for each ABNF element.
377 Downgrading an unknown header field is also defined as ENCAPSULATION
378 downgrading. Converting the header field terminates when no non-
379 ASCII characters remain in the header field.
381 5.1.1. RECEIVED downgrading
383 If the header field name is "Received:" and the FOR clause contains a
384 non-ASCII addresses, remove the FOR clause from the header field.
385 Other parts (not counting s) should not contain non-ASCII
386 values.
388 5.1.2. UNSTRUCTURED downgrading
390 If the header field has an field which contains non-
391 ASCII characters, apply [RFC2047] encoding with charset UTF-8.
393 5.1.3. WORD downgrading
395 If the header field has any fields which contains non-ASCII
396 characters, apply [RFC2047] encoding with charset UTF-8.
398 5.1.4. COMMENT downgrading
400 If the header field has any fields which contains non-ASCII
401 characters, apply [RFC2047] encoding with charset UTF-8.
403 5.1.5. MIME-VALUE downgrading
405 If the header field has any elements defined by [RFC2045] and
406 the elements contain non-ASCII characters, encode the
407 elements by [RFC2231] with charset UTF-8 and the Language information
408 empty. If the element is and it contains
409 outside the DQUOTE, remove the before this conversion.
411 5.1.6. DISPLAY-NAME downgrading
413 If the header field has any ( and )
414 elements and they have elements which contain non-
415 ASCII characters, encode the elements according to
416 [RFC2047] with charset UTF-8. DISPLAY-NAME downgrading is the same
417 algorithm as WORD downgrading.
419 5.1.7. MAILBOX downgrading
421 The elements have no equivalent format for non-ASCII
422 addresses. If the header field has any elements which
423 contain non-ASCII characters, preserve the header field in each
424 Address header field preservation header field defined in
425 Section 3.2, and rewrite each element to ASCII only format.
426 The element which contains non-ASCII characters is one of
427 three formats.
429 o [ Display-name ] "<" Utf8-addr-spec 1*FCS "<" Addr-spec ">>"
431 Rewrite it as
433 [ Display-name ] "<" Addr-spec ">"
435 o [ Display-name ] "<" Utf8-addr-spec ">"
436 o Utf8-addr-spec
438 Rewrite both as
439 [ Display-name ] "Internationalized Address " Encoded-word
440 " Removed:;"
441 where the is the original encoded
442 according to [RFC2047].
444 5.1.8. ENCAPSULATION downgrading
446 if the header field contains non-ASCII characters and for which no
447 rule is given above, encapsulate it in a Downgraded header field
448 described in Section 3.3 as a last resort.
450 Applying this procedure to "Received" header field is prohibited.
452 5.1.9. TYPED-ADDRESS downgrading
454 If the header field contains and the contains raw non-ASCII characters, it is utf-8-address form and
456 convert it to utf-8-addr-xtext form as described in Section 4.2.
457 COMMENT downgrading is also performed in this case. If the address
458 type is unrecognized and the header field contains non-ASCII
459 characters, then fall back to using ENCAPSULATION downgrading on the
460 entire header field.
462 5.2. Downgrading method for each header field
464 Header fields are listed in [RFC4021]. This section describes the
465 downgrading method for each header field.
467 If the whole mail header field does not contain non-ASCII characters,
468 email header field downgrading is not required. Each header field's
469 downgrading method is described below.
471 5.2.1. Address header fields which contain s
473 From:
474 Sender:
475 To:
476 Cc:
477 Bcc:
478 Reply-To:
479 Resent-From:
480 Resent-Sender:
481 Resent-To:
482 Resent-Cc:
483 Resent-Bcc:
484 Resent-Reply-To:
486 Return-Path:
487 Disposition-Notification-To:
489 If the header field contains elements which contains non-
490 ASCII addresses, preserve the header field in a downgraded header
491 field before the conversion. Then perform COMMENT downgrading,
492 DISPLAY-NAME downgrading and MAILBOX downgrading.
494 5.2.2. Address header fields with typed addresses
496 Original-Recipient:
497 Final-Recipient:
499 If the header field contains non-ASCII characters, perform TYPED-
500 ADDRESS downgrading.
502 5.2.3. Downgrading Non-ASCII in comments
504 Date:
505 Message-ID:
506 Resent-Message-ID:
507 In-Reply-To:
508 References:
509 Resent-Date:
510 Resent-Message-ID:
511 MIME-Version:
512 Content-ID:
513 Content-Transfer-Encoding:
514 Content-Language:
515 Accept-Language:
516 Auto-Submitted:
518 These header fields do not contain non-ASCII characters except in
519 comments. If the header field contains UTF-8 characters in comments,
520 perform COMMENT downgrading.
522 5.2.4. Received header field
524 Received:
526 perform COMMENT downgrading and RECEIVED downgrading.
528 5.2.5. MIME Content header fields
529 Content-Type:
530 Content-Disposition:
532 Perform MIME-VALUE downgrading and COMMENT downgrading.
534 5.2.6. Non-ASCII in
536 Subject:
537 Comments:
538 Content-Description:
540 Perform UNSTRUCTURED downgrading.
542 5.2.7. Non-ASCII in
544 Keywords:
546 Perform WORD downgrading.
548 5.2.8. Other header fields
550 All other header fields which contains non-ASCII characters are user-
551 defined, missing from this draft or future defined header fields.
552 Perform ENCAPSULATION downgrading.
554 If the software understands the header field's structure and a
555 downgrading algorithm other than ENCAPSULATION is applicable, that
556 software SHOULD use that algorithm; ENCAPSULATION downgrading is used
557 as a last resort.
559 Mailing list header fields (those that start in "List-") are part of
560 this category.
562 6. MIME body part header fields downgrading
564 MIME body part header fields may contain non-ASCII characters
565 [RFC5335]. This section defines the conversion method to ASCII only
566 header fields for each MIME header field which contains non-ASCII
567 characters. Parse the message body's MIME structure for all levels
568 and check each MIME header field whether it contains non-ASCII
569 characters. If the header field contains non-ASCII characters in the
570 header field value, the header field is a target of the MIME body
571 part header fields downgrading. Each MIME header field's downgrading
572 method is described below. COMMENT downgrading, MIME-VALUE
573 downgrading, UNSTRUCTURED downgrading are described in Section 5.
575 Content-ID:
576 The Content-ID: header field does not contain non-ASCII characters
577 except in comments. If the header field contains UTF-8 characters
578 in comments, perform COMMENT downgrading.
580 Content-Type:
581 Content-Disposition:
582 Perform MIME-VALUE downgrading and COMMENT downgrading.
584 Content-Description:
585 Perform UNSTRUCTURED downgrading.
587 7. Security considerations
589 A Downgraded message's header fields contain ASCII characters only.
590 But they still contain MIME encapsulated header fields which contains
591 non-ASCII UTF-8 characters. Furthermore, the body part may contain
592 UTF-8 characters. Implementations parsing Internet messages need to
593 accept UTF-8 body parts and UTF-8 header fields which are MIME
594 encoded. Thus it inherits the security considerations of MIME
595 encoded header fields [RFC2047] and [RFC3629].
597 Rewriting header fields increases the opportunities for undetected
598 spoofing by the malicious senders. However rewritten header fields
599 are preserved into Downgraded-* header fields and parsing
600 Downgraded-* header fields enables detecting spoofing caused by
601 downgrading.
603 Addresses that do not appear in the message header fields may appear
604 in the RCPT commands to an SMTP server for a number of reasons.
605 Copying information from the Envelope into header fields risks
606 inadvertent information disclosure (see [RFC5321] and Section 4).
607 Mitigating inadvertent information disclosure is discussed in same
608 place.
610 The techniques described here invalidates methods that depend on
611 digital signatures over the envelope or any part of the message which
612 includes the top-level header fields or body part header fields.
613 Depending on the specific message being downgraded, DKIM especially,
614 but also possibly S/MIME, PGP, and similar techniques are all likely
615 to break. The two obvious mitigations are to stick to 7-bit
616 transport when using these techniques (as most/all of them presently
617 require), or make sure you have UTF8SMTP end-to-end when needed.
619 Many gateways and servers on the Internet will discard header fields
620 with which they are not familiar. To the extent to which the
621 downgrade procedures depend on new header fields (e.g.,
622 "Downgraded-") to avoid information loss, the risk of having those
623 header fields dropped and its implications must be identified. In
624 particular, if the Downgraded header fields are dropped, there is no
625 possibility of reconstructing the original information at any point
626 (before, during, or after delivery). Such gateways violate [RFC2979]
627 and can be upgraded to correct the problem.
629 Even though the information is not lost, the original message cannot
630 be perfectly reconstructed because some downgrading methods remove
631 information (see Section 5.1.1 and Section 5.1.5). Hence,
632 downgrading is a one-way process.
634 While information in any email header field should usually treated
635 with some suspicion, current email systems commonly employ various
636 mechanisms and protocols to make the information more trustworthy.
637 Currently, information in the new Downgraded-* header fields is
638 usually not inspected by these mechanisms, and may be even less
639 trustworthy than the traditional header fields. Note that the
640 Downgraded-* header fields could have been inserted with malicious
641 intent. (and with content unrelated to the traditional header
642 fields).
644 If an internationalized MUA would simply try to "upgrade" the message
645 for display purposes (that is, display the information in the
646 Downgraded-* header fields instead of the traditional header fields),
647 the effectiveness of the deployed mechanisms and protocols is likely
648 to be reduced, and the user may be exposed to additional risks. More
649 guidance on how to display downgraded messages will be given in
650 [I-D.ietf-eai-downgraded-display].
652 Concerns about the trustworthiness of the Downgraded-* header fields
653 are not limited to displaying and replying in MUAs, and should be
654 carefully considered before using them for other purposes as well.
656 See "Security considerations" section in [RFC4952] for more
657 discussion.
659 8. Implementation notes
661 8.1. RFC 2047 encoding
663 While [RFC2047] has a specific algorithm to deal with whitespace in
664 adjacent encoded-words, there are a number of deployed
665 implementations that fail to implement the algorithm correctly. As a
666 result, whitespace behavior is somewhat unpredictable in practice
667 when multiple encoded words are used. While RFC 5322 states that
668 implementations SHOULD limit lines to not more than 78 characters,
669 implementations MAY choose to allow overlong encoded words in order
670 to work around faulty [RFC2047] implementations. Implementations
671 that choose to do so SHOULD have an optional mechanism to limit line
672 length to 78 characters.
674 8.2. Trivial downgrading
676 Downgrading is an alternative to avoid the rejection of messages
677 which require UTF8SMTP support by a server which does not provide
678 this. Implementing the full specification of this document is
679 desirable, but a partial implementation is also possible.
681 If a partial downgrading implementation confronts an unsupported
682 downgrading target, the implementation MUST NOT send the message to a
683 server which does not support UTF8SMTP. Instead, it MUST reject the
684 message or generate a notification of non-deliverability.
686 A partial downgrading, Trivial downgrading is discussed. It does not
687 support non-ASCII addresses in SMTP envelope and address header
688 fields, unknown header fields downgrading, the MIME body part header
689 fields downgrading. It supports
690 o some simple header fields downgrading: Subject
691 o comments and display name downgrading: From, To, Cc
692 o trace header field downgrading: Received
694 Otherwise, the downgrading fails.
696 Trivial downgrading targets mail messages which are generated by
697 UTF8SMTP aware MUAs and contain non-ASCII characters in comments,
698 display names, unstructured parts without using non-ASCII E-mail
699 addresses. This mail message does not contain non-ASCII E-mail
700 addresses in the SMTP Envelope and its header fields. But it is not
701 deliverable via a UTF8SMTP un-aware SMTP server. Implementing full
702 specification downgrading may be hard, but trivial downgrading saves
703 mail messages without using non-ASCII addresses.
705 8.3. 7bit transport consideration
707 The SMTP client may encounter a SMTP server which does not support
708 the 8BITMIME SMTP extension [RFC1652]. The server does not support
709 "8bit" or "binary" data. Implementers need to consider converting
710 "8bit" data to "base64" or "quoted-printable" encoded form and adjust
711 the "Content-Transfer-Encoding" header field accordingly. If the
712 body contains multiple MIME parts, this conversion MUST be performed
713 for each MIME part.
715 9. IANA Considerations
717 IANA is requested to register the following header fields in the
718 Permanent Message Header Field Repository, in accordance with the
719 procedures set out in [RFC3864].
721 Header field name: Downgraded-Mail-From
722 Applicable protocol: mail
723 Status: experimental
724 Author/change controller: IETF
725 Specification document(s): This document (Section 3)
727 Header field name: Downgraded-Rcpt-To
728 Applicable protocol: mail
729 Status: experimental
730 Author/change controller: IETF
731 Specification document(s): This document (Section 3)
733 Header field name: Downgraded-From
734 Applicable protocol: mail
735 Status: experimental
736 Author/change controller: IETF
737 Specification document(s): This document (Section 3)
739 Header field name: Downgraded-Sender
740 Applicable protocol: mail
741 Status: experimental
742 Author/change controller: IETF
743 Specification document(s): This document (Section 3)
745 Header field name: Downgraded-To
746 Applicable protocol: mail
747 Status: experimental
748 Author/change controller: IETF
749 Specification document(s): This document (Section 3)
751 Header field name: Downgraded-Cc
752 Applicable protocol: mail
753 Status: experimental
754 Author/change controller: IETF
755 Specification document(s): This document (Section 3)
757 Header field name: Downgraded-Bcc
758 Applicable protocol: mail
759 Status: experimental
760 Author/change controller: IETF
761 Specification document(s): This document (Section 3)
763 Header field name: Downgraded-Reply-To
764 Applicable protocol: mail
765 Status: experimental
766 Author/change controller: IETF
767 Specification document(s): This document (Section 3)
769 Header field name: Downgraded-Resent-From
770 Applicable protocol: mail
771 Status: experimental
772 Author/change controller: IETF
773 Specification document(s): This document (Section 3)
775 Header field name: Downgraded-Resent-Sender
776 Applicable protocol: mail
777 Status: experimental
778 Author/change controller: IETF
779 Specification document(s): This document (Section 3)
781 Header field name: Downgraded-Resent-To
782 Applicable protocol: mail
783 Status: experimental
784 Author/change controller: IETF
785 Specification document(s): This document (Section 3)
787 Header field name: Downgraded-Resent-Cc
788 Applicable protocol: mail
789 Status: experimental
790 Author/change controller: IETF
791 Specification document(s): This document (Section 3)
793 Header field name: Downgraded-Resent-Bcc
794 Applicable protocol: mail
795 Status: experimental
796 Author/change controller: IETF
797 Specification document(s): This document (Section 3)
799 Header field name: Downgraded-Resent-Reply-To
800 Applicable protocol: mail
801 Status: experimental
802 Author/change controller: IETF
803 Specification document(s): This document (Section 3)
805 Header field name: Downgraded-Return-Path
806 Applicable protocol: mail
807 Status: experimental
808 Author/change controller: IETF
809 Specification document(s): This document (Section 3)
811 Header field name: Downgraded-Disposition-Notification-To
812 Applicable protocol: mail
813 Status: experimental
814 Author/change controller: IETF
815 Specification document(s): This document (Section 3)
817 Furthermore, IANA is requested to refuse registration of all the
818 field names that start with "Downgraded-" for unknown header fields
819 downgrading described in Section 3.3 to avoid conflicts with existing
820 IETF activity (Email Address Internationalization).
822 10. Acknowledgements
824 Significant comments and suggestions were received from John Klensin,
825 Harald Alvestrand, Chris Newman, Randall Gellens, Charles Lindsey,
826 Marcos Sanz, Alexey Melnikov, Frank Ellermann, Edward Lewis, S.
827 Moonesamy and JET members.
829 11. Change History
831 This section is used for tracking the update of this document. Will
832 be removed after finalize.
834 11.1. draft-yoneya-ima-downgrade: Version 00
836 o Initial version
837 o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00
839 11.2. draft-yoneya-ima-downgrade: Version 01
841 o Document structure was changed
842 o Followed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02
843 o Downgrading requirements were added
844 o SMTP DATA encapsulation method was proposed
845 o Downgrading examples was provided
847 11.3. draft-ietf-eai-downgrade: Version 00
849 o Followed draft-yeh-ima-utf8headers-01 and
850 draft-ietf-eai-smtpext-00
851 o No header field downgrading method was proposed
852 o Header encapsulation method was proposed
854 11.4. draft-ietf-eai-downgrade: Version 01
856 o Followed draft-ietf-eai-utf8headers-00
857 o Header conversion and encapsulation method was merged
858 o Header conversion method was defined in detail
860 11.5. draft-ietf-eai-downgrade: Version 02
862 o Followed draft-ietf-eai-utf8headers-01 and
863 draft-ietf-eai-smtpext-01
864 o Specification about algorithmic generated address is removed
865 o No header field downgrading method was removed
866 o SMTP DATA encapsulation method was removed
868 11.6. draft-ietf-eai-downgrade: Version 03
870 o Followed draft-ietf-eai-utf8headers-03 and
871 draft-ietf-eai-smtpext-03
872 o Downgraded: and Envelope-Downgraded: headers definition was added
873 o Mail header fields downgrading method was refined
874 o Examples in Appendix A were refined
876 11.7. draft-ietf-eai-downgrade: Version 04
878 o Followed draft-ietf-eai-utf8headers-06, draft-ietf-eai-smtpext-07
879 and draft-ietf-eai-dsn-02
880 o Downgrading requirements and conditions were moved to
881 Introduction.
882 o Descriptions about upgrading were removed.
883 o SPF and DKIM discussion were removed.
884 o Added many header fields downgrading.
885 o Allow address literal rewriting without alternate ASCII address in
886 header fields.
887 o Added MIME body part headers downgrading.
888 o Added ORCPT downgrading.
890 11.8. draft-ietf-eai-downgrade: Version 05
892 o fixed examples
893 * ALT-ADDRESS parameter mistake
894 * RFC2047(x) notation was changed to encoded-word format
895 o Added implementation consideration section and trivial downgrading
896 o Downgraded: and Envelope-Downgraded: headers are separated for
897 each original headers.
898 o Removed list-* header fields downgrading
899 o Changed the way of writing the header field downgrading section
901 11.9. draft-ietf-eai-downgrade: Version 06
903 o Moved decoding downgraded messages as a separate document
904 o Added a text to UNSTRUCTURED downgrading
905 o Added "replacing SMTP connection" if necessary to SMTP
906 downgrading.
907 o fixed examples
909 11.10. draft-ietf-eai-downgrade: Version 07
911 o Fixed some typos
912 o Added a text about 7bit transport
914 11.11. draft-ietf-eai-downgrade: Version 08
916 o Comments from the working group last call (wording)
918 11.12. draft-ietf-eai-downgrade: Version 09
920 o References
922 11.13. draft-ietf-eai-downgrade: Version 10
924 o Comments from AD Review
926 11.14. draft-ietf-eai-downgrade: Version 11
928 o IETF Last call: Comments from Gen-ART and IANA
929 o Added new downgraded header field definitions for Resent-Reply-To,
930 Recent-Bcc and Disposition-Notification-To
931 o Separated "Email header fields downgrading" section into
932 subsections
933 o Updated ORCPT and TYPED-ADDRESS downgrading
935 11.15. draft-ietf-eai-downgrade: Version 12
937 o Comments from IESG
938 o rewrite all 'header' to 'header field'.
940 12. References
942 12.1. Normative References
944 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
945 Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
946 RFC 1652, July 1994.
948 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
949 Extensions (MIME) Part One: Format of Internet Message
950 Bodies", RFC 2045, November 1996.
952 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
953 Part Three: Message Header Extensions for Non-ASCII Text",
954 RFC 2047, November 1996.
956 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
957 Requirement Levels", BCP 14, RFC 2119, March 1997.
959 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
960 Presentation Information in Internet Messages: The
961 Content-Disposition Header Field", RFC 2183, August 1997.
963 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
964 Word Extensions:
965 Character Sets, Languages, and Continuations", RFC 2231,
966 November 1997.
968 [RFC2979] Freed, N., "Behavior of and Requirements for Internet
969 Firewalls", RFC 2979, October 2000.
971 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
972 Extension for Delivery Status Notifications (DSNs)",
973 RFC 3461, January 2003.
975 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
976 10646", STD 63, RFC 3629, November 2003.
978 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
979 Procedures for Message Header Fields", BCP 90, RFC 3864,
980 September 2004.
982 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME
983 Header Fields", RFC 4021, March 2005.
985 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
986 Internationalized Email", RFC 4952, July 2007.
988 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
989 October 2008.
991 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
992 October 2008.
994 [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335,
995 September 2008.
997 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized
998 Email Addresses", RFC 5336, September 2008.
1000 [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery
1001 Status and Disposition Notifications", RFC 5337,
1002 September 2008.
1004 12.2. Informative References
1006 [I-D.ietf-eai-downgraded-display]
1007 Fujiwara, K., "Displaying Downgraded Messages for Email
1008 Address Internationalization",
1009 draft-ietf-eai-downgraded-display-00 (work in progress),
1010 October 2008.
1012 [I-D.ietf-eai-dsnbis]
1013 Newman, C. and A. Melnikov, "Internationalized Delivery
1014 Status and Disposition Notifications",
1015 draft-ietf-eai-dsnbis-00 (work in progress),
1016 December 2008.
1018 Appendix A. Examples
1020 A.1. Downgrading example 1
1022 This section shows an SMTP Downgrading example. Consider a mail
1023 message where:
1024 o The sender address is "NON-ASCII-local@example.com" which is a
1025 non-ASCII address. Its ASCII alternative is
1026 "ASCII-local@example.com" and its display-name is "DISPLAY-local".
1027 o The "To:" address is "NON-ASCII-remote1@example.net" which is a
1028 non-ASCII address. Its ASCII alternative is
1029 "ASCII-remote1@example.net" and its display-name is "DISPLAY-
1030 remote1".
1031 o The "Cc:" address is a non-ASCII address
1032 "NON-ASCII-remote2@example.org" without alternative ASCII address.
1033 Its display-name is "DISPLAY-remote2".
1035 o Three display-names contain non-ASCII characters.
1036 o The Subject header field is "NON-ASCII-SUBJECT" which contains
1037 non-ASCII characters.
1038 o Assuming the "To:" recipient's MTA (example.net) does not support
1039 UTF8SMTP.
1040 o assuming the "Cc:" recipient's MTA (example.org) supports
1041 UTF8SMTP.
1042 The example SMTP envelope/message is shown in Figure 1. In this
1043 example, the "To:" recipient's session is the focus.
1045 MAIL FROM:
1046 ALT-ADDRESS=ASCII-local@example.com
1047 RCPT TO:
1048 ALT-ADDRESS=ASCII-remote1@example.net
1049 RCPT TO:
1050 -------------------------------------------------------------
1051 Message-Id: MESSAGE_ID
1052 Mime-Version: 1.0
1053 Content-Type: text/plain; charset="UTF-8"
1054 Content-Transfer-Encoding: 8bit
1055 Subject: NON-ASCII-SUBJECT
1056 From: DISPLAY-local >
1058 To: DISPLAY-remote1 >
1060 Cc: DISPLAY-remote2
1061 Date: DATE
1063 MAIL_BODY
1065 Figure 1: Original envelope/message (example 1)
1067 In this example, there are two SMTP recipients, one is "To:", the
1068 other is "Cc:". The SMTP downgrading treats To: session downgrading.
1069 Figure 2 shows SMTP downgraded example.
1071 MAIL FROM:
1072 RCPT TO:
1073 -------------------------------------------------------------
1074 Downgraded-Mail-From: =?UTF-8?Q?>?=
1076 Downgraded-Rcpt-To: =?UTF-8?Q?>?=
1078 Message-Id: MESSAGE_ID
1079 Mime-Version: 1.0
1080 Content-Type: text/plain; charset="UTF-8"
1081 Content-Transfer-Encoding: 8bit
1082 Subject: NON-ASCII-SUBJECT
1083 From: DISPLAY-local >
1085 To: DISPLAY-remote1 >
1087 Cc: DISPLAY-remote2
1088 Date: DATE
1090 MAIL_BODY
1092 Figure 2: SMTP Downgraded envelope/message (example 1)
1094 After SMTP downgrading, header fields downgrading is performed.
1095 Final downgraded message is shown in Figure 3. Return-Path header
1096 field will be added by the final destination MTA.
1098 Return-Path:
1099 Downgraded-Mail-From: =?UTF-8?Q?>?=
1101 Downgraded-Rcpt-To: =?UTF-8?Q?>?=
1103 Message-Id: MESSAGE_ID
1104 Mime-Version: 1.0
1105 Content-Type: text/plain; charset="UTF-8"
1106 Content-Transfer-Encoding: 8bit
1107 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
1108 From: =?UTF-8?Q?DISPLAY-local?=
1109 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?=
1111 To: =?UTF-8?Q?DISPLAY-remote1?=
1112 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
1113 =?UTF-8?Q?>?=
1114 Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
1115 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:;
1116 Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
1117 =?UTF-8?Q??=
1118 Date: DATE
1120 MAIL_BODY
1122 Figure 3: Downgraded message (example 1)
1124 A.2. Downgrading example 2
1126 In many cases, the sender wants to use non-ASCII address and the
1127 recipient is a traditional mail user. The SMTP server handing mail
1128 for the recipient and/or the recipient's MUA does not support
1129 UTF8SMTP extension. Consider a mail message where:
1130 o The sender address is "NON-ASCII-local@example.com" which is a
1131 non-ASCII address. Its ASCII alternative is
1132 "ASCII-local@example.com". It has a display-name "DISPLAY-local"
1133 which contains non-ASCII characters.
1134 o The "To:" address is "ASCII-remote1@example.net" which is ASCII
1135 only. It has a display-name "DISPLAY-remote1" which contains non-
1136 ASCII characters.
1137 o The "Subject:" header field is "NON-ASCII-SUBJECT" which contains
1138 non-ASCII characters.
1139 The second example envelope/message is shown in Figure 4.
1141 MAIL From:
1142 ALT-ADDRESS=ASCII-local@example.com
1143 RCPT TO:
1144 -------------------------------------------------------------
1145 Message-Id: MESSAGE_ID
1146 Mime-Version: 1.0
1147 Content-Type: text/plain; charset="UTF-8"
1148 Content-Transfer-Encoding: 8bit
1149 Subject: NON-ASCII-SUBJECT
1150 From: DISPLAY-local >
1152 To: DISPLAY-remote1
1153 Date: DATE
1155 MAIL_BODY
1157 Figure 4: Original message (example 2)
1159 In this example, SMTP session is downgradable. Figure 5 shows SMTP
1160 downgraded envelope/message.
1162 MAIL From:
1163 RCPT TO:
1164 -------------------------------------------------------------
1165 Downgraded-Mail-From: =?UTF-8?Q?>?=
1167 Message-Id: MESSAGE_ID
1168 Mime-Version: 1.0
1169 Content-Type: text/plain; charset="UTF-8"
1170 Content-Transfer-Encoding: 8bit
1171 Subject: NON-ASCII-SUBJECT
1172 From: DISPLAY-local >
1174 To: DISPLAY-remote1
1175 Date: DATE
1177 MAIL_BODY
1179 Figure 5: SMTP Downgraded envelope/message (example 2)
1181 After SMTP downgrading, header fields downgrading is performed. The
1182 downgraded example is shown in Figure 6.
1184 Return-Path:
1185 Downgraded-Mail-From: =?UTF-8?Q?>?=
1187 Message-Id: MESSAGE_ID
1188 Mime-Version: 1.0
1189 Content-Type: text/plain; charset="UTF-8"
1190 Content-Transfer-Encoding: 8bit
1191 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
1192 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?=
1194 From: =?UTF-8?Q?DISPLAY-local?=
1195 To: =?UTF-8?Q?DISPLAY-remote1?=
1196 Date: DATE
1198 MAIL_BODY
1200 Figure 6: Downgraded message (example 2)
1202 Authors' Addresses
1204 Kazunori Fujiwara (editor)
1205 Japan Registry Services Co., Ltd.
1206 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
1207 Chiyoda-ku, Tokyo 101-0065
1208 Japan
1210 Phone: +81 3 5215 8451
1211 Email: fujiwara@jprs.co.jp
1213 Yoshiro YONEYA (editor)
1214 Japan Registry Services Co., Ltd.
1215 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
1216 Chiyoda-ku, Tokyo 101-0065
1217 Japan
1219 Phone: +81 3 5215 8451
1220 Email: yone@jprs.co.jp