Network Working Group T. Hansen
Request for Comments: 3887 AT&T Laboratories
Category: Standards Track September 2004
Message Tracking Query Protocol
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 (C) The Internet Society (2004).
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 describes
the Message Tracking Query Protocol that is used in conjunction with
extensions to the ESMTP protocol to provide a complete message
tracking solution for the Internet.
The Message Tracking Models and Requirements document
[RFC-MTRK-MODEL] discusses the models that message tracking solutions
could follow, along with requirements for a message tracking solution
that can be used with the Internet-wide message infrastructure. This
memo and its companions, [RFC-MTRK-ESMTP] and [RFC-MTRK-TSN],
describe a complete message tracking solution that satisfies those
requirements. The memo [RFC-MTRK-ESMTP] defines an extension to the
SMTP service that provides the information necessary to track
messages. This memo defines a protocol that can be used to query the
status of messages that have been transmitted on the Internet via
SMTP. The memo [RFC-MTRK-TSN] describes the message/tracking-status
[RFC-MIME] media type that is used to report tracking status
information. Using the model document's terminology, this solution
uses active enabling and active requests with both request and
Hansen Standards Track [Page 1]
RFC 3887 Message Tracking Query Protocol 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
All syntax descriptions use the ABNF specified by [RFC-ABNF].
Terminal nodes not defined elsewhere in this document are defined in
[RFC-ABNF], [RFC-URI], [RFC-MTRK-ESMTP], [RFC-SMTP], or
2. Basic Operation
The Message Tracking Query Protocol (MTQP) is similar to many other
line-oriented Internet protocols, such as [POP3] and [NNTP].
Initially, the server host starts the MTQP service by listening on
TCP port 1038.
When an MTQP client wishes to make use of the message tracking
service, it establishes a TCP connection with the server host, as
recorded from the initial message submission or as returned by a
previous tracking request. To find the server host, the MTQP client
first does an SRV lookup for the server host using DNS SRV records,
with a service name of "mtqp" and a protocol name of "tcp", as in
_mtqp._tcp.smtp3.example.com. (See the "Usage rules" section in
[RFC-SRV] for details.) If the SRV records do not exist, the MTQP
client then does an address record lookup for the server host. When
the connection is established, the MTQP server sends a greeting. The
MTQP client and MTQP server then exchange commands and responses
(respectively) until the connection is closed or aborted.
2.1. Tracking Service DNS Considerations
Because of the ways server host lookups are performed, many different
tracking server host configurations are supported.
A mail system that uses a single mail server host and has the MTQP
server host on the same server host will most likely have a single MX
record pointing at the server host, and if not, will have an address
record. Both mail and MTQP clients will access that host directly.
A mail system that uses a single mail server host, but wants tracking
queries to be performed on a different machine, MUST have an SRV MTQP
record pointing at that different machine.
Hansen Standards Track [Page 2]