7Network Working Group K. Moore
8Request for Comments: 3461 University of Tennessee
9Obsoletes 1891 January 2003
10Category: Standards Track
13 Simple Mail Transfer Protocol (SMTP) Service Extension
14 for Delivery Status Notifications (DSNs)
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 Copyright (C) The Internet Society (2003). All Rights Reserved.
30 This memo defines an extension to the Simple Mail Transfer Protocol
31 (SMTP) service, which allows an SMTP client to specify (a) that
32 Delivery Status Notifications (DSNs) should be generated under
33 certain conditions, (b) whether such notifications should return the
34 contents of the message, and (c) additional information, to be
35 returned with a DSN, that allows the sender to identify both the
36 recipient(s) for which the DSN was issued, and the transaction in
37 which the original message was sent.
41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
43 document are to be interpreted as described in BCP 14, RFC 2119 [7].
47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
48 2. Framework for the Delivery Status Notification Extension . . . 4
49 3. The Delivery Status Notification service extension . . . . . . 5
50 4. Additional parameters for RCPT and MAIL commands . . . . . . . 6
51 4.1 The NOTIFY parameter of the ESMTP RCPT command. . . . . . . . 7
52 4.2 The ORCPT parameter to the ESMTP RCPT command . . . . . . . . 8
53 4.3 The RET parameter of the ESMTP MAIL command . . . . . . . . . 9
54 4.4 The ENVID parameter to the ESMTP MAIL command . . . . . . . . 9
58Moore Standards Track [Page 1]
60RFC 3461 SMTP DSN Extension January 2003
63 4.5 Restrictions on the use of Delivery Status Notification
64 parameters. . . . . . . . . . . . . . . . . . . . . . . . . . 10
65 5. Conformance requirements . . . . . . . . . . . . . . . . . . . 10
66 5.1 SMTP protocol interactions. . . . . . . . . . . . . . . . . . 11
67 5.2 Handling of messages received via SMTP. . . . . . . . . . . . 11
68 5.2.1 Relay of messages to other conforming SMTP servers. . . . . 12
69 5.2.2 Relay of messages to non-conforming SMTP servers. . . . . . 13
70 5.2.3 Local delivery of messages. . . . . . . . . . . . . . . . . 14
71 5.2.4 Gatewaying a message into a foreign environment . . . . . . 14
72 5.2.5 Delays in delivery. . . . . . . . . . . . . . . . . . . . . 15
73 5.2.6 Failure of a conforming MTA to deliver a message. . . . . . 16
74 5.2.7 Forwarding, aliases, and mailing lists. . . . . . . . . . . 16
75 5.2.7.1 mailing lists . . . . . . . . . . . . . . . . . . . . . . 17
76 5.2.7.2 single-recipient aliases. . . . . . . . . . . . . . . . . 18
77 5.2.7.3 multiple-recipient aliases. . . . . . . . . . . . . . . . 18
78 5.2.7.4 confidential forwarding addresses . . . . . . . . . . . . 18
79 5.2.8 DSNs describing delivery to multiple recipients . . . . . . 19
80 5.3 Handling of messages from other sources . . . . . . . . . . . 19
81 5.4 Implementation limits . . . . . . . . . . . . . . . . . . . . 19
82 6. Format of delivery notifications . . . . . . . . . . . . . . . 20
83 6.1 SMTP Envelope to be used with delivery status
84 notifications . . . . . . . . . . . . . . . . . . . . . . . . 20
85 6.2 Contents of the DSN . . . . . . . . . . . . . . . . . . . . . 20
86 6.3 Message/delivery-status fields. . . . . . . . . . . . . . . . 21
87 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 22
88 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
89 9. Appendix - Type-Name Definitions . . . . . . . . . . . . . . . 24
90 9.1 "rfc822" address-type . . . . . . . . . . . . . . . . . . . . 24
91 9.2 "smtp" diagnostic-type. . . . . . . . . . . . . . . . . . . . 24
92 9.3 "dns" MTA-name-type . . . . . . . . . . . . . . . . . . . . . 25
93 10. Appendix - Example. . . . . . . . . . . . . . . . . . . . . . 26
94 10.1 Submission . . . . . . . . . . . . . . . . . . . . . . . . . 27
95 10.2 Relay to Example.COM . . . . . . . . . . . . . . . . . . . . 28
96 10.3 Relay to Ivory.EDU . . . . . . . . . . . . . . . . . . . . . 29
97 10.4 Relay to Bombs.AF.MIL. . . . . . . . . . . . . . . . . . . . 30
98 10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV . . . . 31
99 10.6 "Delivered" DSN for Bob@Example.COM. . . . . . . . . . . . . 32
100 10.7 Failed DSN for Carol@Ivory.EDU . . . . . . . . . . . . . . . 33
101 10.8 Relayed DSN For Dana@Ivory.EDU . . . . . . . . . . . . . . . 34
102 10.9 Failure notification for Sam@Boondoggle.GOV. . . . . . . . . 35
103 11. Appendix - Changes since RFC 1891 . . . . . . . . . . . . . . 35
104 12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 36
105 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 36
106 12.2 Informative References . . . . . . . . . . . . . . . . . . . 36
107 13. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 37
108 14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 38
114Moore Standards Track [Page 2]
116RFC 3461 SMTP DSN Extension January 2003
121 The SMTP protocol [1] requires that an SMTP server provide
122 notification of delivery failure, if it determines that a message
123 cannot be delivered to one or more recipients. Traditionally, such
124 notification consists of an ordinary Internet mail message (format
125 defined by [2]), sent to the envelope sender address (the argument of
126 the SMTP MAIL command), containing an explanation of the error and at
127 least the headers of the failed message.
129 Experience with large mail distribution lists [8] indicates that such
130 messages are often insufficient to diagnose problems, or even to
131 determine at which host or for which recipients a problem occurred.
132 In addition, the lack of a standardized format for delivery
133 notifications in Internet mail makes it difficult to exchange such
134 notifications with other message handling systems.
136 Such experience has demonstrated a need for a delivery status
137 notification service for Internet electronic mail, which:
139 (a) is reliable, in the sense that any DSN request will either be
140 honored at the time of final delivery, or result in a response
141 that indicates that the request cannot be honored,
143 (b) when both success and failure notifications are requested,
144 provides an unambiguous and nonconflicting indication of whether
145 delivery of a message to a recipient succeeded or failed,
147 (c) is stable, in that a failed attempt to deliver a DSN should
148 never result in the transmission of another DSN over the
151 (d) preserves sufficient information to allow the sender to identify
152 both the mail transaction and the recipient address which caused
153 the notification, even when mail is forwarded or gatewayed to
154 foreign environments, and
156 (e) interfaces acceptably with non-SMTP and non-822-based mail
157 systems, both so that notifications returned from foreign mail
158 systems may be useful to Internet users, and so that the
159 notification requests from foreign environments may be honored.
160 Among the requirements implied by this goal are the ability to
161 request non-return-of-content, and the ability to specify
162 whether positive delivery notifications, negative delivery
163 notifications, both, or neither, should be issued.
170Moore Standards Track [Page 3]
172RFC 3461 SMTP DSN Extension January 2003
175 In an attempt to provide such a service, this memo uses the mechanism
176 defined in [1] to define an extension to the SMTP protocol. Using
177 this mechanism, an SMTP client may request that an SMTP server issue
178 or not issue a Delivery Status Notification (DSN) under certain
179 conditions. The format of a DSN is defined in [3].
1812. Framework for the Delivery Status Notification Extension
183 The following service extension is therefore defined:
185 (1) The name of the SMTP service extension is "Delivery Status
188 (2) the EHLO keyword value associated with this extension is "DSN",
189 the meaning of which is defined in section 3 of this memo;
191 (3) no parameters are allowed with this EHLO keyword value;
193 (4) two optional parameters are added to the RCPT command, and two
194 optional parameters are added to the MAIL command:
196 An optional parameter for the RCPT command, using the
197 esmtp-keyword "NOTIFY", (to specify the conditions under which a
198 Delivery Status Notification should be generated), is defined in
201 An optional parameter for the RCPT command, using the
202 esmtp-keyword "ORCPT", (used to convey the "original"
203 (sender-specified) recipient address), is defined in section
206 An optional parameter for the MAIL command, using the
207 esmtp-keyword "RET", (to request that DSNs containing an
208 indication of delivery failure either return the entire contents
209 of a message or only the message headers), is defined in section
212 An optional parameter for the MAIL command, using the
213 esmtp-keyword "ENVID", (used to propagate an identifier for this
214 message transmission envelope, which is also known to the sender
215 and will, if present, be returned in any DSNs issued for this
216 transmission), is defined in section 4.4;
218 (5) no additional SMTP verbs are defined by this extension.
220 The remainder of this memo specifies how support for the extension
221 affects the behavior of a message transfer agent.
226Moore Standards Track [Page 4]
228RFC 3461 SMTP DSN Extension January 2003
2313. The Delivery Status Notification service extension
233 An SMTP client wishing to request a DSN for a message may issue the
234 EHLO command to start an SMTP session, to determine if the server
235 supports any of several service extensions. If the server responds
236 with code 250 to the EHLO command, and the response includes the EHLO
237 keyword DSN, then the Delivery Status Notification extension (as
238 described in this memo) is supported.
240 Ordinarily, when an SMTP server returns a positive (2xx) reply code
241 in response to a RCPT command, it agrees to accept responsibility for
242 either delivering the message to the named recipient, or sending a
243 notification to the sender of the message indicating that delivery
244 has failed. However, an extended SMTP ("ESMTP") server which
245 implements this service extension will accept an optional NOTIFY
246 parameter with the RCPT command. If present, the NOTIFY parameter
247 alters the conditions for generation of Delivery Status Notifications
248 from the default (issue notifications only on failure) specified in
249 [1]. The ESMTP client may also request (via the RET parameter)
250 whether the entire contents of the original message should be
251 returned (as opposed to just the headers of that message), along with
254 In general, an ESMTP server which implements this service extension
255 will propagate Delivery Status Notification requests when relaying
256 mail to other SMTP-based MTAs which also support this extension, and
257 make a "best effort" to ensure that such requests are honored when
258 messages are passed into other environments.
260 In order for Delivery Status Notifications to be meaningful to the
261 sender, ESMTP servers, which support this extension, should propagate
262 the following information for use in generating DSNs to any other
263 MTAs that are used to relay the message:
265 (a) for each recipient, a copy of the original recipient address, as
266 used by the sender of the message.
268 This address need not be the same as the mailbox specified in
269 the RCPT command. For example, if a message was originally
270 addressed to A@B.C and later forwarded to A@D.E, after such
271 forwarding has taken place, the RCPT command will specify a
272 mailbox of A@D.E. However, the original recipient address
282Moore Standards Track [Page 5]
284RFC 3461 SMTP DSN Extension January 2003
287 Also, if the message originated from an environment which does
288 not use Internet-style user@domain addresses, and was gatewayed
289 into SMTP, the original recipient address will preserve the
290 original form of the recipient address.
292 (b) for the entire SMTP transaction, an envelope identification
293 string, which may be used by the sender to associate any
294 delivery status notifications with the transaction used to send
295 the original message.
2974. Additional parameters for RCPT and MAIL commands
299 The extended RCPT and MAIL commands are issued by a client when it
300 wishes to request a DSN from the server, under certain conditions,
301 for a particular recipient. The extended RCPT and MAIL commands are
302 identical to the RCPT and MAIL commands defined in [1], except that
303 one or more of the following parameters appear after the sender or
304 recipient address, respectively. The general syntax for extended
305 SMTP commands is defined in [1].
307 NOTE: Although RFC 822 ABNF is used to describe the syntax of these
308 parameters, they are not, in the language of that document,
309 "structured field bodies". Therefore, while parentheses MAY appear
310 within an emstp-value, they are not recognized as comment delimiters.
312 The syntax for "esmtp-value" in [1] does not allow SP, "=", control
313 characters, or characters outside the traditional ASCII range of
314 1-127 decimal to be transmitted in an esmtp-value. Because the ENVID
315 and ORCPT parameters may need to convey values outside this range,
316 the esmtp-values for these parameters are encoded as "xtext".
317 "xtext" is formally defined as follows:
319 xtext = *( xchar / hexchar )
321 xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
322 except for "+" and "=".
324 ; "hexchar"s are intended to encode octets that cannot appear
325 ; as ASCII characters within an esmtp-value.
327 hexchar = ASCII "+" immediately followed by two upper case
330 When encoding an octet sequence as xtext:
332 + Any ASCII CHAR between "!" and "~" inclusive, except for "+" and
333 "=", MAY be encoded as itself. (A CHAR in this range MAY instead
334 be encoded as a "hexchar", at the implementor's discretion.)
338Moore Standards Track [Page 6]
340RFC 3461 SMTP DSN Extension January 2003
343 + ASCII CHARs that fall outside the range above must be encoded as
3464.1 The NOTIFY parameter of the ESMTP RCPT command
348 A RCPT command issued by a client may contain the optional
349 esmtp-keyword "NOTIFY", to specify the conditions under which the
350 SMTP server should generate DSNs for that recipient. If the NOTIFY
351 esmtp-keyword is used, it MUST have an associated esmtp-value,
352 formatted according to the following rules, using the ABNF of RFC
355 notify-esmtp-value = "NEVER" / 1#notify-list-element
357 notify-list-element = "SUCCESS" / "FAILURE" / "DELAY"
361 a. Multiple notify-list-elements, separated by commas, MAY appear in
362 a NOTIFY parameter; however, the NEVER keyword MUST appear by
365 b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be
366 spelled in any combination of upper and lower case letters.
368 The meaning of the NOTIFY parameter values is generally as follows:
370 + A NOTIFY parameter value of "NEVER" requests that a DSN not be
371 returned to the sender under any conditions.
373 + A NOTIFY parameter value containing the "SUCCESS" or "FAILURE"
374 keywords requests that a DSN be issued on successful delivery or
375 delivery failure, respectively.
377 + A NOTIFY parameter value containing the keyword "DELAY" indicates
378 the sender's willingness to receive "delayed" DSNs. Delayed DSNs
379 may be issued if delivery of a message has been delayed for an
380 unusual amount of time (as determined by the MTA at which the
381 message is delayed), but the final delivery status (whether
382 successful or failure) cannot be determined. The absence of the
383 DELAY keyword in a NOTIFY parameter requests that a "delayed" DSN
384 NOT be issued under any conditions.
386 The actual rules governing interpretation of the NOTIFY parameter are
394Moore Standards Track [Page 7]
396RFC 3461 SMTP DSN Extension January 2003
399 For compatibility with SMTP clients that do not use the NOTIFY
400 facility, the absence of a NOTIFY parameter in a RCPT command may be
401 interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY.
4034.2 The ORCPT parameter to the ESMTP RCPT command
405 The ORCPT esmtp-keyword of the RCPT command is used to specify an
406 "original" recipient address that corresponds to the actual recipient
407 to which the message is to be delivered. If the ORCPT esmtp-keyword
408 is used, it MUST have an associated esmtp-value, which consists of
409 the original recipient address, encoded according to the rules below.
410 The ABNF for the ORCPT parameter is:
412 orcpt-parameter = "ORCPT=" original-recipient-address
414 original-recipient-address = addr-type ";" xtext
418 The "addr-type" portion MUST be an IANA-registered electronic mail
419 address-type (as defined in [3]), while the "xtext" portion contains
420 an encoded representation of the original recipient address using the
421 rules in section 5 of this document. The entire ORCPT parameter MAY
422 be up to 500 characters in length.
424 When initially submitting a message via SMTP, if the ORCPT parameter
425 is used, it MUST contain the same address as the RCPT TO address
426 (unlike the RCPT TO address, the ORCPT parameter will be encoded as
427 xtext). Likewise, when a mailing list submits a message via SMTP to
428 be distributed to the list subscribers, if ORCPT is used, the ORCPT
429 parameter MUST match the new RCPT TO address of each recipient, not
430 the address specified by the original sender of the message.)
432 The "addr-type" portion of the original-recipient-address is used to
433 indicate the "type" of the address which appears in the ORCPT
434 parameter value. However, the address associated with the ORCPT
435 keyword is NOT constrained to conform to the syntax rules for that
438 Ideally, the "xtext" portion of the original-recipient-address should
439 contain, in encoded form, the same sequence of characters that the
440 sender used to specify the recipient. However, for a message
441 gatewayed from an environment (such as X.400) in which a recipient
442 address is not a simple string of printable characters, the
443 representation of recipient address must be defined by a
444 specification for gatewaying between DSNs and that environment.
450Moore Standards Track [Page 8]
452RFC 3461 SMTP DSN Extension January 2003
455 Due to limitations in the Delivery Status Notification format, the
456 value of the original recipient address prior to encoding as "xtext"
457 MUST consist entirely of printable (graphic and white space)
458 characters from the US-ASCII [4] repertoire. If an addr-type is
459 defined for addresses which use characters outside of this
460 repertoire, the specification for that addr-type MUST define the
461 means of encoding those addresses in printable US-ASCII characters
462 when are then encoded as xtext.
4644.3 The RET parameter of the ESMTP MAIL command
466 The RET esmtp-keyword on the extended MAIL command specifies whether
467 or not the message should be included in any failed DSN issued for
468 this message transmission. If the RET esmtp-keyword is used, it MUST
469 have an associated esmtp-value, which is one of the following
472 FULL requests that the entire message be returned in any "failed"
473 Delivery Status Notification issued for this recipient.
475 HDRS requests that only the headers of the message be returned.
477 The FULL and HDRS keywords may be spelled in any combination of upper
478 and lower case letters.
480 If no RET parameter is supplied, the MTA MAY return either the
481 headers of the message or the entire message for any DSN containing
482 indication of failed deliveries.
484 Note that the RET parameter only applies to DSNs that indicate
485 delivery failure for at least one recipient. If a DSN contains no
486 indications of delivery failure, only the headers of the message
4894.4 The ENVID parameter to the ESMTP MAIL command
491 The ENVID esmtp-keyword of the SMTP MAIL command is used to specify
492 an "envelope identifier" to be transmitted along with the message and
493 included in any DSNs issued for any of the recipients named in this
494 SMTP transaction. The purpose of the envelope identifier is to allow
495 the sender of a message to identify the transaction for which the DSN
506Moore Standards Track [Page 9]
508RFC 3461 SMTP DSN Extension January 2003
511 The ABNF for the ENVID parameter is:
513 envid-parameter = "ENVID=" xtext
515 The ENVID esmtp-keyword MUST have an associated esmtp-value. No
516 meaning is assigned by the mail system to the presence or absence of
517 this parameter or to any esmtp-value associated with this parameter;
518 the information is used only by the sender or his user agent. The
519 ENVID parameter MAY be up to 100 characters in length.
521 Due to limitations in the Delivery Status Notification format, the
522 value of the ENVID parameter prior to encoding as "xtext" MUST
523 consist entirely of printable (graphic and white space) characters
524 from the US-ASCII [4] repertoire.
5264.5 Restrictions on the use of Delivery Status Notification parameters
528 The RET and ENVID parameters MUST NOT appear more than once each in
529 any single MAIL command. If more than one of either of these
530 parameters appears in a MAIL command, the ESMTP server SHOULD respond
531 with "501 syntax error in parameters or arguments".
533 The NOTIFY and ORCPT parameters MUST NOT appear more than once in any
534 RCPT command. If more than one of either of these parameters appears
535 in a RCPT command, the ESMTP server SHOULD respond with "501 syntax
536 error in parameters or arguments".
5385. Conformance requirements
540 The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer
541 Agents (MTAs) when accepting, relaying, or gatewaying mail, as well
542 as User Agents (UAs) when submitting mail to the mail transport
543 system. The DSN extension to SMTP may be used to allow UAs to convey
544 the sender's requests as to when DSNs should be issued. A UA which
545 claims to conform to this specification must meet certain
546 requirements as described below.
548 Typically, a message transfer agent (MTA) which supports SMTP will
549 assume, at different times, both the role of a SMTP client and an
550 SMTP server, and may also provide local delivery, gatewaying to
551 foreign environments, forwarding, and mailing list expansion. An MTA
552 which, when acting as an SMTP server, issues the DSN keyword in
553 response to the EHLO command, MUST obey the rules below for a
554 "conforming SMTP client" when acting as a client, and a "conforming
555 SMTP server" when acting as a server. The term "conforming MTA"
556 refers to an MTA which conforms to this specification, independent of
557 its role of client or server.
562Moore Standards Track [Page 10]
564RFC 3461 SMTP DSN Extension January 2003
5675.1 SMTP protocol interactions
569 The following rules apply to SMTP transactions in which any of the
570 ENVID, NOTIFY, RET, or ORCPT keywords are used:
572 (a) If an SMTP client issues a MAIL command containing a valid ENVID
573 parameter and associated esmtp-value and/or a valid RET parameter
574 and associated esmtp-value, a conforming SMTP server MUST return
575 the same reply-code as it would to the same MAIL command without
576 the ENVID and/or RET parameters. A conforming SMTP server MUST
577 NOT refuse a MAIL command based on the absence or presence of
578 valid ENVID or RET parameters, or on their associated
581 However, if the associated esmtp-value is not valid (i.e.,
582 contains illegal characters), or if there is more than one ENVID
583 or RET parameter in a particular MAIL command, the server MUST
584 issue the reply-code 501 with an appropriate message (e.g.,
585 "syntax error in parameter").
587 (b) If an SMTP client issues a RCPT command containing any valid
588 NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST
589 return the same response as it would to the same RCPT command
590 without those NOTIFY and/or ORCPT parameters. A conforming SMTP
591 server MUST NOT refuse a RCPT command based on the presence or
592 absence of any of these parameters.
594 However, if any of the associated esmtp-values are not valid, or
595 if there is more than one of any of these parameters in a
596 particular RCPT command, the server SHOULD issue the response
597 "501 syntax error in parameter".
5995.2 Handling of messages received via SMTP
601 This section describes how a conforming MTA should handle any
602 messages received via SMTP.
604 NOTE: A DSN MUST NOT be returned to the sender for any message for
605 which the return address from the SMTP MAIL command was NULL ("<>"),
606 even if the sender's address is available from other sources (e.g.,
607 the message header). However, the MTA which would otherwise issue a
608 DSN SHOULD inform the local postmaster of delivery failures through
609 some appropriate mechanism that will not itself result in the
612 DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to
613 be sent with a NULL return address ("reverse-path"). This creates an
614 interesting situation when a message arrives with one or more
618Moore Standards Track [Page 11]
620RFC 3461 SMTP DSN Extension January 2003
623 nonfunctional recipient addresses in addition to a nonfunctional
624 return address. When delivery to one of the recipient addresses
625 fails, the MTA will attempt to send a nondelivery notification to the
626 return address, setting the return address on the notification to
627 NULL. When the delivery of this notification fails, the MTA
628 attempting delivery of that notification sees a NULL return address.
629 If that MTA were not to inform anyone of the situation, the original
630 message would be silently lost. Furthermore, a nonfunctional return
631 address is often indicative of a configuration problem in the
632 sender's MTA. Reporting the condition to the local postmaster may
633 help to speed correction of such errors.
6355.2.1 Relay of messages to other conforming SMTP servers
637 The following rules govern the behavior of a conforming MTA, when
638 relaying a message which was received via the SMTP protocol, to an
639 SMTP server that supports the Delivery Status Notification service
642 (a) Any ENVID parameter included in the MAIL command when a message
643 was received, MUST also appear on the MAIL command with which the
644 message is relayed, with the same associated esmtp-value. If no
645 ENVID parameter was included in the MAIL command when the message
646 was received, the ENVID parameter MUST NOT be supplied when the
649 (b) Any RET parameter included in the MAIL command when a message was
650 received, MUST also appear on the MAIL command with which the
651 message is relayed, with the same associated esmtp-value. If no
652 RET parameter was included in the MAIL command when the message
653 was received, the RET parameter MUST NOT supplied when the
656 (c) If the NOTIFY parameter was supplied for a recipient when the
657 message was received, the RCPT command issued when the message is
658 relayed MUST also contain the NOTIFY parameter along with its
659 associated esmtp-value. If the NOTIFY parameter was not supplied
660 for a recipient when the message was received, the NOTIFY
661 parameter MUST NOT be supplied for that recipient when the
664 (d) If any ORCPT parameter was present in the RCPT command for a
665 recipient when the message was received, an ORCPT parameter with
666 the identical original-recipient-address MUST appear in the RCPT
667 command issued for that recipient when relaying the message.
668 (For example, the MTA therefore MUST NOT change the case of any
669 alphabetic characters in an ORCPT parameter.)
674Moore Standards Track [Page 12]
676RFC 3461 SMTP DSN Extension January 2003
679 If no ORCPT parameter was present in the RCPT command when the
680 message was received, an ORCPT parameter MAY be added to the RCPT
681 command when the message is relayed. If an ORCPT parameter is
682 added by the relaying MTA, it MUST contain the recipient address
683 from the RCPT command used when the message was received by that
6865.2.2 Relay of messages to non-conforming SMTP servers
688 The following rules govern the behavior of a conforming MTA (in the
689 role of client), when relaying a message which was received via the
690 SMTP protocol, to an SMTP server that does not support the Delivery
691 Status Notification service extension:
693 (a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when
694 relaying the message.
696 (b) If the NOTIFY parameter was supplied for a recipient, with an
697 esmtp-value containing the keyword SUCCESS, and the SMTP server
698 returns a success (2xx) reply-code in response to the RCPT
699 command, the client MUST issue a "relayed" DSN for that
702 (c) If the NOTIFY parameter was supplied for a recipient with an
703 esmtp-value containing the keyword FAILURE, and the SMTP server
704 returns a permanent failure (5xx) reply-code in response to the
705 RCPT command, the client MUST issue a "failed" DSN for that
708 (d) If the NOTIFY parameter was supplied for a recipient with an
709 esmtp-value of NEVER, the client MUST NOT issue a DSN for that
710 recipient, regardless of the reply-code returned by the SMTP
711 server. However, if the server returned a failure (5xx)
712 reply-code, the client MAY inform the local postmaster of the
713 delivery failure via an appropriate mechanism that will not
714 itself result in the generation of DSNs.
716 When attempting to relay a message to an SMTP server that does
717 not support this extension, and if NOTIFY=NEVER was specified for
718 some recipients of that message, a conforming SMTP client MAY
719 relay the message for those recipients in a separate SMTP
720 transaction, using an empty reverse-path in the MAIL command.
721 This will prevent DSNs from being issued for those recipients by
722 MTAs that conform to [1].
730Moore Standards Track [Page 13]
732RFC 3461 SMTP DSN Extension January 2003
735 (e) If a NOTIFY parameter was not supplied for a recipient, and the
736 SMTP server returns a success (2xx) reply-code in response to a
737 RCPT command, the client MUST NOT issue any DSN for that
740 (f) If a NOTIFY parameter was not supplied for a recipient, and the
741 SMTP server returns a permanent failure (5xx) reply-code in
742 response to a RCPT command, the client MUST issue a "failed" DSN
7455.2.3 Local delivery of messages
747 The following rules govern the behavior of a conforming MTA upon
748 successful delivery of a message that was received via the SMTP
749 protocol, to a local recipient's mailbox:
751 "Delivery" means that the message has been placed in the recipient's
752 mailbox. For messages which are transmitted to a mailbox for later
753 retrieval via IMAP [9], POP [10] or a similar message access
754 protocol, "delivery" occurs when the message is made available to the
755 IMAP (POP, etc.) service, rather than when the message is retrieved
756 by the recipient's user agent.
758 Similarly, for a recipient address which corresponds to a mailing
759 list exploder, "delivery" occurs when the message is made available
760 to that list exploder, even though the list exploder might refuse to
761 deliver that message to the list recipients.
763 (a) If the NOTIFY parameter was supplied for that recipient, with an
764 esmtp-value containing the SUCCESS keyword, the MTA MUST issue a
765 "delivered" DSN for that recipient.
767 (b) If the NOTIFY parameter was supplied for that recipient which did
768 not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for
771 (c) If the NOTIFY parameter was not supplied for that recipient, the
772 MTA MUST NOT issue a DSN.
7745.2.4 Gatewaying a message into a foreign environment
776 The following rules govern the behavior of a conforming MTA, when
777 gatewaying a message that was received via the SMTP protocol, into a
778 foreign (non-SMTP) environment:
780 (a) If the the foreign environment is capable of issuing appropriate
781 notifications under the conditions requested by the NOTIFY
782 parameter, and the conforming MTA can ensure that any
786Moore Standards Track [Page 14]
788RFC 3461 SMTP DSN Extension January 2003
791 notification thus issued will be translated into a DSN and
792 delivered to the original sender, then the MTA SHOULD gateway the
793 message into the foreign environment, requesting notification
794 under the desired conditions, without itself issuing a DSN.
796 (b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but
797 the destination environment cannot return an appropriate
798 notification on successful delivery, the MTA SHOULD issue a
799 "relayed" DSN for that recipient.
801 (c) If a NOTIFY parameter was supplied with an esmtp-keyword of
802 NEVER, a DSN MUST NOT be issued. If possible, the MTA SHOULD
803 direct the destination environment to not issue delivery
804 notifications for that recipient.
806 (d) If the NOTIFY parameter was not supplied for a particular
807 recipient, a DSN SHOULD NOT be issued by the gateway. The
808 gateway SHOULD attempt to ensure that appropriate notification
809 will be provided by the foreign mail environment if eventual
810 delivery failure occurs, and that no notification will be issued
811 on successful delivery.
813 (e) When gatewaying a message into a foreign environment, the
814 return-of-content conditions specified by any RET parameter are
815 nonbinding; however, the MTA SHOULD attempt to honor the request
816 using whatever mechanisms exist in the foreign environment.
8185.2.5 Delays in delivery
820 If a conforming MTA receives a message via the SMTP protocol, and is
821 unable to deliver or relay the message to one or more recipients for
822 an extended length of time (to be determined by the MTA), it MAY
823 issue a "delayed" DSN for those recipients, subject to the following
826 (a) If the NOTIFY parameter was supplied for a recipient and its
827 value included the DELAY keyword, a "delayed" DSN MAY be issued.
829 (b) If the NOTIFY parameter was not supplied for a recipient, a
830 "delayed" DSN MAY be issued.
832 (c) If the NOTIFY parameter was supplied which did not contain the
833 DELAY keyword, a "delayed" DSN MUST NOT be issued.
842Moore Standards Track [Page 15]
844RFC 3461 SMTP DSN Extension January 2003
847 NOTE: Although delay notifications are common in present-day
848 electronic mail, a conforming MTA is never required to issue
849 "delayed" DSNs. The DELAY keyword of the NOTIFY parameter is
850 provided to allow the SMTP client to specifically request (by
851 omitting the DELAY parameter) that "delayed" DSNs NOT be issued.
8535.2.6 Failure of a conforming MTA to deliver a message
855 The following rules govern the behavior of a conforming MTA which
856 received a message via the SMTP protocol, and is unable to deliver a
857 message to a recipient specified in the SMTP transaction:
859 (a) If a NOTIFY parameter was supplied for the recipient with an
860 esmtp-keyword containing the value FAILURE, a "failed" DSN MUST
861 be issued by the MTA.
863 (b) If a NOTIFY parameter was supplied for the recipient which did
864 not contain the value FAILURE, a DSN MUST NOT be issued for that
865 recipient. However, the MTA MAY inform the local postmaster of
866 the delivery failure via some appropriate mechanism which does
867 not itself result in the generation of DSNs.
869 (c) If no NOTIFY parameter was supplied for the recipient, a
870 "failed" DSN MUST be issued.
872 NOTE: Some MTAs are known to forward undeliverable messages to the
873 local postmaster or "dead letter" mailbox. This is still considered
874 delivery failure, and does not diminish the requirement to issue a
875 "failed" DSN under the conditions defined elsewhere in this memo. If
876 a DSN is issued for such a recipient, the Action value MUST be
8795.2.7 Forwarding, aliases, and mailing lists
881 Delivery of a message to a local email address usually causes the
882 message to be stored in the recipient's mailbox. However, MTAs
883 commonly provide a facility where a local email address can be
884 designated as an "alias" or "mailing list"; delivery to that address
885 then causes the message to be forwarded to each of the (local or
886 remote) recipient addresses associated with the alias or list. It is
887 also common to allow a user to optionally "forward" her mail to one
888 or more alternate addresses. If this feature is enabled, her mail is
889 redistributed to those addresses instead of being deposited in her
892 Following the example of [11] (section 5.3.6), this document defines
893 the difference between an "alias" and "mailing list" as follows: When
894 forwarding a message to the addresses associated with an "alias", the
898Moore Standards Track [Page 16]
900RFC 3461 SMTP DSN Extension January 2003
903 envelope return address (e.g., SMTP MAIL FROM) remains intact.
904 However, when forwarding a message to the addresses associated with a
905 "mailing list", the envelope return address is changed to that of the
906 administrator of the mailing list. This causes DSNs and other
907 nondelivery reports resulting from delivery to the list members to be
908 sent to the list administrator rather than the sender of the original
911 The DSN processing for aliases and mailing lists is as follows:
915 When a message is delivered to a list submission address (i.e.,
916 placed in the list's mailbox for incoming mail, or accepted by the
917 process that redistributes the message to the list subscribers), this
918 is considered final delivery for the original message. If the NOTIFY
919 parameter for the list submission address contained the SUCCESS
920 keyword, a "delivered" DSN MUST be returned to the sender of the
923 NOTE: Some mailing lists are able to reject message submissions,
924 based on the content of the message, the sender's address, or some
925 other criteria. While the interface between such a mailing list and
926 its MTA is not well-defined, it is important that DSNs NOT be issued
927 by both the MTA (to report successful delivery to the list), and the
928 list (to report message rejection using a "failure" DSN.)
930 However, even if a "delivered" DSN was issued by the MTA, a mailing
931 list which rejects a message submission MAY notify the sender that
932 the message was rejected using an ordinary message instead of a DSN.
934 Whenever a message is redistributed to an mailing list,
936 (a) The envelope return address is rewritten to point to the list
937 maintainer. This address MAY be that of a process that
938 recognizes DSNs and processes them automatically, but it MUST
939 forward unrecognized messages to the human responsible for the
942 (b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the
943 redistributed message MUST NOT be derived from those of the
946 (c) The NOTIFY and RET parameters MAY be specified by the local
947 postmaster or the list administrator. If ORCPT parameters are
948 supplied during redistribution to the list subscribers, they
949 SHOULD contain the addresses of the list subscribers in the
950 format used by the mailing list.
954Moore Standards Track [Page 17]
956RFC 3461 SMTP DSN Extension January 2003
9595.2.7.2 single-recipient aliases
961 Under normal circumstances, when a message arrives for an "alias"
962 which has a single forwarding address, a DSN SHOULD NOT be issued.
963 Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with
964 the message as it is redistributed to the forwarding address.
9665.2.7.3 multiple-recipient aliases
968 An "alias" with multiple recipient addresses may be handled in any of
971 (a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated
972 when relaying the message to any of the forwarding addresses.
973 If the NOTIFY parameter for the alias contained the SUCCESS
974 keyword, the MTA issues a "relayed" DSN. (In effect, the MTA
975 treats the message as if it were being relayed into an
976 environment that does not support DSNs.)
978 (b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent
979 requests if the message is gatewayed) are propagated to EXACTLY
980 one of the forwarding addresses. No DSN is issued. (This is
981 appropriate when aliasing is used to forward a message to a
982 "vacation" auto-responder program in addition to the local
985 (c) Any ENVID, RET, or ORCPT parameters are propagated to all
986 forwarding addresses associated with that alias. The NOTIFY
987 parameter is propagated to the forwarding addresses, except that
988 it any SUCCESS keyword is removed. If the original NOTIFY
989 parameter for the alias contained the SUCCESS keyword, an
990 "expanded" DSN is issued for the alias. If the NOTIFY parameter
991 for the alias did not contain the SUCCESS keyword, no DSN is
992 issued for the alias.
9945.2.7.4 confidential forwarding addresses
996 If it is desired to maintain the confidentiality of a recipient's
997 forwarding address, the forwarding may be treated as if it were a
998 mailing list. A DSN will be issued, if appropriate, upon "delivery"
999 to the recipient address specified by the sender. When the message
1000 is forwarded it will have a new envelope return address. Any DSNs
1001 which result from delivery failure of the forwarded message will not
1002 be returned to the original sender of the message and thus not expose
1003 the recipient's forwarding address.
1010Moore Standards Track [Page 18]
1012RFC 3461 SMTP DSN Extension January 2003
10155.2.8 DSNs describing delivery to multiple recipients
1017 A single DSN may describe attempts to deliver a message to multiple
1018 recipients of that message. If a DSN is issued for some recipients
1019 in an SMTP transaction and not for others according to the rules
1020 above, the DSN SHOULD NOT contain information for recipients for whom
1021 DSNs would not otherwise have been issued.
10235.3 Handling of messages from other sources
1025 For messages which originated from "local" users (whatever that
1026 means), the specifications under which DSNs should be generated can
1027 be communicated to the MTA via any protocol agreed on between the
1028 sender's mail composer (user agent) and the MTA. The local MTA can
1029 then either relay the message, or issue appropriate delivery status
1030 notifications. However, if such requests are transmitted within the
1031 message itself (for example in the message headers), the requests
1032 MUST be removed from the message before it is transmitted via SMTP.
1034 For messages gatewayed from non-SMTP sources and further relayed by
1035 SMTP, the gateway SHOULD, using the SMTP extensions described here,
1036 attempt to provide the delivery reporting conditions expected by the
1037 source mail environment. If appropriate, any DSNs returned to the
1038 source environment SHOULD be translated into the format expected in
10415.4 Implementation limits
1043 A conforming MTA MUST accept ESMTP parameters of at least the
1046 (a) ENVID parameter: 100 characters.
1048 (b) NOTIFY parameter: 28 characters.
1050 (c) ORCPT parameter: 500 characters.
1052 (d) RET parameter: 8 characters.
1054 The maximum sizes for the ENVID and ORCPT parameters are intended to
1055 be adequate for the transmission of "foreign" envelope identifier and
1056 original recipient addresses. However, user agents which use SMTP as
1057 a message submission protocol SHOULD NOT generate ENVID parameters
1058 which are longer than 38 characters in length.
1060 A conforming MTA MUST be able to accept SMTP command-lines which are
1061 at least 1036 characters long (530 characters for the ORCPT and
1062 NOTIFY parameters of the RCPT command, in addition to the 512
1066Moore Standards Track [Page 19]
1068RFC 3461 SMTP DSN Extension January 2003
1071 characters required by [1]). If other SMTP extensions are supported
1072 by the MTA, the MTA MUST be able to accept a command-line large
1073 enough for each SMTP command and any combination of ESMTP parameters
1074 which may be used with that command.
10766. Format of delivery notifications
1078 The format of Delivery Status Notifications is defined in [3], which
1079 uses the framework defined in [5]. Delivery Status Notifications are
1080 to be returned to the sender of the original message as outlined
10836.1 SMTP Envelope to be used with Delivery Status Notifications
1085 The DSN sender address (in the SMTP MAIL command) MUST be a null
1086 reverse-path ("<>"), as required by section 5.3.3 of [11]. The DSN
1087 recipient address (in the RCPT command) is copied from the MAIL
1088 command which accompanied the message for which the DSN is being
1089 issued. When transmitting a DSN via SMTP, the RET parameter MUST NOT
1090 be used. The NOTIFY parameter MAY be used, but its value MUST be
1091 NEVER. The ENVID parameter (with a newly generated envelope-id)
1092 and/or ORCPT parameter MAY be used.
10946.2 Contents of the DSN
1096 A DSN is transmitted as a MIME message with a top-level content-type
1097 of multipart/report (as defined in [3]).
1099 The multipart/report content-type may be used for any of several
1100 kinds of reports generated by the mail system. When multipart/report
1101 is used to convey a DSN, the report-type parameter of the
1102 multipart/report content-type is "delivery-status".
1104 As described in [5], the first component of a multipart/report
1105 content-type is a human readable explanation of the report. For a
1106 DSN, the second component of the multipart/report is of content-type
1107 message/delivery-status (defined in [3]). The third component of the
1108 multipart/report consists of the original message or some portion
1109 thereof. When the value of the RET parameter is FULL, the full
1110 message SHOULD be returned for any DSN which conveys notification of
1111 delivery failure. (However, if the length of the message is greater
1112 than some implementation-specified length, the MTA MAY return only
1113 the headers even if the RET parameter specified FULL.) If a DSN
1114 contains no notifications of delivery failure, the MTA SHOULD return
1117 The third component must have an appropriate content-type label.
1118 Issues concerning selection of the content-type are discussed in [5].
1122Moore Standards Track [Page 20]
1124RFC 3461 SMTP DSN Extension January 2003
11276.3 Message/delivery-status fields
1129 The message/delivery-status content-type defines a number of fields,
1130 with general specifications for their contents. The following
1131 requirements for any DSNs generated in response to a message received
1132 by the SMTP protocol by a conforming SMTP server, are in addition to
1133 the requirements defined in [3] for the message/delivery-status type.
1135 When generating a DSN for a message which was received via the SMTP
1136 protocol, a conforming MTA will generate the following fields of the
1137 message/delivery-status body part:
1140 Original-Envelope-ID field MUST be supplied, and the value
1141 associated with the ENVID parameter must appear in that field.
1142 If the message was received via SMTP with no ENVID parameter,
1143 the Original-Envelope-ID field MUST NOT be supplied.
1145 Since the ENVID parameter is encoded as xtext, but the
1146 Original-Envelope-ID header is NOT encoded as xtext, the MTA
1147 must decode the xtext encoding when copying the ENVID value to
1148 the Original-Envelope-ID field.
1150 (b) The Reporting-MTA field MUST be supplied. If Reporting MTA can
1151 determine its fully-qualified Internet domain name, the MTA-
1152 name-type subfield MUST be "dns", and the field MUST contain the
1153 fully-qualified domain name of the Reporting MTA. If the
1154 fully-qualified Internet domain name of the Reporting MTA is not
1155 known (for example, for an SMTP server which is not directly
1156 connected to the Internet), the Reporting-MTA field may contain
1157 any string identifying the MTA, however, in this case the MTA-
1158 name-type subfield MUST NOT be "dns". A MTA-name-type subfield
1159 value of "x-local-hostname" is suggested.
1161 (c) Other per-message fields as defined in [3] MAY be supplied as
1164 (d) If the ORCPT parameter was provided for this recipient, the
1165 Original-Recipient field MUST be supplied, with its value taken
1166 from the ORCPT parameter. If no ORCPT parameter was provided
1167 for this recipient, the Original-Recipient field MUST NOT
1170 (e) The Final-Recipient field MUST be supplied. It MUST contain the
1171 recipient address from the message envelope. If the message was
1172 received via SMTP, the address-type will be "rfc822".
1174 (f) The Action field MUST be supplied.
1178Moore Standards Track [Page 21]
1180RFC 3461 SMTP DSN Extension January 2003
1183 (g) The Status field MUST be supplied, using a status-code from [6].
1184 If there is no specific code which suitably describes a delivery
1185 failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent
1186 failure) MUST be used.
1188 (h) For DSNs resulting from attempts to relay a message to one or
1189 more recipients via SMTP, the Remote-MTA field MUST be supplied
1190 for each of those recipients. The mta-name-type subfields of
1191 those Remote-MTA fields will be "dns".
1193 (i) For DSNs resulting from attempts to relay a message to one or
1194 more recipients via SMTP, the Diagnostic-Code MUST be supplied
1195 for each of those recipients. The diagnostic-type subfield will
1196 be "smtp". See section 9.2 of this document for a description
1197 of the "smtp" diagnostic-code.
1199 (j) For DSNs resulting from attempts to relay a message to one or
1200 more recipients via SMTP, an SMTP-Remote-Recipient extension
1201 field MAY be supplied for each recipient, which contains the
1202 address of that recipient which was presented to the remote SMTP
1205 (k) Other per-recipient fields defined in [3] MAY appear, as
1210 The author wishes to thank Eric Allman, Harald Alvestrand, Jim
1211 Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned
1212 Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios
1213 Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall
1214 Rose, Greg Vaudreuil, and Klaus Weide for their suggestions for
1215 improvement of this document.
12178. Security Considerations
1219 The SMTP extension described in this document does not change the
1220 fundamental nature of the SMTP service and hence does not create any
1221 new security exposures in and of itself. It necessarily adds
1222 complexity to implementations, however, and with added complexity
1223 comes an increased risk of implementation errors.
1225 Previous ad-hoc delivery notification mechanisms sometimes produced a
1226 storm of receipts due to unanticipated interactions with mailing list
1227 expansion software. In this specification notification of successful
1228 delivery is carefully designed so, if properly implemented, it cannot
1229 interact with a list expander in this way.
1234Moore Standards Track [Page 22]
1236RFC 3461 SMTP DSN Extension January 2003
1239 The security considerations section in [5] describes security issues
1240 associated with multipart/report objects in general and the security
1241 considerations section in [3] describes security issues with DSNs in
1290Moore Standards Track [Page 23]
1292RFC 3461 SMTP DSN Extension January 2003
12959. Appendix - Type-Name Definitions
1297 The following type names are defined for use in DSN fields generated
1298 by conforming SMTP-based MTAs:
13009.1 "rfc822" address-type
1302 The "rfc822" address-type is to be used when reporting Internet
1303 electronic mail address in the Original-Recipient and Final-Recipient
1306 (a) address-type name: rfc822
1308 (b) syntax for mailbox addresses
1310 RFC822 mailbox addresses are generally expected to be of the
1315 where "route" and "addr-spec" are defined in [2], and the
1316 "domain" portions of both "route" and "addr-spec" are fully-
1317 qualified domain names that are registered in the DNS. However,
1318 an MTA MUST NOT modify an address obtained from the message
1319 envelope to force it to conform to syntax rules.
1321 (c) If addresses of this type are not composed entirely of graphic
1322 characters from the US-ASCII repertoire, a specification for how
1323 they are to be encoded as graphic US-ASCII characters in a DSN
1324 Original-Recipient or Final-Recipient DSN field.
1326 RFC822 addresses consist entirely of graphic characters from the
1327 US-ASCII repertoire, so no translation is necessary.
1331 The "smtp" diagnostic-type is to be used when reporting SMTP reply-
1332 codes in Diagnostic-Code DSN fields.
1334 (a) diagnostic-type name: SMTP
1336 (b) A description of the syntax to be used for expressing diagnostic
1337 codes of this type as graphic characters from the US-ASCII
1340 An SMTP diagnostic-code is of the form
1346Moore Standards Track [Page 24]
1348RFC 3461 SMTP DSN Extension January 2003
1351 For a single-line SMTP reply to an SMTP command, the
1352 diagnostic-code SHOULD be an exact transcription of the reply.
1353 For multi-line SMTP replies, it is necessary to insert a SPACE
1354 before each line after the first. For example, an SMTP reply
1357 550-mailbox unavailable
1358 550 user has moved with no forwarding address
1360 could appear as follows in a Diagnostic-Code DSN field:
1362 Diagnostic-Code: smtp ; 550-mailbox unavailable
1363 550 user has moved with no forwarding address
1366 (c) A list of valid diagnostic codes of this type and the meaning of
1369 SMTP reply-codes are currently defined in [1] and [11].
1370 Additional codes may be defined by other RFCs.
13729.3 "dns" MTA-name-type
1374 The "dns" MTA-name-type should be used in the Reporting-MTA field.
1375 An MTA-name of type "dns" is a fully-qualified domain name. The name
1376 must be registered in the DNS, and the address Postmaster@{mta-name}
1379 (a) MTA-name-type name: dns
1381 (b) A description of the syntax of MTA names of this type, using
1382 BNF, regular expressions, ASN.1, or other non-ambiguous
1385 MTA names of type "dns" SHOULD be valid Internet domain names.
1386 If such domain names are not available, a domain-literal
1387 containing the internet protocol address is acceptable. Such
1388 domain names generally conform to the following syntax:
1390 domain = real-domain / domain-literal
1392 real-domain = sub-domain *("." sub-domain)
1396 domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]"
1398 where "atom" and "DIGIT" are defined in [2].
1402Moore Standards Track [Page 25]
1404RFC 3461 SMTP DSN Extension January 2003
1407 (c) If MTA names of this type do not consist entirely of graphic
1408 characters from the US-ASCII repertoire, a specification for how
1409 an MTA name of this type should be expressed as a sequence of
1410 graphic US-ASCII characters.
1412 MTA names of type "dns" consist entirely of graphic US-ASCII
1413 characters, so no translation is needed.
141510. Appendix - Example
1417 This example traces the flow of a single message addressed to
1418 multiple recipients. The message is sent by Alice@Example.ORG to
1419 Bob@Example.COM, Carol@Ivory.EDU, Dana@Ivory.EDU, Eric@Bombs.AF.MIL,
1420 Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a variety of per-
1421 recipient options. The message is successfully delivered to Bob,
1422 Dana (via a gateway), Eric, and Fred. Delivery fails for Carol and
1425 NOTE: Formatting rules for RFCs require that no line be longer than
1426 72 characters. Therefore, in the following examples, some SMTP
1427 commands longer than 72 characters are printed on two lines, with the
1428 first line ending in "\". In an actual SMTP transaction, such a
1429 command would be sent as a single line (i.e., with no embedded
1430 CRLFs), and without the "\" character that appears in these examples.
1458Moore Standards Track [Page 26]
1460RFC 3461 SMTP DSN Extension January 2003
1465 Alice's user agent sends the message to the SMTP server at
1466 Example.ORG. Note that while this example uses SMTP as a mail
1467 submission protocol, other protocols could also be used.
1469 <<< 220 Example.ORG SMTP server here
1470 >>> EHLO Example.ORG
1475 >>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
1476 <<< 250 <Alice@Example.ORG> sender ok
1477 >>> RCPT TO:<Bob@Example.COM> NOTIFY=SUCCESS \
1478 ORCPT=rfc822;Bob@Example.COM
1479 <<< 250 <Bob@Example.COM> recipient ok
1480 >>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
1481 ORCPT=rfc822;Carol@Ivory.EDU
1482 <<< 250 <Carol@Ivory.EDU> recipient ok
1483 >>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
1484 ORCPT=rfc822;Dana@Ivory.EDU
1485 <<< 250 <Dana@Ivory.EDU> recipient ok
1486 >>> RCPT TO:<Eric@Bombs.AF.MIL> NOTIFY=FAILURE \
1487 ORCPT=rfc822;Eric@Bombs.AF.MIL
1488 <<< 250 <Eric@Bombs.AF.MIL> recipient ok
1489 >>> RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER
1490 <<< 250 <Fred@Bombs.AF.MIL> recipient ok
1491 >>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \
1492 ORCPT=rfc822;George@Tax-ME.GOV
1493 <<< 250 <George@Tax-ME.GOV> recipient ok
1495 <<< 354 okay, send message
1496 >>> (message goes here)
1498 <<< 250 message accepted
1514Moore Standards Track [Page 27]
1516RFC 3461 SMTP DSN Extension January 2003
151910.2 Relay to Example.COM
1521 The SMTP at Example.ORG then relays the message to Example.COM. (For
1522 the purpose of this example, mail.Example.COM is the primary mail
1523 exchanger for Example.COM).
1525 <<< 220 mail.Example.COM says hello
1526 >>> EHLO Example.ORG
1527 <<< 250-mail.Example.COM
1529 >>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
1531 >>> RCPT TO:<Bob@Example.COM> NOTIFY=SUCCESS \
1532 ORCPT=rfc822;Bob@Example.COM
1533 <<< 250 recipient okay
1535 <<< 354 send message
1536 >>> (message goes here)
1538 <<< 250 message received
1570Moore Standards Track [Page 28]
1572RFC 3461 SMTP DSN Extension January 2003
157510.3 Relay to Ivory.EDU
1577 The SMTP at Example.ORG relays the message to Ivory.EDU, which (as it
1578 happens) is a gateway to a LAN-based mail system that accepts SMTP
1579 mail and supports the DSN extension.
1581 <<< 220 Ivory.EDU gateway to FooMail(tm) here
1582 >>> EHLO Example.ORG
1585 >>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
1587 >>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
1588 ORCPT=rfc822;Carol@Ivory.EDU
1589 <<< 550 error - no such recipient
1590 >>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
1591 ORCPT=rfc822;Dana@Ivory.EDU
1592 <<< 250 recipient ok
1594 <<< 354 send message, end with '.'
1595 >>> (message goes here)
1597 <<< 250 message received
1601 Note that since the Ivory.EDU refused to accept mail for
1602 Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the
1603 sender-SMTP (in this case Example.ORG) must generate a DSN.
1626Moore Standards Track [Page 29]
1628RFC 3461 SMTP DSN Extension January 2003
163110.4 Relay to Bombs.AF.MIL
1633 The SMTP at Example.ORG relays the message to Bombs.AF.MIL, which
1634 does not support the SMTP extension. Because the sender specified
1635 NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Example.ORG
1636 chooses to send the message for that recipient in a separate
1637 transaction with a reverse-path of <>.
1639 <<< 220-Bombs.AF.MIL reporting for duty.
1640 <<< 220 Electronic mail is to be used for official business only.
1641 >>> EHLO Example.ORG
1642 <<< 502 command not implemented
1645 >>> HELO Example.ORG
1646 <<< 250 Bombs.AF.MIL
1647 >>> MAIL FROM:<Alice@Example.ORG>
1649 >>> RCPT TO:<Eric@Bombs.AF.MIL>
1652 <<< 354 send message
1653 >>> (message goes here)
1655 <<< 250 message accepted
1658 >>> RCPT TO:<Fred@Bombs.AF.MIL>
1661 <<< 354 send message
1662 >>> (message goes here)
1664 <<< 250 message accepted
1666 <<< 221 Bombs.AF.MIL closing connection
1682Moore Standards Track [Page 30]
1684RFC 3461 SMTP DSN Extension January 2003
168710.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV
1689 The SMTP at Example.ORG relays the message to Tax-ME.GOV. (this step
1690 is not shown). MTA Tax-ME.GOV then forwards the message to
1691 Sam@Boondoggle.GOV (shown below). Both Tax-ME.GOV and Example.ORG
1692 support the SMTP DSN extension. Note that RET, ENVID, and ORCPT all
1693 retain their original values.
1695 <<< 220 BoonDoggle.GOV says hello
1696 >>> EHLO Example.ORG
1697 <<< 250-mail.Example.COM
1699 >>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
1701 >>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCESS \
1702 ORCPT=rfc822;George@Tax-ME.GOV
1703 <<< 250 recipient okay
1705 <<< 354 send message
1706 >>> (message goes here)
1708 <<< 250 message received
1738Moore Standards Track [Page 31]
1740RFC 3461 SMTP DSN Extension January 2003
174310.6 "Delivered" DSN for Bob@Example.COM
1745 MTA mail.Example.COM successfully delivers the message to
1746 Bob@Example.COM. Because the sender specified NOTIFY=SUCCESS,
1747 mail.Example.COM issues the following DSN, and sends it to
1750 To: Alice@Example.ORG
1751 From: postmaster@mail.Example.COM
1752 Subject: Delivery Notification (success) for Bob@Example.COM
1753 Content-Type: multipart/report; report-type=delivery-status;
1758 Content-type: text/plain; charset=us-ascii
1760 Your message (id QQ314159) was successfully delivered to
1764 Content-type: message/delivery-status
1766 Reporting-MTA: dns; mail.Example.COM
1767 Original-Envelope-ID: QQ314159
1769 Original-Recipient: rfc822;Bob@Example.COM
1770 Final-Recipient: rfc822;Bob@Example.COM
1775 Content-type: message/rfc822
1777 (headers of returned message go here)
1794Moore Standards Track [Page 32]
1796RFC 3461 SMTP DSN Extension January 2003
179910.7 Failed DSN for Carol@Ivory.EDU
1801 Because delivery to Carol failed and the sender specified
1802 NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Example.ORG (the SMTP client
1803 to which the failure was reported via SMTP) issues the following DSN.
1805 To: Alice@Example.ORG
1806 From: postmaster@Example.ORG
1807 Subject: Delivery Notification (failure) for Carol@Ivory.EDU
1808 Content-Type: multipart/report; report-type=delivery-status;
1813 Content-type: text/plain; charset=us-ascii
1815 Your message (id QQ314159) could not be delivered to
1818 A transcript of the session follows:
1820 (while talking to Ivory.EDU)
1821 >>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE
1822 <<< 550 error - no such recipient
1825 Content-type: message/delivery-status
1827 Reporting-MTA: dns; Example.ORG
1828 Original-Envelope-ID: QQ314159
1830 Original-Recipient: rfc822;Carol@Ivory.EDU
1831 Final-Recipient: rfc822;Carol@Ivory.EDU
1832 SMTP-Remote-Recipient: Carol@Ivory.EDU
1833 Diagnostic-Code: smtp; 550 error - no such recipient
1838 Content-type: message/rfc822
1840 (headers of returned message go here)
1850Moore Standards Track [Page 33]
1852RFC 3461 SMTP DSN Extension January 2003
185510.8 Relayed DSN For Dana@Ivory.EDU
1857 Although the mail gateway Ivory.EDU supports the DSN SMTP extension,
1858 the LAN mail system attached to its other side does not generate
1859 positive delivery confirmations. So Ivory.EDU issues a "relayed"
1862 To: Alice@Example.ORG
1863 From: postmaster@Ivory.EDU
1864 Subject: mail relayed for Dana@Ivory.EDU
1865 Content-Type: multipart/report; report-type=delivery-status;
1870 Content-type: text/plain; charset=us-ascii
1872 Your message (addressed to Dana@Ivory.EDU) was successfully
1877 by the FooMail gateway at Ivory.EDU.
1879 Unfortunately, the remote mail system does not support
1880 confirmation of actual delivery. Unless delivery to ymail!Dana
1881 fails, this will be the only Delivery Status Notification sent.
1884 Content-type: message/delivery-status
1886 Reporting-MTA: dns; Ivory.EDU
1887 Original-Envelope-ID: QQ314159
1889 Original-Recipient: rfc822;Dana@Ivory.EDU
1890 Final-Recipient: rfc822;Dana@Ivory.EDU
1895 Content-type: message/rfc822
1897 (headers of returned message go here)
1906Moore Standards Track [Page 34]
1908RFC 3461 SMTP DSN Extension January 2003
191110.9 Failure notification for Sam@Boondoggle.GOV
1913 The message originally addressed to George@Tax-ME.GOV was forwarded
1914 to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to
1915 deliver the message due to a lack of disk space in Sam's mailbox.
1916 After trying for several days, Boondoggle.GOV returned the following
1919 To: Alice@Example.ORG
1920 From: Postmaster@Boondoggle.GOV
1921 Subject: Delivery failure for Sam@Boondoggle.GOV
1922 Content-Type: multipart/report; report-type=delivery-status;
1927 Your message, originally addressed to George@Tax-ME.GOV, and
1928 forwarded from there to Sam@Boondoggle.GOV could not be delivered,
1929 for the following reason:
1931 write error to mailbox, disk quota exceeded
1934 Content-type: message/delivery-status
1936 Reporting-MTA: Boondoggle.GOV
1937 Original-Envelope-ID: QQ314159
1939 Original-Recipient: rfc822;George@Tax-ME.GOV
1940 Final-Recipient: rfc822;Sam@Boondoggle.GOV
1942 Status: 4.2.2 (disk quota exceeded)
1945 Content-type: message/rfc822
1947 (headers of returned message go here)
195111. Appendix - Changes since RFC 1891
1953 - updated author's address
1955 - In examples, changed Pure-Heart.ORG and Big-Bucks.COM to
1956 Example.ORG and Example.COM, respectively. Since publication
1957 of RFC 1891, the former two domains have been registered.
1962Moore Standards Track [Page 35]
1964RFC 3461 SMTP DSN Extension January 2003
1967 - Clarified that ENVID and ORCPT parameters must consist
1968 entirely of US-ASCII characters prior to encoding as xtext.
1970 - A Security Considerations section was added.
197412.1 Normative References
1976 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
1979 [2] Crocker, D., "Standard for the format of ARPA Internet Text
1980 Messages", STD 11, RFC 822, August 1982.
1982 [3] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
1983 Delivery Status Notifications", RFC 3464, January 2003.
1985 [4] Coded Character Set - 7-Bit American Standard Code for
1986 Information Interchange, ANSI X3.4-1986.
1988 [5] Vaudreuil, G., "The Multipart/Report Content Type for the
1989 Reporting of Mail System Administrative Messages", RFC 3462,
1992 [6] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
1995 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1996 Levels", BCP 14, RFC 2119, March 1997.
199812.2 Informative References
2000 [8] Westine, A. and J. Postel, "Problems with the Maintenance of
2001 Large Mailing Lists.", RFC 1211, March 1991.
2003 [9] Crispin, M., "Internet Message Access Protocol - Version 4rev1",
2004 RFC 2060, December 1996.
2006 [10] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
2007 53, RFC 1939, May 1996.
2009 [11] Braden, R., Ed., "Requirements for Internet Hosts - Application
2010 and Support", STD 3, RFC 1123, October 1989.
2018Moore Standards Track [Page 36]
2020RFC 3461 SMTP DSN Extension January 2003
2026 University of Tennessee
2027 1122 Volunteer Blvd, Suite 203
2028 Knoxville, TN 37996-3450
2031 EMail: moore@cs.utk.edu
2074Moore Standards Track [Page 37]
2076RFC 3461 SMTP DSN Extension January 2003
207914. Full Copyright Statement
2081 Copyright (C) The Internet Society (2003). All Rights Reserved.
2083 This document and translations of it may be copied and furnished to
2084 others, and derivative works that comment on or otherwise explain it
2085 or assist in its implementation may be prepared, copied, published
2086 and distributed, in whole or in part, without restriction of any
2087 kind, provided that the above copyright notice and this paragraph are
2088 included on all such copies and derivative works. However, this
2089 document itself may not be modified in any way, such as by removing
2090 the copyright notice or references to the Internet Society or other
2091 Internet organizations, except as needed for the purpose of
2092 developing Internet standards in which case the procedures for
2093 copyrights defined in the Internet Standards process must be
2094 followed, or as required to translate it into languages other than
2097 The limited permissions granted above are perpetual and will not be
2098 revoked by the Internet Society or its successors or assigns.
2100 This document and the information contained herein is provided on an
2101 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2102 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2103 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2104 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2105 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2109 Funding for the RFC Editor function is currently provided by the
2130Moore Standards Track [Page 38]