rfc2298.txt

用C#开发实现SMTP相关技术,能接收到带附件的邮件服务功能.

        [ mdn-gateway-field CRLF ]
        [ original-recipient-field CRLF ]
        final-recipient-field CRLF
        [ original-message-id-field CRLF ]
        disposition-field CRLF
        *( failure-field CRLF )
        *( error-field CRLF )
        *( warning-field CRLF )
        *( extension-field CRLF )

   address-type = atom

   mta-name-type = atom

   reporting-ua-field = "Reporting-UA" ":" ua-name
                        [ ";" ua-product ]

   ua-name = *text

   ua-product = *text

   mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name

   mta-name = *text

   original-recipient-field =
        "Original-Recipient" ":" address-type ";" generic-address

   generic-address = *text

   final-recipient-field =
        "Final-Recipient" ":" address-type ";" generic-address

   disposition-field = "Disposition" ":" disposition-mode ";"
                       disposition-type

                       [ '/' disposition-modifier
                         *( "," dispostion-modifier ) ]

   disposition-mode = action-mode "/" sending-mode

   action-mode = "manual-action" / "automatic-action"

   sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"

   disposition-type = "displayed"
                    / "dispatched"
                    / "processed"
                    / "deleted"
                    / "denied"
                    / "failed"

   disposition-modifier = ( "error" / "warning" )
                        / ( "superseded" / "expired" /
                            "mailbox-terminated" )
                        / disposition-modifier-extension

   disposition-modifier-extension = atom

   original-message-id-field = "Original-Message-ID" ":" msg-id

   failure-field = "Failure" ":" *text

   error-field = "Error" ":" *text

   warning-field = "Warning" ":" *text

   extension-field = extension-field-name ":" *text

   extension-field-name = atom

8.  Guidelines for Gatewaying MDNs

   NOTE:  This section provides non-binding recommendations for the
   construction of mail gateways that wish to provide semi-transparent
   disposition notifications between the Internet and another electronic
   mail system.  Specific MDN gateway requirements for a particular pair
   of mail systems may be defined by other documents.

8.1 Gatewaying from other mail systems to MDNs

   A mail gateway may issue an MDN to convey the contents of a "foreign"
   disposition notification over Internet Mail.  When there are
   appropriate mappings from the foreign notification elements to MDN

   fields, the information may be transmitted in those MDN fields.
   Additional information (such as might be needed to tunnel the foreign
   notification through the Internet) may be defined in extension MDN
   fields.  (Such fields should be given names that identify the foreign
   mail protocol, e.g. X400-* for X.400 protocol elements)

   The gateway must attempt to supply reasonable values for the
   Reporting-UA, Final-Recipient, and Disposition fields.  These will
   normally be obtained by translating the values from the foreign
   notification into their Internet-style equivalents.  However, some
   loss of information is to be expected.

   The sender-specified recipient address, and the original message-id,
   if present in the foreign notification, should be preserved in the
   Original-Recipient and Original-Message-ID fields.

   The gateway should also attempt to preserve the "final" recipient
   address from the foreign system.  Whenever possible, foreign protocol
   elements should be encoded as meaningful printable ASCII strings.

   For MDNs produced from foreign disposition notifications, the name of
   the gateway MUST appear in the MDN-Gateway field of the MDN.

8.2 Gatewaying from MDNs to other mail systems

   It may be possible to gateway MDNs from the Internet into a foreign
   mail system.  The primary purpose of such gatewaying is to convey
   disposition information in a form that is usable by the destination
   system.  A secondary purpose is to allow "tunneling" of MDNs through
   foreign mail systems, in case the MDN may be gatewayed back into the
   Internet.

   In general, the recipient of the MDN (i.e., the sender of the
   original message) will want to know, for each recipient:  the closest
   available approximation to the original recipient address, and the
   disposition (displayed, printed, etc.).

   If possible, the gateway should attempt to preserve the Original-
   Recipient address and Original-Message-ID (if present), in the
   resulting foreign disposition report.

   If it is possible to tunnel an MDN through the destination
   environment, the gateway specification may define a means of
   preserving the MDN information in the disposition reports used by
   that environment.

9.  Example

   NOTE:  This example is provided as illustration only, and is not
   considered part of the MDN protocol specification.  If the example
   conflicts with the protocol definition above, the example is wrong.

   Likewise, the use of *-type subfield names or extension fields in
   this example is not to be construed as a definition for those type
   names or extension fields.

9.1 This is an MDN issued after a message has been displayed to the user
   of an Internet Mail user agent.

   Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
   From: Joe Recipient <[e-mail]>
   Message-Id: <news:[e-mail]>
   Subject: Disposition notification
   To: Jane Sender <[e-mail]>
   MIME-Version: 1.0
   Content-Type: multipart/report; report-type=disposition-notification;
         boundary="RAA14128.773615765/mega.edu"

   --RAA14128.773615765/mega.edu

   The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe
   Recipient <[e-mail]> with subject "First draft of
   report" has been displayed.  This is no guarantee that the message
   has been read or understood.

   --RAA14128.773615765/mega.edu
   content-type: message/disposition-notification

   Reporting-UA: joes-pc.cs.mega.edu; Foomail 97.1
   Original-Recipient: rfc822;[e-mail]
   Final-Recipient: rfc822;[e-mail]
   Original-Message-ID: <news:[e-mail]>
   Disposition: manual-action/MDN-sent-manually; displayed

   --RAA14128.773615765/mega.edu
   content-type: message/rfc822

   [original message goes here]

   --RAA14128.773615765/mega.edu--

10.  IANA Registration Forms

   The forms below are for use when registering a new parameter name for
   the Disposition-Notification-Options header, a new disposition
   modifier name, or a new MDN extension field.  Each piece of
   information required by a registration form may be satisfied either
   by providing the information on the form itself, or by including a
   reference to a published, publicly available specification that
   includes the necessary information.  IANA MAY reject registrations
   because of incomplete registration forms, imprecise specifications,
   or inappropriate names.

   To register, complete the applicable form below and send it via
   electronic mail to <[e-mail]>.

10.1 IANA registration form for Disposition-Notification-Options header
   parameter names

   A registration for a Disposition-Notification-Options header
   parameter name MUST include the following information:

   (a) The proposed parameter name.

   (b) The syntax for parameter values, specified using BNF, ABNF,
   regular expressions, or other non-ambiguous language.

   (c) If parameter values 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 Disposition-
   Notification-Options header.

   (d) A reference to a standards track RFC or experimental RFC approved
   by the IESG that describes the semantics of the parameter values.

10.2 IANA registration form for disposition modifer names

   A registration for a disposition-modifier name MUST include the
   following information:

   (a) The proposed disposition-modifier name.

   (b) A reference to a standards track RFC or experimental RFC approved
   by the IESG that describes the semantics of the disposition modifier.

10.3 IANA registration form for MDN extension field names

   A registration for an MDN extension field name MUST include the
   following information:

   (a) The proposed extension field name.

   (b) The syntax for extension values, specified using BNF, ABNF,
   regular expressions, or other non-ambiguous language.

   (c) If extension field values 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 Disposition-
   Notification-Options header.

   (d) A reference to a standards track RFC or experimental RFC approved
   by the IESG that describes the semantics of the extension field.

11.  Acknowledgments

   This document is based on the Delivery Status Notifications document,
   RFC 1894 [9], by Keith Moore and Greg Vaudreuil.  Contributions were
   made by members of the IETF Receipt Working Group, including Harald
   Alverstrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned
   Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell,
   Pete Resnick, Chuck Shih.

12.  References

   [1]   Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
         August 1982.

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

   [3]   Braden, R. (ed.), "Requirements for Internet Hosts -
         Application and Support", STD 3, RFC 1123, October 1989.

   [4]   Freed, N., and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One:  Format of Internet Message
         Bodies", RFC 2045, November 1996.

   [5]   Freed, N., and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part Two:  Media Types", RFC 2046, November
         1996.

   [6]   Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part
         Three:  Message Header Extensions for Non-Ascii Text", RFC
         2047, November 1996.

   [7]   Vaudreuil, G., "The Multipart/Report Content Type for the
         Reporting of Mail System Administrative Messages", RFC 1892,
         January 1996.

   [8]   Moore, K., "SMTP Service Extension for Delivery Status
         Notifications", RFC 1891, January 1996.

   [9]   Moore, K., and G. Vaudreuil, "An Extensible Format for
         Delivery Status Notifications, RFC 1894, January 1996.

   [10]  Bradner, S., "Key Words for Use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, March 1997.

13.  Author's Address

   Roger Fajman
   National Institutes of Health
   Building 12A, Room 3063
   12 South Drive MSC 5659
   Bethesda, Maryland 20892-5659
   USA

   EMail:  [e-mail]
   Phone:  [phone]
   Fax:    [phone]

14.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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.