7Network Working Group C. Newman
8Request for Comments: 5337 Sun Microsystems
9Updates: 3461, 3464, 3798 A. Melnikov, Ed.
10Category: Experimental Isode Ltd
14 Internationalized Delivery Status and Disposition Notifications
18 This memo defines an Experimental Protocol for the Internet
19 community. It does not specify an Internet standard of any kind.
20 Discussion and suggestions for improvement are requested.
21 Distribution of this memo is unlimited.
25 Delivery status notifications (DSNs) are critical to the correct
26 operation of an email system. However, the existing Draft Standards
27 (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text
28 in the machine-readable portions of the protocol. This specification
29 adds a new address type for international email addresses so an
30 original recipient address with non-US-ASCII characters can be
31 correctly preserved even after downgrading. This also provides
32 updated content return media types for delivery status notifications
33 and message disposition notifications to support use of the new
36 This document experimentally extends RFC 3461, RFC 3464, and RFC
58Newman & Melnikov Experimental [Page 1]
60RFC 5337 Internationalized DSN and MDNs September 2008
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
67 3. UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . . 3
68 4. UTF-8 Delivery Status Notifications . . . . . . . . . . . . . 6
69 4.1. Additional Requirements on SMTP Servers . . . . . . . . . 8
70 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 9
71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
72 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 10
73 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 11
74 6.3. message/global-headers . . . . . . . . . . . . . . . . . . 11
75 6.4. message/global-delivery-status . . . . . . . . . . . . . . 12
76 6.5. message/global-disposition-notification . . . . . . . . . 13
77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
80 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17
114Newman & Melnikov Experimental [Page 2]
116RFC 5337 Internationalized DSN and MDNs September 2008
121 When an email message is transmitted using the UTF8SMTP [RFC5336]
122 extension and Internationalized Email Headers [RFC5335], 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.
1322. Conventions Used in This Document
134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
136 document are to be interpreted as described in [RFC2119].
138 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234]
139 notation including the core rules defined in Appendix B of RFC 5234
140 [RFC5234] and the UTF-8 syntax rules in Section 4 of [RFC3629].
144 An Extensible Message Format for Delivery Status Notifications
145 [RFC3464] defines the concept of an address type. The address format
146 introduced in Internationalized Email Headers [RFC5335] is a new
147 address type. The syntax for the new address type in the context of
148 status notifications is specified at the end of this section.
150 An SMTP [RFC2821] server that advertises both the UTF8SMTP extension
151 [RFC5336] and the DSN extension [RFC3461] MUST accept a UTF-8 address
152 type in the ORCPT parameter including 8-bit UTF-8 characters. This
153 address type also includes a 7-bit encoding suitable for use in a
154 message/delivery-status body part or an ORCPT parameter sent to an
155 SMTP server that does not advertise UTF8SMTP.
157 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext,
158 and utf-8-address. The first 2 forms are 7-bit safe.
160 The utf-8-address form is only suitable for use in newly defined
161 protocols capable of native representation of 8-bit characters. That
162 is, the utf-8-address form MUST NOT be used in the ORCPT parameter
163 when the SMTP server doesn't advertise support for UTF8SMTP or the
164 SMTP server supports UTF8SMTP, but the address contains US-ASCII
165 characters not permitted in the ORCPT parameter (e.g., the ORCPT
166 parameter forbids unencoded SP and the = character), or in a 7-bit
170Newman & Melnikov Experimental [Page 3]
172RFC 5337 Internationalized DSN and MDNs September 2008
175 transport environment including a message/delivery-status Original-
176 Recipient or Final-Recipient field. In the former case, the utf-8-
177 addr-xtext form (see below) MUST be used instead; in the latter case,
178 the utf-8-addr-unitext form MUST be used. The utf-8-address form MAY
179 be used in the ORCPT parameter when the SMTP server also advertises
180 support for UTF8SMTP and the address doesn't contain any US-ASCII
181 characters not permitted in the ORCPT parameter. It SHOULD be used
182 in a message/global-delivery-status Original-Recipient or Final-
183 Recipient DSN field, or in an Original-Recipient header field
184 [RFC3798] if the message is a UTF8SMTP message.
186 In addition, the utf-8-addr-unitext form can be used anywhere where
187 the utf-8-address form is allowed.
189 When using in the ORCPT parameter, the UTF-8 address type requires
190 that US-ASCII CTLs, SP, \, +, and = be encoded using xtext encoding
191 as described in [RFC3461]. This is described by the utf-8-addr-xtext
192 form in the ABNF below. Unicode characters MAY be included in a
193 UTF-8 address type using a "\x{HEXPOINT}" syntax
194 (EmbeddedUnicodeChar), where HEXPOINT is 2 to 6 hexadecimal digits.
195 When sending data to a UTF8SMTP-capable server, native UTF-8
196 characters SHOULD be used instead of the EmbeddedUnicodeChar syntax
197 described in details below. When sending data to an SMTP server that
198 does not advertise UTF8SMTP, then the EmbeddedUnicodeChar syntax MUST
199 be used instead of UTF-8.
201 When the ORCPT parameter is placed in a message/
202 global-delivery-status Original-Recipient field, the utf-8-addr-xtext
203 form of the UTF-8 address type SHOULD be converted to the utf-8-
204 address form (see the ABNF below) by removing all xtext encoding
205 first (which will result in the utf-8-addr-unitext form), followed by
206 removal of the unitext encoding. However, if an address is labeled
207 with the UTF-8 address type but does not conform to utf-8 syntax,
208 then it MUST be copied into the message/global-delivery-status field
211 The ability to encode characters with the EmbeddedUnicodeChar
212 encodings should be viewed as a transitional mechanism. It is hoped
213 that as systems lacking support for UTF8SMTP become less common over
214 time, these encodings can eventually be phased out.
216 In the ABNF below, all productions not defined in this document are
217 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in
226Newman & Melnikov Experimental [Page 4]
228RFC 5337 Internationalized DSN and MDNs September 2008
231 utf-8-type-addr = "utf-8;" utf-8-enc-addr
233 utf-8-address = uMailbox [ 1*WSP "<" Mailbox ">" ]
234 ; uMailbox is defined in [RFC5336].
235 ; Mailbox is defined in [RFC2821].
237 utf-8-enc-addr = utf-8-addr-xtext /
241 utf-8-addr-xtext = xtext
242 ; xtext is defined in [RFC3461].
243 ; When xtext encoding is removed,
244 ; the syntax MUST conform to
245 ; utf-8-addr-unitext.
247 utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar)
248 ; MUST follow utf-8-address ABNF when
251 QUCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e /
252 UTF8-2 / UTF8-3 / UTF8-4
253 ; US-ASCII printable characters except
254 ; CTLs, SP, '\', '+' and '=', plus
255 ; other Unicode characters in UTF-8
257 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}"
260 HEXPOINT = "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms
261 ( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms
262 ( NZDHEXDIG 3(HEXDIG) ) /
263 ( "D" %x30-37 2(HEXDIG) ) /
264 ; 4 digit forms excluding surrogate
265 ( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms
266 ( "10" 4*HEXDIG ) ; 6 digit forms
267 ; represents either "\" or a Unicode code point outside the
268 ; US-ASCII repertoire
270 HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F"
271 ; HEXDIG excluding 0-7
272 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F"
273 ; HEXDIG excluding "0"
274 NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F"
275 ; HEXDIG excluding "0" and "D"
282Newman & Melnikov Experimental [Page 5]
284RFC 5337 Internationalized DSN and MDNs September 2008
2874. UTF-8 Delivery Status Notifications
289 A traditional delivery status notification [RFC3464] comes in a
290 three-part multipart/report [RFC3462] container, where the first part
291 is human-readable text describing the error, the second part is a
292 7-bit-only message/delivery-status, and the optional third part is
293 used for content (message/rfc822) or header (text/rfc822-headers)
294 return. As the present DSN format does not permit returning of
295 undeliverable UTF8SMTP messages, three new media types are needed.
297 The first type, message/global-delivery-status, has the syntax of
298 message/delivery-status with three modifications. First, the charset
299 for message/global-delivery-status is UTF-8, and thus any field MAY
300 contain UTF-8 characters when appropriate (see the ABNF below). In
301 particular, the Diagnostic-Code field MAY contain UTF-8 as described
302 in UTF8SMTP [RFC5336]; the Diagnostic-Code field SHOULD be in
303 i-default language [DEFAULTLANG]. Second, systems generating a
304 message/global-delivery-status body part SHOULD use the utf-8-address
305 form of the UTF-8 address type for all addresses containing
306 characters outside the US-ASCII repertoire. These systems SHOULD up-
307 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a
308 UTF-8 address type in the ORCPT parameter to the utf-8-address form
309 of a UTF-8 address type in the Original-Recipient field. Third, a
310 new optional field called Localized-Diagnostic is added. Each
311 instance includes a language tag [LANGTAGS] and contains text in the
312 specified language. This is equivalent to the text part of the
313 Diagnostic-Code field. All instances of Localized-Diagnostic MUST
314 use different language tags. The ABNF for message/
315 global-delivery-status is specified below.
317 In the ABNF below, all productions not defined in this document are
318 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in
321 utf-8-delivery-status-content = per-message-fields
322 1*( CRLF utf-8-per-recipient-fields )
323 ; "per-message-fields" remains unchanged from the definition
324 ; in RFC 3464, except for the "extension-field"
325 ; which is updated below.
338Newman & Melnikov Experimental [Page 6]
340RFC 5337 Internationalized DSN and MDNs September 2008
343 utf-8-per-recipient-fields =
344 [ original-recipient-field CRLF ]
345 final-recipient-field CRLF
348 [ remote-mta-field CRLF ]
349 [ diagnostic-code-field CRLF
350 *(localized-diagnostic-text-field CRLF) ]
351 [ last-attempt-date-field CRLF ]
352 [ will-retry-until-field CRLF ]
353 *( extension-field CRLF )
354 ; All fields except for "original-recipient-field",
355 ; "final-recipient-field", "diagnostic-code-field"
356 ; and "extension-field" remain unchanged from
357 ; the definition in RFC 3464.
359 generic-address =/ utf-8-enc-addr
360 ; Only allowed with the "utf-8" address-type.
362 ; This indirectly updates "original-recipient-field"
363 ; and "final-recipient-field"
365 diagnostic-code-field =
366 "Diagnostic-Code" ":" diagnostic-type ";" *text-fixed
368 localized-diagnostic-text-field =
369 "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text
370 ; "Language-Tag" is a language tag as defined in [LANGTAGS].
372 extension-field =/ extension-field-name ":" *utf8-text
374 text-fixed = %d1-9 / ; Any Unicode character except for NUL,
375 %d11 / ; CR and LF, encoded in UTF-8
378 ; Same as <text> from [RFC2822], but without <obs-text>.
379 ; If/when RFC 2822 is updated to disallow <obs-text>,
380 ; this should become just <text>
381 ; Also, if/when RFC 2822 is updated to disallow control characters
382 ; this should become a reference to RFC 2822upd instead.
384 utf8-text = text-fixed / UTF8-non-ascii
386 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
394Newman & Melnikov Experimental [Page 7]
396RFC 5337 Internationalized DSN and MDNs September 2008
399 The second type, used for returning the content, is message/global
400 which is similar to message/rfc822, except it contains a message with
401 UTF-8 headers. This media type is described in [RFC5335].
403 The third type, used for returning the headers, is message/
404 global-headers and contains only the UTF-8 header fields of a message
405 (all lines prior to the first blank line in a UTF8SMTP message).
406 Unlike message/global, this body part provides no difficulties for
407 the present infrastructure.
409 Note that as far as multipart/report [RFC3462] container is
410 concerned, message/global-delivery-status, message/global, and
411 message/global-headers MUST be treated as equivalent to message/
412 delivery-status, message/rfc822, and text/rfc822-headers. That is,
413 implementations processing multipart/report MUST expect any
414 combinations of the 6 MIME types mentioned above inside a multipart/
417 All three new types will typically use the "8bit" Content-Transfer-
418 Encoding. (In the event all content is 7-bit, the equivalent
419 traditional types for delivery status notifications MAY be used. For
420 example, if information in message/global-delivery-status part can be
421 represented without any loss of information as message/
422 delivery-status, then the message/delivery-status body part may be
423 used.) Note that [RFC5335] relaxed restriction from MIME [RFC2046]
424 regarding use of Content-Transfer-Encoding in new "message" subtypes.
425 This specification explicitly allows use of Content-Transfer-Encoding
426 in message/global-headers and message/global-delivery-status. This
427 is not believed to be problematic as these new MIME types are
428 intended primarily for use by newer systems with full support for
429 8-bit MIME and UTF-8 headers.
4314.1. Additional Requirements on SMTP Servers
433 If an SMTP server that advertises both UTF8SMTP and DSN needs to
434 return an undeliverable UTF8SMTP message, then it MUST NOT downgrade
435 [DOWNGRADE] the UTF8SMTP message when generating the corresponding
436 multipart/report. If the return path SMTP server does not support
437 UTF8SMTP, then the undeliverable body part and headers MUST be
438 encoded using a 7-bit Content-Transfer-Encoding such as "base64" or
439 "quoted-printable" [RFC2045], as detailed in Section 4. Otherwise,
440 "8bit" Content-Transfer-Encoding can be used.
450Newman & Melnikov Experimental [Page 8]
452RFC 5337 Internationalized DSN and MDNs September 2008
4555. UTF-8 Message Disposition Notifications
457 Message Disposition Notifications [RFC3798] have a similar design and
458 structure to DSNs. As a result, they use the same basic return
459 format. When generating an MDN for a UTF-8 header message, the third
460 part of the multipart/report contains the returned content (message/
461 global) or header (message/global-headers), same as for DSNs. The
462 second part of the multipart/report uses a new media type, message/
463 global-disposition-notification, which has the syntax of message/
464 disposition-notification with two modifications. First, the charset
465 for message/global-disposition-notification is UTF-8, and thus any
466 field MAY contain UTF-8 characters when appropriate (see the ABNF
467 below). (In particular, the failure-field, the error-field, and the
468 warning-field MAY contain UTF-8. These fields SHOULD be in i-default
469 language [DEFAULTLANG].) Second, systems generating a message/
470 global-disposition-notification body part (typically a mail user
471 agent) SHOULD use the UTF-8 address type for all addresses containing
472 characters outside the US-ASCII repertoire.
474 The MDN specification also defines the Original-Recipient header
475 field, which is added with a copy of the contents of ORCPT at
476 delivery time. When generating an Original-Recipient header field, a
477 delivery agent writing a UTF-8 header message in native format SHOULD
478 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a
479 UTF-8 address type in the ORCPT parameter to the corresponding utf-8-
482 The MDN specification also defines the Disposition-Notification-To
483 header, which is an address header and thus follows the same 8-bit
484 rules as other address headers such as "From" and "To" when used in a
485 UTF-8 header message.
487 ; ABNF for "original-recipient-header", "original-recipient-field",
488 ; and "final-recipient-field" from RFC 3798 is implicitly updated
489 ; as they use the updated "generic-address" as defined in
490 ; Section 4 of this document.
492 failure-field = "Failure" ":" *utf8-text
493 ; "utf8-text" is defined in Section 4 of this document.
495 error-field = "Error" ":" *utf8-text
496 ; "utf8-text" is defined in Section 4 of this document.
498 warning-field = "Warning" ":" *utf8-text
499 ; "utf8-text" is defined in Section 4 of this document.
506Newman & Melnikov Experimental [Page 9]
508RFC 5337 Internationalized DSN and MDNs September 2008
5116. IANA Considerations
513 This specification does not create any new IANA registries. However,
514 the following items have been registered as a result of this
5176.1. UTF-8 Mail Address Type Registration
519 The mail address type registry was created by RFC 3464. The
520 registration template response follows:
522 (a) The proposed address-type name.
526 (b) The syntax for mailbox addresses of this type, specified using
527 BNF, regular expressions, ASN.1, or other non-ambiguous language.
531 (c) If addresses of this type are not composed entirely of graphic
532 characters from the US-ASCII repertoire, a specification for how
533 they are to be encoded as graphic US-ASCII characters in a DSN
534 Original-Recipient or Final-Recipient DSN field.
536 This address type has 3 forms (as defined in Section 3): utf-8-
537 addr-xtext, utf-8-addr-unitext, and utf-8-address. The first 2
538 forms are 7-bit safe.
540 The utf-8-address form MUST NOT be used
542 1. in the ORCPT parameter when the SMTP server doesn't advertise
543 support for UTF8SMTP;
545 2. or the SMTP server supports UTF8SMTP, but the address contains
546 US-ASCII characters not permitted in the ORCPT parameter (e.g.,
547 the ORCPT parameter forbids SP and the = characters);
549 3. or in a 7-bit transport environment including a message/
550 delivery-status Original-Recipient or Final-Recipient field.
552 The utf-8-addr-xtext form MUST be used instead in the first case; the
553 utf-8-addr-unitext form MUST be used in the other two cases. The
554 utf-8-address form MAY be used in the ORCPT parameter when the SMTP
555 server also advertises support for UTF8SMTP and the address doesn't
556 contain any US-ASCII characters not permitted in the ORCPT parameter;
562Newman & Melnikov Experimental [Page 10]
564RFC 5337 Internationalized DSN and MDNs September 2008
567 in a message/global-delivery-status Original-Recipient or Final-
568 Recipient DSN field; or in an Original-Recipient header field
569 [RFC3798] if the message is a UTF8SMTP message.
571 In addition, the utf-8-addr-unitext form can be used anywhere where
572 the utf-8-address form is allowed.
5746.2. Update to 'smtp' Diagnostic Type Registration
576 The mail diagnostic type registry was created by RFC 3464. The
577 registration for the 'smtp' diagnostic type should be updated to
578 reference RFC 5337 in addition to RFC 3464.
580 When the 'smtp' diagnostic type is used in the context of a message/
581 delivery-status body part, it remains as presently defined. When the
582 'smtp' diagnostic type is used in the context of a message/
583 global-delivery-status body part, the codes remain the same, but the
584 text portion MAY contain UTF-8 characters.
5866.3. message/global-headers
590 Subtype name: global-headers
592 Required parameters: none
594 Optional parameters: none
596 Encoding considerations: This media type contains Internationalized
597 Email Headers [RFC5335] with no message body. Whenever possible,
598 the 8-bit content transfer encoding SHOULD be used. When this
599 media type passes through a 7-bit-only SMTP infrastructure it MAY
600 be encoded with the base64 or quoted-printable content transfer
603 Security considerations: See Section 7.
605 Interoperability considerations: It is important that this media
606 type is not converted to a charset other than UTF-8. As a result,
607 implementations MUST NOT include a charset parameter with this
608 media type. Although it might be possible to downconvert this
609 media type to the text/rfc822-header media type, such conversion
610 is discouraged as it loses information.
612 Published specification: RFC 5337
618Newman & Melnikov Experimental [Page 11]
620RFC 5337 Internationalized DSN and MDNs September 2008
623 Applications that use this media type: UTF8SMTP servers and email
624 clients that support multipart/report generation or parsing.
626 Additional information:
628 Magic number(s): none
630 File extension(s): In the event this is saved to a file, the
631 extension ".u8hdr" is suggested.
633 Macintosh file type code(s): The 'TEXT' type code is suggested as
634 files of this type are typically used for diagnostic purposes and
635 suitable for analysis in a UTF-8 aware text editor. A uniform
636 type identifier (UTI) of "public.utf8-email-message-header" is
637 suggested. This type conforms to "public.utf8-plain-text" and
640 Person & email address to contact for further information: See the
641 Authors' Addresses section of this document.
643 Intended usage: COMMON
645 Restrictions on usage: This media type contains textual data in the
646 UTF-8 charset. It typically contains octets with the 8th bit set.
647 As a result, a transfer encoding is required when a 7-bit
650 Author: See the Authors' Addresses section of this document.
652 Change controller: IETF Standards Process
6546.4. message/global-delivery-status
658 Subtype name: global-delivery-status
660 Required parameters: none
662 Optional parameters: none
664 Encoding considerations: This media type contains delivery status
665 notification attributes in the UTF-8 charset. The 8-bit content
666 transfer encoding MUST be used with this content-type, unless it
667 is sent over a 7-bit transport environment in which case quoted-
668 printable or base64 may be necessary.
670 Security considerations: See Section 7
674Newman & Melnikov Experimental [Page 12]
676RFC 5337 Internationalized DSN and MDNs September 2008
679 Interoperability considerations: This media type provides
680 functionality similar to the message/delivery-status content-type
681 for email message return information. Clients of the previous
682 format will need to be upgraded to interpret the new format;
683 however, the new media type makes it simple to identify the
686 Published specification: RFC 5337
688 Applications that use this media type: SMTP servers and email
689 clients that support delivery status notification generation or
692 Additional information:
694 Magic number(s): none
696 File extension(s): The extension ".u8dsn" is suggested.
698 Macintosh file type code(s): A uniform type identifier (UTI) of
699 "public.utf8-email-message-delivery-status" is suggested. This
700 type conforms to "public.utf8-plain-text".
702 Person & email address to contact for further information: See the
703 Authors' Addresses section of this document.
705 Intended usage: COMMON
707 Restrictions on usage: This is expected to be the second part of a
710 Author: See the Authors' Addresses section of this document.
712 Change controller: IETF Standards Process
7146.5. message/global-disposition-notification
718 Subtype name: global-disposition-notification
720 Required parameters: none
722 Optional parameters: none
730Newman & Melnikov Experimental [Page 13]
732RFC 5337 Internationalized DSN and MDNs September 2008
735 Encoding considerations: This media type contains disposition
736 notification attributes in the UTF-8 charset. The 8-bit content
737 transfer encoding MUST be used with this content-type, unless it
738 is sent over a 7-bit transport environment in which case quoted-
739 printable or base64 may be necessary.
741 Security considerations: See Section 7.
743 Interoperability considerations: This media type provides
744 functionality similar to the message/disposition-notification
745 content-type for email message disposition information. Clients
746 of the previous format will need to be upgraded to interpret the
747 new format; however, the new media type makes it simple to
748 identify the difference.
750 Published specification: RFC 5337
752 Applications that use this media type: Email clients or servers that
753 support message disposition notification generation or parsing.
755 Additional information:
757 Magic number(s): none
759 File extension(s): The extension ".u8mdn" is suggested.
761 Macintosh file type code(s): A uniform type identifier (UTI) of
762 "public.utf8-email-message-disposition-notification" is suggested.
763 This type conforms to "public.utf8-plain-text".
765 Person & email address to contact for further information: See the
766 Authors' Addresses section of this document.
768 Intended usage: COMMON
770 Restrictions on usage: This is expected to be the second part of a
773 Author: See the Authors' Addresses section of this document.
775 Change controller: IETF Standards Process
786Newman & Melnikov Experimental [Page 14]
788RFC 5337 Internationalized DSN and MDNs September 2008
7917. Security Considerations
793 Automated use of report types without authentication presents several
794 security issues. Forging negative reports presents the opportunity
795 for denial-of-service attacks when the reports are used for automated
796 maintenance of directories or mailing lists. Forging positive
797 reports may cause the sender to incorrectly believe a message was
798 delivered when it was not.
800 Malicious users can generate report structures designed to trigger
801 coding flaws in report parsers. Report parsers need to use secure
802 coding techniques to avoid the risk of buffer overflow or denial-of-
803 service attacks against parser coding mistakes. Code reviews of such
804 parsers are also recommended.
806 Malicious users of the email system regularly send messages with
807 forged envelope return paths, and these messages trigger delivery
808 status reports that result in a large amount of unwanted traffic on
809 the Internet. Many users choose to ignore delivery status
810 notifications because they are usually the result of "blowback" from
811 forged messages and thus never notice when messages they sent go
812 undelivered. As a result, support for correlation of delivery status
813 and message disposition notification messages with sent-messages has
814 become a critical feature of mail clients and possibly mail stores if
815 the email infrastructure is to remain reliable. In the short term,
816 simply correlating message-IDs may be sufficient to distinguish true
817 status notifications from those resulting from forged originator
818 addresses. But in the longer term, including cryptographic signature
819 material that can securely associate the status notification with the
820 original message is advisable.
822 As this specification permits UTF-8 in additional fields, the
823 security considerations of UTF-8 [RFC3629] apply.
8278.1. Normative References
829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
830 Requirement Levels", BCP 14, RFC 2119, March 1997.
832 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
833 RFC 2821, April 2001.
835 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
842Newman & Melnikov Experimental [Page 15]
844RFC 5337 Internationalized DSN and MDNs September 2008
847 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP)
848 Service Extension for Delivery Status Notifications
849 (DSNs)", RFC 3461, January 2003.
851 [RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for
852 the Reporting of Mail System Administrative Messages",
853 RFC 3462, January 2003.
855 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message
856 Format for Delivery Status Notifications", RFC 3464,
859 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
860 10646", STD 63, RFC 3629, November 2003.
862 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
863 Notification", RFC 3798, May 2004.
865 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
866 Specifications: ABNF", STD 68, RFC 5234, January 2008.
868 [RFC5335] Yang, A., Ed., "Internationalized Email Headers",
869 RFC 5335, September 2008.
871 [RFC5336] Yao, J., Ed. and W. Mao, Ed., "SMTP Extension for
872 Internationalized Email Addresses", RFC 5336,
875 [LANGTAGS] Phillips, A. and M. Davis, "Tags for Identifying
876 Languages", RFC 4646, September 2006.
878 [DEFAULTLANG] Alvestrand, H., "IETF Policy on Character Sets and
879 Languages", RFC 2277, January 1998.
8818.2. Informative References
883 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
884 Mail Extensions (MIME) Part One: Format of Internet
885 Message Bodies", RFC 2045, November 1996.
887 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
888 Mail Extensions (MIME) Part Two: Media Types",
889 RFC 2046, November 1996.
891 [DOWNGRADE] Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for
892 Email Address Internationalization", Work in Progress,
898Newman & Melnikov Experimental [Page 16]
900RFC 5337 Internationalized DSN and MDNs September 2008
903Appendix A. Acknowledgements
905 Many thanks for input provided by Pete Resnick, James Galvin, Ned
906 Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, and
907 members of the EAI WG to help solidify this proposal.
914 Monrovia, CA 91016-6347
917 EMail: chris.newman@sun.com
920 Alexey Melnikov (editor)
922 5 Castle Business Village
924 Hampton, Middlesex TW12 2BX
927 EMail: Alexey.Melnikov@isode.com
954Newman & Melnikov Experimental [Page 17]
956RFC 5337 Internationalized DSN and MDNs September 2008
959Full Copyright Statement
961 Copyright (C) The IETF Trust (2008).
963 This document is subject to the rights, licenses and restrictions
964 contained in BCP 78, and except as set forth therein, the authors
965 retain all their rights.
967 This document and the information contained herein are provided on an
968 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
969 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
970 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
971 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
972 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
973 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
977 The IETF takes no position regarding the validity or scope of any
978 Intellectual Property Rights or other rights that might be claimed to
979 pertain to the implementation or use of the technology described in
980 this document or the extent to which any license under such rights
981 might or might not be available; nor does it represent that it has
982 made any independent effort to identify any such rights. Information
983 on the procedures with respect to rights in RFC documents can be
984 found in BCP 78 and BCP 79.
986 Copies of IPR disclosures made to the IETF Secretariat and any
987 assurances of licenses to be made available, or the result of an
988 attempt made to obtain a general license or permission for the use of
989 such proprietary rights by implementers or users of this
990 specification can be obtained from the IETF on-line IPR repository at
991 http://www.ietf.org/ipr.
993 The IETF invites any interested party to bring to its attention any
994 copyrights, patents or patent applications, or other proprietary
995 rights that may cover technology that may be required to implement
996 this standard. Please address the information to the IETF at
1010Newman & Melnikov Experimental [Page 18]