< draft-vaudreuil-mdnbis-04.txt   draft-vaudreuil-mdnbis-05.txt >
Internet Draft Tony Hansen, ed Internet Draft Tony Hansen, ed
Expires in six months AT&T Laboratories Expires in six months AT&T Laboratories
Obsoletes: RFC 2298 Greg Vaudreuil, ed Obsoletes: RFC 2298 Greg Vaudreuil, ed
Updates: RFC 1891bis, 2046 Lucent Technologies Updates: RFC 1891bis, 2046 Lucent Technologies
May 12, 2003 July 23, 2003
Message Disposition Notification Message Disposition Notification
<draft-vaudreuil-mdnbis-04.txt> <draft-vaudreuil-mdnbis-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
This memo defines a MIME content-type that may be used by a mail user This memo defines a MIME content-type that may be used by a mail user
agent (MUA) or electronic mail gateway to report the disposition of a agent (MUA) or electronic mail gateway to report the disposition of a
message after it has been successfully delivered to a recipient. This message after it has been successfully delivered to a recipient. This
content-type is intended to be machine-processable. Additional content-type is intended to be machine-processable. Additional
message headers are also defined to permit Message Disposition message headers are also defined to permit Message Disposition
Notifications (MDNs) to be requested by the sender of a message. The Notifications (MDNs) to be requested by the sender of a message. The
purpose is to extend Internet Mail to support functionality often purpose is to extend Internet Mail to support functionality often
found in other messaging systems, such as X.400 and the proprietary found in other messaging systems, such as X.400 and the proprietary
"LAN-based" systems, and often referred to as "read receipts," "LAN-based" systems, and often referred to as "read receipts,"
"acknowledgements", or "receipt notifications." The intention is to "acknowledgements", or "receipt notifications." The intention is to
do this while respecting the privacy concerns that have often been do this while respecting privacy concerns, which have often been
expressed when such functions have been discussed in the past. expressed when such functions have been discussed in the past.
Because many messages are sent between the Internet and other Because many messages are sent between the Internet and other
messaging systems (such as X.400 or the proprietary "LAN-based" messaging systems (such as X.400 or the proprietary "LAN-based"
systems), the MDN protocol is designed to be useful in a multi- systems), the MDN protocol is designed to be useful in a multi-
protocol messaging environment. To this end, the protocol described protocol messaging environment. To this end, the protocol described
in this memo provides for the carriage of "foreign" addresses, in in this memo provides for the carriage of "foreign" addresses, in
addition to those normally used in Internet Mail. Additional addition to those normally used in Internet Mail. Additional
attributes may also be defined to support "tunneling" of foreign attributes may also be defined to support "tunneling" of foreign
notifications through Internet Mail. notifications through Internet Mail.
skipping to change at page 6, line 31 skipping to change at page 6, line 31
The presence of a Disposition-Notification-To header in a message is The presence of a Disposition-Notification-To header in a message is
merely a request for an MDN. The recipients' user agents are always merely a request for an MDN. The recipients' user agents are always
free to silently ignore such a request. Alternatively, an explicit free to silently ignore such a request. Alternatively, an explicit
denial of the request for information about the disposition of the denial of the request for information about the disposition of the
message may be sent using the "denied" disposition in an MDN. message may be sent using the "denied" disposition in an MDN.
An MDN MUST NOT itself have a Disposition-Notification-To header. An An MDN MUST NOT itself have a Disposition-Notification-To header. An
MDN MUST NOT be generated in response to an MDN. MDN MUST NOT be generated in response to an MDN.
At most one MDN may be issued on behalf of each particular recipient A user agent MUST NOT issue more than one MDN on behalf of each
by their user agent. That is, once an MDN has been issued on behalf particular recipient. That is, once an MDN has been issued on behalf
of a recipient, no further MDNs may be issued on behalf of that of a recipient, no further MDNs may be issued on behalf of that
recipient, even if another disposition is performed on the message. recipient, even if another disposition is performed on the message.
However, if a message is forwarded, an MDN may have been issued for However, if a message is forwarded, an MDN may have been issued for
the recipient doing the forwarding and the recipient of the forwarded the recipient doing the forwarding and the recipient of the forwarded
message may also cause an MDN to be generated. message may also cause an MDN to be generated.
While Internet standards normally do not specify the behavior of user While Internet standards normally do not specify the behavior of user
interfaces, it is strongly recommended that the user agent obtain the interfaces, it is strongly recommended that the user agent obtain the
user's consent before sending an MDN. This consent could be obtained user's consent before sending an MDN. This consent could be obtained
for each message through some sort of prompt or dialog box, or for each message through some sort of prompt or dialog box, or
skipping to change at page 7, line 54 skipping to change at page 7, line 54
what MDNs are generated. The Disposition-Notification-Options header what MDNs are generated. The Disposition-Notification-Options header
provides an extensible mechanism for such information. The syntax of provides an extensible mechanism for such information. The syntax of
this header is this header is
Disposition-Notification-Options = Disposition-Notification-Options =
"Disposition-Notification-Options" ":" "Disposition-Notification-Options" ":"
disposition-notification-parameters disposition-notification-parameters
disposition-notification-parameters = parameter *(";" parameter) disposition-notification-parameters = parameter *(";" parameter)
parameter = attribute "=" importance *("," value) parameter = attribute "=" importance "," value *("," value)
importance = "required" / "optional" importance = "required" / "optional"
An importance of "required" indicates that interpretation of the An importance of "required" indicates that interpretation of the
parameter is necessary for proper generation of an MDN in response to parameter is necessary for proper generation of an MDN in response to
this request. If a MUA does not understand the meaning of the this request. If a MUA does not understand the meaning of the
parameter, it MUST NOT generate an MDN with any disposition type other parameter, it MUST NOT generate an MDN with any disposition type other
than "failed" in response to the request. An importance of "optional" than "failed" in response to the request. An importance of "optional"
indicates that a MUA that does not understand the meaning of this indicates that a MUA that does not understand the meaning of this
parameter MAY generate an MDN in response anyway, ignoring the value parameter MAY generate an MDN in response anyway, ignoring the value
skipping to change at page 11, line 32 skipping to change at page 11, line 32
Security considerations: discussed in section 6 of this memo. Security considerations: discussed in section 6 of this memo.
The message/disposition-notification report type for use in the The message/disposition-notification report type for use in the
multipart/report is "disposition-notification". multipart/report is "disposition-notification".
The body of a message/disposition-notification consists of one or more The body of a message/disposition-notification consists of one or more
"fields" formatted according to the ABNF of [RFC-MSGFMT] header "fields" formatted according to the ABNF of [RFC-MSGFMT] header
"fields". The syntax of the message/disposition-notification content "fields". The syntax of the message/disposition-notification content
is as follows: is as follows:
disposition-notification-content = [ reporting-ua-field CRLF ] disposition-notification-content = [ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ] [ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ] [ original-recipient-field CRLF ]
final-recipient-field CRLF final-recipient-field CRLF
[ original-message-id-field CRLF ] [ original-message-id-field CRLF ]
disposition-field CRLF disposition-field CRLF
*( failure-field CRLF ) *( failure-field CRLF )
*( error-field CRLF ) *( error-field CRLF )
*( warning-field CRLF ) *( warning-field CRLF )
*( extension-field CRLF ) *( extension-field CRLF )
skipping to change at page 12, line 14 skipping to change at page 12, line 14
3.1.2 "*-type" subfields 3.1.2 "*-type" subfields
Several fields consist of a "-type" subfield, followed by a semi- Several fields consist of a "-type" subfield, followed by a semi-
colon, followed by "*text". For these fields, the keyword used in the 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-type or MTA-type subfield indicates the expected format of the
address or MTA-name that follows. address or MTA-name that follows.
The "-type" subfields are defined as follows: The "-type" subfields are defined as follows:
(a) An "address-type" specifies the format of a mailbox address. For (a) An "address-type" specifies the format of a mailbox address. For
example, Internet Mail addresses use the "rfc822" address-type. example, Internet Mail addresses use the "rfc822" address-type.
address-type = atom address-type = atom
(b) An "MTA-name-type" specifies the format of a mail transfer agent (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 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- MTA name is the domain name of that host, and the "dns" MTA-name-
type is used. type is used.
mta-name-type = atom mta-name-type = atom
skipping to change at page 13, line 17 skipping to change at page 13, line 17
product names. product names.
3.2.2 The MDN-Gateway field 3.2.2 The MDN-Gateway field
The MDN-Gateway field indicates the name of the gateway or MTA that The MDN-Gateway field indicates the name of the gateway or MTA that
translated a foreign (non-Internet) message disposition notification translated a foreign (non-Internet) message disposition notification
into this MDN. This field MUST appear in any MDN that was translated into this MDN. This field MUST appear in any MDN that was translated
by a gateway from a foreign system into MDN format, and MUST NOT by a gateway from a foreign system into MDN format, and MUST NOT
appear otherwise. appear otherwise.
mdn-gateway field = "MDN - -Gateway" ":" mta-name-type ";" mta-name mdn-gateway field = "MDN-Gateway" ":" mta-name-type ";" mta-name
mta-name = *text mta-name = *text
For gateways into Internet Mail, the MTA-name-type will normally be 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 "smtp", and the mta-name will be the Internet domain name of the
gateway. gateway.
3.2.3 Original-Recipient field 3.2.3 Original-Recipient field
The Original-Recipient field indicates the original recipient address The Original-Recipient field indicates the original recipient address
as specified by the sender of the message for which the MDN is being as specified by the sender of the message for which the MDN is being
issued. For Internet Mail messages the value of the issued. For Internet Mail messages the value of the
skipping to change at page 14, line 43 skipping to change at page 14, line 43
be preserved. be preserved.
3.2.5 Original-Message-ID field 3.2.5 Original-Message-ID field
The Original-Message-ID field indicates the message-ID of the message 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 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 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 present if the original message contained a Message-ID header. The
syntax of the field is syntax of the field is
original-message-id-field = original-message-id-field =
"Original-Message-ID" ":" msg-id "Original-Message-ID" ":" msg-id
The msg-id token is as specified in [RFC-MSGFMT]. The msg-id token is as specified in [RFC-MSGFMT].
3.2.6 Disposition field 3.2.6 Disposition field
The Disposition field indicates the action performed by the Reporting- The Disposition field indicates the action performed by the Reporting-
MUA on behalf of the user. This field MUST be present. MUA on behalf of the user. This field MUST be present.
The syntax for the Disposition field is: The syntax for the Disposition field is:
disposition-field = disposition-field =
"Disposition" ":" disposition-mode ";" "Disposition" ":" disposition-mode ";"
disposition-type disposition-type
[ '/' disposition-modifier [ "/" disposition-modifier
*( "," disposition-modifier ) ] *( "," disposition-modifier ) ]
disposition-mode = action-mode "/" sending-mode disposition-mode = action-mode "/" sending-mode
action-mode = "manual-action" / "automatic-action" action-mode = "manual-action" / "automatic-action"
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
disposition-type = "displayed" disposition-type = "displayed"
/ "deleted" / "deleted"
/ "dispatched"
/ "processed"
disposition-modifier = "error" disposition-modifier = "error"
/ disposition-modifier-extension / disposition-modifier-extension
disposition-modifier-extension = atom disposition-modifier-extension = atom
The disposition-mode, disposition-type and disposition-modifier may be The disposition-mode, disposition-type and disposition-modifier may be
spelled in any combination of upper and lower case characters. spelled in any combination of upper and lower case characters.
3.2.6.1 Disposition modes 3.2.6.1 Disposition modes
The following disposition modes are defined: The following disposition modes are defined:
"manual-action" The disposition described by the disposition type "manual-action" The disposition described by the disposition
was a result of an explicit instruction by type was a result of an explicit instruction
the user rather than some sort of by the user rather than some sort of
automatically performed action. automatically performed action.
"automatic-action" The disposition described by the disposition "automatic-action" The disposition described by the disposition
type was a result of an automatic action, type was a result of an automatic action,
rather than an explicit instruction by the rather than an explicit instruction by the
user for this message. user for this message.
"Manual-action" and "automatic-action" are mutually exclusive. One or "Manual-action" and "automatic-action" are mutually exclusive. One or
the other must be specified. the other MUST be specified.
"MDN-sent-manually" The user explicitly gave permission for this "MDN-sent-manually" The user explicitly gave permission for this
particular MDN to be sent. particular MDN to be sent.
"MDN-sent-automatically" The MDN was sent because the MUA had "MDN-sent-automatically"
The MDN was sent because the MUA had
previously been configured to do so previously been configured to do so
automatically. automatically.
"MDN-sent-manually" and "MDN-sent-automatically" are mutually "MDN-sent-manually" and "MDN-sent-automatically" are mutually
exclusive. One or the other must be specified. exclusive. One or the other MUST be specified.
3.2.6.2 Disposition types 3.2.6.2 Disposition types
The following disposition-types are defined: The following disposition-types are defined:
"displayed" The message has been displayed by the MUA "displayed" The message has been displayed by the MUA
to someone reading the recipient's mailbox. to someone reading the recipient's mailbox.
There is no guarantee that the content has There is no guarantee that the content has
been read or understood. been read or understood.
"deleted" The message has been deleted. The "deleted" The message has been deleted. The
recipient may or may not have seen the recipient may or may not have seen the
message. The recipient might "undelete" message. The recipient might "undelete"
the message at a later time and read the the message at a later time and read the
message. message.
3.2.6.3 Disposition modifiers 3.2.6.3 Disposition modifiers
Only the extension disposition modifiers is defined: Only the extension disposition modifiers is defined:
disposition-modifier-extension Disposition modifiers may be disposition-modifier-extension
defined in the future by later revisions of Disposition modifiers may be defined
in the future by later revisions of
or extensions to this specification. or extensions to this specification.
Disposition value names beginning with "X-" Disposition value names beginning with "X-"
will never be defined as standard values; will never be defined as standard values;
such names are reserved for experimental such names are reserved for experimental
use. MDN disposition value names NOT use. MDN disposition value names NOT
beginning with "X-" MUST be registered with beginning with "X-" MUST be registered with
the Internet Assigned Numbers Authority the Internet Assigned Numbers Authority
(IANA) and described in a standards-track (IANA) and described in a standards-track
RFC or an experimental RFC approved by the RFC or an experimental RFC approved by the
IESG. (See Section 10 for a registration IESG. (See Section 10 for a registration
skipping to change at page 17, line 32 skipping to change at page 17, line 33
names not understood by the receiving MUA names not understood by the receiving MUA
MAY be silently ignored or placed in the MAY be silently ignored or placed in the
user's mailbox without special user's mailbox without special
interpretation. They MUST not cause any interpretation. They MUST not cause any
error message to be sent to the sender of error message to be sent to the sender of
the MDN. the MDN.
If an MUA developer does not wish to register the meanings of such If an MUA developer does not wish to register the meanings of such
disposition modifier extensions, "X-" modifiers may be used for this disposition modifier extensions, "X-" modifiers may be used for this
purpose. To avoid name collisions, the name of the MUA implementation purpose. To avoid name collisions, the name of the MUA implementation
should follow the "X-", (e.g. "X-Foomail-fratzed"). should follow the "X-", (e.g. "X-Foomail-").
It is not required that a MUA be able to generate all of the possible It is not required that a MUA be able to generate all of the possible
values of the Disposition field. values of the Disposition field.
One and only one MDN may be issued on behalf of each particular A user agent MUST NOT issue more than one MDN on behalf of each
recipient by their user agent. That is, once an MDN has been issued particular recipient. That is, once an MDN has been issued on
on behalf of a recipient, no further MDNs may be issued on behalf of behalf of a recipient, no further MDNs may be issued on behalf of
that recipient, even if another disposition is performed on the that recipient, even if another disposition is performed on the
message. However, if a message is forwarded, a "dispatched" MDN may message. However, if a message is forwarded, a "dispatched" MDN may
be issued for the recipient doing the forwarding and the recipient of be issued for the recipient doing the forwarding and the recipient of
the forwarded message may also cause an MDN to be generated. the forwarded message may also cause an MDN to be generated.
3.2.7 Failure, Error and Warning fields 3.2.7 Failure, Error and Warning fields
The Failure, Error and Warning fields are used to supply additional The Failure, Error and Warning fields are used to supply additional
information in the form of text messages when the "failure" information in the form of text messages when the "failure"
disposition type, "error" disposition modifier, and/or the "warning" disposition type, "error" disposition modifier, and/or the "warning"
skipping to change at page 18, line 23 skipping to change at page 18, line 23
error-field = "Error" ":" *text error-field = "Error" ":" *text
warning-field = "Warning" ":" *text warning-field = "Warning" ":" *text
3.3 Extension-fields 3.3 Extension-fields
Additional MDN fields may be defined in the future by later revisions Additional MDN fields may be defined in the future by later revisions
or extensions to this specification. Extension-field names beginning or extensions to this specification. Extension-field names beginning
with "X-" will never be defined as standard fields; such names are with "X-" will never be defined as standard fields; such names are
reserved for experimental use. MDN field names NOT beginning with "X- reserved for experimental use. MDN field names NOT beginning with
" MUST be registered with the Internet Assigned Numbers Authority "X-" MUST be registered with the Internet Assigned Numbers Authority
(IANA) and described in a standards-track RFC or an experimental RFC (IANA) and described in a standards-track RFC or an experimental RFC
approved by the IESG. (See Section 10 for a registration form.) approved by the IESG. (See Section 10 for a registration form.)
MDN Extension-fields may be defined for the following reasons: MDN Extension-fields may be defined for the following reasons:
(a) To allow additional information from foreign disposition reports (a) To allow additional information from foreign disposition reports
to be tunneled through Internet MDNs. The names of such MDN to be tunneled through Internet MDNs. The names of such MDN
fields should begin with an indication of the foreign environment fields should begin with an indication of the foreign environment
name (e.g. X400-Physical-Forwarding-Address). name (e.g. X400-Physical-Forwarding-Address).
(b) To allow transmission of diagnostic information that is specific (b) To allow transmission of diagnostic information that is specific
to a particular mail user agent (MUA). The names of such MDN to a particular mail user agent (MUA). The names of such MDN
fields should begin with an indication of the MUA implementation fields should begin with an indication of the MUA implementation
that produced the MDN. (e.g. Foomail-information). that produced the MDN. (e.g. Foomail-information).
If an application developer does not wish to register the meanings of If an application developer does not wish to register the meanings of
such extension fields, "X-" fields may be used for this purpose. To such extension fields, "X-" fields may be used for this purpose. To
avoid name collisions, the name of the application implementation avoid name collisions, the name of the application implementation
should follow the "X-", (e.g. "X-Foomail-fratzed"). should follow the "X-", (e.g. "X-Foomail-Log-ID" or "X-Foomail-EDI-
info").
4. Timeline of events 4. Timeline of events
The following timeline shows when various events in the processing of The following timeline shows when various events in the processing of
a message and generation of MDNs take place: a message and generation of MDNs take place:
-- User composes message -- User composes message
-- User tells MUA to send message -- User tells MUA to send message
skipping to change at page 22, line 33 skipping to change at page 22, line 33
The MDN request mechanism introduces an additional way of mailbombing The MDN request mechanism introduces an additional way of mailbombing
a mailbox. The MDN request notification provides an address to which a mailbox. The MDN request notification provides an address to which
MDN's should be sent. It is possible for an attacking agent to send a MDN's should be sent. It is possible for an attacking agent to send a
potentially large set of messages to otherwise unsuspecting third potentially large set of messages to otherwise unsuspecting third
party recipients with a false "disposition-notification-to:" address. party recipients with a false "disposition-notification-to:" address.
Automatic, or simplistic processing of such requests would result in a Automatic, or simplistic processing of such requests would result in a
flood of MDN notifications to the target of the attack. Such an flood of MDN notifications to the target of the attack. Such an
attack could overrun the capacity of the targeted mailbox and deny attack could overrun the capacity of the targeted mailbox and deny
service. service.
For that reason, MDN's should not be sent automatically where the For that reason, MDN's SHOULD NOT be sent automatically where the
"disposition-notification-to:" address is different from the envelope "disposition-notification-to:" address is different from the envelope
MAIL FROM address. See section 2.1 for further discussion. MAIL FROM address. See section 2.1 for further discussion.
7. Collected Grammar 7. Collected Grammar
NOTE: The following lexical tokens are defined in [RFC-MSGFMT]: NOTE: The following lexical tokens are defined in [RFC-MSGFMT]:
atom, CRLF, mailbox, msg-id, text. The definitions of attribute atom, CRLF, mailbox, msg-id, text. The definitions of attribute
and value are as in the definition of the Content-Type header in and value are as in the definition of the Content-Type header in
[RFC-MIME-BODY]. [RFC-MIME-BODY].
Message headers: Message headers:
mdn-request-header = mdn-request-header =
"Disposition-Notification-To" ":" "Disposition-Notification-To" ":"
mailbox *("." mailbox) mailbox *("," mailbox)
Disposition-Notification-Options = Disposition-Notification-Options =
"Disposition-Notification-Options" ":" "Disposition-Notification-Options" ":"
disposition-notification-parameters disposition-notification-parameters
disposition-notification-parameters = disposition-notification-parameters =
parameter *(";" parameter) parameter *(";" parameter)
parameter = attribute "=" importance "," value *("," value) parameter = attribute "=" importance "," value *("," value)
importance = "required" / "optional" importance = "required" / "optional"
original-recipient-header = original-recipient-header =
"Original-Recipient" ":" address-type ";" generic-address "Original-Recipient" ":" address-type ";" generic-address
Report content: Report content:
disposition-notification-content = disposition-notification-content =
[ reporting-ua-field CRLF ] [ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ] [ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ] [ original-recipient-field CRLF ]
final-recipient-field CRLF final-recipient-field CRLF
[ original-message-id-field CRLF ] [ original-message-id-field CRLF ]
disposition-field CRLF disposition-field CRLF
*( failure-field CRLF ) *( failure-field CRLF )
*( error-field CRLF ) *( error-field CRLF )
*( warning-field CRLF ) *( warning-field CRLF )
*( extension-field CRLF ) *( extension-field CRLF )
address-type = atom address-type = atom
mta-name-type = atom mta-name-type = atom
reporting-ua-field = "Reporting-UA" ":" ua-name [ ";" ua-product ] reporting-ua-field = "Reporting-UA" ":" ua-name [ ";" ua-product ]
ua-name = *text ua-name = *text
ua-product = *text ua-product = *text
mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
mta-name = *text mta-name = *text
original-recipient-field original-recipient-field
= "Original-Recipient" ":" address-type ";" = "Original-Recipient" ":" address-type ";"
generic-address generic-address
generic-address = *text generic-address = *text
final-recipient-field = final-recipient-field =
"Final-Recipient" ":" address-type ";" generic-address "Final-Recipient" ":" address-type ";" generic-address
disposition-field = disposition-field =
"Disposition" ":" disposition-mode ";" "Disposition" ":" disposition-mode ";"
disposition-type disposition-type
[ '/' disposition-modifier [ "/" disposition-modifier
*( "," disposition-modifier ) ] *( "," disposition-modifier ) ]
disposition-mode = action-mode "/" sending-mode disposition-mode = action-mode "/" sending-mode
action-mode = "manual-action" / "automatic-action" action-mode = "manual-action" / "automatic-action"
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
disposition-type = "displayed" disposition-type = "displayed"
/ "dispatched" / "deleted"
/ "processed"
/ "failed"
disposition-modifier = disposition-modifier-extension disposition-modifier = "error" / disposition-modifier-extension
disposition-modifier-extension = atom disposition-modifier-extension = atom
original-message-id-field = "Original-Message-ID" ":" msg-id original-message-id-field = "Original-Message-ID" ":" msg-id
failure-field = "Failure" ":" *text failure-field = "Failure" ":" *text
error-field = "Error" ":" *text error-field = "Error" ":" *text
warning-field = "Warning" ":" *text warning-field = "Warning" ":" *text
extension-field = extension-field-name ":" *text extension-field = extension-field-name ":" *text
extension-field-name = atom extension-field-name = atom
8. Guidelines for Gatewaying MDNs 8. Guidelines for Gatewaying MDNs
NOTE: This section provides non-binding recommendations for the NOTE: This section provides non-binding recommendations for the
construction of mail gateways that wish to provide semi-transparent construction of mail gateways that wish to provide semi-transparent
disposition notifications between the Internet and another electronic disposition notifications between the Internet and another electronic
mail system. Specific MDN gateway requirements for a particular pair mail system. Specific MDN gateway requirements for a particular pair
of mail systems may be defined by other documents. of mail systems may be defined by other documents.
8.1 Gatewaying from other mail systems to MDNs 8.1 Gatewaying from other mail systems to MDNs
skipping to change at page 33, line 12 skipping to change at page 33, line 12
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
16. Authors' Addresses 16. Authors' Addresses
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Voice: +1-732-420-8934 Voice: +1-732-420-8934
E-Mail: tony@att.com E-Mail: tony+mdnbis@maillennium.att.com
Gregory M. Vaudreuil Gregory M. Vaudreuil
Lucent Technologies Lucent Technologies
7291 Williamson Rd 7291 Williamson Rd
Dallas, TX 75214 Dallas, TX 75214
USA USA
Voice: +1 214 823 9325 Voice: +1 214 823 9325
E-Mail: GregV@ieee.org E-Mail: GregV@ieee.org
17. Appendix A - Changes from RFC2298 17. Appendix A - Changes from RFC2298
 End of changes. 63 change blocks. 
75 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/