doc: Add RFC documents

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]
+