draft-ietf-appsawg-mdn-3798bis-02.txt   draft-ietf-appsawg-mdn-3798bis-03.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.
Intended status: Standards Track Isode Ltd Intended status: Standards Track Isode Ltd
Expires: September 10, 2015 March 9, 2015 Expires: January 5, 2016 July 4, 2015
Message Disposition Notification Message Disposition Notification
draft-ietf-appsawg-mdn-3798bis-02.txt draft-ietf-appsawg-mdn-3798bis-03.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 4 skipping to change at page 2, line 4
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 September 10, 2015. This Internet-Draft will expire on January 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 3, line 7 skipping to change at page 3, line 7
3.1. The message/disposition-notification content-type . . . . 11 3.1. The message/disposition-notification content-type . . . . 11
3.2. Message/disposition-notification Fields . . . . . . . . . 13 3.2. Message/disposition-notification Fields . . . . . . . . . 13
3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 18 3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 18
4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 19 4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 19
5. Conformance and Usage Requirements . . . . . . . . . . . . . 20 5. Conformance and Usage Requirements . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 22 6.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 22
6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 22 6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 22
7. Collected Grammar . . . . . . . . . . . . . . . . . . . . . . 22 7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 22
8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 24 8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 24
8.1. Gatewaying from other mail systems to MDNs . . . . . . . 24 8.1. Gatewaying from other mail systems to MDNs . . . . . . . 24
8.2. Gatewaying from MDNs to other mail systems . . . . . . . 25 8.2. Gatewaying from MDNs to other mail systems . . . . . . . 25
8.3. Gatewaying of MDN-requests to other mail systems . . . . 25 8.3. Gatewaying of MDN-requests to other mail systems . . . . 25
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10.1. Disposition-Notification-Options header field 10.1. Disposition-Notification-Options header field
disposition-notification-parameter names . . . . . . . . 27 disposition-notification-parameter names . . . . . . . . 27
10.2. Disposition modifier names . . . . . . . . . . . . . . . 28 10.2. Disposition modifier names . . . . . . . . . . . . . . . 28
10.3. MDN extension field names . . . . . . . . . . . . . . . 28 10.3. MDN extension field names . . . . . . . . . . . . . . . 28
skipping to change at page 11, line 43 skipping to change at page 11, line 43
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 ":" *(CFWS / 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 fixed, with the exception
of the extension fields. of the extension fields.
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
[2], the same conventions for continuation lines and comments apply. [2], the same conventions for continuation lines and comments apply.
Notification fields may be continued onto multiple lines by beginning Notification fields may be continued onto multiple lines by beginning
each additional line with a SPACE or HTAB. Text that appears in each additional line with a SPACE or HTAB. Text that appears in
parentheses is considered a comment and not part of the contents of parentheses is considered a comment and not part of the contents of
that notification field. Field names are case-insensitive, so the that notification field. Field names are case-insensitive, so the
names of notification fields may be spelled in any combination of names of notification fields may be spelled in any combination of
upper and lower case letters. Comments in notification fields may upper and lower case letters. Comments in notification fields may
use the "encoded-word" construct defined in RFC-MIME-HEADER [5]. use the "encoded-word" construct defined in RFC-MIME-HEADER [5].
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". [[ more work needed here ]] colon, followed by "*text".
[[CREF2: (Here and elsewhere in the document) It looks like there is [[CREF2: (Here and elsewhere in the document) It looks like there is
emerging consensus that the document should describe 2 grammars: one emerging consensus that the document should describe 2 grammars: one
for "must accept" (which allows CFWS) and another one for "should for "must accept" (which either allows CFWS or [FWS]) and another one
generate" (CFWS not allowed, but [FWS] are allowed). A future for "should generate" (CFWS not allowed, but *WSP are allowed). A
version of this document will implement this change, unless future version of this document will implement this change, unless
objections are voiced. ]] objections are voiced. ]]
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.
skipping to change at page 13, line 13 skipping to change at page 13, line 13
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
defined in RFC-DSN-SMTP [7].) Registration forms for address-type defined in RFC-DSN-SMTP [7].) Registration forms for address-type
and mta-name-type appear in RFC-DSN-FORMAT [8]. and mta-name-type appear in RFC-DSN-FORMAT [8].
3.2. Message/disposition-notification Fields 3.2. Message/disposition-notification Fields
3.2.1. The Reporting-UA field 3.2.1. The Reporting-UA field
reporting-ua-field = "Reporting-UA" ":" ua-name [ ";" ua-product ] reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ]
ua-name = *text-no-semi ua-name = *text-no-semi
ua-product = *text-no-semi ua-product = *(FWS / text)
text-no-semi = %d1-9 / ; text characters excluding NUL, CR, text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR,
%d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon %d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon
OWS = *WSP
; Optional whitespace.
; MDN generators SHOULD use "*WSP"
; (typically a single space or nothing.
; It SHOULD be nothing at the end of a field).
; MDN parsers MUST parse it as "[CFWS]".
The Reporting-UA field is defined as follows: The Reporting-UA field is defined as follows:
An MDN describes the disposition of a message after it has been An MDN describes the disposition of a message after it has been
delivered to a recipient. In all cases, the Reporting-UA is the MUA delivered to a recipient. In all cases, the Reporting-UA is the MUA
that performed the disposition described in the MDN. This field is that performed the disposition described in the MDN. This field is
optional, but recommended. For Internet Mail user agents, it is optional, but recommended. For Internet Mail user agents, it is
recommended that this field contain both: the DNS name of the recommended that this field contain both: the DNS name of the
particular instance of the MUA that generated the MDN, and the name particular instance of the MUA that generated the MDN, and the name
of the product. For example, of the product. For example,
Reporting-UA: pc.example.com; Foomail 97.1 Reporting-UA: pc.example.com; Foomail 97.1
If the reporting MUA consists of more than one component (e.g., a If the reporting MUA consists of more than one component (e.g., a
base program and plug-ins), this may be indicated by including a list base program and plug-ins), this may be indicated by including a list
of product names. of product names. [[CREF3: Should ua-name be defined as "*(FWS /
text-no-semi)"?]]
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" ":" OWS mta-name-type OWS ";" OWS mta-name OWS
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 Original- issued. For Internet Mail messages, the value of the Original-
Recipient field is obtained from the Original-Recipient header field Recipient field is obtained from the Original-Recipient header field
skipping to change at page 14, line 23 skipping to change at page 14, line 26
Recipient field MUST be omitted, unless the same information is Recipient field MUST be omitted, unless the same information is
reliably available some other way. If there is an Original-Recipient reliably available some other way. If there is an Original-Recipient
header field in the original message (or original recipient header field in the original message (or original recipient
information is reliably available some other way), then the Original- information is reliably available some other way), then the Original-
Recipient field must be supplied. If there is more than one Recipient field must be supplied. If there is more than one
Original-Recipient header field in the message, the MUA may choose Original-Recipient header field in the message, the MUA may choose
the one to use, or act as if no Original-Recipient header field is the one to use, or act as if no Original-Recipient header field is
present. present.
original-recipient-field = original-recipient-field =
"Original-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS
generic-address = *text generic-address = *text
The address-type field indicates the type of the original recipient The address-type field indicates the type of the original recipient
address. If the message originated within the Internet, the address- address. If the message originated within the Internet, the address-
type field will normally be "rfc822", and the address will be type field will normally be "rfc822", and the address will be
according to the syntax specified in RFC-MSGFMT [2]. The value according to the syntax specified in RFC-MSGFMT [2]. The value
"unknown" should be used if the Reporting MUA cannot determine the "unknown" should be used if the Reporting MUA cannot determine the
type of the original recipient address from the message envelope. type of the original recipient address from the message envelope.
This address is the same as that provided by the sender and can be This address is the same as that provided by the sender and can be
used to automatically correlate MDN reports with original messages on used to automatically correlate MDN reports with original messages on
a per recipient basis. a per recipient basis.
3.2.4. Final-Recipient field 3.2.4. Final-Recipient field
The Final-Recipient field indicates the recipient for which the MDN The Final-Recipient field indicates the recipient for which the MDN
is being issued. This field MUST be present. is being issued. This field MUST be present.
The syntax of the field is as follows: The syntax of the field is as follows:
final-recipient-field = final-recipient-field =
"Final-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address "Final-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS
The generic-address subfield of the Final-Recipient field MUST The generic-address subfield of the Final-Recipient field MUST
contain the mailbox address of the recipient (from the From header contain the mailbox address of the recipient (from the From header
field of the MDN) as it was when the MDN was generated by the MUA. field of the MDN) as it was when the MDN was generated by the MUA.
The Final-Recipient address may differ from the address originally The Final-Recipient address may differ from the address originally
provided by the sender, because it may have been transformed during provided by the sender, because it may have been transformed during
forwarding and gatewaying into a totally unrecognizable mess. forwarding and gatewaying into a totally unrecognizable mess.
However, in the absence of the optional Original-Recipient field, the However, in the absence of the optional Original-Recipient field, the
Final-Recipient field and any returned content may be the only Final-Recipient field and any returned content may be the only
information available with which to correlate the MDN with a information available with which to correlate the MDN with a
particular message recipient. particular message recipient.
The address-type subfield indicates the type of address expected by The address-type subfield indicates the type of address expected by
the reporting MTA in that context. Recipient addresses obtained via the reporting MTA in that context. Recipient addresses obtained via
SMTP will normally be of address-type "rfc822". SMTP will normally be of address-type "rfc822".
Since mailbox addresses (including those used in the Internet) may be Since mailbox addresses (including those used in the Internet) may be
skipping to change at page 15, line 27 skipping to change at page 15, line 30
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- for which the MDN is being issued. It is obtained from the Message-
ID header field of the message for which the MDN is issued. This ID header field of the message for which the MDN is issued. This
field MUST be present if the original message contained a Message-ID field MUST be present if the original message contained a Message-ID
header field. The syntax of the field is as follows: header field. The syntax of the field is as follows:
original-message-id-field = original-message-id-field =
"Original-Message-ID" ":" msg-id "Original-Message-ID" ":" OWS msg-id OWS
The msg-id token is as specified in RFC-MSGFMT [2]. The msg-id token is as specified in RFC-MSGFMT [2].
3.2.6. Disposition field 3.2.6. Disposition field
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" ":" [FWS] disposition-mode ";" "Disposition" ":" OWS disposition-mode OWS ";"
[FWS] disposition-type OWS disposition-type
[ "/" disposition-modifier [ OWS "/" OWS disposition-modifier
*( "," disposition-modifier ) ] *( OWS "," OWS disposition-modifier ) ] OWS
disposition-mode = action-mode "/" [FWS] 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 = [FWS] disposition-modifier = "error" / disposition-modifier-extension
("error" / disposition-modifier-extension)
disposition-modifier-extension = atom disposition-modifier-extension = atom
The disposition-mode, disposition-type, and disposition-modifier may The disposition-mode, disposition-type, and disposition-modifier may
be spelled in any combination of upper and lower case characters. be 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 type
was a result of an explicit instruction by the was a result of an explicit instruction by the
skipping to change at page 18, line 20 skipping to change at page 18, line 20
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 "failure"
disposition type or "error" disposition modifier appear. The syntax disposition type or "error" disposition modifier appear. The syntax
is as follows: is as follows:
failure-field = "Failure" ":" *text failure-field = "Failure" ":" *(FWS / text)
error-field = "Error" ":" *text error-field = "Error" ":" *(FWS / 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 reserved for experimental use. MDN field names NOT beginning with
"X-" 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.) MDN approved by the IESG. (See Section 10 for a registration form.) MDN
skipping to change at page 22, line 42 skipping to change at page 22, line 42
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 Automatic, or simplistic processing of such requests would result in
a flood of MDN notifications to the target of the attack. Such an a 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 ABNF Grammar
NOTE: The following lexical tokens are defined in RFC-MSGFMT [2]: NOTE: The following lexical tokens are defined in RFC-MSGFMT [2]:
CRLF, FWS, CFWS, field-name, mailbox, msg-id, text. The following CRLF, FWS, CFWS, field-name, mailbox, msg-id, text. The following
lexical tokens are defined in RFC-SMTP [1]: atom. (Note that RFC- lexical tokens are defined in RFC-SMTP [1]: atom. (Note that RFC-
MSGFMT [2] also defines "atom", but the version from RFC-SMTP [1] is MSGFMT [2] also defines "atom", but the version from RFC-SMTP [1] is
more restrictive and this more restrictive version is used in this more restrictive and this more restrictive version is used in this
document) The definitions of attribute and value are as in the document.) The definitions of attribute and value are as in the
definition of the Content-Type header field in RFC-MIME-BODY [3]. definition of the Content-Type header field in RFC-MIME-BODY [3].
Message header fields: Message header fields:
mdn-request-header = mdn-request-header =
"Disposition-Notification-To" ":" [FWS] "Disposition-Notification-To" ":" [FWS]
mailbox *("," [FWS] mailbox) mailbox *("," [FWS] mailbox)
Disposition-Notification-Options = Disposition-Notification-Options =
"Disposition-Notification-Options" ":" [FWS] "Disposition-Notification-Options" ":" [FWS]
disposition-notification-parameter-list disposition-notification-parameter-list
skipping to change at page 23, line 30 skipping to change at page 23, line 30
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 )
*( extension-field CRLF ) *( extension-field CRLF )
OWS = *WSP
; Optional whitespace.
; MDN generators SHOULD use "*WSP"
; (typically a single space or nothing).
; MDN parsers MUST parse it as "[CFWS]".
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" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ]
ua-name = *text-no-semi ua-name = *text-no-semi
ua-product = *text-no-semi ua-product = *(FWS / text)
text-no-semi = %d1-9 / ; text characters excluding NUL, CR, text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR,
%d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon %d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon
mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name
mta-name = *text mta-name = *text
original-recipient-field = original-recipient-field =
"Original-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS
generic-address = *text generic-address = *text
final-recipient-field = final-recipient-field =
"Final-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address "Final-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS
original-message-id-field = "Original-Message-ID" ":" msg-id original-message-id-field = "Original-Message-ID" ":" OWS msg-id OWS
disposition-field = disposition-field =
"Disposition" ":" [FWS] disposition-mode ";" "Disposition" ":" OWS disposition-mode OWS ";"
[FWS] disposition-type OWS disposition-type
[ "/" disposition-modifier
*( "," disposition-modifier ) ] [ OWS "/" OWS disposition-modifier
disposition-mode = action-mode "/" [FWS] sending-mode *( OWS "," OWS disposition-modifier ) ] OWS
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 = [FWS] disposition-modifier = "error" / disposition-modifier-extension
("error" / disposition-modifier-extension)
disposition-modifier-extension = atom disposition-modifier-extension = atom
failure-field = "Failure" ":" *text failure-field = "Failure" ":" *(FWS / text)
error-field = "Error" ":" *text error-field = "Error" ":" *(FWS / text)
extension-field = extension-field-name ":" *text extension-field = extension-field-name ":" *(FWS / text)
extension-field-name = field-name extension-field-name = field-name
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.
skipping to change at page 30, line 32 skipping to change at page 30, line 32
whitespace and folding in the header fields just like any other whitespace and folding in the header fields just like any other
RFC5322 [2]-formatted header field. There were also a number of RFC5322 [2]-formatted header field. There were also a number of
places in the ABNF that inconsistently permitted comments and places in the ABNF that inconsistently permitted comments and
whitespace in one leg of the production and not another. The ABNF whitespace in one leg of the production and not another. The ABNF
now specifies FWS and CFWS in several places that should have already now specifies FWS and CFWS in several places that should have already
been specified by the grammar. been specified by the grammar.
Extension-field was defined in the collected grammar but not in the Extension-field was defined in the collected grammar but not in the
main text. main text.
[[CREF3: Shouldn't the places we use *text and *text-no-semi allow [[CREF4: Shouldn't the places we use *text and *text-no-semi allow
FWS? ]] FWS? ]]
The comparison of mailboxes in Disposition-Notification-To to the The comparison of mailboxes in Disposition-Notification-To to the
Return-Path addr-spec was clarified. Return-Path addr-spec was clarified.
The use of the grammar production "parameter" was confusing with the The use of the grammar production "parameter" was confusing with the
RFC2045 [3] production of the same name, as well as other uses of the RFC2045 [3] production of the same name, as well as other uses of the
same term. These have been clarified. same term. These have been clarified.
[[CREF4: Not sure what to do with this one: (From Bruce) In the case [[CREF5: Not sure what to do with this one: (From Bruce) In the case
of the message header fields, RFC 2822 also specifies minimum and of the message header fields, RFC 2822 also specifies minimum and
maximum counts for each header field, and similar guidance would maximum counts for each header field, and similar guidance would
clarify 3798 (e.g. are multiple Disposition-Notification-Options clarify 3798 (e.g. are multiple Disposition-Notification-Options
fields permitted in a single message header, and if so, what fields permitted in a single message header, and if so, what
semantics apply?). ]] semantics apply?). ]]
[[CREF5: Not sure what to do with this one: (From Bruce) Note also [[CREF6: Not sure what to do with this one: (From Bruce) Note also
that RFC 2045 is itself based on RFC 822 rather than 2822, so the that RFC 2045 is itself based on RFC 822 rather than 2822, so the
issue of where CFWS is permitted or prohibited should probably be issue of where CFWS is permitted or prohibited should probably be
clearly specified where "attribute" and "value" are used. Note clearly specified where "attribute" and "value" are used. Note
further that the RFC 2045 definitions are clarified by errata and further that the RFC 2045 definitions are clarified by errata and
modified by RFC 2231, and by RFC 2231 errata. Finally, note that RFC modified by RFC 2231, and by RFC 2231 errata. Finally, note that RFC
2231 has provisions for continuation of long parameter values (where 2231 has provisions for continuation of long parameter values (where
there would otherwise be problems with the maximum line length there would otherwise be problems with the maximum line length
specifications of RFCs 822 and 2822), specification of language and specifications of RFCs 822 and 2822), specification of language and
charset, and provision for compatible handling of non-ASCII text, charset, and provision for compatible handling of non-ASCII text,
none of which are provided for in the RFC 3798 disposition- none of which are provided for in the RFC 3798 disposition-
notification parameters. It might be a good idea to think about that notification parameters. It might be a good idea to think about that
now, as a future change would almost certainly reset the document now, as a future change would almost certainly reset the document
status to "Proposed". ]] status to "Proposed". ]]
A clarification was added on the extent of the 7bit nature of MDNs. A clarification was added on the extent of the 7bit nature of MDNs.
Uses of the terms "may" and "might" were clarified. Uses of the terms "may" and "might" were clarified.
A clarification was added on the order of the fields in the message/ A clarification was added on the order of the fields in the message/
disposition-notification content. disposition-notification content.
[[CREF6: Not sure what to do with this one: (From Bruce) 3.1.1 [[CREF7: Not sure what to do with this one: (From Bruce) 3.1.1
explicitly mentions use of RFC 2047 encoded-words in comments explicitly mentions use of RFC 2047 encoded-words in comments
(however, as noted above there is no explicit provision for (however, as noted above there is no explicit provision for
comments), but fails to mention the other contexts in which encoded- comments), but fails to mention the other contexts in which encoded-
words may be used, viz. in an RFC [2]822 "phrase" (e.g. in the words may be used, viz. in an RFC [2]822 "phrase" (e.g. in the
display name of a name-addr mailbox in Disposition-Notification-To display name of a name-addr mailbox in Disposition-Notification-To
(therefore, the discussion of encoded-words should probably be moved (therefore, the discussion of encoded-words should probably be moved
earlier in the document, prior to the specification of Disposition- earlier in the document, prior to the specification of Disposition-
Notification-To]), and in unstructured text (i.e. every instance of Notification-To]), and in unstructured text (i.e. every instance of
*text in the ABNF). In particular, use of encoded-words might be *text in the ABNF). In particular, use of encoded-words might be
highly desirable in the following places: *) the ua-product portion highly desirable in the following places: *) the ua-product portion
 End of changes. 32 change blocks. 
54 lines changed or deleted 63 lines changed or added

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