From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3886.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc3886.txt (limited to 'doc/rfc/rfc3886.txt') 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] + -- cgit v1.2.3