1
2
3
4
5
6
7Internet Engineering Task Force (IETF) T. Hansen, Ed.
8Request for Comments: 6533 AT&T Laboratories
9Obsoletes: 5337 C. Newman
10Updates: 3461, 3464, 3798, 6522 Oracle
11Category: Standards Track A. Melnikov
12ISSN: 2070-1721 Isode Ltd
13 February 2012
14
15
16 Internationalized Delivery Status and Disposition Notifications
17
18Abstract
19
20 Delivery status notifications (DSNs) are critical to the correct
21 operation of an email system. However, the existing Draft Standards
22 (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in
23 the machine-readable portions of the protocol. This specification
24 adds a new address type for international email addresses so an
25 original recipient address with non-ASCII characters can be correctly
26 preserved even after downgrading. This also provides updated content
27 return media types for delivery status notifications and message
28 disposition notifications to support use of the new address type.
29
30 This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522.
31
32Status of This Memo
33
34 This is an Internet Standards Track document.
35
36 This document is a product of the Internet Engineering Task Force
37 (IETF). It represents the consensus of the IETF community. It has
38 received public review and has been approved for publication by the
39 Internet Engineering Steering Group (IESG). Further information on
40 Internet Standards is available in Section 2 of RFC 5741.
41
42 Information about the current status of this document, any errata,
43 and how to provide feedback on it may be obtained at
44 http://www.rfc-editor.org/info/rfc6533.
45
46
47
48
49
50
51
52
53
54
55
56
57
58Hansen, et al. Standards Track [Page 1]
59
60RFC 6533 Internationalized DSN and MDNs February 2012
61
62
63Copyright Notice
64
65 Copyright (c) 2012 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
67
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
77
78Table of Contents
79
80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
81 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
82 3. UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . . 3
83 4. UTF-8 Delivery Status Notifications . . . . . . . . . . . . . 6
84 4.1. The message/global-delivery-status Media Type . . . . . . 6
85 4.2. The message/global Media Type . . . . . . . . . . . . . . 8
86 4.3. The message/global-headers Media Type . . . . . . . . . . 8
87 4.4. Using These Media Types with multipart/report . . . . . . 8
88 4.5. Additional Requirements on SMTP Servers . . . . . . . . . 9
89 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 9
90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
91 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 10
92 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 11
93 6.3. message/global-headers . . . . . . . . . . . . . . . . . . 11
94 6.4. message/global-delivery-status . . . . . . . . . . . . . . 12
95 6.5. message/global-disposition-notification . . . . . . . . . 14
96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
98 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
99 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
100 Appendix A. Changes since RFC 5337 . . . . . . . . . . . . . . . 18
101 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18
102
103
104
105
106
107
108
109
110
111
112
113
114Hansen, et al. Standards Track [Page 2]
115
116RFC 6533 Internationalized DSN and MDNs February 2012
117
118
1191. Introduction
120
121 When an email message is transmitted using the SMTPUTF8 [RFC6531]
122 extension and Internationalized Email Headers [RFC6532], it is
123 sometimes necessary to return that message or generate a Message
124 Disposition Notification (MDN) [RFC3798]. As a message sent to
125 multiple recipients can generate a status and disposition
126 notification for each recipient, it is helpful if a client can
127 correlate these notifications based on the recipient address it
128 provided; thus, preservation of the original recipient is important.
129 This specification describes how to preserve the original recipient
130 and updates the MDN and DSN formats to support the new address types.
131
132 NOTE: While this specification updates the experimental versions of
133 this protocol by removing certain constructs (e.g., the "<addr
134 <addr>>" address syntax is no longer permitted), the name of the
135 Address Type "UTF-8" and the media type names message/global,
136 message/global-delivery-status, and message/global-headers have not
137 been changed.
138
139 This specification is a revision of and replacement for [RFC5337].
140 Section 6 of [RFC6530] describes the change in approach between this
141 specification and the previous version.
142
1432. Conventions Used in This Document
144
145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
147 document are to be interpreted as described in [RFC2119].
148
149 The formal syntax uses the Augmented Backus-Naur Form (ABNF)
150 [RFC5234] notation including the core rules defined in Appendix B of
151 [RFC5234] and the UTF-8 syntax rules in Section 4 of [RFC3629].
152
1533. UTF-8 Address Type
154
155 "An Extensible Message Format for Delivery Status Notifications"
156 [RFC3464] defines the concept of an address type. The address format
157 introduced in "Internationalized Email Headers" [RFC6532] is a new
158 address type. The syntax for the new address type in the context of
159 status notifications is specified at the end of this section.
160
161 An SMTP [RFC5321] server that advertises both the SMTPUTF8 extension
162 [RFC6531] and the DSN extension [RFC3461] MUST accept a UTF-8 address
163 type in the ORCPT parameter including 8-bit UTF-8 characters. This
164 address type also includes a 7-bit encoding suitable for use in a
165 message/delivery-status body part or an ORCPT parameter sent to an
166 SMTP server that does not advertise SMTPUTF8.
167
168
169
170Hansen, et al. Standards Track [Page 3]
171
172RFC 6533 Internationalized DSN and MDNs February 2012
173
174
175 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext,
176 and utf-8-address. Only the first form is 7-bit safe (only uses
177 ASCII characters [ASCII]).
178
179 The utf-8-address form is only suitable for use in newly defined
180 protocols capable of native representation of 8-bit characters. That
181 is, the utf-8-address form MUST NOT be used:
182
183 1. in the ORCPT parameter when the SMTP server doesn't advertise
184 support for SMTPUTF8 (utf-8-addr-xtext MUST be used instead); or
185
186 2. if the SMTP server supports SMTPUTF8, but the address contains
187 ASCII characters not permitted in the ORCPT parameter (e.g., the
188 ORCPT parameter forbids unencoded SP and the '=' character),
189 (either utf-8-addr-unitext or utf-8-addr-xtext MUST be used
190 instead); or
191
192 3. in a 7-bit transport environment including a message/
193 delivery-status "Original-Recipient:" or "Final-Recipient:"
194 field, (utf-8-addr-xtext MUST be used instead).
195
196 The utf-8-address form MAY be used in the ORCPT parameter when the
197 SMTP server also advertises support for SMTPUTF8 and the address
198 doesn't contain any ASCII characters not permitted in the ORCPT
199 parameter. It SHOULD be used in a message/global-delivery-status
200 "Original-Recipient:" or "Final-Recipient:" DSN field, or in an
201 "Original-Recipient:" header field [RFC3798] if the message is a
202 SMTPUTF8 message.
203
204 In addition, the utf-8-addr-unitext form can be used anywhere where
205 the utf-8-address form is allowed.
206
207 When used in the ORCPT parameter, the UTF-8 address type requires
208 that ASCII CTLs, SP, '\', '+', and '=' be encoded using 'unitext'
209 encoding (see below). This is described by the utf-8-addr-xtext and
210 utf-8-addr-unitext forms in the ABNF below. The 'unitext' encoding
211 uses "\x{HEXPOINT}" syntax (EmbeddedUnicodeChar in the ABNF below)
212 for encoding any Unicode character outside of ASCII range, as well as
213 for encoding CTLs, SP, '\', '+', and '='. HEXPOINT is 2 to 6
214 hexadecimal digits. This encoding avoids the need to use the xtext
215 encoding described in [RFC3461], as any ASCII characters that need to
216 be escaped using xtext encoding never appear in any unitext-encoded
217 string. When sending data to a SMTPUTF8-capable server, native UTF-8
218 characters SHOULD be used instead of the EmbeddedUnicodeChar syntax
219 described below. When sending data to an SMTP server that does not
220 advertise SMTPUTF8, then the EmbeddedUnicodeChar syntax MUST be used
221 instead of UTF-8.
222
223
224
225
226Hansen, et al. Standards Track [Page 4]
227
228RFC 6533 Internationalized DSN and MDNs February 2012
229
230
231 When the ORCPT parameter is placed in a message/
232 global-delivery-status "Original-Recipient:" field, the
233 utf-8-addr-xtext form of the UTF-8 address type SHOULD be converted
234 to the utf-8-address form (see the ABNF below) by removing the
235 unitext encoding. However, if an address is labeled with the UTF-8
236 address type but does not conform to utf-8 syntax, then it MUST be
237 copied into the message/global-delivery-status field without
238 alteration.
239
240 The ability to encode characters with the EmbeddedUnicodeChar
241 encodings should be viewed as a transitional mechanism and avoided
242 when possible. It is hoped that as systems lacking support for
243 SMTPUTF8 become less common over time, these encodings can eventually
244 be phased out.
245
246 In the ABNF below, all productions not defined in this document are
247 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in
248 [RFC3464].
249
250 utf-8-type-addr = "utf-8;" utf-8-enc-addr 3464:513 ../dsn/dsn.go:248 ../dsn/parse.go:305
251
252 utf-8-address = Mailbox
253 ; Mailbox as defined in [RFC6531].
254
255 utf-8-enc-addr = utf-8-addr-xtext /
256 utf-8-addr-unitext /
257 utf-8-address
258
259 utf-8-addr-xtext = 1*(QCHAR / EmbeddedUnicodeChar) 4954:696 ../smtp/address.go:81 ../smtpserver/parse.go:513 todo future: ../smtpserver/server.go:1430
260 ; 7bit form of utf-8-addr-unitext.
261 ; Safe for use in the ORCPT [RFC3461]
262 ; parameter even when SMTPUTF8 SMTP
263 ; extension is not advertised.
264
265 utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar)
266 ; MUST follow utf-8-address ABNF when
267 ; dequoted.
268 ; Safe for using in the ORCPT [RFC3461]
269 ; parameter when SMTPUTF8 SMTP extension
270 ; is also advertised.
271
272 QCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e
273 ; ASCII printable characters except
274 ; CTLs, SP, '\', '+', '='.
275
276
277
278
279
280
281
282Hansen, et al. Standards Track [Page 5]
283
284RFC 6533 Internationalized DSN and MDNs February 2012
285
286
287 QUCHAR = QCHAR / UTF8-2 / UTF8-3 / UTF8-4
288 ; ASCII printable characters except
289 ; CTLs, SP, '\', '+' and '=', plus
290 ; other Unicode characters encoded in UTF-8
291
292 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}"
293 ; starts with "\x"
294
295 HEXPOINT = ( ( "0"/"1" ) %x31-39 ) / "10" / "20" /
296 "2B" / "3D" / "7F" / ; all xtext-specials
297 "5C" / (HEXDIG8 HEXDIG) / ; 2-digit forms
298 ( NZHEXDIG 2(HEXDIG) ) / ; 3-digit forms
299 ( NZDHEXDIG 3(HEXDIG) ) / ; 4-digit forms excluding
300 ( "D" %x30-37 2(HEXDIG) ) / ; ... surrogate
301 ( NZHEXDIG 4(HEXDIG) ) / ; 5-digit forms
302 ( "10" 4*HEXDIG ) ; 6-digit forms
303 ; represents either "\" or a Unicode code point outside
304 ; the ASCII repertoire
305
306 HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F"
307 ; HEXDIG excluding 0-7
308 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F"
309 ; HEXDIG excluding "0"
310 NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F"
311 ; HEXDIG excluding "0" and "D"
312
3134. UTF-8 Delivery Status Notifications
314
315 A traditional delivery status notification [RFC3464] comes in a
316 three-part multipart/report [RFC6522] container, where the first part
317 is human-readable text describing the error, the second part is a
318 7-bit-only message/delivery-status, and the optional third part is
319 used for content (message/rfc822) or header (text/rfc822-headers)
320 return. As the present standard DSN format does not permit the
321 return of undeliverable SMTPUTF8 messages, three new media types have
322 been defined. ([RFC5337] introduced experimental versions of these
323 media types.)
324
3254.1. The message/global-delivery-status Media Type ../dsn/dsn.go:204
326
327 The first type, message/global-delivery-status, has the syntax of
328 message/delivery-status with three modifications. First, the charset
329 for message/global-delivery-status is UTF-8, and thus any field MAY
330 contain UTF-8 characters when appropriate (see the ABNF below). In
331 particular, the "Diagnostic-Code:" field MAY contain UTF-8 as
332 described in SMTPUTF8 [RFC6531]; the "Diagnostic-Code:" field SHOULD
333 be in i-default language [RFC2277]. Second, systems generating a
334 message/global-delivery-status body part SHOULD use the utf-8-address
335
336
337
338Hansen, et al. Standards Track [Page 6]
339
340RFC 6533 Internationalized DSN and MDNs February 2012
341
342
343 form of the UTF-8 address type for all addresses containing
344 characters outside the ASCII repertoire. These systems SHOULD up-
345 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a
346 UTF-8 address type in the ORCPT parameter to the utf-8-address form
347 of a UTF-8 address type in the "Original-Recipient:" field. Third,
348 an optional field called "Localized-Diagnostic:" is added. Each
349 instance includes a language tag [RFC5646] and contains text in the
350 specified language. This is equivalent to the text part of the
351 "Diagnostic-Code:" field. All instances of "Localized-Diagnostic:"
352 MUST use different language tags. The ABNF for message/
353 global-delivery-status is specified below.
354
355 In the ABNF below, all productions not defined in this document are
356 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in
357 [RFC3464]. Note that <text-fixed> is the same as <text> from
358 [RFC5322], but without <obs-text>. If or when RFC 5322 is updated to
359 disallow <obs-text>, <text-fixed> should become just <text>. Also,
360 if or when RFC 5322 is updated to disallow control characters in
361 <text>, <text-fixed> should become a reference to that update
362 instead.
363
364 utf-8-delivery-status-content = per-message-fields
365 1*( CRLF utf-8-per-recipient-fields )
366 ; "per-message-fields" remains unchanged from the definition 3464:1522 ../dsn/parse.go:124
367 ; in RFC 3464, except for the "extension-field",
368 ; which is updated below.
369
370 utf-8-per-recipient-fields = 3464:1530 ../dsn/dsn.go:93 ../dsn/parse.go:197
371 [ original-recipient-field CRLF ]
372 final-recipient-field CRLF
373 action-field CRLF
374 status-field CRLF
375 [ remote-mta-field CRLF ]
376 [ diagnostic-code-field CRLF
377 *(localized-diagnostic-text-field CRLF) ]
378 [ last-attempt-date-field CRLF ]
379 [ final-log-id-field CRLF ]
380 [ will-retry-until-field CRLF ]
381 *( extension-field CRLF )
382 ; All fields except for "original-recipient-field",
383 ; "final-recipient-field", "diagnostic-code-field",
384 ; and "extension-field" remain unchanged from
385 ; the definition in RFC 3464.
386
387
388
389
390
391
392
393
394Hansen, et al. Standards Track [Page 7]
395
396RFC 6533 Internationalized DSN and MDNs February 2012
397
398
399 generic-address =/ utf-8-enc-addr
400 ; Only allowed with the "utf-8" address-type.
401 ; Updates Section 3.2.3 of RFC 3798.
402 ;
403 ; This indirectly updates "original-recipient-field"
404 ; and "final-recipient-field".
405
406 diagnostic-code-field =
407 "Diagnostic-Code" ":" diagnostic-type ";" *text-fixed
408
409 localized-diagnostic-text-field =
410 "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text
411 ; "Language-Tag" is a language tag as defined in [RFC5646].
412
413 extension-field =/ extension-field-name ":" *utf8-text
414 ; Updates Section 7 of RFC3798
415
416 text-fixed = %d1-9 / ; Any ASCII character except for NUL,
417 %d11 / ; CR, and LF.
418 %d12 / ; See note above about <text-fixed>
419 %d14-127
420
421 utf8-text = text-fixed / UTF8-non-ascii
422
423 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
424
4254.2. The message/global Media Type
426
427 The second type, used for returning the content, is message/global,
428 which is similar to message/rfc822, except it contains a message with
429 UTF-8 headers. This media type is described in [RFC6532].
430
4314.3. The message/global-headers Media Type ../dsn/dsn.go:319
432
433 The third type, used for returning the headers, is message/
434 global-headers and contains only the UTF-8 header fields of a message
435 (all lines prior to the first blank line in a SMTPUTF8 message).
436 Unlike message/global, this body part provides no difficulties for
437 the present infrastructure.
438
4394.4. Using These Media Types with multipart/report
440
441 Note that as far as a multipart/report [RFC6522] container is ../dsn/parse.go:30
442 concerned, message/global-delivery-status, message/global, and
443 message/global-headers MUST be treated as equivalent to message/
444 delivery-status, message/rfc822, and text/rfc822-headers. That is,
445
446
447
448
449
450Hansen, et al. Standards Track [Page 8]
451
452RFC 6533 Internationalized DSN and MDNs February 2012
453
454
455 implementations processing multipart/report MUST expect any
456 combinations of the 6 media types mentioned above inside a multipart/
457 report media type.
458
459 All three new types will typically use the "8bit" Content-Transfer-
460 Encoding. (In the event all content is 7-bit, the equivalent
461 traditional types for delivery status notifications MAY be used. For
462 example, if information in a message/global-delivery-status part can
463 be represented without any loss of information as message/
464 delivery-status, then the message/delivery-status body part may be
465 used.) Note that [RFC6532] relaxed a restriction from MIME [RFC2046]
466 regarding the use of Content-Transfer-Encoding in new "message"
467 subtypes. This specification explicitly allows the use of Content-
468 Transfer-Encoding in message/global-headers and message/
469 global-delivery-status. This is not believed to be problematic as
470 these new media types are intended primarily for use by newer systems
471 with full support for 8-bit MIME and UTF-8 headers.
472
4734.5. Additional Requirements on SMTP Servers
474
475 If an SMTP server that advertises both SMTPUTF8 and DSN needs to
476 return an undeliverable SMTPUTF8 message, then it has two choices for
477 encapsulating the SMTPUTF8 message when generating the corresponding
478 multipart/report:
479
480 If the return-path SMTP server does not support SMTPUTF8, then the ../dsn/dsn.go:326
481 undeliverable body part and headers MUST be encoded using a 7-bit
482 Content-Transfer-Encoding such as "base64" or "quoted-printable"
483 [RFC2045], as detailed in Section 4.
484
485 Otherwise, "8bit" Content-Transfer-Encoding can be used.
486
4875. UTF-8 Message Disposition Notifications
488
489 Message Disposition Notifications [RFC3798] have a similar design and
490 structure to DSNs. As a result, they use the same basic return
491 format. When generating an MDN for a UTF-8 header message, the third
492 part of the multipart/report contains the returned content (message/
493 global) or header (message/global-headers), same as for DSNs. The
494 second part of the multipart/report uses a new media type, message/
495 global-disposition-notification, which has the syntax of message/
496 disposition-notification with two modifications. First, the charset
497 for message/global-disposition-notification is UTF-8, and thus any
498 field MAY contain UTF-8 characters when appropriate (see the ABNF
499 below). (In particular, the failure-field, the error-field, and the
500 warning-field MAY contain UTF-8. These fields SHOULD be in i-default
501
502
503
504
505
506Hansen, et al. Standards Track [Page 9]
507
508RFC 6533 Internationalized DSN and MDNs February 2012
509
510
511 language [RFC2277].) Second, systems generating a message/
512 global-disposition-notification body part (typically a mail user
513 agent) SHOULD use the UTF-8 address type for all addresses containing
514 characters outside the ASCII repertoire.
515
516 The MDN specification also defines the "Original-Recipient:" header
517 field, which is added with a copy of the contents of ORCPT at
518 delivery time. When generating an "Original-Recipient:" header
519 field, a delivery agent writing a UTF-8 header message in native
520 format SHOULD convert the utf-8-addr-xtext or the utf-8-addr-unitext
521 form of a UTF-8 address type in the ORCPT parameter to the
522 corresponding utf-8-address form.
523
524 The MDN specification also defines the "Disposition-Notification-To:"
525 header field, which is an address header field and thus follows the
526 same 8-bit rules as other address header fields such as "From:" and
527 "To:" when used in a UTF-8 header message.
528
529 ; ABNF for "original-recipient-header", "original-recipient-field",
530 ; and "final-recipient-field" from RFC 3798 is implicitly updated
531 ; as they use the updated "generic-address" as defined in
532 ; Section 4 of this document.
533
534 failure-field = "Failure" ":" *utf8-text
535 ; "utf8-text" is defined in Section 4 of this document.
536
537 error-field = "Error" ":" *utf8-text
538 ; "utf8-text" is defined in Section 4 of this document.
539
540 warning-field = "Warning" ":" *utf8-text
541 ; "utf8-text" is defined in Section 4 of this document.
542
5436. IANA Considerations
544
545 This specification does not create any new IANA registries. However,
546 the following items have been registered as a result of this
547 document.
548
5496.1. UTF-8 Mail Address Type Registration
550
551 The mail address type registry was created by [RFC3464]. The
552 registration template response follows:
553
554 (a) The address-type name.
555
556 UTF-8
557
558
559
560
561
562Hansen, et al. Standards Track [Page 10]
563
564RFC 6533 Internationalized DSN and MDNs February 2012
565
566
567 (b) The syntax for mailbox addresses of this type, specified using
568 BNF, regular expressions, ASN.1, or other non-ambiguous language.
569
570 See Section 3.
571
572 (c) If addresses of this type are not composed entirely of graphic
573 characters from the ASCII repertoire, a specification for how
574 they are to be encoded as graphic ASCII characters in an
575 "Original-Recipient:" or "Final-Recipient:" DSN field.
576
577 This address type has 3 forms (as defined in Section 3):
578 utf-8-addr-xtext, utf-8-addr-unitext, and utf-8-address. Only
579 the first form is 7-bit safe.
580
5816.2. Update to 'smtp' Diagnostic Type Registration
582
583 The mail diagnostic type registry was created by [RFC3464] and
584 updated by [RFC5337]. This specification replaces [RFC5337]. The
585 registration for the 'smtp' diagnostic type has been updated to
586 reference RFC 6533 in addition to [RFC3464] and to remove the
587 reference to [RFC5337].
588
589 When the 'smtp' diagnostic type is used in the context of a message/ 3461:1342 ../dsn/dsn.go:290
590 delivery-status body part, it remains as presently defined. When the
591 'smtp' diagnostic type is used in the context of a message/
592 global-delivery-status body part, the codes remain the same, but the
593 text portion MAY contain UTF-8 characters.
594
5956.3. message/global-headers
596
597 Type name: message
598
599 Subtype name: global-headers
600
601 Required parameters: none
602
603 Optional parameters: none
604
605 Encoding considerations: This media type contains Internationalized ../dsn/dsn.go:320
606 Email Headers [RFC6532] with no message body. Whenever possible,
607 the 8-bit content transfer encoding SHOULD be used. When this
608 media type passes through a 7-bit-only SMTP infrastructure, it MAY
609 be encoded with the base64 or quoted-printable content transfer
610 encoding.
611
612 Security considerations: See Section 7.
613
614
615
616
617
618Hansen, et al. Standards Track [Page 11]
619
620RFC 6533 Internationalized DSN and MDNs February 2012
621
622
623 Interoperability considerations: It is important that this media
624 type is not converted to a charset other than UTF-8. As a result,
625 implementations MUST NOT include a charset parameter with this ../dsn/dsn.go:321
626 media type. Although it might be possible to down-convert this
627 media type to the text/rfc822-header media type, such conversion
628 is discouraged as it loses information.
629
630 Published specification: RFC 6533
631
632 Applications that use this media type: SMTPUTF8 servers and email
633 clients that support multipart/report generation or parsing.
634
635 Additional information:
636
637 Magic number(s): none
638
639 File extension(s): In the event this is saved to a file, the
640 extension ".u8hdr" is suggested.
641
642 Macintosh file type code(s): The 'TEXT' type code is suggested as
643 files of this type are typically used for diagnostic purposes
644 and suitable for analysis in a UTF-8-aware text editor. A
645 uniform type identifier (UTI) of
646 "public.utf8-email-message-header" is suggested. This type
647 conforms to "public.utf8-plain-text" and "public.plain-text".
648
649 Person & email address to contact for further information: See the
650 Authors' Addresses section of this document.
651
652 Intended usage: COMMON
653
654 Restrictions on usage: This media type contains textual data in the
655 UTF-8 charset. It typically contains octets with the 8th bit set.
656 As a result, a transfer encoding is required when a 7-bit
657 transport is used.
658
659 Author: See the Authors' Addresses section of this document.
660
661 Change controller: IETF Standards Process
662
6636.4. message/global-delivery-status
664
665 Type name: message
666
667 Subtype name: global-delivery-status
668
669 Required parameters: none
670
671
672
673
674Hansen, et al. Standards Track [Page 12]
675
676RFC 6533 Internationalized DSN and MDNs February 2012
677
678
679 Optional parameters: none
680
681 Encoding considerations: This media type contains delivery status
682 notification attributes in the UTF-8 charset. The 8-bit content
683 transfer encoding MUST be used with this content-type, unless it
684 is sent over a 7-bit transport environment, in which case quoted-
685 printable or base64 may be necessary.
686
687 Security considerations: See Section 7
688
689 Interoperability considerations: This media type provides
690 functionality similar to the message/delivery-status content-type
691 for email message return information. Clients of the previous
692 format will need to be upgraded to interpret the new format;
693 however, the new media type makes it simple to identify the
694 difference.
695
696 Published specification: RFC 6533
697
698 Applications that use this media type: SMTP servers and email
699 clients that support delivery status notification generation or
700 parsing.
701
702 Additional information:
703
704 Magic number(s): none
705
706 File extension(s): The extension ".u8dsn" is suggested.
707
708 Macintosh file type code(s): A uniform type identifier (UTI) of
709 "public.utf8-email-message-delivery-status" is suggested. This
710 type conforms to "public.utf8-plain-text".
711
712 Person & email address to contact for further information: See the
713 Authors' Addresses section of this document.
714
715 Intended usage: COMMON
716
717 Restrictions on usage: This is expected to be the second part of a
718 multipart/report.
719
720 Author: See the Authors' Addresses section of this document.
721
722 Change controller: IETF Standards Process
723
724
725
726
727
728
729
730Hansen, et al. Standards Track [Page 13]
731
732RFC 6533 Internationalized DSN and MDNs February 2012
733
734
7356.5. message/global-disposition-notification
736
737 Type name: message
738
739 Subtype name: global-disposition-notification
740
741 Required parameters: none
742
743 Optional parameters: none
744
745 Encoding considerations: This media type contains disposition
746 notification attributes in the UTF-8 charset. The 8-bit content
747 transfer encoding MUST be used with this content-type, unless it
748 is sent over a 7-bit transport environment, in which case quoted-
749 printable or base64 may be necessary.
750
751 Security considerations: See Section 7.
752
753 Interoperability considerations: This media type provides
754 functionality similar to the message/disposition-notification
755 content-type for email message disposition information. Clients
756 of the previous format will need to be upgraded to interpret the
757 new format; however, the new media type makes it simple to
758 identify the difference.
759
760 Published specification: RFC 6533
761
762 Applications that use this media type: Email clients or servers that
763 support message disposition notification generation or parsing.
764
765 Additional information:
766
767 Magic number(s): none
768
769 File extension(s): The extension ".u8mdn" is suggested.
770
771 Macintosh file type code(s): A uniform type identifier (UTI) of
772 "public.utf8-email-message-disposition-notification" is
773 suggested. This type conforms to "public.utf8-plain-text".
774
775 Person & email address to contact for further information: See the
776 Authors' Addresses section of this document.
777
778 Intended usage: COMMON
779
780 Restrictions on usage: This is expected to be the second part of a
781 multipart/report.
782
783
784
785
786Hansen, et al. Standards Track [Page 14]
787
788RFC 6533 Internationalized DSN and MDNs February 2012
789
790
791 Author: See the Authors' Addresses section of this document.
792
793 Change controller: IETF Standards Process
794
7957. Security Considerations
796
797 Automated use of report types without authentication presents several
798 security issues. Forging negative reports presents the opportunity
799 for denial-of-service attacks when the reports are used for automated
800 maintenance of directories or mailing lists. Forging positive
801 reports may cause the sender to incorrectly believe a message was
802 delivered when it was not.
803
804 Malicious users can generate report structures designed to trigger
805 coding flaws in report parsers. Report parsers need to use secure
806 coding techniques to avoid the risk of buffer overflow or denial-of-
807 service attacks against parser coding mistakes. Code reviews of such
808 parsers are also recommended.
809
810 Malicious users of the email system regularly send messages with
811 forged envelope return paths, and these messages trigger delivery
812 status reports that result in a large amount of unwanted traffic on
813 the Internet. Many users choose to ignore delivery status
814 notifications because they are usually the result of "blowback" from
815 forged messages and thus never notice when messages they sent go
816 undelivered. As a result, support for correlation of delivery status
817 and message disposition notification messages with sent messages has
818 become a critical feature of mail clients and possibly mail stores,
819 if the email infrastructure is to remain reliable. In the short
820 term, simply correlating Message-IDs may be sufficient to distinguish
821 true status notifications from those resulting from forged originator
822 addresses. But in the longer term, including cryptographic signature
823 material that can securely associate the status notification with the
824 original message is advisable.
825
826 As this specification permits UTF-8 in additional fields, the
827 security considerations of UTF-8 [RFC3629] apply.
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842Hansen, et al. Standards Track [Page 15]
843
844RFC 6533 Internationalized DSN and MDNs February 2012
845
846
8478. References
848
8498.1. Normative References
850
851 [ASCII] American National Standards Institute (formerly United
852 States of America Standards Institute), "USA Code for
853 Information Interchange", ANSI X3.4-1968, 1968.
854
855 ANSI X3.4-1968 has been replaced by newer versions with
856 slight modifications, but the 1968 version remains
857 definitive for the Internet.
858
859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
860 Requirement Levels", BCP 14, RFC 2119, March 1997.
861
862 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
863 Languages", BCP 18, RFC 2277, January 1998.
864
865 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
866 Extension for Delivery Status Notifications (DSNs)",
867 RFC 3461, January 2003.
868
869 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
870 for Delivery Status Notifications", RFC 3464,
871 January 2003.
872
873 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
874 10646", STD 63, RFC 3629, November 2003.
875
876 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
877 Notification", RFC 3798, May 2004.
878
879 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
880 Specifications: ABNF", STD 68, RFC 5234, January 2008.
881
882 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
883 October 2008.
884
885 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
886 October 2008.
887
888 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
889 Languages", BCP 47, RFC 5646, September 2009.
890
891 [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for
892 the Reporting of Mail System Administrative Messages", STD
893 73, RFC 6522, January 2012.
894
895
896
897
898Hansen, et al. Standards Track [Page 16]
899
900RFC 6533 Internationalized DSN and MDNs February 2012
901
902
903 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
904 Internationalized Email", RFC 6530, February 2012.
905
906 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized
907 Email", RFC 6531, February 2012.
908
909 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
910 Email Headers", RFC 6532, February 2012.
911
9128.2. Informative References
913
914 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
915 Extensions (MIME) Part One: Format of Internet Message
916 Bodies", RFC 2045, November 1996.
917
918 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
919 Extensions (MIME) Part Two: Media Types", RFC 2046,
920 November 1996.
921
922 [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery
923 Status and Disposition Notifications", RFC 5337,
924 September 2008.
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954Hansen, et al. Standards Track [Page 17]
955
956RFC 6533 Internationalized DSN and MDNs February 2012
957
958
959Appendix A. Changes since RFC 5337
960
961 Changes were made to move from Experimental to Standards Track. The
962 most significant was the removal of an embedded alternative ASCII
963 address within a utf-8-address, and the reflections of the ABNF
964 changes in [RFC6531].
965
966 Fixed description of utf-8-addr-xtext and utf-8-addr-unitext.
967
968 References to Downgrade and uMailbox removed/fixed.
969
970 ABNF changes and fixed errata submitted by Alfred Hoenes.
971
972 Minor changes to MIME type references.
973
974 Other minor corrections.
975
976Appendix B. Acknowledgements
977
978 Many thanks for input provided by Pete Resnick, James Galvin, Ned
979 Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, Alfred
980 Hoenes, Kazunori Fujiwara, and members of the EAI working group to
981 help solidify this proposal.
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010Hansen, et al. Standards Track [Page 18]
1011
1012RFC 6533 Internationalized DSN and MDNs February 2012
1013
1014
1015Authors' Addresses
1016
1017 Tony Hansen (editor)
1018 AT&T Laboratories
1019 200 Laurel Ave.
1020 Middletown, NJ 07748
1021 US
1022
1023 EMail: tony+eaidsn@maillennium.att.com
1024
1025
1026 Chris Newman
1027 Oracle
1028 800 Royal Oaks
1029 Monrovia, CA 91016-6347
1030 US
1031
1032 EMail: chris.newman@oracle.com
1033
1034
1035 Alexey Melnikov
1036 Isode Ltd
1037 5 Castle Business Village
1038 36 Station Road
1039 Hampton, Middlesex TW12 2BX
1040 UK
1041
1042 EMail: Alexey.Melnikov@isode.com
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066Hansen, et al. Standards Track [Page 19]
1067
1068