field MAY be supplied for each recipient, which contains the
address of that recipient which was presented to the remote SMTP
server.
(k) Other per-recipient fields defined in [3] MAY appear, as
appropriate.
7. Acknowledgments
The author wishes to thank Eric Allman, Harald Alvestrand, Jim
Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned
Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios
Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall
Rose, Greg Vaudreuil, and Klaus Weide for their suggestions for
improvement of this document.
8. Security Considerations
The SMTP extension described in this document does not change the
fundamental nature of the SMTP service and hence does not create any
new security exposures in and of itself. It necessarily adds
complexity to implementations, however, and with added complexity
comes an increased risk of implementation errors.
Previous ad-hoc delivery notification mechanisms sometimes produced a
storm of receipts due to unanticipated interactions with mailing list
expansion software. In this specification notification of successful
delivery is carefully designed so, if properly implemented, it cannot
interact with a list expander in this way.
The security considerations section in [5] describes security issues
associated with multipart/report objects in general and the security
considerations section in [3] describes security issues with DSNs in
particular.
9. Appendix - Type-Name Definitions
The following type names are defined for use in DSN fields generated
by conforming SMTP-based MTAs:
9.1 "rfc822" address-type
The "rfc822" address-type is to be used when reporting Internet
electronic mail address in the Original-Recipient and Final-Recipient
DSN fields.
(a) address-type name: rfc822
(b) syntax for mailbox addresses
RFC822 mailbox addresses are generally expected to be of the
form
[route] addr-spec
where "route" and "addr-spec" are defined in [2], and the
"domain" portions of both "route" and "addr-spec" are fully-
qualified domain names that are registered in the DNS. However,
an MTA MUST NOT modify an address obtained from the message
envelope to force it to conform to syntax rules.
(c) If addresses of this type are not composed entirely of graphic
characters from the US-ASCII repertoire, a specification for how
they are to be encoded as graphic US-ASCII characters in a DSN
Original-Recipient or Final-Recipient DSN field.
RFC822 addresses consist entirely of graphic characters from the
US-ASCII repertoire, so no translation is necessary.
9.2 "smtp" diagnostic-type
The "smtp" diagnostic-type is to be used when reporting SMTP reply-
codes in Diagnostic-Code DSN fields.
(a) diagnostic-type name: SMTP
(b) A description of the syntax to be used for expressing diagnostic
codes of this type as graphic characters from the US-ASCII
repertoire.
An SMTP diagnostic-code is of the form
*( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text
For a single-line SMTP reply to an SMTP command, the
diagnostic-code SHOULD be an exact transcription of the reply.
For multi-line SMTP replies, it is necessary to insert a SPACE
before each line after the first. For example, an SMTP reply
of:
550-mailbox unavailable
550 user has moved with no forwarding address
could appear as follows in a Diagnostic-Code DSN field:
Diagnostic-Code: smtp ; 550-mailbox unavailable
550 user has moved with no forwarding address
(c) A list of valid diagnostic codes of this type and the meaning of
each code.
SMTP reply-codes are currently defined in [1] and [11].
Additional codes may be defined by other RFCs.
9.3 "dns" MTA-name-type
The "dns" MTA-name-type should be used in the Reporting-MTA field.
An MTA-name of type "dns" is a fully-qualified domain name. The name
must be registered in the DNS, and the address Postmaster@{mta-name}
must be valid.
(a) MTA-name-type name: dns
(b) A description of the syntax of MTA names of this type, using
BNF, regular expressions, ASN.1, or other non-ambiguous
language.
MTA names of type "dns" SHOULD be valid Internet domain names.
If such domain names are not available, a domain-literal
containing the internet protocol address is acceptable. Such
domain names generally conform to the following syntax:
domain = real-domain / domain-literal
real-domain = sub-domain *("." sub-domain)
sub-domain = atom
domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]"
where "atom" and "DIGIT" are defined in [2].
(c) If MTA names of this type do not consist entirely of graphic
characters from the US-ASCII repertoire, a specification for how
an MTA name of this type should be expressed as a sequence of
graphic US-ASCII characters.
MTA names of type "dns" consist entirely of graphic US-ASCII
characters, so no translation is needed.
10. Appendix - Example
This example traces the flow of a single message addressed to
multiple recipients. The message is sent by Alice@Example.ORG to
Bob@Example.COM, Carol@Ivory.EDU, Dana@Ivory.EDU, Eric@Bombs.AF.MIL,
Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a variety of per-
recipient options. The message is successfully delivered to Bob,
Dana (via a gateway), Eric, and Fred. Delivery fails for Carol and
George.
NOTE: Formatting rules for RFCs require that no line be longer than
72 characters. Therefore, in the following examples, some SMTP
commands longer than 72 characters are printed on two lines, with the
first line ending in "\". In an actual SMTP transaction, such a
command would be sent as a single line (i.e., with no embedded
CRLFs), and without the "\" character that appears in these examples.
10.1 Submission
Alice's user agent sends the message to the SMTP server at
Example.ORG. Note that while this example uses SMTP as a mail
submission protocol, other protocols could also be used.
<<< 220 Example.ORG SMTP server here
>>> EHLO Example.ORG
<<< 250-Example.ORG
<<< 250-DSN
<<< 250-EXPN
<<< 250 SIZE
>>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
<<< 250 <Alice@Example.ORG> sender ok
>>> RCPT TO:<Bob@Example.COM> NOTIFY=SUCCESS \
ORCPT=rfc822;Bob@Example.COM
<<< 250 <Bob@Example.COM> recipient ok
>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
ORCPT=rfc822;Carol@Ivory.EDU
<<< 250 <Carol@Ivory.EDU> recipient ok
>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;Dana@Ivory.EDU
<<< 250 <Dana@Ivory.EDU> recipient ok
>>> RCPT TO:<Eric@Bombs.AF.MIL> NOTIFY=FAILURE \
ORCPT=rfc822;Eric@Bombs.AF.MIL
<<< 250 <Eric@Bombs.AF.MIL> recipient ok
>>> RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER
<<< 250 <Fred@Bombs.AF.MIL> recipient ok
>>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \
ORCPT=rfc822;George@Tax-ME.GOV
<<< 250 <George@Tax-ME.GOV> recipient ok
>>> DATA
<<< 354 okay, send message
>>> (message goes here)
>>> .
<<< 250 message accepted
>>> QUIT
<<< 221 goodbye
10.2 Relay to Example.COM
The SMTP at Example.ORG then relays the message to Example.COM. (For
the purpose of this example, mail.Example.COM is the primary mail
exchanger for Example.COM).
<<< 220 mail.Example.COM says hello
>>> EHLO Example.ORG
<<< 250-mail.Example.COM
<<< 250 DSN
>>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
<<< 250 sender okay
>>> RCPT TO:<Bob@Example.COM> NOTIFY=SUCCESS \
ORCPT=rfc822;Bob@Example.COM
<<< 250 recipient okay
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message received
>>> QUIT
<<< 221 bcnu
10.3 Relay to Ivory.EDU
The SMTP at Example.ORG relays the message to Ivory.EDU, which (as it
happens) is a gateway to a LAN-based mail system that accepts SMTP
mail and supports the DSN extension.
<<< 220 Ivory.EDU gateway to FooMail(tm) here
>>> EHLO Example.ORG
<<< 250-Ivory.EDU
<<< 250 DSN
>>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
<<< 250 ok
>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
ORCPT=rfc822;Carol@Ivory.EDU
<<< 550 error - no such recipient
>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;Dana@Ivory.EDU
<<< 250 recipient ok
>>> DATA
<<< 354 send message, end with '.'
>>> (message goes here)
>>> .
<<< 250 message received
>>> QUIT
<<< 221 bye
Note that since the Ivory.EDU refused to accept mail for
Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the
sender-SMTP (in this case Example.ORG) must generate a DSN.
10.4 Relay to Bombs.AF.MIL
The SMTP at Example.ORG relays the message to Bombs.AF.MIL, which
does not support the SMTP extension. Because the sender specified
NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Example.ORG
chooses to send the message for that recipient in a separate
transaction with a reverse-path of <>.
<<< 220-Bombs.AF.MIL reporting for duty.
<<< 220 Electronic mail is to be used for official business only.
>>> EHLO Example.ORG
<<< 502 command not implemented
>>> RSET
<<< 250 reset
>>> HELO Example.ORG
<<< 250 Bombs.AF.MIL
>>> MAIL FROM:<Alice@Example.ORG>
<<< 250 ok
>>> RCPT TO:<Eric@Bombs.AF.MIL>
<<< 250 ok
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message accepted
>>> MAIL FROM:<>
<<< 250 ok
>>> RCPT TO:<Fred@Bombs.AF.MIL>
<<< 250 ok
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message accepted
>>> QUIT
<<< 221 Bombs.AF.MIL closing connection
10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV
The SMTP at Example.ORG relays the message to Tax-ME.GOV. (this step
is not shown). MTA Tax-ME.GOV then forwards the message to
Sam@Boondoggle.GOV (shown below). Both Tax-ME.GOV and Example.ORG
support the SMTP DSN extension. Note that RET, ENVID, and ORCPT all
retain their original values.
<<< 220 BoonDoggle.GOV says hello
>>> EHLO Example.ORG
<<< 250-mail.Example.COM
<<< 250 DSN
>>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
<<< 250 sender okay
>>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCESS \
ORCPT=rfc822;George@Tax-ME.GOV
<<< 250 recipient okay
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message received
>>> QUIT
<<< 221 bcnu
10.6 "Delivered" DSN for Bob@Example.COM
MTA mail.Example.COM successfully delivers the message to
Bob@Example.COM. Because the sender specified NOTIFY=SUCCESS,
mail.Example.COM issues the following DSN, and sends it to
Alice@Example.ORG.
To: Alice@Example.ORG
From: postmaster@mail.Example.COM
Subject: Delivery Notification (success) for Bob@Example.COM
Content-Type: multipart/report; report-type=delivery-status;
boundary=abcde
MIME-Version: 1.0
--abcde
Content-type: text/plain; charset=us-ascii
Your message (id QQ314159) was successfully delivered to
Bob@Example.COM.
--abcde
Content-type: message/delivery-status
Reporting-MTA: dns; mail.Example.COM
Original-Envelope-ID: QQ314159
Original-Recipient: rfc822;Bob@Example.COM
Final-Recipient: rfc822;Bob@Example.COM
Action: delivered
Status: 2.0.0
--abcde
Content-type: message/rfc822
(headers of returned message go here)
--abcde--
10.7 Failed DSN for Carol@Ivory.EDU
Because delivery to Carol failed and the sender specified
NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Example.ORG (the SMTP client
to which the failure was reported via SMTP) issues the following DSN.
To: Alice@Example.ORG
From: postmaster@Example.ORG
Subject: Delivery Notification (failure) for Carol@Ivory.EDU
Content-Type: multipart/report; report-type=delivery-status;
boundary=bcdef
MIME-Version: 1.0
--bcdef
Content-type: text/plain; charset=us-ascii
Your message (id QQ314159) could not be delivered to
Carol@Ivory.EDU.
A transcript of the session follows:
(while talking to Ivory.EDU)
>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE
<<< 550 error - no such recipient
--bcdef
Content-type: message/delivery-status
Reporting-MTA: dns; Example.ORG
Original-Envelope-ID: QQ314159
Original-Recipient: rfc822;Carol@Ivory.EDU
Final-Recipient: rfc822;Carol@Ivory.EDU
SMTP-Remote-Recipient: Carol@Ivory.EDU
Diagnostic-Code: smtp; 550 error - no such recipient
Action: failed
Status: 5.0.0
--bcdef
Content-type: message/rfc822
(headers of returned message go here)
--bcdef--
10.8 Relayed DSN For Dana@Ivory.EDU
Although the mail gateway Ivory.EDU supports the DSN SMTP extension,
the LAN mail system attached to its other side does not generate
positive delivery confirmations. So Ivory.EDU issues a "relayed"
DSN:
To: Alice@Example.ORG
From: postmaster@Ivory.EDU
Subject: mail relayed for Dana@Ivory.EDU
Content-Type: multipart/report; report-type=delivery-status;
boundary=cdefg
MIME-Version: 1.0
--cdefg
Content-type: text/plain; charset=us-ascii
Your message (addressed to Dana@Ivory.EDU) was successfully
relayed to:
ymail!Dana
by the FooMail gateway at Ivory.EDU.
Unfortunately, the remote mail system does not support
confirmation of actual delivery. Unless delivery to ymail!Dana
fails, this will be the only Delivery Status Notification sent.
--cdefg
Content-type: message/delivery-status
Reporting-MTA: dns; Ivory.EDU
Original-Envelope-ID: QQ314159
Original-Recipient: rfc822;Dana@Ivory.EDU
Final-Recipient: rfc822;Dana@Ivory.EDU
Action: relayed
Status: 2.0.0
--cdefg
Content-type: message/rfc822
(headers of returned message go here)
--cdefg--
10.9 Failure notification for Sam@Boondoggle.GOV
The message originally addressed to George@Tax-ME.GOV was forwarded
to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to
deliver the message due to a lack of disk space in Sam's mailbox.
After trying for several days, Boondoggle.GOV returned the following
DSN:
To: Alice@Example.ORG
From: Postmaster@Boondoggle.GOV
Subject: Delivery failure for Sam@Boondoggle.GOV
Content-Type: multipart/report; report-type=delivery-status;
boundary=defgh
MIME-Version: 1.0
--defgh
Your message, originally addressed to George@Tax-ME.GOV, and
forwarded from there to Sam@Boondoggle.GOV could not be delivered,
for the following reason:
write error to mailbox, disk quota exceeded
--defgh
Content-type: message/delivery-status
Reporting-MTA: Boondoggle.GOV
Original-Envelope-ID: QQ314159
Original-Recipient: rfc822;George@Tax-ME.GOV
Final-Recipient: rfc822;Sam@Boondoggle.GOV
Action: failed
Status: 4.2.2 (disk quota exceeded)
--defgh
Content-type: message/rfc822
(headers of returned message go here)
--defgh--
11. Appendix - Changes since RFC1891
- updated author's address
- In examples, changed Pure-Heart.ORG and Big-Bucks.COM to
Example.ORG and Example.COM, respectively. Since publication
of RFC1891, the former two domains have been registered.
- Clarified that ENVID and ORCPT parameters must consist
entirely of US-ASCII characters prior to encoding as xtext.
- A Security Considerations section was added.
12. References
12.1 Normative References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821,
August 1982.
[2] Crocker, D., "Standard for the format of ARPA Internet Text
Messages", STD 11, RFC822, August 1982.
[3] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC3464, January 2003.
[4] Coded Character Set - 7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[5] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC3462,
January 2003.
[6] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC3463,
January 2003.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
12.2 Informative References
[8] Westine, A. and J. Postel, "Problems with the Maintenance of
Large Mailing Lists.", RFC1211, March 1991.
[9] Crispin, M., "Internet Message Access Protocol - Version 4rev1",
RFC2060, December 1996.
[10] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
53, RFC1939, May 1996.
[11] Braden, R., Ed., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC1123, October 1989.
13. Author's Address
Keith Moore
University of Tennessee
1122 Volunteer Blvd, Suite 203
Knoxville, TN 37996-3450
USA
EMail: moore@cs.utk.edu
14. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.