RFC 3888

Message Tracking Model and Requirements

📅 published September 2004, from ietf

RFC 3888: Message Tracking Model and Requirements 📦💌

Okay bestie, so this one is RFC 3888 🎀, titled Message Tracking Model and Requirements. It was written by T. Hansen from AT&T Laboratories and published in September 2004. It's marked as Informational, which means it shares info with the Internet community and doesn't set an Internet standard 💅. The header doesn't list anything it obsoletes or updates, so it's a standalone doc 🦋.

Status of this Memo ✨

This memo gives info to the Internet community. It does NOT specify an Internet standard of any kind 🙈. Distribution of this memo is unlimited, so share it with everyone 🌸.

Copyright (C) The Internet Society (2004).

Abstract 🍓

Okay, so customers buying enterprise message systems keep asking the same thing: "Can I track the messages?" 👀 Message tracking is the ability to find the path a specific message took through a messaging system, plus its current routing status. This doc gives us a model of message tracking that helps us understand the Internet-wide message infrastructure and grow it to include tracking. It also lists the requirements for proposed message tracking solutions, which is giving planning energy 🧚.

1. Problem Statement 💖

Picture sending a package through a delivery company 📦. After you ship it, you want to know if it arrived, and if not, where it is and what its status is. A package's status might not say whether it reached the actual person it was addressed to. It might just show the destination. Lots of carriers already offer this, often through a web page 💻.

Message tracking brings that same vibe to the Internet-wide message infrastructure ✨. You can quickly find where a message (the package) is and check whether it reached its final destination. An Internet-standard approach lets people build tracking apps that work across different vendors' messaging systems, and it encourages tracking to work across administrative boundaries too 🫶.

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]. Yes, these are the official requirement words, so pay attention to them 👑.

2. Definitions 📚

Okay, so these are the terms that matter for message tracking. Tracking User Agent and Tracking Server are brand new 🆕. Everything else was collected here from other sources, so don't panic if you've seen them before 🙈.

  • Originating Mail User Agent (MUA): This is the software used to compose and originate a message. It's the app sitting on a person's desktop 💻.
  • Originating Mail Submission Agent (MSA): The Mail Submission Agent accepts a message from a User Agent. It adds or modifies the message as needed for Internet standards and/or site policy, then injects it into the network 💉. The MSA may be the initial MTA, or it may hand the message off to an MTA 🔁.
  • Message Transfer Agent (MTA): An MTA accepts a message and moves it forward toward its destination 🚚. That destination might be local or reached via another MTA. It may use a local queue to store the message before sending 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's the final place a message is accepted 🏁. The Final MTA is what sends any Delivery Status Notifications (DSNs). (Intermediate MTA's may also send a DSN if they relay to a non-DSN aware MTA 🤓.)
  • Foreign Message Transfer Agent: A foreign MTA delivers messages using protocols other than the ones specified for Internet mail, like an X.400 mail system 🌍.
  • 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 in two situations. One is when a message fails to deliver, either to its next hop or to the final message store. The other is when a message succeeds, whether to a foreign MTA, to a local delivery agent, or to 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 kind of DSN that signals unsuccessful delivery 🚫.
  • Message Disposition Notification (MDN): An MDN reports the disposition of a message after it has been successfully delivered to a recipient 👀.
  • Tracking User Agent (TUA): A tracking user agent looks up information on a message on behalf of a user. It's 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's the repository of information about a message as it moves through a particular MTA 🗄️. (The tracking server and MTA may run on the same system 💜.)

3. Entities 🧚

The entities in message tracking are: message user agents, message submission agents, message transfer agents, tracking user agents and tracking servers. That's the whole cast 🎭.

4. Requirements 👑

These are the requirements that any message tracking solution has to satisfy. Read these like a checklist, bestie 📝.

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 🦋

Okay, so there are several models for enabling tracking, for tracking messages, and for requesting and gathering information. Let's go through them 🍭.

5.1. Tracking Enabling Models 🔓

Either the envelope or the message header must contain enough information to track a message and securely retrieve information about it. Any message that doesn't have enough info to be tracked is, by definition, not trackable 🚫.

If the current standard envelopes or message headers don't have enough info, then the current standards will need to be extended 🛠️. Either the MUA or the MSA must figure out the additional information and enable tracking by adding it to 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 there's already sufficient information available. No UA or MSA interaction happens to turn tracking on, so it's on by default ✅.

5.1.2. Active Enabling Model 🙋‍♀️

The "active enabling" model requires the MUA and MSA to exchange information when the message is submitted 🤝. This exchange says that logging the message's traversal should happen, and it provides enough extra info to let the message be tracked 📝. This information will need to be passed on to subsequent MTAs as needed 🚚.

5.2. Tracking Request Models 📬

There are several models for requesting tracking information 🙋.

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 right away (as a form of telemetry) or sent to a 3rd party for later retrieval 📤.

5.2.2. Passive Request Tracking Information 📋

These are the forms of passive tracking information that could potentially be requested 🫧. Heads up: mechanisms already exist for requesting the items marked with (+). The references for those 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 needs an active query from a user's user agent. That query goes 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 works 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 that this tracking server knows nothing about, 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).

5.3.2. Active Request Tracking Information 🧠

These are the forms of active tracking information that could potentially be requested. (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. 🤷‍♀️

Part 1 of 2 is done, bestie 🎀. Part 2 is coming with the rest of the doc 🫶✨.

5.4. Combining DSN and MDN Information with Message Tracking Information 💖

okay so message tracking and DSN/MDN requests are both trying to answer the same big question: "what happened to message XX"? 🧐 their info is complementary (different but totally vibing together) ✨ a tracking user agent can pull from all three sources and build a full picture of a message's status 💅

both DSN and MDN notifications use the formats from RFC 3462 [RFC-REPORT]. so it makes sense that the info coming back from message tracking should look pretty similar too 🫶

6. Security Considerations 🔐

6.1. Security Considerations Summary 🚨

okay bestie, this part is SERIOUS 😭 security vulnerabilities are detailed in [RFC-MTRK-ESMTP], [RFC-MTRK-TSN] and [RFC-MTRK-MTQP]. the big ones include:

  • vulnerability to snooping or replay attacks when using unencrypted sessions 💀
  • a dependency on the randomness of the per-message secret 🎲
  • reliance on TLS 🔒
  • 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 one security model for message identification and authentication that could be deployed. (there may be others, no cap 🧚)

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. then the user calculates another one-way hash B, which is just the hash of A. the user includes B in the submitted message and keeps A for themselves 🤫 later, when they make a message tracking request to the messaging system or tracking entity, they submit A in the tracking request. the entity receiving the request uses A to calculate B (it was already given B, so it can check), and that verifies 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 of a large (>128 bits) random number. B gets calculated the same way as before. in summary:

A = H(large-random-number)

B = H(A)

this is similar to the methods used for One-Time Passwords [RFC-OTP] 🔑 the success of these techniques depends on the randomness of the per-user secret or the large random number, and in some environments that randomness can be incredibly difficult to get 🥺

if the originator of a message were to delegate their tracking request to a third party by sending it A, that would be vulnerable to snooping over unencrypted sessions 👀 the user can decide, message by message, whether that 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.

8. Acknowledgements 🙌

this document is the product of input from SO many people and 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 a lot to earlier work by Gordon Jones, Bruce Ernst, and Greg Vaudreuil. and the author specifically wants to 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

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. it also doesn't claim it has made any independent effort to identify any such rights. info on the IETF's procedures for rights in IETF Documents can be found in BCP 78 and BCP 79.

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights 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 required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📬

Acknowledgement 💐

funding for the RFC Editor function is currently provided by the Internet Society 🌸

📦 where this page comes from