Message Tracking Query Protocol
RFC 3887

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 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 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.

1.  Introduction

   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
   chaining referrals.

Hansen                      Standards Track                     [Page 1]
RFC 3887            Message Tracking Query Protocol       September 2004

1.1.  Terminology

   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].

   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
   [RFC-SMTPEXT].

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]