summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3886.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3886.txt')
-rw-r--r--doc/rfc/rfc3886.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc3886.txt b/doc/rfc/rfc3886.txt
new file mode 100644
index 0000000..986f06f
--- /dev/null
+++ b/doc/rfc/rfc3886.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group E. Allman
+Request for Comments: 3886 Sendmail, Inc.
+Updates: 3463 September 2004
+Category: Standards Track
+
+
+ An Extensible Message Format for Message Tracking Responses
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ Message Tracking is expected to be used to determine the status of
+ undelivered e-mail upon request. Tracking is used in conjunction
+ with Delivery Status Notifications (DSN) and Message Disposition
+ Notifications (MDN); generally, a message tracking request will be
+ issued only when a DSN or MDN has not been received within a
+ reasonable timeout period.
+
+ This memo defines a MIME content-type for message tracking status in
+ the same spirit as RFC 3464, "An Extensible Message Format for
+ Delivery Status Notifications". It is to be issued upon a request as
+ described in "Message Tracking Query Protocol". This memo defines
+ only the format of the status information. An extension to SMTP to
+ label messages for further tracking and request tracking status is
+ defined in a separate memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman Standards Track [Page 1]
+
+RFC 3886 Message/Tracking-Status September 2004
+
+
+1. Introduction
+
+ Message Tracking is expected to be used to determine the status of
+ undelivered e-mail upon request. Tracking is used in conjunction
+ with Delivery Status Notifications (DSN) [RFC-DSN-SMTP] and Message
+ Disposition Notifications (MDN) [RFC-MDN]; generally, a message
+ tracking request will be issued only when a DSN or MDN has not been
+ received within a reasonable timeout period.
+
+ This memo defines a MIME [RFC-MIME] content-type for message tracking
+ status in the same spirit as RFC 3464, "An Extensible Message Format
+ for Delivery Status Notifications" [RFC-DSN-STAT]. It is to be
+ issued upon a request as described in "Message Tracking Query
+ Protocol" [RFC-MTRK-MTQP]. This memo defines only the format of the
+ status information. An extension to SMTP [RFC-ESMTP] to label
+ messages for further tracking and request tracking status is defined
+ in a separate memo [RFC-MTRK-SMTPEXT].
+
+2. Other Documents and Conformance
+
+ The model used for Message Tracking is described in [RFC-MTRK-MODEL].
+
+ Message tracking is intended for use as a "last resort" mechanism.
+ Normally, Delivery Status Notifications (DSNs) [RFC-DSN-SMTP] and
+ Message Disposition Notifications (MDNs) [RFC-MDN] would provide the
+ primary delivery status. Only if no response is received from either
+ of these mechanisms would Message Tracking be used.
+
+ This document is based on [RFC-DSN-STAT]. Sections 1.3
+ (Terminology), 2.1.1 (General conventions for DSN fields), 2.1.2
+ ("*-type" subfields), and 2.1.3 (Lexical tokens imported from RFC
+ 822) of [RFC-DSN-STAT] are included into this document by reference.
+ Other sections are further incorporated as described herein.
+
+ Syntax notation in this document conforms to [RFC-ABNF].
+
+ The following lexical tokens, defined in [RFC-MSGFMT], are used in
+ the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF,
+ linear-white-space, SPACE, text. The date-time lexical token is
+ defined in [RFC-HOSTREQ].
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC-
+ KEYWORDS].
+
+
+
+
+
+
+Allman Standards Track [Page 2]
+
+RFC 3886 Message/Tracking-Status September 2004
+
+
+3. Format of a Message Tracking Status Notification
+
+ A Message Tracking Status Notification (MTSN) is intended to be
+ returned as the body of a Message Tracking request [RFC-MTRK-MTQP].
+ The actual body MUST be a multipart/related [RFC-RELATED] with type
+ parameter of "message/tracking-status"; each subpart MUST be of type
+ "message/tracking-status" as described herein. The multipart/related
+ body can include multiple message/tracking-status parts if an MTQP
+ server chains requests to the next server; see [RFC-MTRK-MODEL] and
+ [RFC-MTRK-MTQP] for more information about chaining.
+
+3.1. The message/tracking-status content-type
+
+ The message/tracking-status content-type is defined as follows:
+
+ MIME type name: message
+ MIME subtype name: tracking-status
+ Optional parameters: none
+ Encoding considerations: "7bit" encoding is sufficient and
+ MUST be used to maintain readability
+ when viewed by non-MIME mail readers.
+ Security considerations: discussed in section 4 of this memo.
+
+ The body of a message/tracking-status is modeled after [RFC-DSN-
+ STAT]. That body consists of one or more "fields" formatted to
+ according to the ABNF of RFC 2822 header "fields" (see [RFC-MSGFMT]).
+ The per-message fields appear first, followed by a blank line.
+ Following the per-message fields are one or more groups of per-
+ recipient fields. Each group of per-recipient fields is preceded by
+ a blank line. Note that there will be a blank line between the final
+ per-recipient field and the MIME boundary, since one CRLF is
+ necessary to terminate the field, and a second is necessary to
+ introduce the MIME boundary. Formally, the syntax of the
+ message/tracking-status content is as follows:
+
+ tracking-status-content =
+ per-message-fields 1*( CRLF per-recipient-fields )
+
+ The per-message fields are described in section 3.2. The per-
+ recipient fields are described in section 3.3.
+
+3.1.1. General conventions for MTSN fields
+
+ Section 2.1.1 (General conventions for DSN fields) of [RFC-DSN-STAT]
+ is included herein by reference. Notably, the definition of xtext is
+ identical to that of that document.
+
+
+
+
+
+Allman Standards Track [Page 3]
+
+RFC 3886 Message/Tracking-Status September 2004
+
+
+3.1.2. *-type subfields
+
+ Section 2.1.2 (*-type subfields) of [RFC-DSN-STAT] is included herein
+ by reference. Notably, the definitions of address-type, diagnostic-
+ type, and MTA-name type are identical to that of RFC 3464.
+
+3.2. Per-Message MTSN Fields
+
+ Some fields of an MTSN apply to all of the addresses in a single
+ envelope. These fields may appear at most once in any MTSN. These
+ fields are used to correlate the MTSN with the original message
+ transaction and to provide additional information which may be useful
+ to gateways.
+
+ per-message-fields =
+ original-envelope-id-field CRLF
+ reporting-mta-field CRLF
+ arrival-date-field CRLF
+ *( extension-field CRLF )
+
+3.2.1. The Original-Envelope-Id field
+
+ The Original-Envelope-Id field is defined as in section 2.2.1 of
+ [RFC-DSN-STAT]. This field is REQUIRED.
+
+3.2.2. The Reporting-MTA field
+
+ The Reporting-MTA field is defined as in section 2.2.2 of [RFC-DSN-
+ STAT]. This field is REQUIRED.
+
+3.2.3. The Arrival-Date field
+
+ The Arrival-Date field is defined as in section 2.2.5 of [RFC-DSN-
+ STAT]. This field is REQUIRED.
+
+3.3. Per-Recipient MTSN fields
+
+ An MTSN contains information about attempts to deliver a message to
+ one or more recipients. The delivery information for any particular
+ recipient is contained in a group of contiguous per-recipient fields.
+ Each group of per-recipient fields is preceded by a blank line.
+
+
+
+
+
+
+
+
+
+
+Allman Standards Track [Page 4]
+
+RFC 3886 Message/Tracking-Status September 2004
+
+
+ The syntax for the group of per-recipient fields is as follows:
+
+ per-recipient-fields =
+ original-recipient-field CRLF
+ final-recipient-field CRLF
+ action-field CRLF
+ status-field CRLF
+ [ remote-mta-field CRLF ]
+ [ last-attempt-date-field CRLF ]
+ [ will-retry-until-field CRLF ]
+ *( extension-field CRLF )
+
+3.3.1. Original-Recipient field
+
+ The Original-Recipient field is defined as in section 2.3.1 of [RFC-
+ DSN-STAT]. This field is REQUIRED.
+
+3.3.2. Final-Recipient field
+
+ The required Final-Recipient field is defined as in section 2.3.2 of
+ [RFC-DSN-STAT]. This field is REQUIRED.
+
+3.3.3. Action field
+
+ The required Action field indicates the action performed by the
+ Reporting-MTA as a result of its attempt to deliver the message to
+ this recipient address. This field MUST be present for each
+ recipient named in the MTSN. The syntax is as defined in RFC 3464.
+ This field is REQUIRED.
+
+ Valid actions are:
+
+ failed The message could not be delivered. If DSNs have been
+ enabled, a "failed" DSN should already have been
+ returned.
+
+ delayed The message is currently waiting in the MTA queue for
+ future delivery. Essentially, this action means "the
+ message is located, and it is here."
+
+ delivered The message has been successfully delivered to the final
+ recipient. This includes "delivery" to a mailing list
+ exploder. It does not indicate that the message has
+ been read. No further information is available; in
+ particular, the tracking agent SHOULD NOT attempt
+ further "downstream" tracking requests.
+
+
+
+
+
+Allman Standards Track [Page 5]
+
+RFC 3886 Message/Tracking-Status September 2004
+
+
+ expanded The message has been successfully delivered to the
+ recipient address as specified by the sender, and
+ forwarded by the Reporting-MTA beyond that destination
+ to multiple additional recipient addresses. However,
+ these additional addresses are not trackable, and the
+ tracking agent SHOULD NOT attempt further "downstream"
+ tracking requests.
+
+ relayed The message has been delivered into an environment that
+ does not support message tracking. No further
+ information is available; in particular, the tracking
+ agent SHOULD NOT attempt further "downstream" tracking
+ requests.
+
+ transferred The message has been transferred to another MTRK-
+ compliant MTA. The tracking agent SHOULD attempt
+ further "downstream" tracking requests unless that
+ information is already given in a chaining response.
+
+ opaque The message may or may not have been seen by this
+ system. No further information is available or
+ forthcoming.
+
+ There may be some confusion between when to use "expanded" versus
+ "delivered". Whenever possible, "expanded" should be used when the
+ MTA knows that the message will be sent to multiple addresses.
+ However, in some cases the delivery occurs to a program which,
+ unknown to the MTA, causes mailing list expansion; in the extreme
+ case, the delivery may be to a real mailbox that has the side effect
+ of list expansion. If the MTA cannot ensure that this delivery will
+ cause list expansion, it should set the action to "delivered".
+
+3.3.4. Status field
+
+ The Status field is defined as in RFC 3464. A new code is added to
+ RFC 3463 [RFC-EMSSC], "Enhanced Mail System Status Codes",
+
+ X.1.9 Message relayed to non-compliant mailer"
+
+ The mailbox address specified was valid, but the message has
+ been relayed to a system that does not speak this protocol; no
+ further information can be provided.
+
+ A 2.1.9 Status field MUST be used exclusively with a "relayed" Action
+ field. This field is REQUIRED.
+
+
+
+
+
+
+Allman Standards Track [Page 6]
+
+RFC 3886 Message/Tracking-Status September 2004
+
+
+3.3.5. Remote-MTA field
+
+ The Remote-MTA field is defined as in section Reference 2.3.5 of
+ [RFC-DSN-STAT]. This field MUST NOT be included if no delivery
+ attempts have been made or if the Action field has value "opaque".
+ If delivery to some agent other than an MTA (for example, a Local
+ Delivery Agent) then this field MAY be included, giving the name of
+ the host on which that agent was contacted.
+
+3.3.6. Last-Attempt-Date field
+
+ The Last-Attempt-Date field is defined as in section Reference 2.3.7
+ of [RFC-DSN-STAT]. This field is REQUIRED if any delivery attempt
+ has been made and the Action field does not have value "opaque", in
+ which case it will specify when it last attempted to deliver this
+ message to another MTA or other Delivery Agent. This field MUST NOT
+ be included if no delivery attempts have been made.
+
+3.3.7. Will-Retry-Until field
+
+ The Will-Retry-Until field is defined as in section Reference 2.3.9
+ of [RFC-DSN-STAT]. If the message is not in the local queue or the
+ Action field has the value "opaque" the Will-Retry-Until field MUST
+ NOT be included; otherwise, this field SHOULD be included.
+
+3.4. Extension fields
+
+ Future extension fields may be defined as defined in section 2.4 of
+ [RFC-DSN-STAT].
+
+3.5. Interaction Between MTAs and LDAs
+
+ A message that has been delivered to a Local Delivery Agent (LDA)
+ that understands message tracking (in particular, an LDA speaking
+ LMTP [RFC-LMTP] that supports the MTRK extension) SHOULD pass the
+ tracking request to the LDA. In this case, the Action field for the
+ MTA->LDA exchange will look the same as a transfer to a compliant
+ MTA; that is, a "transferred" tracking status will be issued.
+
+4. Security Considerations
+
+4.1. Forgery
+
+ Malicious servers may attempt to subvert message tracking and return
+ false information. This could result in misdirection or
+ misinterpretation of results.
+
+
+
+
+
+Allman Standards Track [Page 7]
+
+RFC 3886 Message/Tracking-Status September 2004
+
+
+4.2. Confidentiality
+
+ Another dimension of security is confidentiality. There may be cases
+ in which a message recipient is autoforwarding messages but does not
+ wish to divulge the address to which the messages are autoforwarded.
+ The desire for such confidentiality will probably be heightened as
+ "wireless mailboxes", such as pagers, become more widely used as
+ autoforward addresses.
+
+ MTA authors are encouraged to provide a mechanism which enables the
+ end user to preserve the confidentiality of a forwarding address.
+ Depending on the degree of confidentiality required, and the nature
+ of the environment to which a message were being forwarded, this
+ might be accomplished by one or more of:
+
+ (a) respond with a "relayed" tracking status when a message is
+ forwarded to a confidential forwarding address, and disabling
+ further message tracking requests.
+
+ (b) declaring the message to be delivered, issuing a "delivered"
+ tracking status, re-sending the message to the confidential
+ forwarding address, and disabling further message tracking
+ requests.
+
+ The tracking algorithms MUST NOT allow tracking through list
+ expansions. When a message is delivered to a list, a tracking
+ request MUST respond with an "expanded" tracking status and MUST NOT
+ display the contents of the list.
+
+5. IANA Considerations
+
+ IANA has registered the SMTP extension defined in section 3.
+
+6. Acknowledgements
+
+ Several individuals have commented on and enhanced this document,
+ including Tony Hansen, Philip Hazel, Alexey Melnikov, Lyndon
+ Nerenberg, Chris Newman, Gregory Neil Shapiro, and Dan Wing.
+
+7. References
+
+7.1. Normative References
+
+ [RFC-MTRK-MODEL] Hansen, T., "Message Tracking Model and
+ Requirements", RFC 3888, September 2004.
+
+
+
+
+
+
+Allman Standards Track [Page 8]
+
+RFC 3886 Message/Tracking-Status September 2004
+
+
+ [RFC-MTRK-MTQP] Hansen, T., "Message Tracking Query Protocol",
+ RFC 3887, September 2004.
+
+ [RFC-MTRK-SMTPEXT] Allman, E., "SMTP Service Extension for Message
+ Tracking", RFC 3885, September 2004.
+
+ [RFC-ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF
+ for Syntax Specifications: ABNF", RFC 2234,
+ November 1997.
+
+ [RFC-EMSSC] Vaudreuil, G., "Enhanced Mail System Status
+ Codes", RFC 3463, January 2003.
+
+ [RFC-HOSTREQ] Braden, R., Ed., "Requirements for Internet
+ Hosts -- Application and Support", STD 3, RFC
+ 1123, October 1989.
+
+ [RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to
+ Indicate Requirement Levels", BCP 14, RFC 2119,
+ March 1997.
+
+ [RFC-MIME] Freed, N. and N. Borenstein, "Multipurpose
+ Internet Mail Extensions (MIME) Part One: Format
+ of Internet Message Bodies", RFC 2045, November
+ 1996.
+
+ [RFC-MSGFMT] Resnick, P., Ed., "Internet Message Format", RFC
+ 2822, April 2001.
+
+ [RFC-RELATED] Levinson, E., "The MIME Multipart/Related
+ Content-type", RFC 2387, August 1998.
+
+7.2. Informational References
+
+ [RFC-DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP)
+ Service Extension for Delivery Status
+ Notifications (DSNs)", RFC 3461, January 2003.
+
+ [RFC-DSN-STAT] Moore, K. and G. Vaudreuil, "An Extensible
+ Message Format for Delivery Status
+ Notifications", RFC 3464, January 2003.
+
+ [RFC-ESMTP] Rose, M., Stefferud, E., Crocker, D., Klensin,
+ J., and N. Freed, "SMTP Service Extensions", STD
+ 10, RFC 1869, November 1995.
+
+
+
+
+
+
+Allman Standards Track [Page 9]
+
+RFC 3886 Message/Tracking-Status September 2004
+
+
+ [RFC-LMTP] Myers, J., "Local Mail Transfer Protocol", RFC
+ 2033, October 1996.
+
+ [RFC-MDN] Hansen, T. and G. Vaudreuil, Eds., "Message
+ Disposition Notifications", RFC 3798, May 2004.
+
+8. Author's Address
+
+ Eric Allman
+ Sendmail, Inc.
+ 6425 Christie Ave, 4th Floor
+ Emeryville, CA 94608
+ U.S.A.
+
+ Phone: +1 510 594 5501
+ Fax: +1 510 594 5429
+ EMail: eric@Sendmail.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman Standards Track [Page 10]
+
+RFC 3886 Message/Tracking-Status September 2004
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the IETF's procedures with respect to rights in IETF Documents can
+ be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Allman Standards Track [Page 11]
+