diff options
Diffstat (limited to 'doc/rfc/rfc3887.txt')
| -rw-r--r-- | doc/rfc/rfc3887.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc3887.txt b/doc/rfc/rfc3887.txt new file mode 100644 index 0000000..86ac843 --- /dev/null +++ b/doc/rfc/rfc3887.txt @@ -0,0 +1,1291 @@ + + + + + + +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. In + the former case, no additional DNS records are needed beyond the MX + records already in place for the mail system. In the latter case, + SRV MTQP records are needed that point at the machine(s) that are + running the tracking service. In both cases, note that the tracking + service MUST be able to handle the queries for all messages accepted + by that mail system. + +2.2. Commands + + Commands in MTQP consist of a case-insensitive keyword, possibly + followed by one or more parameters. All commands are terminated by a + CRLF pair. Keywords and parameters consist of printable ASCII + characters. Keywords and parameters are separated by whitespace (one + or more space or tab characters). A command line is limited to 998 + characters before the CRLF. + +2.3. Responses + + Responses in MTQP consist of a status indicator that indicates + success or failure. Successful commands may also be followed by + additional lines of data. All response lines are terminated by a + CRLF pair and are limited to 998 characters before the CRLF. There + are several status indicators: "+OK" indicates success; "+OK+" + indicates a success followed by additional lines of data, a multi- + line success response; "-TEMP" indicates a temporary failure; "-ERR" + indicates a permanent failure; and "-BAD" indicates a protocol error + (such as for unrecognized commands). + + A status indicator MAY be followed by a series of machine-parsable, + case-insensitive response information giving more data about the + errors. These are separated from the status indicator and each other + by a single slash character ("/", decimal code 47). Following that, + there MAY be white space and a human-readable text message. The + human-readable text message is not intended to be presented to the + end user, but should be appropriate for putting in a log for use in + debugging problems. + + In a multi-line success response, each subsequent line is terminated + by a CRLF pair and limited to 998 characters before the CRLF. When + all lines of the response have been sent, a final line is sent + consisting of a single period (".", decimal code 046) and a CRLF + pair. If any line of the multi-line response begins with a period, + the line is "dot-stuffed" by prepending the period with a second + + + +Hansen Standards Track [Page 3] + +RFC 3887 Message Tracking Query Protocol September 2004 + + + period. When examining a multi-line response, the client checks to + see if the line begins with a period. If so, and octets other than + CRLF follow, the first octet of the line (the period) is stripped + away. If so, and if CRLF immediately follows the period, then the + response from the MTQP server is ended and the line containing the + ".CRLF" is not considered part of the multi-line response. + + An MTQP server MUST respond to an unrecognized, unimplemented, or + syntactically invalid command by responding with a negative -BAD + status indicator. A server MUST respond to a command issued when the + session is in an incorrect state by responding with a negative -ERR + status indicator. + +2.4. Firewall Considerations + + A firewall mail gateway has two choices when receiving a tracking + query for a host within its domain: it may return a response to the + query that says the message has been passed on, but no further + information is available; or it may perform a chaining operation + itself, gathering information on the message from the mail hosts + behind the firewall, and returning to the MTQP client the information + for each behind-the-firewall hop, or possibly just the final hop + information, possibly also disguising the names of any hosts behind + the firewall. Which option is picked is an administrative decision + and is not further mandated by this document. + + If a server chooses to perform a chaining operation itself, it MUST + provide a response within 2 minutes, and SHOULD return a "no further + information is available" response if it cannot provide an answer at + the end of that time limit. + +2.5. Optional Timers + + An MTQP server MAY have an inactivity autologout timer. Such a timer + MUST be of at least 10 minutes in duration. The receipt of any + command from the client during that interval should suffice to reset + the autologout timer. An MTQP server MAY limit the number of + commands, unrecognized commands, or total connection time, or MAY use + other criteria, to prevent denial of service attacks. + + An MTQP client MAY have an inactivity autologout timer while waiting + for a response from the server. Since an MTQP server may be a + firewall, and may be chaining information from other servers, such a + timer MUST be at least 2 minutes in duration. + + + + + + + +Hansen Standards Track [Page 4] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +3. Initialization and Option Response + + Once the TCP connection has been opened by an MTQP client, the MTQP + server issues an initial status response that indicates its + readiness. If the status response is positive (+OK or +OK+), the + client may proceed with other commands. + + The initial status response MUST include the response information + "/MTQP". Negative responses MUST include a reason code as response + information. The following reason codes are defined here; + unrecognized reason codes added in the future may be treated as + equivalent to "unavailable". + + "/" "unavailable" + "/" "admin" + + The reason code "/admin" SHOULD be used when the service is + unavailable for administrative reasons. The reason code + "/unavailable" SHOULD be used when the service is unavailable for + other reasons. + + If the server has any options enabled, they are listed as the multi- + line response of the initial status response, one per line. An + option specification consists of an identifier, optionally followed + by option-specific parameters. An option specification may be + continued onto additional lines by starting the continuation lines + with white space. The option identifier is case insensitive. Option + identifiers beginning with the characters "vnd." are reserved for + vendor use. (See below.) + + One option specification is defined here: + + STARTTLS [1*WSP "required"] + + This capability MUST be listed if the optional STARTTLS command is + enabled on the MQTP server and one or more certificates have been + properly installed. + + It has one optional parameter: the word "required" (The parameters + for STARTTLS are case-insensitive). If the server requires that TLS + be used for some of the domains the server handles, the server MUST + specify the "required" parameter. + + + + + + + + + +Hansen Standards Track [Page 5] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +3.1. Examples + + Example #1 (no options): + S: +OK/MTQP MTQP server ready + + Example #2 (service temporarily unavailable): + S: -TEMP/MTQP/admin Service down for admin, call back later + + Example #3 (service permanently unavailable): + S: -ERR/MTQP/unavailable Service down + + Example #4 (alternative for no options): + S: +OK+/MTQP MTQP server ready + S: . + + Example #5 (options available): + S: +OK+/MTQP MTQP server ready + S: starttls + S: vnd.com.example.option2 with parameters private to example.com + S: vnd.com.example.option3 with a very long + S: list of parameters + S: . + +4. TRACK Command + + Syntax: + + track-command = "TRACK" 1*WSP unique-envid 1*WSP mtrk-secret CRLF + mtrk-secret = base64 + + Unique-envid is defined in [RFC-MTRK-ESMTP]. Mtrk-secret is the + secret A described in [RFC-MTRK-ESMTP], encoded using base64. + + When the client issues the TRACK command, and the user is validated, + the MTQP server retrieves tracking information about an email + message. To validate the user, the value of mtrk-secret is hashed + using SHA1, as described in [RFC-SHA1]. The hash value is then + compared with the value passed with the message when it was + originally sent. If the hash values match, the user is validated. + + A successful response MUST be multi-line, consisting of a [RFC-MIME] + body part. The MIME body part MUST be of type multipart/related, + with subparts of message/tracking-status, as defined in + [RFC-MTRK-TSN]. The response contains the tracking information about + the email message that used the given tracking-id. A negative + response to the TRACK command may include these reason codes: + + + + + +Hansen Standards Track [Page 6] + +RFC 3887 Message Tracking Query Protocol September 2004 + + + "/" "tls-required" + "/" "admin" + "/" "unavailable" + "/" "noinfo" + "/" "insecure" + + The reason code "/tls-required" SHOULD be used when the server has + decided to require TLS. The reason code "/admin" SHOULD be used when + the server has become unavailable, due to administrative reasons, + since the connection was initialized. The reason code "/unavailable" + SHOULD be used when the server has become unavailable, for other + reasons, since the connection was initialized. The reason code + "/insecure" is described later. + + If a message has not been seen by the MTQP server, the server MUST + choose between two choices: it MAY return a positive response with an + action field of "opaque" in the tracking information, or it MAY + return a negative response with a reason code of "noinfo". + +4.1. Examples + + In each of the examples below, the unique-envid is + "<12345-20010101@example.com>", the secret A is "abcdefgh", and the + SHA1 hash B is (in hex) "734ba8b31975d0dbae4d6e249f4e8da270796c94". + The message came from example.com and the MTQP server is + example2.com. + +Example #6 Message Delivered: +C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK +S: +OK+ Tracking information follows +S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status +S: +S: --%%%% +S: Content-Type: message/tracking-status +S: +S: Original-Envelope-Id: 12345-20010101@example.com +S: Reporting-MTA: dns; example2.com +S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 +S: +S: Original-Recipient: rfc822; user1@example1.com +S: Final-Recipient: rfc822; user1@example1.com +S: Action: delivered +S: Status: 2.5.0 +S: +S: --%%%%-- +S: . + + + + + +Hansen Standards Track [Page 7] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +Example #7 Message Transferred: +C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK +S: +OK+ Tracking information follows +S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status +S: +S: --%%%% +S: Content-Type: message/tracking-status +S: +S: Original-Envelope-Id: 12345-20010101@example.com +S: Reporting-MTA: dns; example2.com +S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 +S: +S: Original-Recipient: rfc822; user1@example1.com +S: Final-Recipient: rfc822; user1@example1.com +S: Action: transferred +S: Remote-MTA: dns; example3.com +S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 +S: Status:2.4.0 +S: +S: --%%%%-- +S: . + +Example #8 Message Delayed and a Dot-Stuffed Header: +C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK +S: +OK+ Tracking information follows +S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status +S: ..Dot-Stuffed-Header: as an example +S: +S: --%%%% +S: Content-Type: message/tracking-status +S: +S: Original-Envelope-Id: 12345-20010101@example.com +S: Reporting-MTA: dns; example2.com +S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 +S: +S: Original-Recipient: rfc822; user1@example1.com +S: Final-Recipient: rfc822; user1@example1.com +S: Action: delayed +S: Status: 4.4.1 (No answer from host) +S: Remote-MTA: dns; example3.com +S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 +S: Will-Retry-Until: Thu, 4 Jan 2001 15:15:15 -0500 +S: +S: --%%%%-- +S: . + + + + + + +Hansen Standards Track [Page 8] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +Example #9 Two Users, One Relayed, One Failed: +C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK +S: +OK+ Tracking information follows +S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status +S: +S: --%%%% +S: Content-Type: message/tracking-status +S: +S: Original-Envelope-Id: 12345-20010101@example.com +S: Reporting-MTA: dns; example2.com +S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 +S: +S: Original-Recipient: rfc822; user1@example1.com +S: Final-Recipient: rfc822; user1@example1.com +S: Action: relayed +S: Status: 2.1.9 +S: Remote-MTA: dns; example3.com +S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 +S: +S: Original-Recipient: rfc822; user2@example1.com +S: Final-Recipient: rfc822; user2@example1.com +S: Action: failed +S: Status 5.2.2 (Mailbox full) +S: Remote-MTA: dns; example3.com +S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 +S: +S: --%%%%-- +S: . + +Example #10 Firewall: +C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK +S: +OK+ Tracking information follows +S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status +S: +S: --%%%% +S: Content-Type: message/tracking-status +S: +S: Original-Envelope-Id: 12345-20010101@example.com +S: Reporting-MTA: dns; example2.com +S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 +S: +S: Original-Recipient: rfc822; user1@example1.com +S: Final-Recipient: rfc822; user1@example1.com +S: Action: relayed +S: Status: 2.1.9 +S: Remote-MTA: dns; smtp.example3.com +S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 +S: + + + +Hansen Standards Track [Page 9] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +S: --%%%% +S: Content-Type: message/tracking-status +S: +S: Original-Envelope-Id: 12345-20010101@example.com +S: Reporting-MTA: dns; smtp.example3.com +S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 +S: +S: Original-Recipient: rfc822; user2@example1.com +S: Final-Recipient: rfc822; user4@example3.com +S: Action: delivered +S: Status: 2.5.0 +S: +S: --%%%%-- +S: . + +Example #11 Firewall, Combining Per-Recipient Blocks: +C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK +S: +OK+ Tracking information follows +S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status +S: +S: --%%%% +S: Content-Type: message/tracking-status +S: +S: Original-Envelope-Id: 12345-20010101@example.com +S: Reporting-MTA: dns; example2.com +S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 +S: +S: Original-Recipient: rfc822; user1@example1.com +S: Final-Recipient: rfc822; user1@example1.com +S: Action: relayed +S: Status: 2.1.9 +S: Remote-MTA: dns; smtp.example3.com +S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 +S: +S: Original-Recipient: rfc822; user2@example1.com +S: Final-Recipient: rfc822; user4@example3.com +S: Action: delivered +S: Status:2.5.0 +S: +S: --%%%%-- +S: . + + + + + + + + + + +Hansen Standards Track [Page 10] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +Example #12 Firewall, Hiding System Names Behind the Firewall: +C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK +S: +OK+ Tracking information follows +S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status +S: +S: --%%%% +S: Content-Type: message/tracking-status +S: +S: Original-Envelope-Id: 12345-20010101@example.com +S: Reporting-MTA: dns; example2.com +S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 +S: +S: Original-Recipient: rfc822; user1@example1.com +S: Final-Recipient: rfc822; user1@example1.com +S: Action: relayed +S: Status: 2.1.9 +S: Remote-MTA: dns; example2.com +S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 +S: +S: --%%%% +S: Content-Type: message/tracking-status +S: +S: Original-Envelope-Id: 12345-20010101@example.com +S: Reporting-MTA: dns; example2.com +S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 +S: +S: Original-Recipient: rfc822; user2@example1.com +S: Final-Recipient: rfc822; user4@example1.com +S: Action: delivered +S: Status: 2.5.0 +S: +S: --%%%%-- +S: . + +5. COMMENT Command + + Syntax: + + comment-command = "COMMENT" opt-text CRLF + opt-text = [WSP *(VCHAR / WSP)] + + When the client issues the COMMENT command, the MTQP server MUST + respond with a successful response (+OK or +OK+). All optional text + provided with the COMMENT command are ignored. + + + + + + + +Hansen Standards Track [Page 11] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +6. STARTTLS Command + + Syntax: + + starttls-command = "STARTTLS" 1*WSP domain *WSP CRLF + domain = (sub-domain 1*("." sub-domain)) + + TLS [TLS] is a popular mechanism for enhancing TCP communications + with confidentiality and authentication. All MTQP servers MUST + implement TLS. However, TLS MAY be disabled by a server + administrator, either explicitly or by failing to install any + certificates for TLS to use. If an MTQP server supports TLS and has + one or more certificates available it MUST include "STARTTLS" in the + option specifications list on protocol startup. + + Note: TLS SHOULD be enabled on MQTP servers whenever possible. + + The parameter MUST be a fully qualified domain name (FQDN). A client + MUST specify the hostname it believes it is speaking with so that the + server may respond with the proper TLS certificate. This is useful + for virtual servers that provide message tracking for multiple + domains (i.e., virtual hosting). + + If the server returns a negative response, it MAY use one of the + following response codes: + "/" "unsupported" + "/" "unavailable" + "/" "tls-in-progress" + "/" "bad-fqdn" + + If TLS is not supported, then a response code of "/unsupported" + SHOULD be used. If TLS is not available for some other reason, then + a response code of "/unavailable" SHOULD be used. If a TLS session + is already in progress, then it is a protocol error and "-BAD" MUST + be returned with a response code of "/tls-in-progress". If there is + a mismatch between the supplied FQDN and the FQDN found in the + dNSName field of the subjectAltName extension of the server's + certificate [RFC-X509], then it is a protocol error and "-BAD" MUST + be returned with a response code of "/bad-fqdn". + + After receiving a positive response to a STARTTLS command, the client + MUST start the TLS negotiation before giving any other MTQP commands. + + If the MTQP client is using pipelining (see below), the STARTTLS + command must be the last command in a group. + + + + + + +Hansen Standards Track [Page 12] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +6.1. Processing After the STARTTLS Command + + If the TLS handshake fails, the server SHOULD abort the connection. + + After the TLS handshake has been completed, both parties MUST + immediately decide whether or not to continue based on the + authentication and confidentiality achieved. The MTQP client and + server may decide to move ahead even if the TLS negotiation ended + with no authentication and/or no confidentiality because most MTQP + services are performed with no authentication and no confidentiality, + but some MTQP clients or servers may want to continue only if a + particular level of authentication and/or confidentiality was + achieved. + + If the MTQP client decides that the level of authentication or + confidentiality is not high enough for it to continue, it SHOULD + issue an MTQP QUIT command immediately after the TLS negotiation is + complete. + + If the MTQP server decides that the level of authentication or + confidentiality is not high enough for it to continue, it MAY abort + the connection. If it decides that the level of authentication or + confidentiality is not high enough for it to continue, and it does + not abort the connection, it SHOULD reply to every MTQP command from + the client (other than a QUIT command) with a negative "-ERR" + response and a response code of "/insecure". + +6.2. Result of the STARTTLS Command + + Upon completion of the TLS handshake, the MTQP protocol is reset to + the initial state (the state in MTQP after a server starts up). The + server MUST discard any knowledge obtained from the client prior to + the TLS negotiation itself. The client MUST discard any knowledge + obtained from the server, such as the list of MTQP options, which was + not obtained from the TLS negotiation itself. + + At the end of the TLS handshake, the server acts as if the connection + had been initiated and responds with an initial status response and, + optionally, a list of server options. The list of MTQP server + options received after the TLS handshake MUST be different than the + list returned before the TLS handshake. In particular, a server MUST + NOT return the STARTTLS option in the list of server options after a + TLS handshake has been completed. + + Both the client and the server MUST know if there is a TLS session + active. A client MUST NOT attempt to start a TLS session if a TLS + session is already active. + + + + +Hansen Standards Track [Page 13] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +7. QUIT Command + + Syntax: + + quit-command = "QUIT" CRLF + + When the client issues the QUIT command, the MTQP session terminates. + The QUIT command has no parameters. The server MUST respond with a + successful response. The client MAY close the session from its end + immediately after issuing this command (if the client is on an + operating system where this does not cause problems). + +8. Pipelining + + The MTQP client may elect to transmit groups of MTQP commands in + batches without waiting for a response to each individual command. + The MTQP server MUST process the commands in the order received. + + Specific commands may place further constraints on pipelining. For + example, STARTTLS must be the last command in a batch of MTQP + commands. + +8.1. Examples + + The following two examples are identical: + + Example #13 : + C: TRACK <tracking-id> YWJjZGVmZ2gK + S: +OK+ Tracking information follows + S: + S: ... tracking details #1 go here ... + S: . + C: TRACK <tracking-id-2> QUJDREVGR0gK + S: +OK+ Tracking information follows + S: + S: ... tracking details #2 go here ... + S: . + + + + + + + + + + + + + + +Hansen Standards Track [Page 14] + +RFC 3887 Message Tracking Query Protocol September 2004 + + + Example #14 : + C: TRACK <tracking-id> YWJjZGVmZ2gK + C: TRACK <tracking-id-2> QUJDREVGR0gK + S: +OK+ Tracking information follows + S: + S: ... tracking details #1 go here ... + S: . + S: +OK+ Tracking information follows + S: + S: ... tracking details #2 go here ... + S: . + +9. The MTQP URI Scheme + +9.1. Intended usage + + The MTQP URI scheme is used to designate MTQP servers on Internet + hosts accessible using the MTQP protocol. It performs an MTQP query + and returns tracking status information. + +9.2. URI Scheme Name + + The name of the URI scheme is "mtqp". + +9.3. URI Scheme Syntax + + An MTQP URI takes one of the following forms: + + mtqp://<mserver>/track/<unique-envid>/<mtrk-secret> + mtqp://<mserver>:<port>/track/<unique-envid>/<mtrk-secret> + + The first form is used to refer to an MTQP server on the standard + port, while the second form specifies a non-standard port. Both of + these forms specify that the TRACK command is to be issued using the + given tracking id (unique-envid) and authorization secret (mtrk- + secret). The path element "/track/" MUST BE treated case + insensitively, but the unique-envid and mtrk-secret MUST NOT be. + +9.3.1. Formal Syntax + + This is an ABNF description of the MTQP URI. + + mtqp-uri = "mtqp://" authority "/track/" unique-envid "/" mtrk-secret + + + + + + + + +Hansen Standards Track [Page 15] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +9.4. Encoding Rules + + The encoding of unique-envid is discussed in [RFC-MTRK-ESMTP]. + Mtrk-secret is required to be base64 encoded. If the "/", "?" and + "%" octets appear in unique-envid or mtrk-secret, they are further + required to be represented by a "%" followed by two hexadecimal + characters. (The two characters give the hexadecimal representation + of that octet). + +10. IANA Considerations + + System port number 1038 has been assigned to the Message Tracking + Query Protocol by the Internet Assigned Numbers Authority (IANA). + + The service name "MTQP" has been registered with the IANA. + + The IANA has also registered the URI registration template found in + Appendix A in accordance with [BCP35]. + + This document requests that IANA maintain one new registry: MTQP + options. The registry's purpose is to register options to this + protocol. Options whose names do not begin with "vnd." MUST be + defined in a standards track or IESG approved experimental RFC. New + MTQP options MUST include the following information as part of their + definition: + + option identifier + option parameters + added commands + standard commands affected + specification reference + discussion + + One MTQP option is defined in this document, with the following + registration definition: + + option identifier: STARTTLS + option parameters: none + added commands: STARTTLS + standard commands affected: none + specification reference: RFC 3887 + discussion: see RFC 3887 + + Additional vendor-specific options for this protocol have names that + begin with "vnd.". After the "vnd." would appear the reversed domain + name of the vendor, another dot ".", and a name for the option + itself. For example, "vnd.com.example.extinfo" might represent a + + + + +Hansen Standards Track [Page 16] + +RFC 3887 Message Tracking Query Protocol September 2004 + + + vendor-specific extension providing extended information by the owner + of the "example.com" domain. These names MAY be registered with + IANA. + +11. Security Considerations + + If the originator of a message were to delegate his or her tracking + request to a third party, this would be vulnerable to snooping over + unencrypted sessions. The user can decide on a message-by-message + basis if this risk is acceptable. + + The security of tracking information is dependent on the randomness + of the secret chosen for each message and the level of exposure of + that secret. If different secrets are used for each message, then + the maximum exposure from tracking any message will be that single + message for the time that the tracking information is kept on any + MTQP server. If this level of exposure is too much, TLS may be used + to reduce the exposure further. + + It should be noted that message tracking is not an end-to-end + mechanism. Thus, if an MTQP client/server pair decide to use TLS + confidentiality, they are not securing tracking queries with any + prior or successive MTQP servers. + + Both the MTQP client and server must check the result of the TLS + negotiation to see whether acceptable authentication or + confidentiality was achieved. Ignoring this step completely + invalidates using TLS for security. The decision about whether + acceptable authentication or confidentiality was achieved is made + locally, is implementation-dependent, and is beyond the scope of this + document. + + The MTQP client and server should note carefully the result of the + TLS negotiation. If the negotiation results in no confidentiality, + or if it results in confidentiality using algorithms or key lengths + that are deemed not strong enough, or if the authentication is not + good enough for either party, the client may choose to end the MTQP + session with an immediate QUIT command, or the server may choose to + not accept any more MTQP commands. + + A man-in-the-middle attack can be launched by deleting the "STARTTLS" + option response from the server. This would cause the client not to + try to start a TLS session. An MTQP client can protect against this + attack by recording the fact that a particular MTQP server offers TLS + during one session and generating an alarm if it does not appear in + an option response for a later session. + + + + + +Hansen Standards Track [Page 17] + +RFC 3887 Message Tracking Query Protocol September 2004 + + + Similarly, the identity of the server as expressed in the server's + certificate should be cached, and an alarm generated if they do not + match in a later session. + + If TLS is not used, a tracking request is vulnerable to replay + attacks, such that a snoop can later replay the same handshake again + to potentially gain more information about a message's status. + + Before the TLS handshake has begun, any protocol interactions are + performed in the clear and may be modified by an active attacker. + For this reason, clients and servers MUST discard any knowledge + obtained prior to the start of the TLS handshake upon completion of + the TLS handshake. + + If a client/server pair successfully performs a TLS handshake and the + server does chaining referrals, then the server SHOULD attempt to + negotiate TLS at the same (or better) security level at the next hop. + In a hop-by-hop scenario, STARTTLS is a request for "best effort" + security and should be treated as such. + + SASL is not used because authentication is per message rather than + per user. + +12. Protocol Syntax + + This is a collected ABNF description of the MTQP protocol. + +mtqp-uri = "mtqp://" authority "/track/" unique-envid "/" mtrk-secret + +conversation = command-response *(client-command command-response) + +; client side +client-command = track-command / starttls-command / quit-command +/comment-command + +track-command = "TRACK" 1*WSP unique-envid 1*WSP mtrk-secret CRLF +mtrk-secret = base64 + +starttls-command = "STARTTLS" 1*WSP domain *WSP CRLF +domain = (sub-domain 1*("." sub-domain)) + +quit-command = "QUIT" CRLF + +comment-command = "COMMENT" opt-text CRLF + + + + + + + +Hansen Standards Track [Page 18] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +; server side +command-response = success-response / temp-response / error-response / +bad-response + +temp-response = "-TEMP" response-info opt-text CRLF + +opt-text = [WSP *(VCHAR / WSP)] + +error-response = "-ERR" response-info opt-text CRLF + +bad-response = "-BAD" response-info opt-text CRLF + +success-response = single-line-success / multi-line-success + +single-line-success = "+OK" response-info opt-text CRLF + +multi-line-success = "+OK+" response-info opt-text CRLF + *dataline dotcrlf + +dataline = *998OCTET CRLF + +dotcrlf = "." CRLF + +NAMECHAR = ALPHA / DIGIT / "-" / "_" + +response-info = *( "/" ( "admin" / "unavailable" / "unsupported" +/ "tls-in-progress" / "insecure" / "tls-required" / 1*NAMECHAR ) ) + +13. Acknowledgements + + The description of STARTTLS is based on [RFC-SMTP-TLS]. + + + + + + + + + + + + + + + + + + + + +Hansen Standards Track [Page 19] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +14. References + +14.1. Normative References + + [RFC-MIME] Freed, N. and N. Borenstein, "Multipurpose + Internet Mail Extensions (MIME) Part One: Format + of Internet Message Bodies", RFC 2045, November + 1996. + + [RFC-ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF + for Syntax Specifications: ABNF", RFC 2234, + November 1997. + + [RFC-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS + RR for specifying the location of services (DNS + SRV)", RFC 2782, February 2000. + + [RFC-SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC + 2821, April 2001. + + [RFC-SMTPEXT] Myers, J., "SMTP Service Extension for + Authentication", RFC 2554, March 1999. + + [RFC-MTRK-ESMTP] Allman, E. and T. Hansen, "SMTP Service Extension + for Message Tracking", RFC 3885, September 2004. + + [RFC-MTRK-MODEL] Hansen, T., "Message Tracking Models and + Requirements", RFC 3885, September 2004. + + [RFC-MTRK-TSN] Allman, E., "The Message/Tracking-Status MIME + Extension", RFC 3886, September 2004. + + [RFC-URI] Berners-Lee, T., Fielding, R. and L. Masinter, + "Uniform Resource Identifiers (URI): Generic + Syntax", RFC 2396, August 1998. + + [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version + 1.0", RFC 2246, January 1999. + + + + + + + + + + + + + +Hansen Standards Track [Page 20] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +14.2. Informational References + + [BCP35] Petke, R. and I. King, "Registration Procedures + for URL Scheme Names", BCP 35, RFC 2717, November + 1999. + + [RFC-SHA1] Eastlake, D. and P. Jones, "US Secure Hash + Algorithm 1 (SHA1)", RFC 3174, September 2001. + + [RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + + [RFC-SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure + SMTP over Transport Layer Security", RFC 3207, + February 2002. + + [RFC-X509] Housley, R., Polk, W., Ford, W. and D. Solo, + "Internet X.509 Public Key Infrastructure + Certificate and Certificate Revocation List (CRL) + Profile", RFC 3280, April 2002. + + [POP3] Myers, J. and M. Rose, "Post Office Protocol - + Version 3", STD 53, RFC 1939, May 1996. + + [NNTP] Kantor, B. and P. Lapsley, "Network News Transfer + Protocol", RFC 977, February 1986. + + + + + + + + + + + + + + + + + + + + + + + + +Hansen Standards Track [Page 21] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +Appendix A. MTQP URI Registration Template + + Scheme name: mtqp + + Scheme syntax: see section 9.1 + + Character encoding considerations: see section 9.4 + + Intended usage: see section 9.3 + + Applications and/or protocols which use this scheme: MTQP + + Interoperability considerations: as specified for MTQP + + Security considerations: see section 11.0 + + Relevant publications: [RFC-MTRK-ESMTP], [RFC-MTRK-MODEL], + [RFC-MTRK-TSN] + + Contact: MSGTRK Working Group + + Author/Change Controller: IESG + +Author's Address + + Tony Hansen + AT&T Laboratories + Middletown, NJ 07748 + USA + + Phone: +1.732.420.8934 + EMail: tony+msgtrk@maillennium.att.com + + + + + + + + + + + + + + + + + + + +Hansen Standards Track [Page 22] + +RFC 3887 Message Tracking Query Protocol September 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Hansen Standards Track [Page 23] + |