Message Tracking Query Protocol
RFC 3887
Document | Type |
RFC - Proposed Standard
(September 2004; Errata)
Updated by RFC 8553
|
|
---|---|---|---|
Author | Tony Hansen | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3887 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Scott Hollenbeck | ||
Send notices to | (None) |
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] RFC 3887 Message Tracking Query Protocol September 2004 A mail system that uses multihomed mail servers has two choices for providing tracking services: either all mail servers must be running tracking servers that are able to retrieve information on all messages, or the tracking service must be performed on one (or more) machine(s) that are able to retrieve information on all messages. InShow full document text