Message Tracking Model and Requirements
RFC 3888
|
Document |
Type |
|
RFC - Informational
(September 2004; No errata)
|
|
Author |
|
Tony Hansen
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 3888 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Scott Hollenbeck
|
|
Send notices to |
|
(None)
|
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
Show full document text