idnits 2.17.1 draft-ietf-msgtrk-mtqp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 2001) is 8333 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'POP3' is mentioned on line 101, but not defined == Missing Reference: 'NNTP' is mentioned on line 101, but not defined == Missing Reference: 'TLS' is mentioned on line 445, but not defined == Unused Reference: 'RFC-821' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'RFC-822' is defined on line 728, but no explicit reference was found in the text == Unused Reference: 'RFC-ESMTP' is defined on line 738, but no explicit reference was found in the text == Unused Reference: 'RFC-MD5' is defined on line 749, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-SHA1' ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2234 (ref. 'RFC-ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 974 (ref. 'RFC-DNS') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1651 (ref. 'RFC-ESMTP') (Obsoleted by RFC 1869) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-HOSTS' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'RFC-MD5') ** Obsolete normative reference: RFC 2554 (ref. 'RFC-SMTPEXT') (Obsoleted by RFC 4954) ** Obsolete normative reference: RFC 2487 (ref. 'RFC-SMTP-TLS') (Obsoleted by RFC 3207) -- No information found for draft-ietf-msgtrk-smtpext- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DRAFT-TRACK-ESMTP' == Outdated reference: A later version (-07) exists of draft-ietf-msgtrk-model-03 ** Downref: Normative reference to an Informational draft: draft-ietf-msgtrk-model (ref. 'DRAFT-TRACK-MODEL') -- No information found for draft-ietf-msgtrk-trkstat- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DRAFT-TRACK-TSN' ** Obsolete normative reference: RFC 2396 (ref. 'RFC-URI') (Obsoleted by RFC 3986) Summary: 15 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft T. Hansen 3 draft-ietf-msgtrk-mtqp-03.txt AT&T Laboratories 4 Valid for six months July 1, 2001 6 Message Tracking Query Protocol 8 10 Authors' version: 1.7 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This memo and its companions are discussed on the MSGTRK working 33 group mailing list, ietf-msgtrk@imc.org. To subscribe, send a message 34 with the word "subscribe" in the body (on a line by itself) to the 35 address ietf-msgtrk-request@imc.org. An archive of the mailing list may 36 be found at http://www.ietf.org/archive/msgtrk. 38 Copyright Notice 40 Copyright (C) The Internet Society (1999). All Rights Reserved. 42 Abstract 44 Customers buying enterprise message systems often ask: Can I track 45 the messages? Message tracking is the ability to find out the path that 46 a particular message has taken through a messaging system and the 47 current routing status of that message. This document describes the 48 Message Tracking Query Protocol that is used in conjunction with exten- 49 sions to the ESMTP protocol to provide a complete message tracking solu- 50 tion for the Internet. 52 1. Introduction 54 The Message Tracking Models and Requirements document [DRAFT- 55 TRACK-MODEL] discusses the models that message tracking solutions could 56 follow, along with requirements for a message tracking solution that can 57 be used with the Internet-wide message infrastructure. This memo and 58 its companions, [DRAFT-TRACK-ESMTP] and [DRAFT-TRACK-TSN], describe a 59 complete message tracking solution that satisfies those requirements. 60 The memo [DRAFT-TRACK-ESMTP] defines an extension to the SMTP service 61 that provides the information necessary to track messages. This memo 62 defines a protocol that can be used to query the status of messages that 63 have been transmitted on the Internet via SMTP. The memo [DRAFT-TRACK- 64 TSN] describes the message/tracking-status MIME media type that is used 65 to report tracking status information. Using the model document's ter- 66 minology, this solution uses active enabling and active requests with 67 both request and chaining referrals. 69 1.1. Terminology 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC-KEYWORDS]. 75 All syntax descriptions use the ABNF specified by [RFC-ABNF]. Ter- 76 minal nodes not defined elsewhere in this document are defined in [RFC- 77 ABNF], [RFC-URI], [DRAFT-TRACK-ESMTP] or [RFC-SMTPEXT]. 79 1.2. Changes Made for -02 81 This section will be removed before publication. 83 Provided information on lookup for an MTQP server: SRV MTQP, then 84 MX, then A. 86 Provided a section on firewall considerations 88 Provided a section on service DNS considerations 90 At IANA's request, left the port number as XXXX and added more 91 information on the option registry. 93 Added text on various error conditions and fixed ABNF for error 94 response codes. 96 Fleshed out the tracking examples. 98 2. Basic Operation 100 The Message Tracking Query Protocol (MTQP) is similar to many other 101 line-oriented Internet protocols, such as [POP3] and [NNTP]. Initially, 102 the server host starts the MTQP service by listening on TCP port XXXX 103 (TBD by IANA). 105 When an MTQP client wishes to make use of the message tracking ser- 106 vice, it establishes a TCP connection with the server host. To find the 107 server host, the MTQP client first does an SRV lookup for the server 108 host using DNS SRV records, with a service name of "mtqp". (See the 109 "Usage rules" section in [RFC-SRV] for details.) If the host is not 110 found, the MTQP client then does an MX lookup for the server host using 111 DNS MX records, as specified in [RFC-DNS] and revised by [RFC-HOSTS]. 112 If the host is still not found, the MTQP client then does an A record 113 lookup for the server host. 115 When the connection is established, the MTQP server sends a greet- 116 ing. The MTQP client and MTQP server then exchange commands and 117 responses (respectively) until the connection is closed or aborted. 119 2.1. Tracking Service DNS Considerations 121 Because of the ways server host lookups are performed, many dif- 122 ferent tracking server host configurations are supported. 124 A mail system that uses a single mail server host and has the MTQP 125 server host on the same server host will most likely have a single MX 126 record pointing at the server host, and if not, will have an A record. 127 Both mail and MTQP clients will access that host directly. 129 A mail system that uses a single mail server host, but wants track- 130 ing queries to be performed on a different machine, MUST have an SRV 131 MTQP record pointing at that different machine. 133 A mail system that uses multiple mail servers has two choices for 134 providing tracking services: either all mail servers must be running 135 tracking servers that are able to retrieve information on all messages, 136 or the tracking service must be performed on one (or more) machine(s) 137 that are able to retrieve information on all messages. In the former 138 case, no additional DNS records are needed beyond the MX records already 139 in place for the mail system. In the latter case, SRV MTQP records are 140 needed that point at the machine(s) that are running the tracking ser- 141 vice. In both cases, note that the tracking service for a given mail 142 domain MUST be able to handle the queries for all messages destined for 143 that mail domain. 145 2.2. Commands 147 Commands in MTQP consist of a case-insensitive keyword, possibly 148 followed by one or more parameters. All commands are terminated by a 149 CRLF pair. Keywords and parameters consist of printable ASCII charac- 150 ters. Keywords and parameters are separated by whitespace (one or more 151 space or tab characters). A command line is limited to 998 characters 152 before the CRLF. 154 2.3. Responses 156 Responses in MTQP consist of a status indicator that indicates suc- 157 cess or failure. Successful commands may also be followed by additional 158 lines of data. All response lines are terminated by a CRLF pair and are 159 limited to 998 characters before the CRLF. There are several status 160 indicators: "+OK" indicates success; "+OK+" indicates a success fol- 161 lowed by additional lines of data, a multi-line success response; "- 162 TEMP" indicates a temporary failure; "-ERR" indicates a permanent 163 failure; and "-BAD" indicates a protocol error (such as for unrecognized 164 commands). 166 A status indicator MAY be followed by a series of machine- 167 parseable, case-insensitive response information giving more data about 168 the errors. These are separated from the status indicator and each 169 other by a single slash character ("/", decimal code 47). Following 170 that, there MAY be white space and a human-readable text message. The 171 human-readable text message is not intended to be presented to the end 172 user, but should be appropriate for putting in a log for use in debug- 173 ging problems. 175 In a multi-line success response, each subsequent line is ter- 176 minated by a CRLF pair and limited to 998 characters before the CRLF. 177 When all lines of the response have been sent, a final line is sent con- 178 sisting of a single period (".", decimal code 046) and a CRLF pair. If 179 any line of the multi-line response begins with a period, the line is 180 "dot-stuffed" by prepending the period with a second period. When exa- 181 mining a multi-line response, the client checks to see if the line 182 begins with a period. If so, and octets other than CRLF follow, the 183 first octet of the line (the period) is stripped away. If so, and if 184 CRLF immediately follows the period, then the response from the MTQP 185 server is ended and the line containing the ".CRLF" is not considered 186 part of the multi-line response. 188 An MTQP server MUST respond to an unrecognized, unimplemented, or 189 syntactically invalid command by responding with a negative -BAD status 190 indicator. A server MUST respond to a command issued when the session 191 is in an incorrect state by responding with a negative -ERR status indi- 192 cator. 194 2.4. Optional Timers 196 An MTQP server MAY have an inactivity autologout timer. Such a 197 timer MUST be of at least 10 minutes in duration. The receipt of any 198 command from the client during that interval should suffice to reset the 199 autologout timer. An MTQP server MAY limit the number of commands or 200 total connection time to prevent denial of service attacks. 202 2.5. Firewall Considerations 204 A firewall mail gateway has two choices when receiving a tracking 205 query for a host within its domain: it may return a response to the 206 query that says the message has been passed on, but no further informa- 207 tion is available; or it may perform a chaining operation itself, gath- 208 ering information on the message from the mail hosts behind the 209 firewall, and returning to the MTQP client the information for each 210 behind-the-firewall hop, or possibly just the final hop information, 211 possibly also disguising the names of any hosts behind the firewall. 212 Which option is picked is an adminstrative decision and is not further 213 mandated by this document. 215 3. Initialization and Option Response 217 Once the TCP connection has been opened by an MTQP client, the MTQP 218 server issues an initial status response that indicates its readiness. 219 If the status response is positive (+OK or +OK+), the client may proceed 220 with other commands. 222 The initial status response MUST include the response information 223 "/MTQP". Negative responses MUST include a reason code as response 224 information. The following reason codes are defined here; unrecognized 225 reason codes added in the future may be treated as equivalent to "una- 226 vailable". 227 "/" "unavailable" 228 "/" "admin" 230 The reason code "/admin" may be used when the service is unavail- 231 able for administrative reasons. The reason code "/unavailable" may be 232 used when the service is unavailable for other reasons. 234 If the server has any options enabled, they are listed as the 235 multi-line response of the initial status response, one per line. An 236 option specification consists of an identifier, optionally followed by 237 option-specific parameters. An option specification may be continued 238 onto additional lines by starting the continuation lines with white 239 space. The option identifier is case insensitive. Option identifiers 240 beginning with the characters "vnd." are reserved for vendor use. 242 One option specification is defined here: 244 STARTTLS 246 This capability MUST be listed if the optional STARTTLS command is sup- 247 ported by the MTQP server. It has no parameters. 249 Example #1 (no options): 250 S: +OK/MTQP MTQP server ready 252 Example #2 (service temporarily unavailable): 253 S: -TEMP/MTQP/admin Service down for admin, call back later 255 Example #3 (service permanently unavailable): 256 S: -ERR/MTQP/unavailable Service down 258 Example #4 (alternative for no options): 259 S: +OK+/MTQP MTQP server ready 260 S: . 262 Example #5 (options available): 263 S: +OK+/MTQP MTQP server ready 264 S: starttls 265 S: Option2 with parameters 266 S: Option3 with a very long 267 S: list of parameters 268 S: . 270 4. TRACK Command 272 Syntax: 273 "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF 275 mtrk-secret = base64 277 Envid is defined in [DRAFT-TRACK-ESMTP]. Mtrk-secret is the secret 278 A described in [DRAFT-TRACK-ESMTP], encoded using base64. 280 When the client issues the TRACK command, and the user is vali- 281 dated, the MTQP server retrieves tracking information about an email 282 message. To validate the user, the value of mtrk-secret is hashed using 283 SHA1, as described in [NIST-SHA1]. The hash value is then compared with 284 the value passed with the message when it was originally sent. If the 285 hash values match, the user is validated. 287 A successful response MUST be multi-line, consisting of a [MIME] 288 body part. The MIME body part must be of type multipart/related, with 289 subparts of message/tracking-status, as defined in [DRAFT-TRACK-TSN]. 291 The response contains the tracking information about the email message 292 that used the given tracking-id. 294 In each of the examples below, the envid is "<12345- 295 20010101@example.com>", the secret A is "abcdefgh", and the SHA1 hash B 296 is (in hex) "734ba8b31975d0dbae4d6e249f4e8da270796c94". The message 297 came from example.com and the MTQP server is example2.com. 299 Example #6 Message Delivered: 300 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 301 S: +OK+ Tracking information follows 302 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 303 S: 304 S: --%%%% 305 S: Content-Type: message/tracking-status 306 S: 307 S: Original-Envelope-Id: 12345-20010101@example.com 308 S: Reporting-MTA: dns; example2.com 309 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 310 S: 311 S: Original-Recipient: rfc822; user1@example1.com 312 S: Final-Recipient: rfc822; user1@example1.com 313 S: Action: delivered 314 S: Status: 2.5.0 315 S: 316 S: --%%%%-- 317 S: . 319 Example #7 Message Transferred: 320 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 321 S: +OK+ Tracking information follows 322 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 323 S: 324 S: --%%%% 325 S: Content-Type: message/tracking-status 326 S: 327 S: Original-Envelope-Id: 12345-20010101@example.com 328 S: Reporting-MTA: dns; example2.com 329 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 330 S: 331 S: Original-Recipient: rfc822; user1@example1.com 332 S: Final-Recipient: rfc822; user1@example1.com 333 S: Action: transferred 334 S: Remote-MTA: dns; example3.com 335 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 336 S: Status: 2.4.0 337 S: 339 S: --%%%%-- 340 S: . 342 Example #8 Message Delayed and a DotStuffed Header: 343 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 344 S: +OK+ Tracking information follows 345 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 346 S: ..Dot-Stuffed-Header: as an example 347 S: 348 S: --%%%% 349 S: Content-Type: message/tracking-status 350 S: 351 S: Original-Envelope-Id: 12345-20010101@example.com 352 S: Reporting-MTA: dns; example2.com 353 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 354 S: 355 S: Original-Recipient: rfc822; user1@example1.com 356 S: Final-Recipient: rfc822; user1@example1.com 357 S: Action: delayed 358 S: Status: 4.4.1 (No answer from host) 359 S: Remote-MTA: dns; example3.com 360 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 361 S: Will-Retry-Until: Thu, 4 Jan 2001 15:15:15 -0500 362 S: 363 S: --%%%%-- 364 S: . 366 Example #9 Two Users, One Relayed, One Failed: 367 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 368 S: +OK+ Tracking information follows 369 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 370 S: 371 S: --%%%% 372 S: Content-Type: message/tracking-status 373 S: 374 S: Original-Envelope-Id: 12345-20010101@example.com 375 S: Reporting-MTA: dns; example2.com 376 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 377 S: 378 S: Original-Recipient: rfc822; user1@example1.com 379 S: Final-Recipient: rfc822; user1@example1.com 380 S: Action: relayed 381 S: Status: 2.1.9 382 S: Remote-MTA: dns; example3.com 383 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 384 S: 385 S: Original-Recipient: rfc822; user2@example1.com 386 S: Final-Recipient: rfc822; user2@example1.com 387 S: Action: failed 388 S: Status 5.2.2 (Mailbox full) 389 S: Remote-MTA: dns; example3.com 390 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 391 S: 392 S: --%%%%-- 393 S: . 395 Example #10 Firewall, Hiding System Names Behind the Firewall: 396 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 397 S: +OK+ Tracking information follows 398 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 399 S: 400 S: --%%%% 401 S: Content-Type: message/tracking-status 402 S: 403 S: Original-Envelope-Id: 12345-20010101@example.com 404 S: Reporting-MTA: dns; example2.com 405 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 406 S: 407 S: Original-Recipient: rfc822; user1@example1.com 408 S: Final-Recipient: rfc822; user1@example1.com 409 S: Action: relayed 410 S: Status: 2.1.9 411 S: Remote-MTA: dns; example2.com 412 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 413 S: 414 S: --%%%% 415 S: Content-Type: message/tracking-status 416 S: 417 S: Original-Envelope-Id: 12345-20010101@example.com 418 S: Reporting-MTA: dns; example2.com 419 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 420 S: 421 S: Original-Recipient: rfc822; user1@example1.com 422 S: Final-Recipient: rfc822; user1@example1.com 423 S: Action: delivered 424 S: Status: 2.5.0 425 S: 426 S: --%%%%-- 427 S: . 429 5. COMMENT Command 431 Syntax: 432 "COMMENT" opt-text CRLF 434 opt-text = [WSP *(VCHAR / WSP)] 436 When the client issues the COMMENT command, the MTQP server MUST 437 respond with a successful response (+OK or +OK+). All optional text 438 provided with the COMMENT command are ignored. 440 6. STARTTLS Command 442 Syntax: 443 "STARTTLS" CRLF 445 TLS [TLS], more commonly known as SSL, is a popular mechanism for 446 enhancing TCP communications with privacy and authentication. An MTQP 447 server MAY support TLS. If an MTQP server supports TLS, it MUST include 448 "STARTTLS" in the option specifications list on protocol startup. 450 If the server returns a negative response, it MAY use one of the 451 following response codes: 452 "/" "unsupported" 453 "/" "unavailable" 455 If a TLS session is already in progress, then it is a protocol 456 error and "-BAD" MUST be returned with a response code of "/tlsinpro- 457 gress". 459 After receiving a positive response to a STARTTLS command, the 460 client MUST start the TLS negotiation before giving any other MTQP com- 461 mands. 463 If the MTQP client is using pipelining, the STARTTLS command must 464 be the last command in a group. 466 6.1. Processing After the STARTTLS Command 468 If the TLS handshake fails, the server SHOULD abort the connection. 470 After the TLS handshake has been completed, both parties MUST 471 immediately decide whether or not to continue based on the authentica- 472 tion and privacy achieved. The MTQP client and server may decide to move 473 ahead even if the TLS negotiation ended with no authentication and/or no 474 privacy because most MTQP services are performed with no authentication 475 and no privacy, but some MTQP clients or servers may want to continue 476 only if a particular level of authentication and/or privacy was 477 achieved. 479 If the MTQP client decides that the level of authentication or 480 privacy is not high enough for it to continue, it SHOULD issue an MTQP 481 QUIT command immediately after the TLS negotiation is complete. If the 482 MTQP server decides that the level of authentication or privacy is not 483 high enough for it to continue, it SHOULD reply to every MTQP command 484 from the client (other than a QUIT command) with a negative "-ERR" 485 response and a response code of "/insecure". 487 6.2. Result of the STARTTLS Command 489 Upon completion of the TLS handshake, the MTQP protocol is reset to 490 the initial state (the state in MTQP after a server starts up). The 491 server MUST discard any knowledge obtained from the client prior to the 492 TLS negotiation itself. The client MUST discard any knowledge obtained 493 from the server, such as the list of MTQP options, which was not 494 obtained from the TLS negotiation itself. 496 At the end of the TLS handshake, the server acts as if the connec- 497 tion had been initiated and responds with an initial status response 498 and, optionally, a list of server options. The list of MTQP server 499 options received after the TLS handshake MUST be different than the list 500 returned before the TLS handshake. In particular, a server MUST NOT 501 return the STARTTLS option in the list of server options after a TLS 502 handshake has completed. 504 Both the client and the server MUST know if there is a TLS session 505 active. A client MUST NOT attempt to start a TLS session if a TLS ses- 506 sion is already active. 508 7. QUIT Command 510 Syntax: 511 "QUIT" CRLF 513 When the client issues the QUIT command, the MTQP session ter- 514 minates. The QUIT command has no parameters. The server MUST respond 515 with a successful response. The client may close the session from its 516 end immediately after issuing this command. 518 8. Pipelining 520 The MTQP client may elect to transmit groups of MTQP commands in 521 batches without waiting for a response to each individual command. The 522 MTQP server MUST process the commands in the order received. 524 Specific commands may place further constraints on pipelining. For 525 example, STARTTLS must be the last command in a batch of MTQP commands. 527 The following two examples are identical: 529 Example #11 : 530 C: TRACK YWJjZGVmZ2gK 531 S: +OK+ Tracking information follows 532 S: 533 S: ... tracking details #1 go here ... 534 S: . 535 C: TRACK QUJDREVGR0gK 536 S: +OK+ Tracking information follows 537 S: 538 S: ... tracking details #2 go here ... 539 S: . 541 Example #12 : 542 C: TRACK YWJjZGVmZ2gK 543 C: TRACK QUJDREVGR0gK 544 S: +OK+ Tracking information follows 545 S: 546 S: ... tracking details #1 go here ... 547 S: . 548 S: +OK+ Tracking information follows 549 S: 550 S: ... tracking details #2 go here ... 551 S: . 553 9. URL Format 555 The MTQP URL scheme is used to designate MTQP servers on Internet 556 hosts accessible using the MTQP protocol. An MTQP URL takes one of the 557 following forms: 559 mtqp:///track// 560 mtqp://:/track// 562 The first form is used to refer to an MTQP server on the standard 563 port, while the second form specifies a non-standard port. Both of 564 these forms specify that the TRACK command is to be issued using the 565 given tracking id and authorization cookie. The path element "/track/" 566 is case insensitive, but the envid and mtrk-secret may not be. 568 9.1. MTQP URL Syntax 570 This is an ABNF description of the MTQP URL. 572 mtqp-url = "mtqp://" net_loc "/track/" envid ":" mtrk-secret 574 10. IANA Considerations 576 System port number XXXX - TBA by IANA 578 The service name to be registered with the Internet Assigned Number 579 Authority (IANA) is "MTQP". 581 This document requests that IANA maintain one new registry: MTQP 582 options. The registry's purpose is to register options to this proto- 583 col. Options whose names do not begin with "vnd." MUST be defined in a 584 standards track or IESG approved experimental RFC. New MTQP options 585 MUST include the following information as part of their definition: 587 option identifier 588 option parameters 589 added commands 590 standard commands affected 591 specification reference 592 discussion 594 Additional vendor-specific options for this protocol whose names 595 begin with "vnd." MUST be registered with IANA on a Firt Come First 596 Served basis. It is expected that after the "vnd." would appear an 597 abbreviated form of the vendor's name that is registering the option, 598 followed by a second dot "." and a name for the option itself. For 599 example, "vnd.example.extinfo" might represent a vendor-specific exten- 600 sion providing extended information being registered by the "Example, 601 Inc." company. 603 11. Security Considerations 605 If the originator of a message were to delegate his or her tracking 606 request to a third party, this would be vulnerable to snooping over 607 unencrypted sessions. The user can decide on a message-by-message basis 608 if this risk is acceptable. 610 The security of tracking information is dependent on the randomness 611 of the secret chosen for each message and the level of exposure of that 612 secret. If different secrets are used for each message, then the max- 613 imum exposure from tracking any message will be that single message for 614 the time that the tracking information is kept on any MTQP server. If 615 this level of exposure is too much, TLS may be used to reduce the expo- 616 sure further. 618 It should be noted that message tracking is not an end-to-end 619 mechanism. Thus, if an MTQP client/server pair decide to use TLS 620 privacy, they are not securing tracking queries with any prior or suc- 621 cessive MTQP servers. 623 Both the STMP client and server must check the result of the TLS 624 negotiation to see whether acceptable authentication or privacy was 625 achieved. Ignoring this step completely invalidates using TLS for secu- 626 rity. The decision about whether acceptable authentication or privacy 627 was achieved is made locally, is implementation-dependant, and is beyond 628 the scope of this document. 630 The SMTP client and server should note carefully the result of the 631 TLS negotiation. If the negotiation results in no privacy, or if it 632 results in privacy using algorithms or key lengths that are deemed not 633 strong enough, or if the authentication is not good enough for either 634 party, the client may choose to end the MTQP session with an immediate 635 QUIT command, or the server may choose to not accept any more MTQP com- 636 mands. 638 A man-in-the-middle attack can be launched by deleting the 639 "STARTTLS" option response from the server. This would cause the client 640 not to try to start a TLS session. An MTQP client can protect against 641 this attack by recording the fact that a particular MTQP server offers 642 TLS during one session and generating an alarm if it does not appear in 643 an option response for a later session. 645 If TLS is not used, a tracking request is vulnerable to replay 646 attacks, such that a snoop can later replay the same handshake again to 647 potentially gain more information about a message's status. 649 Before the TLS handshake has begun, any protocol interactions are 650 performed in the clear and may be modified by an active attacker. For 651 this reason, clients and servers MUST discard any knowledge obtained 652 prior to the start of the TLS handshake upon completion of the TLS 653 handshake. 655 If a client/server pair successfully performs a TLS handshake and 656 the server does chaining referrals, then the server SHOULD attempt to 657 negotiate TLS at the same security level at the next hop. In a hop-by- 658 hop scenario, STARTTLS is a request for "best effort" security and 659 should be treated as such. 661 SASL is not used because authentication is per message rather than 662 per user. 664 12. Protocol Syntax 666 This is a collected ABNF description of the MTQP protocol. 667 conversation = command-response *( client-command command-response ) 669 # client side 670 client-command = track-command / starttls-command / quit-command / comment-command 672 track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF 674 mtrk-secret = base64 676 starttls-command = "STARTTLS" CRLF 677 quit-command = "QUIT" CRLF 679 comment-command = "COMMENT" opt-text CRLF 681 # server side 682 command-response = success-response / temp-response / error-response / bad-response 684 temp-response = "-TEMP" response-info opt-text CRLF 686 opt-text = [WSP *(VCHAR / WSP)] 688 error-response = "-ERR" response-info opt-text CRLF 690 bad-response = "-BAD" response-info opt-text CRLF 692 success-response = single-line-success / multi-line-success 694 single-line-success = "+OK" response-info opt-text CRLF 696 multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf 698 dataline = *998OCTET CRLF 700 dotcrlf = "." CRLF 702 option-list = *option-line 704 option-line = identifier opt-text *[CRLF WSP opt-text] CRLF 706 identifier = (ALPHA / "_") *(ALPHA / DIGIT / "-" / "_") 708 response-info = *( "/" 1*(ALPHA / DIGIT / "-" / "_") 710 13. Acknowledgements 712 The description of STARTTLS is based on [RFC-SMTP-TLS]. 714 14. References 716 [NIST-SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard", 717 National Institute of Standards and Technology, U.S. Department of Com- 718 merce, May 1994. 720 [MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Internet 721 Mail Extensions (MIME) Part One: Format of Internet Message Bodies", 722 Innosoft, First Virtual, November 1996. 724 [RFC-821] STD 10, RFC 821, J. Postel, "Simple Mail Transfer Proto- 725 col", University of Southern California / Information Sciences Insti- 726 tute, August 1982. 728 [RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of 729 ARPA Internet Text Messages", University of Delaware, August 1982. 731 [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented 732 BNF for Syntax Specifications: ABNF", Internet Mail Consortium, Demon 733 Internet Ltd., November 1997. 735 [RFC-DNS] RFC 974, "Mail routing and the domain system", C. Par- 736 tridge, January 1986. 738 [RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud, 739 and D. Crocker, "SMTP Service Extensions", MCI, Innosoft, Dover Beach 740 Consulting, Inc., network Management Associates, Inc., Silicon Graphics, 741 Inc., July 1994. 743 [RFC-HOSTS] "Requirements for Internet Hosts - Application and Sup- 744 port", R. Braden, Ed., October 1989. 746 [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to 747 Indicate Requirement Levels", Harvard University, March 1997. 749 [RFC-MD5] RFC 1321, R. Rivest, "The MD5 Message-Digest Algorithm", 750 MIT Laboratory for Computer Science and RSA Data Security, Inc., April 751 1992. 753 [RFC-SMTPEXT] RFC 2554, J. Myers, "SMTP Service Extension for 754 Authentication", Netscape Communications, March 1999. 756 [RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for 757 Secure SMTP over TLS", Internet Mail Consortium, January 1999. 759 [RFC-SRV] RFC 2782, A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR 760 for specifying the location of services (DNS SRV)" Troll Technologies, 761 Internet Software Consortium, Microsoft Corp., February 2000 763 [DRAFT-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T. 764 Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc., 765 AT&T Laboratories, TBD 2000. 767 [DRAFT-TRACK-MODEL] draft-ietf-msgtrk-model-03.txt, T. Hansen, 768 "Message Tracking Models and Requirements", AT&T Laboratories, November 769 2000. 771 [DRAFT-TRACK-TSN] draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The 773 Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2000. 775 [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni- 776 form Resource Identifiers (URI): Generic Syntax", MIT/LCS, U. C. Irvine, 777 Xerox Corporation, August 1998. 779 15. Author's Address 781 Tony Hansen 782 AT&T Laboratories 783 Lincroft, NJ 07738 784 USA 786 Phone: +1.732.576.3207 787 E-Mail: tony@att.com 789 16. Full Copyright Statement 791 Copyright (C) The Internet Society (1999). All Rights Reserved. 793 This document and translations of it may be copied and furnished to 794 others, and derivative works that comment on or otherwise explain it or 795 assist in its implmentation may be prepared, copied, published and dis- 796 tributed, in whole or in part, without restriction of any kind, provided 797 that the above copyright notice and this paragraph are included on all 798 such copies and derivative works. However, this document itself may not 799 be modified in any way, such as by removing the copyright notice or 800 references to the Internet Society or other Internet organisations, 801 except as needed for the purpose of developing Internet standards in 802 which case the procedures for copyrights defined in the Internet Stan- 803 dards process must be followed, or as required to translate it into 804 languages other than English. 806 The limited permissions granted above are perpetual and will not be 807 revoked by the Internet Society or its successors or assigns. 809 This document and the information contained herein is provided on 810 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 811 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 812 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 813 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 814 FITNESS FOR A PARTICULAR PURPOSE. 816 This document expires January 1, 2002.