summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3888.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3888.txt')
-rw-r--r--doc/rfc/rfc3888.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc3888.txt b/doc/rfc/rfc3888.txt
new file mode 100644
index 0000000..9ed2074
--- /dev/null
+++ b/doc/rfc/rfc3888.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group T. Hansen
+Request for Comments: 3888 AT&T Laboratories
+Category: Informational September 2004
+
+
+ Message Tracking Model and Requirements
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ Customers buying enterprise message systems often ask: Can I track
+ the messages? Message tracking is the ability to find out the path
+ that a particular message has taken through a messaging system and
+ the current routing status of that message. This document provides a
+ model of message tracking that can be used for understanding the
+ Internet-wide message infrastructure and to further enhance those
+ capabilities to include message tracking, as well as requirements for
+ proposed message tracking solutions.
+
+1. Problem Statement
+
+ Consider sending a package through a package delivery company. Once
+ you've sent a package, you would like to be able to find out if the
+ package has been delivered or not, and if not, where that package
+ currently is and what its status is. Note that the status of a
+ package may not include whether it was delivered to its addressee,
+ but just the destination. Many package carriers provide such
+ services today, often via a web interface.
+
+ Message tracking extends that capability to the Internet-wide message
+ infrastructure, analogous to the service provided by package
+ carriers: the ability to quickly locate where a message (package)
+ is, and to determine whether or not the message (package) has been
+ delivered to its final destination. An Internet-standard approach
+ will allow the development of message tracking applications that can
+ operate in a multi-vendor messaging environment, and will encourage
+ the operation of the function across administrative boundaries.
+
+
+
+
+
+Hansen Informational [Page 1]
+
+RFC 3888 Message Tracking Model and Requirements September 2004
+
+
+ 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 BCP 14, RFC 2119
+ [RFC-KEYWORDS].
+
+2. Definitions
+
+ The following terms are relevant to message tracking. The terms
+ Tracking User Agent and Tracking Server are new, while all other
+ terms have been collected here from other sources.
+
+ Originating Mail User Agent (MUA)
+ The originating mail user agent is the software used to
+ compose and originate a message. It is the software
+ sitting on a person's desktop.
+
+ Originating Mail Submission Agent (MSA)
+ The Mail Submission Agent accepts a message from a User
+ Agent, adds or modifies it as required for Internet
+ standards and/or site policy, and injects the message into
+ the network. The MSA may be the initial MTA or may hand
+ off the message to an MTA.
+
+ Message Transfer Agent (MTA)
+ A Message Transfer Agent accepts a message and moves it
+ forward towards its destination. That destination may be
+ local or reached via another MTA. It may use a local queue
+ to store the message before transferring it further. Any
+ MTA may generate a Non-Delivery Notification.
+
+ Intermediate Message Transfer Agent (MTA)
+ An Intermediate MTA is an MTA that accepts a message for
+ transfer somewhere else.
+
+ Final Message Transfer Agent (MTA)
+ A Final MTA is an MTA that accepts a message for local
+ delivery. It is the final place that a message is
+ accepted. The final MTA is what sends any Delivery Status
+ Notifications (DSNs). (Intermediate MTA's may also send a
+ DSN if it relays to a non-DSN aware MTA.)
+
+ Foreign Message Transfer Agent
+ A foreign MTA provides delivery of messages using other
+ protocols than those specified for Internet mail, such as
+ an X.400 mail system.
+
+
+
+
+
+
+Hansen Informational [Page 2]
+
+RFC 3888 Message Tracking Model and Requirements September 2004
+
+
+ Gateway Message Transfer Agent (GW-MTA)
+ A gateway MTA accepts a message for transfer to a foreign
+ MTA outside of the Internet protocol space.
+
+ Local Delivery Agent (LDA)
+ The local Delivery Agent delivers the message to the local
+ message store. (The MTA and LDA are often combined into
+ the same program.)
+
+ Delivery Status Notification (DSN)
+ A Delivery Status Notification [RFC-DSN] is produced by an
+ MTA when a message is unsuccessfully delivered, either to
+ its next hop or the final message store, or when it is
+ successfully delivered, either to a foreign MTA, to a local
+ delivery agent, or a non-DSN aware MTA. Positive
+ notifications are only performed [RFC-ESMTP-DSN] when
+ specifically requested.
+
+ Non-Delivery Notification (NDN)
+ A non-delivery notification is a special form of DSN
+ indicating unsuccessful delivery.
+
+ Message Disposition Notification (MDN)
+ A Message Disposition Notification is used to report the
+ disposition of a message after it has been successfully
+ delivered to a recipient.
+
+ Tracking User Agent (TUA)
+ A tracking user agent wants to find information on a
+ message on the behalf of a user. It is the requestor or
+ initiator of such a request. (The MUA and TUA could be
+ combined into the same program.)
+
+ Tracking Server
+ A tracking server provides tracking information to a
+ tracking client. It is the repository of the information
+ about a message for the traversal through a particular MTA.
+ (The tracking server and MTA may run on the same system.)
+
+3. Entities
+
+ The entities involved in message tracking are: message user agents,
+ message submission agents, message transfer agents, tracking user
+ agents and tracking servers.
+
+
+
+
+
+
+
+Hansen Informational [Page 3]
+
+RFC 3888 Message Tracking Model and Requirements September 2004
+
+
+4. Requirements
+
+ These are requirements that any message tracking solution must be
+ able to satisfy:
+
+ The message tracking solution:
+
+ ** MUST scale to the internet.
+
+ ** MUST be easy to deploy.
+
+ ** SHOULD maximize the reuse of existing, already deployed
+ technology and infrastructure.
+
+ ** If possible, SHOULD extend existing protocols and not invent new
+ ones.
+
+ ** SHOULD have a low implementation cost. (This makes it easy to
+ incorporate into existing products.)
+
+ ** MUST restrict tracking of a message to the originator of the
+ message (or a delegate).
+
+ ** MUST be able to do authentication.
+
+ ** MAY allow an originator to delegate this responsibility to a
+ third party.
+
+ ** SHOULD have the property that they would allow per-message
+ delegation of the tracking responsibility.
+
+ ** MUST require a tracking user agent to prove that they are
+ permitted to request the tracking information.
+
+ ** MUST be able to uniquely identify messages.
+
+ ** MUST require every message to have unique identification.
+
+5. Interaction Models
+
+ There are several models by which tracking of messages can be
+ enabled, by which messages can be tracked, and by which information
+ can be requested and gathered.
+
+
+
+
+
+
+
+
+Hansen Informational [Page 4]
+
+RFC 3888 Message Tracking Model and Requirements September 2004
+
+
+5.1. Tracking Enabling Models
+
+ Either the envelope or message header must contain enough information
+ to track a message and securely retrieve information about the
+ message. Any message that does not have enough information to track
+ it is by definition not trackable.
+
+ If there is not enough information available in current standard
+ envelopes or message headers, then the current standards will need to
+ be extended. Either the MUA or MSA must determine the additional
+ information and enable the tracking by adding the additional
+ information to either the envelope or header.
+
+ This leads to two tracking enabling models: passive enabling and
+ active enabling.
+
+5.1.1. Passive Enabling Model
+
+ The "passive enabling" model assumes that there is sufficient
+ information available. No UA or MSA interaction occurs to turn
+ tracking on; it is on by default.
+
+5.1.2. Active Enabling Model
+
+ The "active enabling" model requires that the MUA and MSA exchange
+ information when the message is submitted. This exchange indicates
+ that logging of the message's traversal should be performed, as well
+ as providing enough additional information to allow the message to be
+ tracked. This information will need to be passed on to subsequent
+ MTAs as needed.
+
+5.2. Tracking Request Models
+
+ There are several models by which tracking information may be
+ requested.
+
+5.2.1. Passive Request Model
+
+ The "passive request" model requires active enabling to indicate that
+ some form of tracking is to be performed. The tracking information
+ can be sent back immediately (as a form of telemetry) or sent to a
+ 3rd party for later retrieval.
+
+
+
+
+
+
+
+
+
+Hansen Informational [Page 5]
+
+RFC 3888 Message Tracking Model and Requirements September 2004
+
+
+5.2.2. Passive Request Tracking Information
+
+ Forms of passive tracking information that could potentially be
+ requested are as follows. Note that mechanisms already exist for
+ requesting the information marked with a (+). The references for
+ such mechanisms are listed at the end of each such entry.
+
+ ** send a DSN of a message arriving at an intermediate MTA
+
+ ** (+) send a DSN of a message being rejected while at an
+ intermediate MTA [RFC-DSN]
+
+ ** (+) send a DSN of a message leaving an intermediate MTA and
+ going to another MTA [RFC-DELIVER-BY]
+
+ ** send a DSN of a message arriving at a final MTA
+
+ ** (+) send a DSN of a message being rejected while at a final MTA
+ [RFC-DSN]
+
+ ** (+) send a DSN of a message being delivered to a user's message
+ store [RFC-DSN]
+
+ ** (+) send a DSN of a message being delivered to a foreign MTA
+ [RFC-DSN]
+
+ ** (+) send an MDN of a message being read by an end user [RFC-MDN]
+
+5.3. Active Request Model
+
+ The "active request" model requires an active query by a user's user
+ agent to the MSA, intermediate MTAs and final MTA, or to a third
+ party, to find the message's status as known by that MTA. Active
+ request will work with either passive enabling or active enabling.
+
+5.3.1. Server Chaining vs. Server Referrals
+
+ When a tracking server has been asked for tracking information, and
+ the message has been passed on to another MTA of which this tracking
+ server has no tracking knowledge, there are two modelling choices:
+
+ ** the first tracking server will contact the next tracking server
+ to query for status and pass back the combined status (server
+ chaining), or
+
+ ** the first tracking server will return the address of the next
+ MTA and the tracking client has the responsibility of contacting
+ the next tracking server (server referrals).
+
+
+
+Hansen Informational [Page 6]
+
+RFC 3888 Message Tracking Model and Requirements September 2004
+
+
+5.3.2. Active Request Tracking Information
+
+ Forms of active tracking information that could potentially be
+ requested are as follows. (Note that no mechanisms currently exist
+ for requesting such information.)
+
+ ** the message has been queued for later delivery
+
+ ** the message was delivered locally
+
+ ** the message was delivered to another MTA,
+
+ ** the message was delivered to a foreign MTA
+
+ ** ask a different tracking server,
+
+ ** I know but can't tell you,
+
+ ** I don't know.
+
+5.4. Combining DSN and MDN Information with Message Tracking
+ Information
+
+ The information that would be retrieved by message tracking and the
+ information that is returned for DSN and MDN requests all attempt to
+ answer the question of "what happened to message XX"? The
+ information provided by each is complimentary in nature, but similar.
+ A tracking user agent could use all three possible information
+ sources to present a total view of the status of a message.
+
+ Both DSN and MDN notifications utilize the formats defined by RFC
+ 3462 [RFC-REPORT]. This suggests that the information returned by
+ message tracking solutions should also be similar.
+
+6. Security Considerations
+
+6.1. Security Considerations Summary
+
+ Security vulnerabilities are detailed in [RFC-MTRK-ESMTP], [RFC-
+ MTRK-TSN] and [RFC-MTRK-MTQP]. These considerations include:
+
+ ** vulnerability to snooping or replay attacks when using
+ unencrypted sessions
+
+ ** a dependency on the randomness of the per-message secret
+
+ ** reliance on TLS
+
+
+
+
+Hansen Informational [Page 7]
+
+RFC 3888 Message Tracking Model and Requirements September 2004
+
+
+ ** man-in-the-middle attacks
+
+ ** reliance on the server maintaining the security level when it
+ performs chaining
+
+ ** denial of service
+
+ ** confidentiality concerns
+
+ ** forgery by malicious servers
+
+6.2. Message Identification and Authentication
+
+ This is a security model for message identification and
+ authentication that could be deployed. (There may be others.)
+
+ A Tracking User Agent must prove that they are permitted to request
+ tracking information about a message. Every [RFC-822]-compliant
+ message is supposed to contain a Message-Id header. One possible
+ mechanism is for the originator to calculate a one-way hash A from
+ the message ID + time stamp + a per-user secret. The user then
+ calculates another one-way hash B to be the hash of A. The user
+ includes B in the submitted message, and retains A. Later, when the
+ user makes a message tracking request to the messaging system or
+ tracking entity, it submits A in the tracking request. The entity
+ receiving the tracking request then uses A to calculate B, since it
+ was already provided B, verifying that the requestor is authentic.
+ In summary,
+
+ A = H(message ID + time stamp + secret)
+
+ B = H(A)
+
+ Another possible mechanism for A is to ignore the message ID and time
+ stamp and just use a one-way hash from a large (>128 bits) random
+ number. B would be calculated as before. In summary,
+
+ A = H(large-random-number)
+
+ B = H(A)
+
+ This is similar in technique to the methods used for One-Time
+ Passwords [RFC-OTP]. The success of these techniques is dependent on
+ the randomness of the per-user secret or the large random number,
+ which can be incredibly difficult in some environments.
+
+
+
+
+
+
+Hansen Informational [Page 8]
+
+RFC 3888 Message Tracking Model and Requirements September 2004
+
+
+ If the originator of a message were to delegate his or her tracking
+ request to a third party by sending it A, this would be vulnerable to
+ snooping over unencrypted sessions. The user can decide on a
+ message-by-message basis if this risk is acceptable.
+
+7. Informational References
+
+ [RFC-822] Crocker, D., "Standard for the format of ARPA
+ Internet text messages", STD 11, RFC 822, August
+ 1982.
+
+ [RFC-DELIVER-BY] Newman, D., "Deliver By SMTP Service Extension",
+ RFC 2852, June 2000.
+
+ [RFC-DSN] Moore, K., and G. Vaudreuil, "An Extensible
+ Message Format for Delivery Status Notifications",
+ RFC 3464, January 2003.
+
+ [RFC-ESMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP)
+ Service Extension for Delivery Status
+ Notifications (DSNs)", RFC 3461, January 2003.
+
+ [RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to
+ Indicate Requirement Levels", BCP 14, RFC 2119,
+ March 1997.
+
+ [RFC-MDN] Hansen, T. and G. Vaudreuil, Eds., "Message
+ Disposition Notifications", RFC 3798, May 2004.
+
+ [RFC-OTP] Haller, N., Metz, C., Nesser, P. and M. Straw, "A
+ One-Time Password System", STD 61, RFC 2289,
+ February 1998.
+
+ [RFC-REPORT] Vaudreuil, G., "The Multipart/Report Content Type
+ for the Reporting of Mail System Administrative
+ Messages", RFC 3462, January 2003.
+
+ [RFC-MTRK-ESMTP] Allman, E. and T. Hansen, "SMTP Service Extension
+ for Message Tracking", RFC 3885, September 2004.
+
+ [RFC-MTRK-TSN] Allman, E., "The Message/Tracking-Status MIME
+ Extension", RFC 3886, September 2004.
+
+ [RFC-MTRK-MTQP] Hansen, T., "Message Tracking Query Protocol", RFC
+ 3887, September 2004.
+
+
+
+
+
+
+Hansen Informational [Page 9]
+
+RFC 3888 Message Tracking Model and Requirements September 2004
+
+
+8. Acknowledgements
+
+ This document is the product of input from many people and many
+ sources, including all of the members of the Message Tracking Working
+ Group: Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris Newman,
+ and Gregory Neil Shapiro. It owes much to earlier work by Gordon
+ Jones, Bruce Ernst, and Greg Vaudreuil. In particular, I'd like to
+ also thank Ken Lin for his considerable contributions to the early
+ versions of the document.
+
+9. Author's Address
+
+ Tony Hansen
+ AT&T Laboratories
+ Middletown, NJ 07748
+ USA
+
+ Phone: +1.732.420.8934
+ EMail: tony+msgtrk@maillennium.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen Informational [Page 10]
+
+RFC 3888 Message Tracking Model and Requirements September 2004
+
+
+10. 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.
+
+
+
+
+
+
+
+Hansen Informational [Page 11]
+