rfc1891.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message accepted
>>> MAIL FROM:<>
<<< 250 ok



Moore                       Standards Track                    [Page 25]

RFC 1891           SMTP Delivery Status Notifications       January 1996


>>> RCPT TO:<[e-mail]>
<<< 250 ok
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message accepted
>>> QUIT
<<< 221 Bombs.AF.MIL closing connection

10.5 Forward from [e-mail] to [e-mail]

   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
   [e-mail] (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:<[e-mail]> RET=HDRS ENVID=QQ314159
<<< 250 sender okay
>>> RCPT TO:<[e-mail]> NOTIFY=SUCCESS \
    ORCPT=rfc822;[e-mail]
<<< 250 recipient okay
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message received
>>> QUIT
<<< 221 bcnu

















Moore                       Standards Track                    [Page 26]

RFC 1891           SMTP Delivery Status Notifications       January 1996


10.6 "Delivered" DSN for [e-mail]

   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: [e-mail]
From: [e-mail]
Subject: Delivery Notification (success) for [e-mail]
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
[e-mail].

--abcde
Content-type: message/delivery-status

Reporting-MTA: dns; mail.Big-Bucks.COM
Original-Envelope-ID: QQ314159

Original-Recipient: rfc822;[e-mail]
Final-Recipient: rfc822;[e-mail]
Action: delivered
Status: 2.0.0

--abcde
Content-type: message/rfc822

(headers of returned message go here)

--abcde--














Moore                       Standards Track                    [Page 27]

RFC 1891           SMTP Delivery Status Notifications       January 1996


10.7 Failed DSN for [e-mail]

   Because delivery to Carol failed and the sender specified
   NOTIFY=FAILURE for [e-mail], MTA Pure-Heart.ORG (the SMTP
   client to which the failure was reported via SMTP) issues the
   following DSN.

To: [e-mail]
From: [e-mail]
Subject: Delivery Notification (failure) for [e-mail]
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
[e-mail].

A transcript of the session follows:

(while talking to Ivory.EDU)
>>> RCPT TO:<[e-mail]> 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;[e-mail]
Final-Recipient: rfc822;[e-mail]
SMTP-Remote-Recipient: [e-mail]
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--






Moore                       Standards Track                    [Page 28]

RFC 1891           SMTP Delivery Status Notifications       January 1996


10.8 Relayed DSN For [e-mail]

   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: [e-mail]
From: [e-mail]
Subject: mail relayed for [e-mail]
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 [e-mail]) 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;[e-mail]
Final-Recipient: rfc822;[e-mail]
Action: relayed
Status: 2.0.0

--cdefg
Content-type: message/rfc822

(headers of returned message go here)

--cdefg--






Moore                       Standards Track                    [Page 29]

RFC 1891           SMTP Delivery Status Notifications       January 1996


10.9 Failure notification for [e-mail]

   The message originally addressed to [e-mail] was forwarded
   to [e-mail], 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: [e-mail]
From: [e-mail]
Subject: Delivery failure for [e-mail]
Content-Type: multipart/report; report-type=delivery-status;
              boundary=defgh
MIME-Version: 1.0

--defgh
Your message, originally addressed to [e-mail], and forwarded
from there to [e-mail] 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;[e-mail]
Final-Recipient: rfc822;[e-mail]
Action: failed
Status: 4.2.2 (disk quota exceeded)

--defgh
Content-type: message/rfc822

(headers of returned message go here)

--defgh--












Moore                       Standards Track                    [Page 30]

RFC 1891           SMTP Delivery Status Notifications       January 1996


11. References

   [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
       USC/Information Sciences Institute, August 1982.

   [2] Crocker, D., "Standard for the Format of ARPA Internet Text
       Messages", STD 11, RFC 822, UDEL, August 1982.

   [3] Westine, A., and J. Postel, "Problems with the Maintenance of
       Large Mailing Lists.", RFC 1211, USC/Information Sciences
       Institute, March 1991.

   [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
       "SMTP Service Extensions", RFC 1651, 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", RFC 1894, 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", RFC 1892, Octel
       Network Services, January 1996.

   [9] Braden, R., Editor, "Requirements for Internet Hosts - Application
       and Support", STD 3, RFC 1123, IETF, October 1989.

   [10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
        Octel Network Services, January 1996.

12. Author's Address

   Keith Moore
   University of Tennessee
   107 Ayres Hall
   Knoxville, TN 37996-1301
   USA

   EMail: [e-mail]





Moore                       Standards Track                    [Page 31]