idnits 2.17.1 draft-ietf-msgtrk-mtqp-02.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 14 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 (March 2, 2001) is 8448 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 430, but not defined == Unused Reference: 'RFC-821' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'RFC-822' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'RFC-ESMTP' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'RFC-MD5' is defined on line 715, 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 1651 (ref. 'RFC-ESMTP') (Obsoleted by RFC 1869) ** 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. 'RFC-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. 'RFC-TRACK-MODEL') -- No information found for draft-ietf-msgtrk-trkstat- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RFC-TRACK-TSN' ** Obsolete normative reference: RFC 2396 (ref. 'RFC-URI') (Obsoleted by RFC 3986) Summary: 14 errors (**), 0 flaws (~~), 10 warnings (==), 8 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-02.txt AT&T Laboratories 4 Valid for six months March 2, 2001 6 Message Tracking Query Protocol 8 10 Authors' version: 1.6 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 [RFC-TRACK- 55 MODEL] discusses the models that message tracking solutions could fol- 56 low, along with requirements for a message tracking solution that can be 57 used with the Internet-wide message infrastructure. This memo and its 58 companions, [RFC-TRACK-ESMTP] and [RFC-TRACK-TSN], describe a complete 59 message tracking solution that satisfies those requirements. The memo 60 [RFC-TRACK-ESMTP] defines an extension to the SMTP service that provides 61 the information necessary to track messages. This memo defines a proto- 62 col that can be used to query the status of messages that have been 63 transmitted on the Internet via SMTP. The memo [RFC-TRACK-TSN] 64 describes the message/tracking-status MIME media type that is used to 65 report tracking status information. Using the model document's termi- 66 nology, this solution uses active enabling and active requests with both 67 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], [RFC-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. If the host is still not found, the MTQP client then 112 does an A record lookup for the server host. 114 When the connection is established, the MTQP server sends a greet- 115 ing. The MTQP client and MTQP server then exchange commands and 116 responses (respectively) until the connection is closed or aborted. 118 2.1. Tracking Service DNS Considerations 120 Because of the ways server host lookups are performed, many dif- 121 ferent tracking server host configurations are supported. 123 A mail system that uses a single mail server host and has the MTQP 124 server host on the same server host will most likely have a single MX 125 record pointing at the server host, and if not, will have an A record. 126 Both mail and MTQP clients will access that host directly. 128 A mail system that uses a single mail server host, but wants track- 129 ing queries to be performed on a different machine, MUST have an SRV 130 MTQP record pointing at that different machine. 132 A mail system that uses multiple mail servers has two choices for 133 providing tracking services: either all mail servers must be running 134 tracking servers that are able to retrieve information on all messages, 135 or the tracking service must be performed on one (or more) machine(s) 136 that are able to retrieve information on all messages. In the former 137 case, no additional DNS records are needed beyond the MX records already 138 in place for the mail system. In the latter case, SRV MTQP records are 139 needed that point at the machine(s) that are running the tracking ser- 140 vice. In both cases, note that the tracking service for a given mail 141 domain MUST be able to handle the queries for all messages destined for 142 that mail domain. 144 2.2. Commands 146 Commands in MTQP consist of a case-insensitive keyword, possibly 147 followed by one or more parameters. All commands are terminated by a 148 CRLF pair. Keywords and parameters consist of printable ASCII charac- 149 ters. Keywords and parameters are separated by whitespace (one or more 150 space or tab characters). A command line is limited to 998 characters 151 before the CRLF. 153 2.3. Responses 155 Responses in MTQP consist of a status indicator that indicates suc- 156 cess or failure. Successful commands may also be followed by additional 157 lines of data. All response lines are terminated by a CRLF pair and are 158 limited to 998 characters before the CRLF. There are several status 159 indicators: "+OK" indicates success; "+OK+" indicates a success fol- 160 lowed by additional lines of data, a multi-line success response; "- 161 TEMP" indicates a temporary failure; "-ERR" indicates a permanent 162 failure; and "-BAD" indicates a protocol error (such as for unrecognized 163 commands). 165 A status indicator MAY be followed by a series of machine- 166 parseable, case-insensitive response information giving more data about 167 the errors. These are separated from the status indicator and each 168 other by a single slash character ("/", decimal code 47). Following 169 that, there MAY be white space and a human-readable text message. The 170 human-readable text message is not intended to be presented to the end 171 user, but should be appropriate for putting in a log for use in debug- 172 ging problems. 174 In a multi-line success response, each subsequent line is ter- 175 minated by a CRLF pair and limited to 998 characters before the CRLF. 176 When all lines of the response have been sent, a final line is sent con- 177 sisting of a single period (".", decimal code 046) and a CRLF pair. If 178 any line of the multi-line response begins with a period, the line is 179 "dot-stuffed" by prepending the period with a second period. When exa- 180 mining a multi-line response, the client checks to see if the line 181 begins with a period. If so, and octets other than CRLF follow, the 182 first octet of the line (the period) is stripped away. If so, and if 183 CRLF immediately follows the period, then the response from the MTQP 184 server is ended and the line containing the ".CRLF" is not considered 185 part of the multi-line response. 187 An MTQP server MUST respond to an unrecognized, unimplemented, or 188 syntactically invalid command by responding with a negative -BAD status 189 indicator. A server MUST respond to a command issued when the session 190 is in an incorrect state by responding with a negative -ERR status indi- 191 cator. 193 2.4. Optional Timers 195 An MTQP server MAY have an inactivity autologout timer. Such a 196 timer MUST be of at least 10 minutes in duration. The receipt of any 197 command from the client during that interval should suffice to reset the 198 autologout timer. An MTQP server MAY limit the number of commands or 199 total connection time to prevent denial of service attacks. 201 2.5. Firewall Considerations 203 A firewall mail gateway has two choices when receiving a tracking 204 query for a host within its domain: it may return a response to the 205 query that says the message has been passed on, but no further informa- 206 tion is available; or it may perform a chaining operation itself, gath- 207 ering information on the message from the mail hosts behind the 208 firewall, and returning to the MTQP client the information for each 209 behind-the-firewall hop, or possibly just the final hop information, 210 possibly also disguising the names of any hosts behind the firewall. 211 Which option is picked is an adminstrative decision and is not further 212 mandated by this document. 214 3. Initialization and Option Response 216 Once the TCP connection has been opened by an MTQP client, the MTQP 217 server issues an initial status response that indicates its readiness. 218 If the status response is positive (+OK or +OK+), the client may proceed 219 with other commands. 221 The initial status response MUST include the response information 222 "/MTQP". Negative responses MUST include a reason code as response 223 information. The following reason codes are defined here; unrecognized 224 reason codes added in the future may be treated as equivalent to 225 "unknown". 226 "/" "unavailable" 227 "/" "admin" 228 "/" "unknown" 229 "/" "referral" "=" net_loc 231 If the server has any options enabled, they are listed as the 232 multi-line response of the initial status response, one per line. An 233 option specification consists of an identifier, optionally followed by 234 option-specific parameters. An option specification may be continued 235 onto additional lines by starting the continuation lines with white 236 space. The option identifier is case insensitive. Option identifiers 237 beginning with the characters "vnd." are reserved for vendor use. 239 One option specification is defined here: 241 STARTTLS 243 This capability MUST be listed if the optional STARTTLS command is sup- 244 ported by the MTQP server. It has no parameters. 246 Example #1 (no options): 247 S: +OK/MTQP MTQP server ready 249 Example #2 (service temporarily unavailable): 250 S: -TEMP/MTQP/admin Service down for admin, call back later 252 Example #3 (service permanently unavailable): 253 S: -ERR/MTQP/unavailable Service down 255 Example #4 (alternative for no options): 256 S: +OK+/MTQP MTQP server ready 257 S: . 259 Example #5 (options available): 260 S: +OK+/MTQP MTQP server ready 261 S: starttls 262 S: Option2 with parameters 263 S: Option3 with a very long 264 S: list of parameters 265 S: . 267 Example #6 (Referred to another server): 268 S: -ERR/MTQP/referral=server42.example.com:37 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 [RFC-TRACK-ESMTP]. Mtrk-secret is the secret A 278 described in [RFC-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 [RFC-TRACK-TSN]. The 290 response contains the tracking information about the email message that 291 used the given tracking-id. 293 In each of the examples below, the envid is "<12345- 294 20010101@example.com>", the secret A is "abcdefghijklmnopqrstuvwxyz", 295 and the SHA1 hash B is TBD. The message came from example.com and the 296 MTQP server is example2.com. 298 Example #7 Message Delivered: 299 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo= 300 S: +OK+ Tracking information follows 301 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 302 S: 303 S: --%%%% 304 S: Content-Type: message/tracking-status 305 S: 306 S: Original-Envelope-Id: 12345-20010101@example.com 307 S: Reporting-MTA: dns; example2.com 308 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 309 S: 310 S: Original-Recipient: user1 311 S: Final-Recipient: user1 312 S: Action: delivered 313 S: --%%%%-- 314 S: . 316 Example #8 Message Transferred: 317 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo= 318 S: +OK+ Tracking information follows 319 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 320 S: 321 S: --%%%% 322 S: Content-Type: message/tracking-status 323 S: 324 S: Original-Envelope-Id: 12345-20010101@example.com 325 S: Reporting-MTA: dns; example2.com 326 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 327 S: 328 S: Original-Recipient: user1 329 S: Final-Recipient: user1 330 S: Action: transferred 331 S: Remote-MTA: example3.com 332 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 333 S: --%%%%-- 334 S: . 336 Example #9 Message Delayed: 337 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo= 338 S: +OK+ Tracking information follows 339 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 340 S: 341 S: --%%%% 342 S: Content-Type: message/tracking-status 343 S: 344 S: Original-Envelope-Id: 12345-20010101@example.com 345 S: Reporting-MTA: dns; example2.com 346 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 347 S: 348 S: Original-Recipient: user1 349 S: Final-Recipient: user1 350 S: Action: delayed 351 S: Remote-MTA: example3.com 352 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 353 S: Will-Retry-Until: Thu, 4 Jan 2001 15:15:15 -0500 354 S: --%%%%-- 355 S: . 357 Example #10 Two Users, One Relayed, One Failed: 358 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo= 359 S: +OK+ Tracking information follows 360 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 361 S: 362 S: --%%%% 363 S: Content-Type: message/tracking-status 364 S: 365 S: Original-Envelope-Id: 12345-20010101@example.com 366 S: Reporting-MTA: dns; example2.com 367 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 368 S: 369 S: Original-Recipient: user1 370 S: Final-Recipient: user1 371 S: Action: relayed 372 S: Remote-MTA: example3.com 373 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 374 S: 375 S: Original-Recipient: user2 376 S: Final-Recipient: user2 377 S: Action: failed 378 S: Remote-MTA: example3.com 379 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 380 S: --%%%%-- 381 S: . 383 Example #11 Firewall, Hiding System Names Behind the Firewall: 385 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo= 386 S: +OK+ Tracking information follows 387 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 388 S: 389 S: --%%%% 390 S: Content-Type: message/tracking-status 391 S: 392 S: Original-Envelope-Id: 12345-20010101@example.com 393 S: Reporting-MTA: dns; example2.com 394 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 395 S: 396 S: Original-Recipient: user1 397 S: Final-Recipient: user1 398 S: Action: relayed 399 S: Remote-MTA: example2.com 400 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 401 S: --%%%% 402 S: Content-Type: message/tracking-status 403 S: 404 S: Original-Envelope-Id: 12345-20010101@example.com 405 S: Reporting-MTA: dns; example2.com 406 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 407 S: 408 S: Original-Recipient: user1 409 S: Final-Recipient: user1 410 S: Action: delivered 411 S: --%%%%-- 412 S: . 414 5. COMMENT Command 416 Syntax: 417 "COMMENT" opt-text CRLF 419 opt-text = [WSP *(VCHAR / WSP)] 421 When the client issues the COMMENT command, the MTQP server MUST 422 respond with a successful response (+OK or +OK+). All optional text 423 provided with the COMMENT command are ignored. 425 6. STARTTLS Command 427 Syntax: 428 "STARTTLS" CRLF 430 TLS [TLS], more commonly known as SSL, is a popular mechanism for 431 enhancing TCP communications with privacy and authentication. An MTQP 432 server MAY support TLS. If an MTQP server supports TLS, it MUST include 433 "STARTTLS" in the option specifications list on protocol startup. 435 If the server returns a negative response, it MAY use one of the 436 following response codes: 437 "/" "unsupported" 438 "/" "unavailable" 440 If a TLS session is already in progress, then it is a protocol 441 error and "-BAD" MUST be returned with a response code of "/tlsinpro- 442 gress". 444 After receiving a positive response to a STARTTLS command, the 445 client MUST start the TLS negotiation before giving any other MTQP com- 446 mands. 448 If the MTQP client is using pipelining, the STARTTLS command must 449 be the last command in a group. 451 6.1. Processing After the STARTTLS Command 453 After the TLS handshake has been completed, both parties MUST 454 immediately decide whether or not to continue based on the authentica- 455 tion and privacy achieved. The MTQP client and server may decide to move 456 ahead even if the TLS negotiation ended with no authentication and/or no 457 privacy because most MTQP services are performed with no authentication 458 and no privacy, but some MTQP clients or servers may want to continue 459 only if a particular level of authentication and/or privacy was 460 achieved. 462 If the MTQP client decides that the level of authentication or 463 privacy is not high enough for it to continue, it SHOULD issue an MTQP 464 QUIT command immediately after the TLS negotiation is complete. If the 465 MTQP server decides that the level of authentication or privacy is not 466 high enough for it to continue, it SHOULD reply to every MTQP command 467 from the client (other than a QUIT command) with a negative "-BAD" 468 response and a response code of "/insecure". 470 6.2. Result of the STARTTLS Command 472 Upon completion of the TLS handshake, the MTQP protocol is reset to 473 the initial state (the state in MTQP after a server starts up). The 474 server MUST discard any knowledge obtained from the client prior to the 475 TLS negotiation itself. The client MUST discard any knowledge obtained 476 from the server, such as the list of MTQP options, which was not 477 obtained from the TLS negotiation itself. 479 At the end of the TLS handshake, the server acts as if the connec- 480 tion had been initiated and responds with an initial status response 481 and, optionally, a list of server options. The list of MTQP server 482 options received after the TLS handshake MUST be different than the list 483 returned before the TLS handshake. In particular, a server MUST NOT 484 return the STARTTLS option in the list of server options after a TLS 485 handshake has completed. 487 Both the client and the server MUST know if there is a TLS session 488 active. A client MUST NOT attempt to start a TLS session if a TLS ses- 489 sion is already active. 491 7. QUIT Command 493 Syntax: 494 "QUIT" CRLF 496 When the client issues the QUIT command, the MTQP session ter- 497 minates. The QUIT command has no parameters. The server MUST respond 498 with a successful response. The client may close the session from its 499 end immediately after issuing this command. 501 8. Pipelining 503 The MTQP client may elect to transmit groups of MTQP commands in 504 batches without waiting for a response to each individual command. The 505 MTQP server MUST process the commands in the order received. 507 Specific commands may place further constraints on pipelining. For 508 example, STARTTLS must be the last command in a batch of MTQP commands. 510 The following two examples are identical: 512 Example #12 : 513 C: TRACK 1234567890ABCDEF 514 S: +OK+ Tracking information follows 515 S: 516 S: ... tracking details #1 go here ... 517 S: . 518 C: TRACK ABCDEF1234567890 519 S: +OK+ Tracking information follows 520 S: 521 S: ... tracking details #2 go here ... 522 S: . 524 Example #13 : 525 C: TRACK 1234567890ABCDEF 526 C: TRACK ABCDEF1234567890 527 S: +OK+ Tracking information follows 528 S: 530 S: ... tracking details #1 go here ... 531 S: . 532 S: +OK+ Tracking information follows 533 S: 534 S: ... tracking details #2 go here ... 535 S: . 537 9. URL Format 539 The MTQP URL scheme is used to designate MTQP servers on Internet 540 hosts accessible using the MTQP protocol. An MTQP URL takes one of the 541 following forms: 543 mtqp:///track// 544 mtqp://:/track// 546 The first form is used to refer to an MTQP server on the standard 547 port, while the second form specifies a non-standard port. Both of 548 these forms specify that the TRACK command is to be issued using the 549 given tracking id and authorization cookie. The path element "/track/" 550 is case insensitive, but the envid and mtrk-secret may not be. 552 9.1. MTQP URL Syntax 554 This is an ABNF description of the MTQP URL. 556 mtqp-url = "mtqp://" net_loc "/track/" envid ":" mtrk-secret 558 10. IANA Considerations 560 System port number XXXX - TBA by IANA 562 The service name to be registered with the Internet Assigned Number 563 Authority (IANA) is "MTQP". 565 This document requests that IANA maintain one new registry: MTQP 566 options. The registry's purpose is to register options to this proto- 567 col. Options whose names do not begin with "vnd." MUST be defined in a 568 standards track or IESG approved experimental RFC. New MTQP options 569 MUST include the following information as part of their definition: 571 option identifier 572 option parameters 573 added commands 574 standard commands affected 575 specification reference 576 discussion 577 Additional vendor-specific options for this protocol whose names 578 begin with "vnd." MUST be registered with IANA on a Firt Come First 579 Served basis. It is expected that after the "vnd." would appear an 580 abbreviated form of the vendor's name that is registering the option, 581 followed by a second dot "." and a name for the option itself. For 582 example, "vnd.example.extinfo" might represent a vendor-specific exten- 583 sion providing extended information being registered by the "Example, 584 Inc." company. 586 11. Security Considerations 588 Security considerations discussed in [RFC-TRACK-MODEL] and [RFC- 589 TRACK-ESMTP] are relevant. 591 The security of tracking information is dependent on the randomness 592 of the secret chosen for each message and the level of exposure of that 593 secret. If different secrets are used for each message, then the max- 594 imum exposure from tracking any message will be that single message for 595 the time that the tracking information is kept on any MTQP server. If 596 this level of exposure is too much, TLS may be used to reduce the expo- 597 sure further. 599 It should be noted that message tracking is not an end-to-end 600 mechanism. Thus, if an MTQP client/server pair decide to use TLS 601 privacy, they are not securing tracking queries with any prior or suc- 602 cessive MTQP servers. 604 Both the STMP client and server must check the result of the TLS 605 negotiation to see whether acceptable authentication or privacy was 606 achieved. Ignoring this step completely invalidates using TLS for secu- 607 rity. The decision about whether acceptable authentication or privacy 608 was achieved is made locally, is implementation-dependant, and is beyond 609 the scope of this document. 611 The SMTP client and server should note carefully the result of the 612 TLS negotiation. If the negotiation results in no privacy, or if it 613 results in privacy using algorithms or key lengths that are deemed not 614 strong enough, or if the authentication is not good enough for either 615 party, the client may choose to end the MTQP session with an immediate 616 QUIT command, or the server may choose to not accept any more MTQP com- 617 mands. 619 A man-in-the-middle attack can be launched by deleting the 620 "STARTTLS" option response from the server. This would cause the client 621 not to try to start a TLS session. An MTQP client can protect against 622 this attack by recording the fact that a particular MTQP server offers 623 TLS during one session and generating an alarm if it does not appear in 624 an option response for a later session. 626 If TLS is not used, a tracking request is vulnerable to replay 627 attacks, such that a snoop can later replay the same handshake again to 628 potentially gain more information about a message's status. 630 Before the TLS handshake has begun, any protocol interactions are 631 performed in the clear and may be modified by an active attacker. For 632 this reason, clients and servers MUST discard any knowledge obtained 633 prior to the start of the TLS handshake upon completion of the TLS 634 handshake. 636 12. Protocol Syntax 638 This is a collected ABNF description of the MTQP protocol. 639 conversation = command-response *( client-command command-response ) 641 # client side 642 client-command = track-command / starttls-command / quit-command / comment-command 644 track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF 646 mtrk-secret = base64 648 starttls-command = "STARTTLS" CRLF 650 quit-command = "QUIT" CRLF 652 comment-command = "COMMENT" opt-text CRLF 654 # server side 655 command-response = success-response / temp-response / error-response / bad-response 657 temp-response = "-TEMP" response-info opt-text CRLF 659 opt-text = [WSP *(VCHAR / WSP)] 661 error-response = "-ERR" response-info opt-text CRLF 663 bad-response = "-BAD" response-info opt-text CRLF 665 success-response = single-line-success / multi-line-success 667 single-line-success = "+OK" response-info opt-text CRLF 669 multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf 671 dataline = *998OCTET CRLF 673 dotcrlf = "." CRLF 674 option-list = *option-line 676 option-line = identifier opt-text *[CRLF WSP opt-text] CRLF 678 identifier = (ALPHA / "_") *(ALPHA / DIGIT / "-" / "_") 680 response-info = *( "/" 1*(ALPHA / DIGIT / "-" / "_") 682 13. Acknowledgements 684 The description of STARTTLS is based on [RFC-SMTP-TLS]. 686 14. References 688 [NIST-SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard", 689 National Institute of Standards and Technology, U.S. Department of Com- 690 merce, May 1994. 692 [MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Internet 693 Mail Extensions (MIME) Part One: Format of Internet Message Bodies", 694 Innosoft, First Virtual, November 1996. 696 [RFC-821] STD 10, RFC 821, J. Postel, "Simple Mail Transfer Proto- 697 col", University of Southern California / Information Sciences Insti- 698 tute, August 1982. 700 [RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of 701 ARPA Internet Text Messages", University of Delaware, August 1982. 703 [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented 704 BNF for Syntax Specifications: ABNF", Internet Mail Consortium, Demon 705 Internet Ltd., November 1997. 707 [RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud, 708 and D. Crocker, "SMTP Service Extensions", MCI, Innosoft, Dover Beach 709 Consulting, Inc., network Management Associates, Inc., Silicon Graphics, 710 Inc., July 1994. 712 [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to 713 Indicate Requirement Levels", Harvard University, March 1997. 715 [RFC-MD5] RFC 1321, R. Rivest, "The MD5 Message-Digest Algorithm", 716 MIT Laboratory for Computer Science and RSA Data Security, Inc., April 717 1992. 719 [RFC-SMTPEXT] RFC 2554, J. Myers, "SMTP Service Extension for 720 Authentication", Netscape Communications, March 1999. 722 [RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for 723 Secure SMTP over TLS", Internet Mail Consortium, January 1999. 725 [RFC-SRV] RFC 2782, A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR 726 for specifying the location of services (DNS SRV)" Troll Technologies, 727 Internet Software Consortium, Microsoft Corp., February 2000 729 [RFC-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T. 730 Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc., 731 AT&T Laboratories, TBD 2000. 733 [RFC-TRACK-MODEL] draft-ietf-msgtrk-model-03.txt, T. Hansen, "Mes- 734 sage Tracking Models and Requirements", AT&T Laboratories, November 735 2000. 737 [RFC-TRACK-TSN] draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The 738 Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2000. 740 [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni- 741 form Resource Identifiers (URI): Generic Syntax", MIT/LCS, U. C. Irvine, 742 Xerox Corporation, August 1998. 744 15. Author's Address 746 Tony Hansen 747 AT&T Laboratories 748 Lincroft, NJ 07738 749 USA 751 Phone: +1.732.576.3207 752 E-Mail: tony@att.com 754 16. Full Copyright Statement 756 Copyright (C) The Internet Society (1999). All Rights Reserved. 758 This document and translations of it may be copied and furnished to 759 others, and derivative works that comment on or otherwise explain it or 760 assist in its implmentation may be prepared, copied, published and dis- 761 tributed, in whole or in part, without restriction of any kind, provided 762 that the above copyright notice and this paragraph are included on all 763 such copies and derivative works. However, this document itself may not 764 be modified in any way, such as by removing the copyright notice or 765 references to the Internet Society or other Internet organisations, 766 except as needed for the purpose of developing Internet standards in 767 which case the procedures for copyrights defined in the Internet Stan- 768 dards process must be followed, or as required to translate it into 769 languages other than English. 771 The limited permissions granted above are perpetual and will not be 772 revoked by the Internet Society or its successors or assigns. 774 This document and the information contained herein is provided on 775 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 776 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 777 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 778 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 779 FITNESS FOR A PARTICULAR PURPOSE. 781 This document expires August 2, 2001.