Message Tracking Query Protocol
updated by
Extracted elements (28)
SASL is not used for authentication because authentication in MTQP is per-message (via the SHA1-hashed secret) rather than per-user. This matches the model where the originator delegates tracking access via a per-message secret.
Option identifiers beginning with 'vnd.' are reserved for vendor use and follow a reversed-domain naming convention (e.g., vnd.com.example.extinfo). These vendor options MAY be registered with IANA but are not required to be.
A mail system using a single mail server host but wanting tracking queries on a different machine MUST have an SRV MTQP record pointing at that different machine. The tracking service MUST be able to handle queries for all messages accepted by the mail system.
A successful response to TRACK MUST be multi-line, consisting of a MIME body part of type multipart/related with subparts of message/tracking-status. If a message has not been seen, the server MUST either return an 'opaque' action response or a -ERR with reason code 'noinfo'.
After a positive STARTTLS response, the client MUST start TLS negotiation before issuing any other MTQP commands. Upon TLS handshake completion, the protocol resets to initial state; both parties MUST discard knowledge obtained prior to the handshake.
After TLS handshake completion, the server MUST NOT return the STARTTLS option in the server options list. The list of options after TLS handshake MUST differ from the list before.
All MTQP servers MUST implement TLS. If a server supports TLS and has certificates available, it MUST include 'STARTTLS' in the option list at startup. TLS SHOULD be enabled whenever possible.
An MTQP server MAY have an inactivity autologout timer, which MUST be at least 10 minutes in duration. An MTQP client waiting for a server response MAY have a timer that MUST be at least 2 minutes in duration.
An MTQP server MUST respond to an unrecognized, unimplemented, or syntactically invalid command with a -BAD status indicator, and MUST respond to a command issued in an incorrect session state with a -ERR status indicator.
If a server performs a chaining operation, it MUST provide a response within 2 minutes, and SHOULD return a 'no further information is available' response if it cannot answer within that time.
If a TLS session is already in progress, STARTTLS is a protocol error and -BAD MUST be returned with '/tls-in-progress'. If the supplied FQDN mismatches the server certificate's dNSName, -BAD MUST be returned with '/bad-fqdn'.
Commands consist of a case-insensitive keyword optionally followed by parameters, all terminated by CRLF. A command line is limited to 998 characters before the CRLF.
MTQP clients locate servers via DNS SRV lookup using service name 'mtqp' and protocol 'tcp' (e.g., _mtqp._tcp.example.com). If SRV records do not exist, an address record lookup is performed.
MTQP is a line-oriented TCP protocol operating on port 1038. Clients establish a TCP connection to the server, which sends a greeting; commands and responses are then exchanged until the connection is closed.
MTQP supports pipelining: a client may transmit groups of commands without waiting for individual responses. The server MUST process commands in order received. STARTTLS must be the last command in any pipelined batch.
Responses use status indicators: +OK (success), +OK+ (multi-line success), -TEMP (temporary failure), -ERR (permanent failure), -BAD (protocol error). A status indicator MAY be followed by slash-delimited machine-parsable response codes and optional human-readable text.
The COMMENT command (syntax: COMMENT [text] CRLF) requires the server to respond with a successful response; all optional text is ignored. It serves as a no-op client comment mechanism.
The MTQP URI scheme takes the form mtqp://<mserver>/track/<unique-envid>/<mtrk-secret> or with a non-standard port. The path element '/track/' is case-insensitive, but unique-envid and mtrk-secret are case-sensitive.
The QUIT command (syntax: QUIT CRLF) terminates the MTQP session. The server MUST respond with a successful response. The client MAY close the connection immediately after issuing the command.
The server's initial status response MUST include the response information '/MTQP'. If options are enabled, they are listed as a multi-line response, one per line. The STARTTLS option MUST be listed if TLS is enabled and certificates are installed.
The STARTTLS command syntax is: STARTTLS <domain> CRLF, where domain is a fully qualified domain name. The FQDN parameter allows virtual-hosting servers to respond with the appropriate TLS certificate.
The TRACK command syntax is: TRACK <unique-envid> <mtrk-secret CRLF>, where mtrk-secret is the base64-encoded secret A from RFC-MTRK-ESMTP. The server validates by SHA1-hashing mtrk-secret and comparing it to the stored hash.
IANA maintains a registry of MTQP options. Options not beginning with 'vnd.' MUST be defined in a standards-track or IESG-approved experimental RFC. The STARTTLS option is the initial registered entry. Vendor-specific options use a 'vnd.<reversed-domain>.<name>' naming convention.
A man-in-the-middle attack can suppress the STARTTLS option response, preventing TLS negotiation. Clients can protect against this by caching the fact that a server offered TLS and generating an alarm if it does not appear in a later session.
If a client/server pair successfully performs a TLS handshake and the server does chaining referrals, the server SHOULD attempt to negotiate TLS at the same or better security level at the next hop. STARTTLS in a hop-by-hop scenario is 'best effort' security.
Message tracking is not end-to-end: TLS between one client/server pair does not protect queries with prior or successive MTQP servers. Both parties must check TLS negotiation results; ignoring this step completely invalidates the security provided by TLS.
Without TLS, tracking requests are vulnerable to replay attacks where a snooper can replay the same handshake to gain information about a message's status. The security of tracking information depends on the randomness and exposure level of the per-message secret.
Multi-line responses terminate each line with CRLF (max 998 chars), end with a single '.' followed by CRLF, and dot-stuff any data line beginning with a period by prepending a second period. Clients strip the leading period from dot-stuffed lines.