📄 rfc2298.txt
字号:
(b) The first component of the multipart/report contains a human-
readable explanation of the MDN, as described in RFC 1892 [7].
(c) The second component of the multipart/report is of content-type
message/disposition-notification, described in section 3.1 of
this document.
(d) If the original message or a portion of the message is to be
returned to the sender, it appears as the third component of the
multipart/report. The decision of whether or not to return the
message or part of the message is up to the UA generating the
MDN. However, in the case of encrypted messages requesting
MDNs, encrypted message text MUST be returned, if it is returned
at all, only in its original encrypted form.
NOTE: For message dispostion notifications gatewayed from
foreign systems, the headers of the original message may not be
available. In this case the third component of the MDN may be
omitted, or it may contain "simulated" RFC 822 headers which
contain equivalent information. In particular, it is very
desirable to preserve the subject and date fields from the
original message.
The MDN MUST be addressed (in both the message header and the
transport envelope) to the address(es) from the Disposition-
Notification-To header from the original message for which the MDN is
being generated.
The From field of the message header of the MDN MUST contain the
address of the person for whom the message disposition notification
is being issued.
The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be
null (<>), specifying that no Delivery Status Notification messages
or other messages indicating successful or unsuccessful delivery are
to be sent in response to an MDN.
A message disposition notification MUST NOT itself request an MDN.
That is, it MUST NOT contain a Disposition-Notification-To header.
The Message-ID header (if present) for an MDN MUST be different from
the Message-ID of the message for which the MDN is being issued.
A particular MDN describes the disposition of exactly one message for
exactly one recipient. Multiple MDNs may be generated as a result of
one message submission, one per recipient. However, due to the
circumstances described in Section 2.1, MDNs may not be generated for
some recipients for which MDNs were requested.
3.1 The message/disposition-notification content-type
The message/disposition-notification content-type is defined as
follows:
MIME type name: message
MIME subtype name: disposition-notification
Optional parameters: none
Encoding considerations: "7bit" encoding is sufficient and
MUST be used to maintain readability
when viewed by non-MIME mail
readers.
Security considerations: discussed in section 6 of this memo.
The message/disposition-notification report type for use in the
multipart/report is "disposition-notification".
The body of a message/disposition-notification consists of one or
more "fields" formatted according to the ABNF of RFC 822 header
"fields" (see [2]). Using the ABNF of RFC 822, the syntax of the
message/disposition-notification content is as follows:
disposition-notification-content = [ reporting-ua-field CRLF ]
[ 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 )
3.1.1 General conventions for fields
Since these fields are defined according to the rules of RFC 822 [2],
the same conventions for continuation lines and comments apply.
Notification fields may be continued onto multiple lines by beginning
each additional line with a SPACE or HTAB. Text which appears in
parentheses is considered a comment and not part of the contents of
that notification field. Field names are case-insensitive, so the
names of notification fields may be spelled in any combination of
upper and lower case letters. Comments in notification fields may
use the "encoded-word" construct defined in RFC 2047 [6].
3.1.2 "*-type" subfields
Several fields consist of a "-type" subfield, followed by a semi-
colon, followed by "*text". For these fields, the keyword used in
the address-type or MTA-type subfield indicates the expected format
of the address or MTA-name that follows.
The "-type" subfields are defined as follows:
(a) An "address-type" specifies the format of a mailbox address.
For example, Internet Mail addresses use the "rfc822" address-
type.
address-type = atom
(b) An "MTA-name-type" specifies the format of a mail transfer
agent name. For example, for an SMTP server on an Internet
host, the MTA name is the domain name of that host, and the
"dns" MTA-name-type is used.
mta-name-type = atom
Values for address-type and mta-name-type are case-insensitive. Thus
address-type values of "RFC822" and "rfc822" are equivalent.
The Internet Assigned Numbers Authority (IANA) will maintain a
registry of address-type and mta-name-type values, along with
descriptions of the meanings of each, or a reference to a one or more
specifications that provide such descriptions. (The "rfc822"
address-type is defined in RFC 1891 [8].) Registration forms for
address-type and mta-name-type appear in RFC 1894 [9].
IANA will not accept registrations for any address-type name that
begins with "X-". These type names are reserved for experimental
use.
3.1.3 Lexical tokens imported from RFC 822
The following lexical tokens, defined in RFC 822 [2], are used in the
ABNF grammar for MDNs: atom, CRLF, mailbox, msg-id, text.
3.2 Message/disposition-notification Fields
3.2.1 The Reporting-UA field
reporting-ua-field = "Reporting-UA" ":" ua-name
[ ";" ua-product ]
ua-name = *text
ua-product = *text
The Reporting-UA field is defined as follows:
A MDN describes the disposition of a message after it has been
delivered to a recipient. In all cases, the Reporting-UA is the UA
that performed the disposition described in the MDN. This field is
optional, but recommended. For Internet Mail user agents, it is
recommended that this field contain both the DNS name of the
particular instance of the UA that generated the MDN and the name of
the product. For example,
Reporting-UA: rogers-mac.dcrt.nih.gov; Foomail 97.1
If the reporting UA consists of more than one component (e.g., a base
program and plug-ins), this may be indicated by including a list of
product names.
3.2.2 The MDN-Gateway field
The MDN-Gateway field indicates the name of the gateway or MTA that
translated a foreign (non-Internet) message disposition notification
into this MDN. This field MUST appear in any MDN which was
translated by a gateway from a foreign system into MDN format, and
MUST NOT appear otherwise.
mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
mta-name = *text
For gateways into Internet Mail, the MTA-name-type will normally be
"smtp", and the mta-name will be the Internet domain name of the
gateway.
3.2.3 Original-Recipient field
The Original-Recipient field indicates the original recipient address
as specified by the sender of the message for which the MDN is being
issued. For Internet Mail messages the value of the
Original-Recipient field is obtained from the Original-Recipient
header from the message for which the MDN is being generated. If
there is no Original-Recipient header in the message, then the
Original-Recipient field MUST be omitted, unless the same information
is reliably available some other way. If there is an Original-
Recipient header in the original message (or original recipient
information is reliably available some other way), then the
Original-Recipient field must be supplied. If there is more than one
Original-Recipient header in the message, the UA may choose the one
to use or act as if no Original-Recipient header is present.
original-recipient-field =
"Original-Recipient" ":" address-type ";" generic-address
generic-address = *text
The address-type field indicates the type of the original recipient
address. If the message originated within the Internet, the
address-type field field will normally be "rfc822", and the address
will be according to the syntax specified in RFC 822 [2]. The value
"unknown" should be used if the Reporting UA cannot determine the
type of the original recipient address from the message envelope.
This address is the same as that provided by the sender and can be
used to automatically correlate MDN reports with original messages on
a per recipient basis.
3.2.4 Final-Recipient field
The Final-Recipient field indicates the recipient for which the MDN
is being issued. This field MUST be present.
The syntax of the field is as follows:
final-recipient-field =
"Final-Recipient" ":" address-type ";" generic-address
The generic-address subfield of the Final-Recipient field MUST
contain the mailbox address of the recipient (from the From header of
the MDN) as it was when the MDN was generated by the UA.
The Final-Recipient address may differ from the address originally
provided by the sender, because it may have been transformed during
forwarding and gatewaying into an totally unrecognizable mess.
However, in the absence of the optional Original-Recipient field, the
Final-Recipient field and any returned content may be the only
information available with which to correlate the MDN with a
particular message recipient.
The address-type subfield indicates the type of address expected by
the reporting MTA in that context. Recipient addresses obtained via
SMTP will normally be of address-type "rfc822".
Since mailbox addresses (including those used in the Internet) may be
case sensitive, the case of alphabetic characters in the address MUST
be preserved.
3.2.5 Original-Message-ID field
The Original-Message-ID field indicates the message-ID of the message
for which the MDN is being issued. It is obtained from the Message-
ID header of the message for which the MDN is issued. This field
MUST be present if the original message contained a Message-ID
header. The syntax of the field is
original-message-id-field = "Original-Message-ID" ":" msg-id
The msg-id token is as specified in RFC 822 [2].
3.2.6 Disposition field
The Disposition field indicates the action performed by the
Reporting-UA on behalf of the user. This field MUST be present.
The syntax for the Disposition field is:
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
The disposition-mode, disposition-type and disposition-modifier may
be spelled in any combination of upper and lower case characters.
3.2.6.1 Disposition modes
The following disposition modes are defined:
"manual-action" The disposition described by the
disposition type was a result of an
explicit instruction by the user rather
than some sort of automatically performed
action.
"automatic-action" The disposition described by the
disposition type was a result of an
automatic action, rather than an explicit
instruction by the user for this message.
"Manual-action" and "automatic-action" are
mutually exclusive. One or the other must
be specified.
"MDN-sent-manually" The user explicity gave permission for
this particular MDN to be sent.
"MDN-sent-automatically" The MDN was sent because the UA had
previously been configured to do so
automatically.
"MDN-sent-manually" and "MDN-sent-
automatically" are mutually exclusive.
One or the other must be specified.
3.2.6.2 Disposition types
The following disposition-types are defined:
"displayed" The message has been displayed by the UA to someone
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -