Message Tracking Model and Requirements
RFC 3888

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

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