idnits 2.17.1 draft-ietf-msgtrk-mtqp-09.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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 16 characters in excess of 72. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (October 24, 2002) is 7852 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: 'RFC-MIME' is mentioned on line 383, but not defined == Missing Reference: 'RFC-ABNF' is mentioned on line 76, but not defined == Missing Reference: 'POP3' is mentioned on line 184, but not defined == Missing Reference: 'NNTP' is mentioned on line 184, but not defined == Missing Reference: 'RFC-SHA1' is mentioned on line 379, but not defined == Missing Reference: 'TLS' is mentioned on line 622, but not defined ** Obsolete normative reference: RFC 2554 (ref. 'RFC-SMTPEXT') (Obsoleted by RFC 4954) -- No information found for draft-ietf-msgtrk-smtpext- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DRAFT-MTRK-ESMTP' -- No information found for draft-ietf-msgtrk-model- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DRAFT-MTRK-MODEL' -- No information found for draft-ietf-msgtrk-trkstat- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DRAFT-MTRK-TSN' ** Obsolete normative reference: RFC 2396 (ref. 'RFC-URI') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2717 (ref. 'BCP35') (Obsoleted by RFC 4395) -- Obsolete informational reference (is this intentional?): RFC 2487 (ref. 'RFC-SMTP-TLS') (Obsoleted by RFC 3207) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 11 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-09.txt AT&T Laboratories 4 Valid for six months October 24, 2002 6 Message Tracking Query Protocol 8 10 Authors' version: 1.20 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 (%Dy%). 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-MTRK- 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, [DRAFT-MTRK-ESMTP] and [DRAFT-MTRK-TSN], describe a complete 59 message tracking solution that satisfies those requirements. The memo 60 [DRAFT-MTRK-ESMTP] defines an extension to the SMTP service that pro- 61 vides the information necessary to track messages. This memo defines a 62 protocol that can be used to query the status of messages that have been 63 transmitted on the Internet via SMTP. The memo [DRAFT-MTRK-TSN] 64 describes the message/tracking-status [RFC-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-MTRK-ESMTP] or [RFC-SMTPEXT]. 79 1.2. Changes Made for... 81 The Changes sections will be removed before publication. 83 1.2.1. Changes Made for -09 85 Fixes for AD comments made on 8/21/2002: 87 The copyright date is 1999. This seems wrong... 89 Section 2.4. Should say something about client timeouts and how 90 long it is appropriate to wait for a server. 92 Section 4. It seems appropriate to have two qualified error 93 responses to TRACK: (1) An indication that TLS must be negotiated 94 before this message can be tracked and (2) An indication that the search 95 succeeded but found no result. 97 What happens when no informatio about the message is found? Does 98 this come back as an empty response or does it get a negative response? 100 The URL registration in section 9 doesn't seem to meet the require- 101 ments set forth in RFC 2717. In particular, the URL registration tem- 102 plate needs to be included. 104 Section 10. The IANA considerations should mention that this docu- 105 ment registers the MQTP URL scheme. 107 References need to be split into normative and informative. 109 1.2.2. Changes Made for -08 111 Change "Option Parameters" back to "none" in STARTTLS registration 112 definition. 114 1.2.3. Changes Made for -07 116 Added hostname to STARTTLS registration information. Corrected 117 ABNF for STARTTLS. 119 1.2.4. Changes Made for -06 121 Added opt-parameter to STARTTLS and description. 123 1.2.5. Changes Made for -05 125 STARTTLS error response changed from "/unsupported" to "/unavail- 126 able". 128 Fixed some minor nits in the examples and some typos. 130 1.2.6. Changes Made for -04 132 Reworked the SRV lookup description. 134 Other comments from the list. 136 Changes to the ABNF. 138 Changed "must" to "MUST" in section 4. 140 Changed "may" to "MAY" in section 4. 142 More examples. 144 Eliminated the registry of vnd. options. 146 Eliminated lots of unused references. 148 1.2.7. Changes Made for -03 150 Changed references. 152 Worked on error codes. 154 Made examples more real with secrets and hashes. 156 Fixes to examples. 158 Added dot-stuffed example. 160 Additional TLS info. 162 Better Security Considerations section. 164 1.2.8. Changes Made for -02 166 Provided information on lookup for an MTQP server: SRV MTQP, then 167 MX, then A. 169 Provided a section on firewall considerations 171 Provided a section on service DNS considerations 173 At IANA's request, left the port number as XXXX and added more 174 information on the option registry. 176 Added text on various error conditions and fixed ABNF for error 177 response codes. 179 Fleshed out the tracking examples. 181 2. Basic Operation 183 The Message Tracking Query Protocol (MTQP) is similar to many other 184 line-oriented Internet protocols, such as [POP3] and [NNTP]. Initially, 185 the server host starts the MTQP service by listening on TCP port XXXX 186 (TBD by IANA). 188 When an MTQP client wishes to make use of the message tracking ser- 189 vice, it establishes a TCP connection with the server host, as recorded 190 from the initial message submission or as returned by a previous track- 191 ing request. To find the server host, the MTQP client first does an SRV 192 lookup for the server host using DNS SRV records, with a service name of 193 "mtqp" and a protocol name of "tcp", as in _mtqp._tcp.smtp3.example.com. 195 (See the "Usage rules" section in [RFC-SRV] for details.) If the SRV 196 records do not exist, the MTQP client then does an address record lookup 197 for the server host. 199 When the connection is established, the MTQP server sends a greet- 200 ing. The MTQP client and MTQP server then exchange commands and 201 responses (respectively) until the connection is closed or aborted. 203 2.1. Tracking Service DNS Considerations 205 Because of the ways server host lookups are performed, many dif- 206 ferent tracking server host configurations are supported. 208 A mail system that uses a single mail server host and has the MTQP 209 server host on the same server host will most likely have a single MX 210 record pointing at the server host, and if not, will have an address 211 record. Both mail and MTQP clients will access that host directly. 213 A mail system that uses a single mail server host, but wants track- 214 ing queries to be performed on a different machine, MUST have an SRV 215 MTQP record pointing at that different machine. 217 A mail system that uses multihomed mail servers has two choices for 218 providing tracking services: either all mail servers must be running 219 tracking servers that are able to retrieve information on all messages, 220 or the tracking service must be performed on one (or more) machine(s) 221 that are able to retrieve information on all messages. In the former 222 case, no additional DNS records are needed beyond the MX records already 223 in place for the mail system. In the latter case, SRV MTQP records are 224 needed that point at the machine(s) that are running the tracking ser- 225 vice. In both cases, note that the tracking service MUST be able to 226 handle the queries for all messages accepted by that mail system. 228 2.2. Commands 230 Commands in MTQP consist of a case-insensitive keyword, possibly 231 followed by one or more parameters. All commands are terminated by a 232 CRLF pair. Keywords and parameters consist of printable ASCII charac- 233 ters. Keywords and parameters are separated by whitespace (one or more 234 space or tab characters). A command line is limited to 998 characters 235 before the CRLF. 237 2.3. Responses 239 Responses in MTQP consist of a status indicator that indicates suc- 240 cess or failure. Successful commands may also be followed by additional 241 lines of data. All response lines are terminated by a CRLF pair and are 242 limited to 998 characters before the CRLF. There are several status 243 indicators: "+OK" indicates success; "+OK+" indicates a success fol- 244 lowed by additional lines of data, a multi-line success response; "- 245 TEMP" indicates a temporary failure; "-ERR" indicates a permanent 246 failure; and "-BAD" indicates a protocol error (such as for unrecognized 247 commands). 249 A status indicator MAY be followed by a series of machine-parsable, 250 case-insensitive response information giving more data about the errors. 251 These are separated from the status indicator and each other by a single 252 slash character ("/", decimal code 47). Following that, there MAY be 253 white space and a human-readable text message. The human-readable text 254 message is not intended to be presented to the end user, but should be 255 appropriate for putting in a log for use in debugging problems. 257 In a multi-line success response, each subsequent line is ter- 258 minated by a CRLF pair and limited to 998 characters before the CRLF. 259 When all lines of the response have been sent, a final line is sent con- 260 sisting of a single period (".", decimal code 046) and a CRLF pair. If 261 any line of the multi-line response begins with a period, the line is 262 "dot-stuffed" by prepending the period with a second period. When exa- 263 mining a multi-line response, the client checks to see if the line 264 begins with a period. If so, and octets other than CRLF follow, the 265 first octet of the line (the period) is stripped away. If so, and if 266 CRLF immediately follows the period, then the response from the MTQP 267 server is ended and the line containing the ".CRLF" is not considered 268 part of the multi-line response. 270 An MTQP server MUST respond to an unrecognized, unimplemented, or 271 syntactically invalid command by responding with a negative -BAD status 272 indicator. A server MUST respond to a command issued when the session 273 is in an incorrect state by responding with a negative -ERR status indi- 274 cator. 276 2.4. Firewall Considerations 278 A firewall mail gateway has two choices when receiving a tracking 279 query for a host within its domain: it may return a response to the 280 query that says the message has been passed on, but no further informa- 281 tion is available; or it may perform a chaining operation itself, gath- 282 ering information on the message from the mail hosts behind the 283 firewall, and returning to the MTQP client the information for each 284 behind-the-firewall hop, or possibly just the final hop information, 285 possibly also disguising the names of any hosts behind the firewall. 286 Which option is picked is an administrative decision and is not further 287 mandated by this document. 289 If a server chooses to perform a chaining operation itself, it MUST 290 provide a response within 2 minutes, and SHOULD return a "no further 291 information is available" response if it cannot provide an answer at the 292 end of that time limit. 294 2.5. Optional Timers 296 An MTQP server MAY have an inactivity autologout timer. Such a 297 timer MUST be of at least 10 minutes in duration. The receipt of any 298 command from the client during that interval should suffice to reset the 299 autologout timer. An MTQP server MAY limit the number of commands, 300 unrecognized commands, or total connection time, or MAY use other cri- 301 teria, to prevent denial of service attacks. 303 An MTQP client MAY have an inactivity autologout timer while wait- 304 ing for a response from the server. Since an MTQP server may be a 305 firewall, and may be chaining information from other servers, such a 306 timer MUST be at least 2 minutes in duration. 308 3. Initialization and Option Response 310 Once the TCP connection has been opened by an MTQP client, the MTQP 311 server issues an initial status response that indicates its readiness. 312 If the status response is positive (+OK or +OK+), the client may proceed 313 with other commands. 315 The initial status response MUST include the response information 316 "/MTQP". Negative responses MUST include a reason code as response 317 information. The following reason codes are defined here; unrecognized 318 reason codes added in the future may be treated as equivalent to "una- 319 vailable". 320 "/" "unavailable" 321 "/" "admin" 323 The reason code "/admin" SHOULD be used when the service is una- 324 vailable for administrative reasons. The reason code "/unavailable" 325 SHOULD be used when the service is unavailable for other reasons. 327 If the server has any options enabled, they are listed as the 328 multi-line response of the initial status response, one per line. An 329 option specification consists of an identifier, optionally followed by 330 option-specific parameters. An option specification may be continued 331 onto additional lines by starting the continuation lines with white 332 space. The option identifier is case insensitive. Option identifiers 333 beginning with the characters "vnd." are reserved for vendor use. (See 334 below.) 336 One option specification is defined here: 338 STARTTLS 340 This capability MUST be listed if the optional STARTTLS command is sup- 341 ported by the MTQP server. It has no parameters. 343 3.1. Examples 345 Example #1 (no options): 346 S: +OK/MTQP MTQP server ready 348 Example #2 (service temporarily unavailable): 349 S: -TEMP/MTQP/admin Service down for admin, call back later 351 Example #3 (service permanently unavailable): 352 S: -ERR/MTQP/unavailable Service down 354 Example #4 (alternative for no options): 355 S: +OK+/MTQP MTQP server ready 356 S: . 358 Example #5 (options available): 359 S: +OK+/MTQP MTQP server ready 360 S: starttls 361 S: vnd.com.example.option2 with parameters private to example.com 362 S: vnd.com.example.option3 with a very long 363 S: list of parameters 364 S: . 366 4. TRACK Command 368 Syntax: 369 "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF 371 mtrk-secret = base64 373 Envid is defined in [DRAFT-MTRK-ESMTP]. Mtrk-secret is the secret 374 A described in [DRAFT-MTRK-ESMTP], encoded using base64. 376 When the client issues the TRACK command, and the user is vali- 377 dated, the MTQP server retrieves tracking information about an email 378 message. To validate the user, the value of mtrk-secret is hashed using 379 SHA1, as described in [RFC-SHA1]. The hash value is then compared with 380 the value passed with the message when it was originally sent. If the 381 hash values match, the user is validated. 383 A successful response MUST be multi-line, consisting of a [RFC- 384 MIME] body part. The MIME body part MUST be of type multipart/related, 385 with subparts of message/tracking-status, as defined in [DRAFT-MTRK- 386 TSN]. The response contains the tracking information about the email 387 message that used the given tracking-id. 389 A negative response to the TRACK command may include these reason 390 codes: 391 "/" "tls-required" 392 "/" "admin" 393 "/" "unavailable" 394 "/" "noinfo" 396 The reason code "/tls-required" SHOULD be used when the server has 397 decided to require TLS. The reason code "/admin" SHOULD be used when 398 the server has become unavailable, due to administrative reasons, since 399 the connection was initialized. The reason code "/unavailable" SHOULD 400 be used when the server has become unavailable, for other reasons, since 401 the connection was initialized. 403 If a message has not been seen by the MTQP server, the server MUST 404 choose between two choices: it MAY return a positive response with an 405 action field of "opaque" in the tracking information, or it MAY return a 406 negative response with a reason code of "noinfo". 408 4.1. Examples 410 In each of the examples below, the envid is "<12345- 411 20010101@example.com>", the secret A is "abcdefgh", and the SHA1 hash B 412 is (in hex) "734ba8b31975d0dbae4d6e249f4e8da270796c94". The message 413 came from example.com and the MTQP server is example2.com. 415 Example #6 Message Delivered: 416 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 417 S: +OK+ Tracking information follows 418 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 419 S: 420 S: --%%%% 421 S: Content-Type: message/tracking-status 422 S: 423 S: Original-Envelope-Id: 12345-20010101@example.com 424 S: Reporting-MTA: dns; example2.com 425 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 426 S: 427 S: Original-Recipient: rfc822; user1@example1.com 428 S: Final-Recipient: rfc822; user1@example1.com 429 S: Action: delivered 430 S: Status: 2.5.0 431 S: 432 S: --%%%%-- 433 S: . 435 Example #7 Message Transferred: 436 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 437 S: +OK+ Tracking information follows 438 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 439 S: 440 S: --%%%% 441 S: Content-Type: message/tracking-status 442 S: 443 S: Original-Envelope-Id: 12345-20010101@example.com 444 S: Reporting-MTA: dns; example2.com 445 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 446 S: 447 S: Original-Recipient: rfc822; user1@example1.com 448 S: Final-Recipient: rfc822; user1@example1.com 449 S: Action: transferred 450 S: Remote-MTA: dns; example3.com 451 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 452 S: Status: 2.4.0 453 S: 454 S: --%%%%-- 455 S: . 457 Example #8 Message Delayed and a Dot-Stuffed Header: 458 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 459 S: +OK+ Tracking information follows 460 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 461 S: ..Dot-Stuffed-Header: as an example 462 S: 463 S: --%%%% 464 S: Content-Type: message/tracking-status 465 S: 466 S: Original-Envelope-Id: 12345-20010101@example.com 467 S: Reporting-MTA: dns; example2.com 468 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 469 S: 470 S: Original-Recipient: rfc822; user1@example1.com 471 S: Final-Recipient: rfc822; user1@example1.com 472 S: Action: delayed 473 S: Status: 4.4.1 (No answer from host) 474 S: Remote-MTA: dns; example3.com 475 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 476 S: Will-Retry-Until: Thu, 4 Jan 2001 15:15:15 -0500 477 S: 478 S: --%%%%-- 479 S: . 481 Example #9 Two Users, One Relayed, One Failed: 482 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 483 S: +OK+ Tracking information follows 484 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 485 S: 486 S: --%%%% 487 S: Content-Type: message/tracking-status 488 S: 489 S: Original-Envelope-Id: 12345-20010101@example.com 490 S: Reporting-MTA: dns; example2.com 491 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 492 S: 493 S: Original-Recipient: rfc822; user1@example1.com 494 S: Final-Recipient: rfc822; user1@example1.com 495 S: Action: relayed 496 S: Status: 2.1.9 497 S: Remote-MTA: dns; example3.com 498 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 499 S: 500 S: Original-Recipient: rfc822; user2@example1.com 501 S: Final-Recipient: rfc822; user2@example1.com 502 S: Action: failed 503 S: Status 5.2.2 (Mailbox full) 504 S: Remote-MTA: dns; example3.com 505 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 506 S: 507 S: --%%%%-- 508 S: . 510 Example #10 Firewall: 511 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 512 S: +OK+ Tracking information follows 513 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 514 S: 515 S: --%%%% 516 S: Content-Type: message/tracking-status 517 S: 518 S: Original-Envelope-Id: 12345-20010101@example.com 519 S: Reporting-MTA: dns; example2.com 520 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 521 S: 522 S: Original-Recipient: rfc822; user1@example1.com 523 S: Final-Recipient: rfc822; user1@example1.com 524 S: Action: relayed 525 S: Status: 2.1.9 526 S: Remote-MTA: dns; smtp.example3.com 527 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 528 S: 529 S: --%%%% 530 S: Content-Type: message/tracking-status 531 S: 532 S: Original-Envelope-Id: 12345-20010101@example.com 533 S: Reporting-MTA: dns; smtp.example3.com 534 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 535 S: 536 S: Original-Recipient: rfc822; user2@example1.com 537 S: Final-Recipient: rfc822; user4@example3.com 538 S: Action: delivered 539 S: Status: 2.5.0 540 S: 541 S: --%%%%-- 542 S: . 544 Example #11 Firewall, Combining Per-Recipient Blocks: 545 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 546 S: +OK+ Tracking information follows 547 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 548 S: 549 S: --%%%% 550 S: Content-Type: message/tracking-status 551 S: 552 S: Original-Envelope-Id: 12345-20010101@example.com 553 S: Reporting-MTA: dns; example2.com 554 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 555 S: 556 S: Original-Recipient: rfc822; user1@example1.com 557 S: Final-Recipient: rfc822; user1@example1.com 558 S: Action: relayed 559 S: Status: 2.1.9 560 S: Remote-MTA: dns; smtp.example3.com 561 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 562 S: 563 S: Original-Recipient: rfc822; user2@example1.com 564 S: Final-Recipient: rfc822; user4@example3.com 565 S: Action: delivered 566 S: Status: 2.5.0 567 S: 568 S: --%%%%-- 569 S: . 571 Example #12 Firewall, Hiding System Names Behind the Firewall: 572 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 573 S: +OK+ Tracking information follows 574 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 575 S: 576 S: --%%%% 577 S: Content-Type: message/tracking-status 578 S: 580 S: Original-Envelope-Id: 12345-20010101@example.com 581 S: Reporting-MTA: dns; example2.com 582 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 583 S: 584 S: Original-Recipient: rfc822; user1@example1.com 585 S: Final-Recipient: rfc822; user1@example1.com 586 S: Action: relayed 587 S: Status: 2.1.9 588 S: Remote-MTA: dns; example2.com 589 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 590 S: 591 S: --%%%% 592 S: Content-Type: message/tracking-status 593 S: 594 S: Original-Envelope-Id: 12345-20010101@example.com 595 S: Reporting-MTA: dns; example2.com 596 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 597 S: 598 S: Original-Recipient: rfc822; user2@example1.com 599 S: Final-Recipient: rfc822; user4@example1.com 600 S: Action: delivered 601 S: Status: 2.5.0 602 S: 603 S: --%%%%-- 604 S: . 606 5. COMMENT Command 608 Syntax: 609 "COMMENT" opt-text CRLF 611 opt-text = [WSP *(VCHAR / WSP)] 613 When the client issues the COMMENT command, the MTQP server MUST 614 respond with a successful response (+OK or +OK+). All optional text 615 provided with the COMMENT command are ignored. 617 6. STARTTLS Command 619 Syntax: 620 "STARTTLS" [WSP hostname] CRLF 622 TLS [TLS], more commonly known as SSL, is a popular mechanism for 623 enhancing TCP communications with privacy and authentication. An MTQP 624 server MAY support TLS. If an MTQP server supports TLS, it MUST include 625 "STARTTLS" in the option specifications list on protocol startup. 627 The optional parameter, if specified, MUST be a fully qualified 629 domain name. A client MAY specify the hostname it believes it is speak- 630 ing with so that the server may respond with the proper TLS certificate. 631 This is useful for virtual servers that provide message tracking for 632 multiple domains (i.e., virtual hosting). 634 If the server returns a negative response, it MAY use one of the 635 following response codes: 636 "/" "unsupported" 637 "/" "unavailable" 638 "/" "tlsinprogress" 640 If TLS is not supported, then a response code of "/unsupported" 641 SHOULD be used. If TLS is not available for some other reason, then a 642 response code of "/unavailable" SHOULD be used. If a TLS session is 643 already in progress, then it is a protocol error and "-BAD" MUST be 644 returned with a response code of "/tlsinprogress". 646 After receiving a positive response to a STARTTLS command, the 647 client MUST start the TLS negotiation before giving any other MTQP com- 648 mands. 650 If the MTQP client is using pipelining (see below), the STARTTLS 651 command must be the last command in a group. 653 6.1. Processing After the STARTTLS Command 655 If the TLS handshake fails, the server SHOULD abort the connection. 657 After the TLS handshake has been completed, both parties MUST 658 immediately decide whether or not to continue based on the authentica- 659 tion and privacy achieved. The MTQP client and server may decide to move 660 ahead even if the TLS negotiation ended with no authentication and/or no 661 privacy because most MTQP services are performed with no authentication 662 and no privacy, but some MTQP clients or servers may want to continue 663 only if a particular level of authentication and/or privacy was 664 achieved. 666 If the MTQP client decides that the level of authentication or 667 privacy is not high enough for it to continue, it SHOULD issue an MTQP 668 QUIT command immediately after the TLS negotiation is complete. If the 669 MTQP server decides that the level of authentication or privacy is not 670 high enough for it to continue, it SHOULD reply to every MTQP command 671 from the client (other than a QUIT command) with a negative "-ERR" 672 response and a response code of "/insecure". 674 6.2. Result of the STARTTLS Command 676 Upon completion of the TLS handshake, the MTQP protocol is reset to 678 the initial state (the state in MTQP after a server starts up). The 679 server MUST discard any knowledge obtained from the client prior to the 680 TLS negotiation itself. The client MUST discard any knowledge obtained 681 from the server, such as the list of MTQP options, which was not 682 obtained from the TLS negotiation itself. 684 At the end of the TLS handshake, the server acts as if the connec- 685 tion had been initiated and responds with an initial status response 686 and, optionally, a list of server options. The list of MTQP server 687 options received after the TLS handshake MUST be different than the list 688 returned before the TLS handshake. In particular, a server MUST NOT 689 return the STARTTLS option in the list of server options after a TLS 690 handshake has completed. 692 Both the client and the server MUST know if there is a TLS session 693 active. A client MUST NOT attempt to start a TLS session if a TLS ses- 694 sion is already active. 696 7. QUIT Command 698 Syntax: 699 "QUIT" CRLF 701 When the client issues the QUIT command, the MTQP session ter- 702 minates. The QUIT command has no parameters. The server MUST respond 703 with a successful response. The client MAY close the session from its 704 end immediately after issuing this command (if the client is on an 705 operating system where this does not cause problems). 707 8. Pipelining 709 The MTQP client may elect to transmit groups of MTQP commands in 710 batches without waiting for a response to each individual command. The 711 MTQP server MUST process the commands in the order received. 713 Specific commands may place further constraints on pipelining. For 714 example, STARTTLS must be the last command in a batch of MTQP commands. 716 8.1. Examples 718 The following two examples are identical: 720 Example #13 : 721 C: TRACK YWJjZGVmZ2gK 722 S: +OK+ Tracking information follows 723 S: 724 S: ... tracking details #1 go here ... 725 S: . 727 C: TRACK QUJDREVGR0gK 728 S: +OK+ Tracking information follows 729 S: 730 S: ... tracking details #2 go here ... 731 S: . 733 Example #14 : 734 C: TRACK YWJjZGVmZ2gK 735 C: TRACK QUJDREVGR0gK 736 S: +OK+ Tracking information follows 737 S: 738 S: ... tracking details #1 go here ... 739 S: . 740 S: +OK+ Tracking information follows 741 S: 742 S: ... tracking details #2 go here ... 743 S: . 745 9. The MTQP URI Scheme 747 9.1. Intended usage 749 The MTQP URI scheme is used to designate MTQP servers on Internet 750 hosts accessible using the MTQP protocol. It performs an MTQP query and 751 returns tracking status information. 753 9.2. URI Scheme Name 755 The name of the URI scheme is "mtqp". 757 9.3. URI Scheme Syntax 759 An MTQP URI takes one of the following forms: 761 mtqp:///track// 762 mtqp://:/track// 764 The first form is used to refer to an MTQP server on the standard 765 port, while the second form specifies a non-standard port. Both of 766 these forms specify that the TRACK command is to be issued using the 767 given tracking id (envid) and authorization secret (mtrk-secret). The 768 path element "/track/" MUST BE treated case insensitively, but the envid 769 and mtrk-secret MUST NOT be. 771 9.3.1. Formal Syntax 773 This is an ABNF description of the MTQP URI. 775 mtqp-uri = "mtqp://" net_loc "/track/" envid "/" mtrk-secret 777 9.4. Encoding Rules 779 The encoding of envid is discussed in [DRAFT-MTRK-ESMTP]. Mtrk- 780 secret is required to be base64 encoded. If the "/", "?" and "%" octets 781 appear in envid or mtrk-secret, they are further required to be 782 represented by a "%" followed by two hexadecimal characters. (The two 783 characters give the hexadecimal representation of that octet.) 785 10. IANA Considerations 787 System port number XXXX - TBD by IANA 789 The service name to be registered with the Internet Assigned Number 790 Authority (IANA) is "MTQP". 792 The IANA is asked to register the URI registration template found 793 in Appendix A in accordance with [BCP35]. 795 This document requests that IANA maintain one new registry: MTQP 796 options. The registry's purpose is to register options to this proto- 797 col. Options whose names do not begin with "vnd." MUST be defined in a 798 standards track or IESG approved experimental RFC. New MTQP options 799 MUST include the following information as part of their definition: 801 option identifier 802 option parameters 803 added commands 804 standard commands affected 805 specification reference 806 discussion 808 One MTQP option is defined in this document, with the following 809 registration definition: 811 option identifier: STARTTLS 812 option parameters: none 813 added commands: STARTTLS 814 standard commands affected: none 815 specification reference: RFC TBD 816 discussion: see RFC TBD 818 Additional vendor-specific options for this protocol have names 819 that begin with "vnd.". After the "vnd." would appear the reversed 820 domain name of the vendor, another dot ".", and a name for the option 821 itself. For example, "vnd.com.example.extinfo" might represent a 822 vendor-specific extension providing extended information by the owner of 823 the "example.com" domain. These names MAY be registered with IANA. 825 11. Security Considerations 827 If the originator of a message were to delegate his or her tracking 828 request to a third party, this would be vulnerable to snooping over 829 unencrypted sessions. The user can decide on a message-by-message basis 830 if this risk is acceptable. 832 The security of tracking information is dependent on the randomness 833 of the secret chosen for each message and the level of exposure of that 834 secret. If different secrets are used for each message, then the max- 835 imum exposure from tracking any message will be that single message for 836 the time that the tracking information is kept on any MTQP server. If 837 this level of exposure is too much, TLS may be used to reduce the expo- 838 sure further. 840 It should be noted that message tracking is not an end-to-end 841 mechanism. Thus, if an MTQP client/server pair decide to use TLS 842 privacy, they are not securing tracking queries with any prior or suc- 843 cessive MTQP servers. 845 Both the MTQP client and server must check the result of the TLS 846 negotiation to see whether acceptable authentication or privacy was 847 achieved. Ignoring this step completely invalidates using TLS for secu- 848 rity. The decision about whether acceptable authentication or privacy 849 was achieved is made locally, is implementation-dependent, and is beyond 850 the scope of this document. 852 The MTQP client and server should note carefully the result of the 853 TLS negotiation. If the negotiation results in no privacy, or if it 854 results in privacy using algorithms or key lengths that are deemed not 855 strong enough, or if the authentication is not good enough for either 856 party, the client may choose to end the MTQP session with an immediate 857 QUIT command, or the server may choose to not accept any more MTQP com- 858 mands. 860 A man-in-the-middle attack can be launched by deleting the 861 "STARTTLS" option response from the server. This would cause the client 862 not to try to start a TLS session. An MTQP client can protect against 863 this attack by recording the fact that a particular MTQP server offers 864 TLS during one session and generating an alarm if it does not appear in 865 an option response for a later session. 867 If TLS is not used, a tracking request is vulnerable to replay 868 attacks, such that a snoop can later replay the same handshake again to 869 potentially gain more information about a message's status. 871 Before the TLS handshake has begun, any protocol interactions are 872 performed in the clear and may be modified by an active attacker. For 873 this reason, clients and servers MUST discard any knowledge obtained 874 prior to the start of the TLS handshake upon completion of the TLS 875 handshake. 877 If a client/server pair successfully performs a TLS handshake and 878 the server does chaining referrals, then the server SHOULD attempt to 879 negotiate TLS at the same (or better) security level at the next hop. 880 In a hop-by-hop scenario, STARTTLS is a request for "best effort" secu- 881 rity and should be treated as such. 883 SASL is not used because authentication is per message rather than 884 per user. 886 12. Protocol Syntax 888 This is a collected ABNF description of the MTQP protocol. 889 conversation = command-response *( client-command command-response ) 891 # client side 892 client-command = track-command / starttls-command / quit-command / comment-command 894 track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF 896 mtrk-secret = base64 898 starttls-command = "STARTTLS" [WSP hostname] CRLF 900 quit-command = "QUIT" CRLF 902 comment-command = "COMMENT" opt-text CRLF 904 # server side 905 command-response = success-response / temp-response / error-response / bad-response 907 temp-response = "-TEMP" response-info opt-text CRLF 909 opt-text = [WSP *(VCHAR / WSP)] 911 error-response = "-ERR" response-info opt-text CRLF 913 bad-response = "-BAD" response-info opt-text CRLF 915 success-response = single-line-success / multi-line-success 917 single-line-success = "+OK" response-info opt-text CRLF 918 multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf 920 dataline = *998OCTET CRLF 922 dotcrlf = "." CRLF 924 option-list = *option-line 926 option-line = identifier opt-text *(CRLF WSP opt-text) CRLF 928 NAMECHAR = ALPHA / DIGIT / "-" / "_" 930 identifier = (ALPHA / "_") *NAMECHAR) 932 response-info = *( "/" ( "admin" / "unavailable" / "unsupported" / 933 "tlsinprogress" / "insecure" / 1*NAMECHAR ) ) 935 13. Acknowledgements 937 The description of STARTTLS is based on [RFC-SMTP-TLS]. 939 14. Normative References 941 [RFC-MIME]RFC 2045, N. Freed & N. Borenstein, "Multipurpose Inter- 942 net Mail Extensions (MIME) Part One: Format of Internet 943 Message Bodies", Innosoft, First Virtual, November 1996. 945 [RFC-ABNF]RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented 946 BNF for Syntax Specifications: ABNF", Internet Mail Con- 947 sortium, Demon Internet Ltd., November 1997. 949 [RFC-SRV] RFC 2782, A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR 950 for specifying the location of services (DNS SRV)" Troll 951 Technologies, Internet Software Consortium, Microsoft 952 Corp., February 2000 954 [RFC-SMTPEXT] 955 RFC 2554, J. Myers, "SMTP Service Extension for Authenti- 956 cation", Netscape Communications, March 1999. 958 [DRAFT-MTRK-ESMTP] 959 draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T. Hansen, 960 "SMTP Service Extension for Message Tracking", Sendmail, 961 Inc., AT&T Laboratories, TBD 2002. 963 [DRAFT-MTRK-MODEL] 964 draft-ietf-msgtrk-model-*.txt, T. Hansen, "Message 965 Tracking Models and Requirements", AT&T Laboratories, TBD 966 2002. 968 [DRAFT-MTRK-TSN] 969 draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The 970 Message/Tracking-Status MIME Extension", Sendmail, Inc., 971 TBD 2002. 973 [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni- 974 form Resource Identifiers (URI): Generic Syntax", 975 MIT/LCS, U. C. Irvine, Xerox Corporation, August 1998. 977 15. Informational References 979 [BCP35] BCP 35, RFC 2717, R. Petke, I. King, "Registration Pro- 980 cedures for URL Scheme Names", November 1999. 982 [RFC-SHA1]RFC 3184, D. Eastlake & P. Jones, "US Secure Hash Stan- 983 dard 1 (SHA1)", September 2001. 985 [RFC-KEYWORDS] 986 RFC 2119, S. Bradner, "Key words for use in RFCs to Indi- 987 cate Requirement Levels", Harvard University, March 1997. 989 [RFC-SMTP-TLS] 990 RFC2487, P. Hoffman, "SMTP Service Extension for Secure 991 SMTP over TLS", Internet Mail Consortium, January 1999. 993 Appendix A. MTQP URI Registration Template 995 Scheme name: mtqp 997 Scheme syntax: see section 9.1 999 Character encoding considerations: see section 9.4 1001 Intended usage: see section 9.3 1003 Applications and/or protocols which use this scheme: MTQP 1005 Interoperability considerations: as specified for MTQP 1007 Security considerations: see section 11.0 1009 Relevant publications: [DRAFT-MTRK-ESMTP], [DRAFT-MTRK-MODEL], 1010 [DRAFT-MTRK-TSN] 1011 Contact: MSGTRK Working Group 1013 Author/Change Controller: IESG 1015 16. Author's Address 1017 Tony Hansen 1018 AT&T Laboratories 1019 Middletown, NJ 07748 1020 USA 1022 Phone: +1.732.420.8934 1023 E-Mail: tony@att.com 1025 17. Full Copyright Statement 1027 Copyright (C) The Internet Society (%Dy%). All Rights Reserved. 1029 This document and translations of it may be copied and furnished to 1030 others, and derivative works that comment on or otherwise explain it or 1031 assist in its implementation may be prepared, copied, published and dis- 1032 tributed, in whole or in part, without restriction of any kind, provided 1033 that the above copyright notice and this paragraph are included on all 1034 such copies and derivative works. However, this document itself may not 1035 be modified in any way, such as by removing the copyright notice or 1036 references to the Internet Society or other Internet organizations, 1037 except as needed for the purpose of developing Internet standards in 1038 which case the procedures for copyrights defined in the Internet Stan- 1039 dards process must be followed, or as required to translate it into 1040 languages other than English. 1042 The limited permissions granted above are perpetual and will not be 1043 revoked by the Internet Society or its successors or assigns. 1045 This document and the information contained herein is provided on 1046 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1047 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1048 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1049 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1050 FITNESS FOR A PARTICULAR PURPOSE. 1052 This document expires April 24, 2003.