📄 rfc2298.txt
字号:
reading the recipient's mailbox. There is
no guarantee that the content has been
read or understood.
"dispatched" The message has been sent somewhere in some manner
(e.g., printed, faxed, forwarded) without
necessarily having been previously
displayed to the user. The user may or
may not see the message later.
"processed" The message has been processed in some manner (i.e.,
by some sort of rules or server) without
being displayed to the user. The user may
or may not see the message later, or there
may not even be a human user associated
with the mailbox.
"deleted" The message has been deleted. The recipient may or
may not have seen the message. The
recipient might "undelete" the message at
a later time and read the message.
"denied" The recipient does not wish the sender to be informed
of the message's disposition. A UA may
also siliently ignore message disposition
requests in this situation.
"failed" A failure occurred that prevented the proper
generation of an MDN. More information
about the cause of the failure may be
contained in a Failure field. The
"failed" disposition type is not to be
used for the situation in which there is
is some problem in processing the message
other than interpreting the request for an
MDN. The "processed" or other disposition
type with appropriate disposition
modifiers is to be used in such
situations.
3.2.6.3 Disposition modifiers
The following disposition modifiers are defined:
"error" An error of some sort occurred
that prevented successful
processing of the message.
Further information is contained
in an Error field.
"warning" The message was successfully
processed but some sort of
exceptional condition occurred.
Further information is contained
in a Warning field.
"superseded" The message has been
automatically rendered obsolete by
another message received. The
recipient may still access and
read the message later.
"expired" The message has reached its
expiration date and has been
automatically removed from the
recipient's mailbox.
"mailbox-terminated" The recipient's mailbox has been
terminated and all message in it
automatically removed.
"Obsoleted", "expired", and
"terminated" are to be used with
the "deleted" disposition type and
the "autoaction" and "autosent"
disposition modifiers.
disposition-modifier-extension Additional disposition modifiers
may be defined in the future by
later revisions or extensions to
this specification. Disposition
value names beginning with "X-"
will never be defined as standard
values; such names are reserved
for experimental use. MDN
disposition value names NOT
beginning with "X-" MUST be
registered with the Internet
Assigned Numbers Authority (IANA)
and described in a standards-
track RFC or an experimental RFC
approved by the IESG. See Section
10 for a registration form. MDNs
with disposition modifier names
not understood by the receiving UA
MAY be silently ignored or placed
in the user's mailbox without
special inter- pretation. They
MUST not cause any error message
to be sent to the sender of the
MDN.
If an UA developer does not wish
to register the meanings of such
disposition modifier extensions,
"X-" modifiers may be used for
this purpose. To avoid name
collisions, the name of the UA
implementation should follow the
"X-", (e.g. "X-Foomail-fratzed").
It is not required that a UA be able to generate all of the possible
values of the Disposition field.
One and only one MDN may be issued on behalf of each particular
recipient by their user agent. That is, once an MDN has been issued
on behalf of a recipient, no further MDNs may be issued on behalf of
that recipient, even if another disposition is performed on the
message. However, if a message is forwarded, a "dispatched" MDN may
been issued for the recipient doing the forwarding and the recipient
of the forwarded message may also cause an MDN to be generated.
3.2.7 Failure, Error and Warning fields
The Failure, Error and Warning fields are used to supply additional
information in the form of text messages when the "failure"
disposition type, "error" disposition modifier, and/or the "warning"
disposition modifer appear. The syntax is
failure-field = "Failure" ":" *text
error-field = "Error" ":" *text
warning-field = "Warning" ":" *text
3.3 Extension fields
Additional MDN fields may be defined in the future by later revisions
or extensions to this specification. Extension-field names beginning
with "X-" will never be defined as standard fields; such names are
reserved for experimental use. MDN field names NOT beginning with
"X-" MUST be registered with the Internet Assigned Numbers Authority
(IANA) and described in a standards-track RFC or an experimental RFC
approved by the IESG. See Section 10 for a registration form.
Extension MDN fields may be defined for the following reasons:
(a) To allow additional information from foreign disposition
reports to be tunneled through Internet MDNs. The names of such
MDN fields should begin with an indication of the foreign
environment name (e.g. X400-Physical-Forwarding-Address).
(b) To allow transmission of diagnostic information which is
specific to a particular user agent (UA). The names of such MDN
fields should begin with an indication of the UA implementation
which produced the MDN. (e.g. Foomail-information).
If an application developer does not wish to register the meanings of
such extension fields, "X-" fields may be used for this purpose. To
avoid name collisions, the name of the application implementation
should follow the "X-", (e.g. "X-Foomail-Log-ID" or "X-EDI-info").
4. Timeline of events
The following timeline shows when various events in the processing of
a message and generation of MDNs take place:
-- User composes message
-- User tells UA to send message
-- UA passes message to MTA (original recipient information
passed along)
-- MTA sends message to next MTA
-- Final MTA receives message
-- Final MTA delivers message to UA (possibily generating DSN)
-- UA performs automatic processing and generates corresponding
MDNs ("dispatched", "processed", "deleted", "denied" or "failed"
disposition type with "automatic-action" and "MDN-sent-
automatically" disposition modes)
-- UA displays list of messages to user
-- User selects a message and requests that some action be
performed on it.
-- UA performs requested action and, with user's permission,
sends appropriate MDN ("displayed", "dispatched", "processed",
"deleted", "denied" or "failed" disposition type with "manual-
action" and "MDN-sent-manually" or "MDN-sent-automatically"
disposition mode).
-- User possibly performs other actions on message, but no
further MDNs are generated.
5. Conformance and Usage Requirements
A UA or gateway conforms to this specification if it generates MDNs
according to the protocol defined in this memo. It is not necessary
to be able to generate all of the possible values of the Disposition
field.
UAs and gateways MUST NOT generate the Original-Recipient field of an
MDN unless the mail protocols provide the address originally
specified by the sender at the time of submission. Ordinary SMTP
does not make that guarantee, but the SMTP extension defined in RFC
1891 [8] permits such information to be carried in the envelope if it
is available. The Original-Recipient header defined in this document
provides a way for the MTA to pass the original recipient address to
the UA.
Each sender-specified recipient address may result in more than one
MDN. If an MDN is requested for a recipient that is forwarded to
multiple recipients of an "alias" (as defined in RFC 1891 [8],
section 6.2.7.3), each of the recipients may issue an MDN.
Successful distribution of a message to a mailing list exploder
SHOULD be considered final disposition of the message. A mailing
list exploder may issue an MDN with a disposition type of "processed"
and disposition modes of "automatic-action" and "MDN- sent-
automatically" indicating that the message has been forwarded to the
list. In this case, the request for MDNs is not propogated to the
members of the list.
Alternaively, the mailing list exploder may issue no MDN and
propogate the request for MDNs to all members of the list. The
latter behavior is not recommended for any but small, closely knit
lists, as it might cause large numbers of MDNs to be generated and
may cause confidential subscribers to the list to be revealed. It is
also permissible for the mailing list exploder to direct MDNs to
itself, correlate them, and produce a report to the original sender
of the message.
This specification places no restrictions on the processing of MDNs
received by user agents or mailing lists.
6. Security Considerations
The following security considerations apply when using MDNs:
6.1 Forgery
MDNs may be forged as easily as ordinary Internet electronic mail.
User agents and automatic mail handling facilities (such as mail
distribution list exploders) that wish to make automatic use of MDNs
should take appropriate precautions to minimize the potential damage
from denial-of-service attacks.
Security threats related to forged MDNs include the sending of:
(a) A falsified disposition notification when the indicated
disposition of the message has not actually ocurred,
(b) Unsolicited MDNs
6.2 Confidentiality
Another dimension of security is confidentiality. There may be cases
in which a message recipient does not wish the disposition of
messages addressed to him to be known or is concerned that the
sending of MDNs may reveal other confidential information (e.g., when
the message was read). In this situation, it is acceptable for the
UA to issue "denied" MDNs or to silently ignore requests for MDNs.
If the Disposition-Notification-To header is passed on unmodified
when a message is distributed to the subscribers of a mailing list,
the subscribers to the list may be revealed to the sender of the
original message by the generation of MDNs.
Headers of the original message returned in part 3 of the
multipart/report could reveal confidential information about host
names and/or network topology inside a firewall.
An unencrypted MDN could reveal confidential information about an
encrypted message, especially if all or part of the original message
is returned in part 3 of the multipart/report. Encrypted MDNs are
not defined in this specification.
In general, any optional MDN field may be omitted if the Reporting UA
site or user determines that inclusion of the field would impose too
great a compromise of site confidentiality. The need for such
confidentiality must be balanced against the utility of the omitted
information in MDNs.
6.3 Non-Repudiation
Within the framework of today's Internet Mail, the MDNs defined in
this document provide valuable information to the mail user; however,
MDNs can not be relied upon as a guarantee that a message was or was
not not seen by the recipient. Even if MDNs are not actively forged,
they may be lost in transit. The MDN issuing mechanism may be
bypassed in some manner by the recipient.
7. Collected Grammar
NOTE: The following lexical tokens are defined in RFC 822: atom,
CRLF, mailbox, msg-id, text. The definitions of attribute and value
are as in the definition of the Content-Type header in RFC 2045 [4].
Message headers:
mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox
Disposition-Notification-Options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
disposition-notification-parameters = parameter *(";" parameter)
parameter = attribute "=" importance "," 1#value
importance = "required" / "optional"
original-recipient-header =
"Original-Recipient" ":" address-type ";" generic-address
Report content:
disposition-notification-content = [ reporting-ua-field CRLF ]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -