Bob@Big-Bucks.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 Pure-
Heart.ORG. Note that while this example uses SMTP as a mail
submission protocol, other protocols could also be used.
<<< 220 Pure-Heart.ORG SMTP server here
>>> EHLO Pure-Heart.ORG
<<< 250-Pure-Heart.ORG
<<< 250-DSN
<<< 250-EXPN
<<< 250 SIZE
>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
<<< 250 <Alice@Pure-Heart.ORG> sender ok
>>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \
ORCPT=rfc822;Bob@Big-Bucks.COM
<<< 250 <Bob@Big-Bucks.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 Big-Bucks.COM
The SMTP at Pure-Heart.ORG then relays the message to Big-Bucks.COM.
(For the purpose of this example, mail.Big-Bucks.COM is the primary
mail exchanger for Big-Bucks.COM).
<<< 220 mail.Big-Bucks.COM says hello
>>> EHLO Pure-Heart.ORG
<<< 250-mail.Big-Bucks.COM
<<< 250 DSN
>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
<<< 250 sender okay
>>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \
ORCPT=rfc822;Bob@Big-Bucks.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 Pure-Heart.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 Pure-Heart.ORG
<<< 250-Ivory.EDU
<<< 250 DSN
>>> MAIL FROM:<Alice@Pure-Heart.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 Pure-Heart.ORG) must generate a DSN.
10.4 Relay to Bombs.AF.MIL
The SMTP at Pure-Heart.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 Pure-
Heart.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 Pure-Heart.ORG
<<< 502 command not implemented
>>> RSET
<<< 250 reset
>>> HELO Pure-Heart.ORG
<<< 250 Bombs.AF.MIL
>>> MAIL FROM:<Alice@Pure-Heart.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 Pure-Heart.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 Pure-Heart.ORG
support the SMTP DSN extension. Note that RET, ENVID, and ORCPT all
retain their original values.
<<< 220 BoonDoggle.GOV says hello
>>> EHLO Pure-Heart.ORG
<<< 250-mail.Big-Bucks.COM
<<< 250 DSN
>>> MAIL FROM:<Alice@Pure-Heart.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@Big-Bucks.COM
MTA mail.Big-Bucks.COM successfully delivers the message to Bob@Big-
Bucks.COM. Because the sender specified NOTIFY=SUCCESS, mail.Big-
Bucks.COM issues the following DSN, and sends it to Alice@Pure-
Heart.ORG.
To: Alice@Pure-Heart.ORG
From: postmaster@mail.Big-Bucks.COM
Subject: Delivery Notification (success) for Bob@Big-Bucks.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@Big-Bucks.COM.
--abcde
Content-type: message/delivery-status
Reporting-MTA: dns; mail.Big-Bucks.COM
Original-Envelope-ID: QQ314159
Original-Recipient: rfc822;Bob@Big-Bucks.COM
Final-Recipient: rfc822;Bob@Big-Bucks.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 Pure-Heart.ORG (the SMTP
client to which the failure was reported via SMTP) issues the
following DSN.
To: Alice@Pure-Heart.ORG
From: postmaster@Pure-Heart.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; Pure-Heart.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@Pure-Heart.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@BigHeart.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. References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821,
USC/Information Sciences Institute, August 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC822, UDEL, August 1982.
[3] Westine, A., and J. Postel, "Problems with the Maintenance of
Large Mailing Lists.", RFC1211, USC/Information Sciences
Institute, March 1991.
[4] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
"SMTP Service Extensions", RFC1651, MCI, Innosoft, Dover Beach
Consulting, Inc., Network Management Associates, Inc., Silicon
Graphics, Inc., July 1994.
[5] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC1894, University of Tennessee,
Octel Network Services, January 1996.
[6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC
1730, University of Washington, 20 December 1994.
[7] Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC
1725, Carnegie Mellon, Dover Beach Consulting, November 1994.
[8] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC1892, Octel
Network Services, January 1996.
[9] Braden, R., Editor, "Requirements for Internet Hosts - Application
and Support", STD 3, RFC1123, IETF, October 1989.
[10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC1893,
Octel Network Services, January 1996.
12. Author's Address
Keith Moore
University of Tennessee
107 Ayres Hall
Knoxville, TN 37996-1301
USA