draft-ietf-appsawg-mdn-3798bis-07.txt   draft-ietf-appsawg-mdn-3798bis-08.txt 
Network Working Group T. Hansen, Ed. Network Working Group T. Hansen, Ed.
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Obsoletes: 3798 (if approved) A. Melnikov, Ed. Obsoletes: 3798 (if approved) A. Melnikov, Ed.
Updates: 2046, 3461 (if approved) Isode Ltd Updates: 2046, 3461 (if approved) Isode Ltd
Intended status: Standards Track May 1, 2016 Intended status: Standards Track June 25, 2016
Expires: November 2, 2016 Expires: December 27, 2016
Message Disposition Notification Message Disposition Notification
draft-ietf-appsawg-mdn-3798bis-07.txt draft-ietf-appsawg-mdn-3798bis-08.txt
Abstract Abstract
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. message after it has been successfully delivered to a recipient.
This content-type is intended to be machine-processable. Additional This content-type is intended to be machine-processable. Additional
message header fields are also defined to permit Message Disposition message header fields 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
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 2, 2016. This Internet-Draft will expire on December 27, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requesting Message Disposition Notifications . . . . . . . . 5 2. Requesting Message Disposition Notifications . . . . . . . . 5
2.1. The Disposition-Notification-To Header . . . . . . . . . 5 2.1. The Disposition-Notification-To Header . . . . . . . . . 5
2.2. The Disposition-Notification-Options Header . . . . . . . 7 2.2. The Disposition-Notification-Options Header . . . . . . . 7
2.3. The Original-Recipient Header Field . . . . . . . . . . . 8 2.3. The Original-Recipient Header Field . . . . . . . . . . . 8
2.4. Use with the Message/Partial Media Type . . . . . . . . . 9 2.4. Use with the Message/Partial Media Type . . . . . . . . . 9
3. Format of a Message Disposition Notification . . . . . . . . 9 3. Format of a Message Disposition Notification . . . . . . . . 10
3.1. The message/disposition-notification Media Type . . . . . 11 3.1. The message/disposition-notification Media Type . . . . . 11
3.2. Message/disposition-notification Content Fields . . . . . 14 3.2. Message/disposition-notification Content Fields . . . . . 14
3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 19 3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 20
4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 20 4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 21
5. Conformance and Usage Requirements . . . . . . . . . . . . . 21 5. Conformance and Usage Requirements . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 23 6.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 24
6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 23 6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 24
7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 24 7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 24
8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 25 8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 27
8.1. Gatewaying from other mail systems to MDNs . . . . . . . 26 8.1. Gatewaying from other mail systems to MDNs . . . . . . . 27
8.2. Gatewaying from MDNs to other mail systems . . . . . . . 26 8.2. Gatewaying from MDNs to other mail systems . . . . . . . 27
8.3. Gatewaying of MDN-requests to other mail systems . . . . 27 8.3. Gatewaying of MDN-requests to other mail systems . . . . 28
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10.1. Disposition-Notification-Options header field 10.1. Disposition-Notification-Options header field
disposition-notification-parameter names . . . . . . . . 29 disposition-notification-parameter names . . . . . . . . 30
10.2. Disposition modifier names . . . . . . . . . . . . . . . 30 10.2. Disposition modifier names . . . . . . . . . . . . . . . 31
10.3. MDN extension field names . . . . . . . . . . . . . . . 30 10.3. MDN extension field names . . . . . . . . . . . . . . . 31
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 31 12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 32 Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
This memo defines a media type [RFC2046] for message disposition This memo defines a media type [RFC2046] for message disposition
notifications (MDNs). An MDN can be used to notify the sender of a notifications (MDNs). An MDN can be used to notify the sender of a
message of any of several conditions that may occur after successful message of any of several conditions that may occur after successful
delivery, such as display of the message contents, printing of the delivery, such as display of the message contents, printing of the
message, deletion (without display) of the message, or the message, deletion (without display) of the message, or the
recipient's refusal to provide MDNs. The "message/disposition- recipient's refusal to provide MDNs. The "message/disposition-
notification" content-type defined herein is intended for use within notification" content-type defined herein is intended for use within
skipping to change at page 8, line 14 skipping to change at page 8, line 34
An importance of "required" indicates that interpretation of the An importance of "required" indicates that interpretation of the
disposition-notification-parameter is necessary for proper generation disposition-notification-parameter is necessary for proper generation
of an MDN in response to this request. An importance of "optional" of an MDN in response to this request. An importance of "optional"
indicates that an MUA that does not understand the meaning of this indicates that an MUA that does not understand the meaning of this
disposition-notification-parameter MAY generate an MDN in response disposition-notification-parameter MAY generate an MDN in response
anyway, ignoring the value of the disposition-notification-parameter. anyway, ignoring the value of the disposition-notification-parameter.
No disposition-notification-parameter attribute names are defined in No disposition-notification-parameter attribute names are defined in
this specification. Attribute names may be defined in the future by this specification. Attribute names may be defined in the future by
later revisions or extensions to this specification. Disposition- later revisions or extensions to this specification. disposition-
notification-parameter attribute names beginning with "X-" will never notification-parameter attribute names MUST be registered with the
be defined as standard names; such names are reserved for Internet Assigned Numbers Authority (IANA) using "Specification
experimental use. disposition-notification-parameter attribute names required" registration policy. Note that a previous version of this
not beginning with "X-" MUST be registered with the Internet Assigned specification reserved disposition-notification-parameter attribute
Numbers Authority (IANA) using "Specification required" registration names beginning with "X-" for experimental use, but they can now be
policy. registered.
(See Section 10 for a registration form.) (See Section 10 for a registration form.)
2.3. The Original-Recipient Header Field 2.3. The Original-Recipient Header Field
Since electronic mail addresses may be rewritten while the message is Since electronic mail addresses may be rewritten while the message is
in transit, it is useful for the original recipient address to be in transit, it is useful for the original recipient address to be
made available by the delivering Message Transfer Agent (MTA) made available by the delivering Message Transfer Agent (MTA)
[RFC5598]. The delivering MTA may be able to obtain this information [RFC5598]. The delivering MTA may be able to obtain this information
from the ORCPT parameter of the SMTP RCPT TO command, as defined in from the ORCPT parameter of the SMTP RCPT TO command, as defined in
RFC-SMTP [RFC5321] and RFC-DSN-SMTP [RFC3461]. RFC-SMTP [RFC5321] and RFC-DSN-SMTP [RFC3461].
skipping to change at page 13, line 14 skipping to change at page 13, line 25
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 )
*( extension-field CRLF ) *( extension-field CRLF )
extension-field = extension-field-name ":" *([FWS] text) extension-field = extension-field-name ":" *([FWS] text)
extension-field-name = field-name extension-field-name = field-name
Note that the order of the above fields is fixed, with the exception Note that the order of the above fields is recommended, but not
of the extension fields. fixed. Extension fields can appear anywhere.
3.1.1. General conventions for fields 3.1.1. General conventions for fields
Since these fields are defined according to the rules of RFC-MSGFMT Since these fields are defined according to the rules of RFC-MSGFMT
[RFC5322], the same conventions for continuation lines and comments [RFC5322], the same conventions for continuation lines and comments
apply. Notification fields may be continued onto multiple lines by apply. Notification fields may be continued onto multiple lines by
beginning each additional line with a SPACE or HTAB. Text that beginning each additional line with a SPACE or HTAB. Text that
appears in parentheses is considered a comment and not part of the appears in parentheses is considered a comment and not part of the
contents of that notification field. Field names are case- contents of that notification field. Field names are case-
insensitive, so the names of notification fields may be spelled in insensitive, so the names of notification fields may be spelled in
skipping to change at page 13, line 37 skipping to change at page 14, line 4
contents of that notification field. Field names are case- contents of that notification field. Field names are case-
insensitive, so the names of notification fields may be spelled in insensitive, so the names of notification fields may be spelled in
any combination of upper and lower case letters. [RFC5322] comments any combination of upper and lower case letters. [RFC5322] comments
in notification fields may use the "encoded-word" construct defined in notification fields may use the "encoded-word" construct defined
in RFC-MIME-HEADER [RFC2047]. in RFC-MIME-HEADER [RFC2047].
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". colon, followed by "*text".
For these fields, the keyword used in the address-type or MTA-type For these fields, the keyword used in the address-type or MTA-type
subfield indicates the expected format of the address or MTA-name subfield indicates the expected format of the address or MTA-name
that follows. 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.
Other values can appear in this field as specified in the
"Address Types" IANA subregistry established by RFC-DSN-FORMAT
[RFC3464].
address-type = atom address-type = atom
atom = <The version from RFC 5321 (not from RFC 5322) is used in this document.> atom = <The version from RFC 5321 (not from RFC 5322) is used in this document.>
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. Other values can appear in this field as specified
in the "MTA Name Types" IANA subregistry established by RFC-DSN-
FORMAT [RFC3464].
mta-name-type = atom mta-name-type = atom
Values for address-type and mta-name-type are case-insensitive. Values for address-type and mta-name-type are case-insensitive.
Thus, address-type values of "RFC822" and "rfc822" are equivalent. Thus, address-type values of "RFC822" and "rfc822" are equivalent.
The Internet Assigned Numbers Authority (IANA) maintains a registry The Internet Assigned Numbers Authority (IANA) maintains a registry
of address-type and mta-name-type values, along with descriptions of of address-type and mta-name-type values, along with descriptions of
the meanings of each, or a reference to one or more specifications the meanings of each, or a reference to one or more specifications
that provide such descriptions. (The "rfc822" address-type is that provide such descriptions. (The "rfc822" address-type is
skipping to change at page 17, line 10 skipping to change at page 17, line 36
The Disposition field indicates the action performed by the The Disposition field indicates the action performed by the
Reporting-MUA on behalf of the user. This field MUST be present. Reporting-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" ":" OWS disposition-mode OWS ";" "Disposition" ":" OWS disposition-mode OWS ";"
OWS disposition-type OWS disposition-type
[ OWS "/" OWS disposition-modifier [ OWS "/" OWS disposition-modifier
*( OWS "," OWS disposition-modifier ) ] OWS *( OWS "," OWS disposition-modifier ) ] OWS
disposition-mode = action-mode OWS "/" OWS sending-mode disposition-mode = action-mode OWS "/" OWS 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" / "deleted" / "dispatched" / disposition-type = "displayed" / "deleted" / "dispatched" /
"processed" "processed"
disposition-modifier = "error" / disposition-modifier-extension disposition-modifier = "error" / disposition-modifier-extension
disposition-modifier-extension = atom
disposition-modifier-extension = atom
The disposition-mode, disposition-type, and disposition-modifier The disposition-mode, disposition-type, and disposition-modifier
values may be spelled in any combination of upper and lower case US- values may be spelled in any combination of upper and lower case US-
ASCII characters. ASCII characters.
3.2.6.1. Disposition modes 3.2.6.1. Disposition modes
The following disposition modes are defined: The following action modes are defined:
"manual-action" The disposition described by the disposition type "manual-action" The disposition described by the disposition type
was a result of an explicit instruction by the was a result of an explicit instruction by the
user rather than some sort of automatically user rather than some sort of automatically
performed action. Unless prescribed otherwise in performed action. Unless prescribed otherwise in
a particular mail environment, in order to a particular mail environment, in order to
preserve user's privacy, this is the default for preserve user's privacy, this is the default for
MUAs. MUAs.
"automatic-action" The disposition described by the disposition type "automatic-action" The disposition described by the disposition type
was a result of an automatic action, rather than was a result of an automatic action, rather than
an explicit instruction by the user for this an explicit instruction by the user for this
message. message. For example, this might be set if the
user configured her MUA to always respond to MDN
requests without asking for confirmation. Other
examples include MDN generations by Sieve reject
action [RFC5429], Fax-over-Email [RFC3249] or
Voice Messaging System (VPIM) [RFC3801].
"Manual-action" and "automatic-action" are mutually exclusive. One "Manual-action" and "automatic-action" are mutually exclusive. One
or the other MUST be specified. or the other MUST be specified.
The following sending modes are defined:
"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. Unless prescribed
otherwise in a particular mail environment, in
order to preserve user's privacy, this is the
default for MUAs.
"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
skipping to change at page 18, line 41 skipping to change at page 19, line 38
might "undelete" the message at a later time and might "undelete" the message at a later time and
read the message. read the 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-modifier-extension
Disposition modifiers may be defined in the Disposition modifiers may be defined in the
future by later revisions or extensions to this future by later revisions or extensions to this
specification. Disposition value names beginning specification. MDN disposition value names MUST
with "X-" will never be defined as standard be registered with the Internet Assigned Numbers
values; such names are reserved for experimental Authority (IANA) using "Specification required"
use. MDN disposition value names NOT beginning registration policy. (See Section 10 for a
with "X-" MUST be registered with the Internet registration form.) MDNs with disposition
Assigned Numbers Authority (IANA) using modifier names not understood by the receiving
"Specification required" registration policy. MUA MAY be silently ignored or placed in the
user's mailbox without special interpretation.
(See Section 10 for a registration form.) MDNs They MUST not cause any error message to be sent
with disposition modifier names not understood by to the sender of the MDN.
the receiving MUA MAY be silently ignored or
placed in the user's mailbox without special
interpretation. They MUST not cause any error
message to be sent to the sender of the MDN.
If an MUA 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 MUA
implementation should follow the "X-", (e.g., "X-Foomail-").
It is not required that an MUA be able to generate all of the It is not required that an MUA be able to generate all of the
possible values of the Disposition field. possible values of the Disposition field.
A user agent MUST NOT issue more than one MDN on behalf of each A user agent MUST NOT issue more than one MDN on behalf of each
particular recipient. 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, a "dispatched" MDN MAY be issued However, if a message is forwarded, a "dispatched" MDN MAY be issued
for the recipient doing the forwarding and the recipient of the for the recipient doing the forwarding and the recipient of the
forwarded message may also cause an MDN to be generated. forwarded message may also cause an MDN to be generated.
3.2.7. Failure and Error Fields 3.2.7. Failure and Error Fields
The Failure and Error fields are used to supply additional The Failure and Error 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 "error" disposition
disposition type or "error" disposition modifier appear. The syntax modifier appear. The syntax is as follows:
is as follows:
failure-field = "Failure" ":" *([FWS] text) failure-field = "Failure" ":" *([FWS] text)
error-field = "Error" ":" *([FWS] text) error-field = "Error" ":" *([FWS] text)
Note that syntax of these header fields doesn't include comments, so Note that syntax of these header fields doesn't include comments, so
"encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] can't "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] can't
be used to convey non ASCII text. Application that need to convey be used to convey non ASCII text. Application that need to convey
non ASCII text in these fields should consider implementing message/ non ASCII text in these fields should consider implementing message/
global-disposition-notification media type specified in [RFC6533] global-disposition-notification media type specified in [RFC6533]
instead of this specification. instead of this specification.
3.3. Extension-fields 3.3. Extension-fields
skipping to change at page 19, line 48 skipping to change at page 20, line 36
Note that syntax of these header fields doesn't include comments, so Note that syntax of these header fields doesn't include comments, so
"encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] can't "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] can't
be used to convey non ASCII text. Application that need to convey be used to convey non ASCII text. Application that need to convey
non ASCII text in these fields should consider implementing message/ non ASCII text in these fields should consider implementing message/
global-disposition-notification media type specified in [RFC6533] global-disposition-notification media type specified in [RFC6533]
instead of this specification. instead of this specification.
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. MDN field names MUST be
with "X-" will never be defined as standard fields; such names are registered with the Internet Assigned Numbers Authority (IANA) using
reserved for experimental use. MDN field names NOT beginning with "Specification required" registration policy. (See Section 10 for a
"X-" MUST be registered with the Internet Assigned Numbers Authority registration form.) MDN Extension-fields may be defined for the
(IANA) using "Specification required" registration policy. (See following reasons:
Section 10 for a registration form.) 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
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-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
-- MUA passes message to MTA (original recipient information passed -- MUA passes message to MTA (original recipient information passed
along) along)
-- MTA sends message to next MTA -- MTA sends message to next MTA
-- Final MTA receives message -- Final MTA receives message
-- Final MTA delivers message to MUA (possibly generating a Delivery -- Final MTA delivers message to MUA (possibly generating a Delivery
Status Notification (DSN)) Status Notification (DSN))
-- MUA performs automatic processing and generates corresponding MDNs -- MUA performs automatic processing and might generate corresponding
("dispatched", "processed" or "deleted" disposition type with MDNs ("dispatched", "processed" or "deleted" disposition type with
"automatic-action" and "MDN-sent-automatically" disposition modes) "automatic-action" and "MDN-sent-automatically" disposition modes)
-- MUA displays list of messages to user -- MUA displays list of messages to user
-- User selects a message and requests that some action be performed -- User selects a message and requests that some action be performed
on it. on it.
-- MUA performs requested action and, with user's permission, sends -- MUA performs requested action; if an automatic MDN has not already
an appropriate MDN ("displayed", "dispatched", "processed", or been generated, with user's permission, sends an appropriate MDN
"deleted" disposition type, with "manual-action" and "MDN-sent- ("displayed", "dispatched", "processed", or "deleted" disposition
manually" or "MDN-sent-automatically" disposition mode). type, with "manual-action" and "MDN-sent-manually" or "MDN-sent-
automatically" disposition mode).
-- User possibly performs other actions on message, but no further -- User possibly performs other actions on message, but no further
MDNs are generated. MDNs are generated.
5. Conformance and Usage Requirements 5. Conformance and Usage Requirements
An MUA or gateway conforms to this specification if it generates MDNs An MUA or gateway conforms to this specification if it generates MDNs
according to the protocol defined in this memo. It is not necessary 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 to be able to generate all of the possible values of the Disposition
field. field.
skipping to change at page 22, line 9 skipping to change at page 22, line 36
Successful distribution of a message to a mailing list exploder Successful distribution of a message to a mailing list exploder
SHOULD be considered the final disposition of the message. A mailing SHOULD be considered the final disposition of the message. A mailing
list exploder MAY issue an MDN with a disposition type of "processed" list exploder MAY issue an MDN with a disposition type of "processed"
and disposition modes of "automatic-action" and "MDN-sent- and disposition modes of "automatic-action" and "MDN-sent-
automatically" indicating that the message has been forwarded to the automatically" indicating that the message has been forwarded to the
list. In this case, the request for MDNs is not propagated to the list. In this case, the request for MDNs is not propagated to the
members of the list. members of the list.
Alternatively (if successful distribution of a message to a mailing Alternatively (if successful distribution of a message to a mailing
list exploder is not considered the final disposition of the list exploder is not considered the final disposition of the
message), the mailing list exploder MAY issue no MDN and propagate message), the mailing list exploder can issue no MDN and propagate
the request for MDNs to all members of the list. The latter behavior 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 is not recommended for any but small, closely knit lists, as it might
cause large numbers of MDNs to be generated and may cause cause large numbers of MDNs to be generated and may cause
confidential subscribers to the list to be revealed. The mailing confidential subscribers to the list to be revealed. The mailing
list exploder MAY also direct MDNs to itself, correlate them, and list exploder can also direct MDNs to itself, correlate them, and
produce a report to the original sender of the message. produce a report to the original sender of the message.
This specification places no restrictions on the processing of MDNs This specification places no restrictions on the processing of MDNs
received by user agents or mailing lists. received by user agents or mailing lists.
6. Security Considerations 6. Security Considerations
The following security considerations apply when using MDNs: The following security considerations apply when using MDNs:
6.1. Forgery 6.1. Forgery
skipping to change at page 32, line 16 skipping to change at page 33, line 16
profile for Internet Message Access Protocol (IMAP)", profile for Internet Message Access Protocol (IMAP)",
RFC 3503, DOI 10.17487/RFC3503, March 2003, RFC 3503, DOI 10.17487/RFC3503, March 2003,
<http://www.rfc-editor.org/info/rfc3503>. <http://www.rfc-editor.org/info/rfc3503>.
12.2. Informative References 12.2. Informative References
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
RFC 2634, DOI 10.17487/RFC2634, June 1999, RFC 2634, DOI 10.17487/RFC2634, June 1999,
<http://www.rfc-editor.org/info/rfc2634>. <http://www.rfc-editor.org/info/rfc2634>.
[RFC3249] Cancio, V., Moldovan, M., Tamura, H., and D. Wing,
"Implementers Guide for Facsimile Using Internet Mail",
RFC 3249, DOI 10.17487/RFC3249, September 2002,
<http://www.rfc-editor.org/info/rfc3249>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<http://www.rfc-editor.org/info/rfc3501>. <http://www.rfc-editor.org/info/rfc3501>.
[RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
Mail - version 2 (VPIMv2)", RFC 3801,
DOI 10.17487/RFC3801, June 2004,
<http://www.rfc-editor.org/info/rfc3801>.
[RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress
Extension", RFC 5233, DOI 10.17487/RFC5233, January 2008, Extension", RFC 5233, DOI 10.17487/RFC5233, January 2008,
<http://www.rfc-editor.org/info/rfc5233>. <http://www.rfc-editor.org/info/rfc5233>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC5429] Stone, A., Ed., "Sieve Email Filtering: Reject and
Extended Reject Extensions", RFC 5429,
DOI 10.17487/RFC5429, March 2009,
<http://www.rfc-editor.org/info/rfc5429>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009, DOI 10.17487/RFC5598, July 2009,
<http://www.rfc-editor.org/info/rfc5598>. <http://www.rfc-editor.org/info/rfc5598>.
[RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov,
"Internationalized Delivery Status and Disposition "Internationalized Delivery Status and Disposition
Notifications", RFC 6533, DOI 10.17487/RFC6533, February Notifications", RFC 6533, DOI 10.17487/RFC6533, February
2012, <http://www.rfc-editor.org/info/rfc6533>. 2012, <http://www.rfc-editor.org/info/rfc6533>.
Appendix A. Changes from RFC 3798 Appendix A. Changes from RFC 3798
Changed IANA registration for different subregistries to Changed IANA registration for different subregistries to
"Specification Required" to match what is already used by IANA. "Specification Required" to match what is already used by IANA.
Updated IANA registration template for message/disposition-
notification.
"X-" fields no longer reserved for experimental use and can now be
registered in compliance with RFC 6648.
Fixed the default MTA-name-type used in "MDN-Gateway" to be "dns".
Strengthen requirements on obtaining user consent in order to protect
user privacy.
The values of "dispatched" and "processed" were lost from the ABNF The values of "dispatched" and "processed" were lost from the ABNF
for "disposition-type". for "disposition-type".
Because the warning disposition modifier was previously removed, Because the warning disposition modifier was previously removed,
warning-field has also been removed. warning-field has also been removed.
The ABNF for ua-name and ua-product included semi-colon, which could The ABNF for ua-name and ua-product included semi-colon, which could
not be distinguished from *text in the production. The ua-name was not be distinguished from *text in the production. The ua-name was
restricted to not include semi-colon. Semi-colon can still appear in restricted to not include semi-colon. Semi-colon can still appear in
the ua-product. the ua-product.
 End of changes. 40 change blocks. 
84 lines changed or deleted 118 lines changed or added

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