idnits 2.17.1 draft-ietf-msgtrk-mtqp-06.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 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 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 (April 1, 2002) is 8060 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 143, but not defined == Missing Reference: 'NNTP' is mentioned on line 143, but not defined == Missing Reference: 'TLS' is mentioned on line 548, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-SHA1' ** Obsolete normative reference: RFC 2234 (ref. 'RFC-ABNF') (Obsoleted by RFC 4234) ** 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' -- No information found for draft-ietf-msgtrk-model- - is the name correct? -- Possible downref: Normative reference to a draft: 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: 9 errors (**), 0 flaws (~~), 6 warnings (==), 10 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-06.txt AT&T Laboratories 4 Valid for six months April 1, 2002 6 Message Tracking Query Protocol 8 10 Authors' version: 1.15 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 [RFC-MIME] media type that is 65 used to report tracking status information. Using the model document's 66 terminology, 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 -06 80 Added opt-parameter to STARTTLS and description. 82 1.3. Changes Made for -05 83 STARTTLS error response changed from "/unsupported" to "/unavailable". 85 Fixed some minor nits in the examples and some typos. 87 1.4. Changes Made for -04 89 Reworked the SRV lookup description. 91 Other comments from the list. 93 Changes to the ABNF. 95 Changed "must" to "MUST" in section 4. 97 Changed "may" to "MAY" in section 4. 99 More examples. 101 Eliminated the registry of vnd. options. 103 Eliminated lots of unused references. 105 1.5. Changes Made for -03 107 Changed references. 109 Worked on error codes. 111 Made examples more real with secrets and hashes. 113 Fixes to examples. 115 Added dot-stuffed example. 117 Additional TLS info. 119 Better Security Considerations section. 121 1.6. Changes Made for -02 123 This section will be removed before publication. 125 Provided information on lookup for an MTQP server: SRV MTQP, then 126 MX, then A. 128 Provided a section on firewall considerations 130 Provided a section on service DNS considerations 132 At IANA's request, left the port number as XXXX and added more 133 information on the option registry. 135 Added text on various error conditions and fixed ABNF for error 136 response codes. 138 Fleshed out the tracking examples. 140 2. Basic Operation 142 The Message Tracking Query Protocol (MTQP) is similar to many other 143 line-oriented Internet protocols, such as [POP3] and [NNTP]. Initially, 144 the server host starts the MTQP service by listening on TCP port XXXX 145 (TBD by IANA). 147 When an MTQP client wishes to make use of the message tracking ser- 148 vice, it establishes a TCP connection with the server host, as recorded 149 from the initial message submission or as returned by a previous track- 150 ing request. To find the server host, the MTQP client first does an SRV 151 lookup for the server host using DNS SRV records, with a service name of 152 "mtqp" and a protocol name of "tcp", as in _mtqp._tcp.smtp3.example.com. 153 (See the "Usage rules" section in [RFC-SRV] for details.) If the SRV 154 records do not exist, the MTQP client then does an address record lookup 155 for the server host. 157 When the connection is established, the MTQP server sends a greet- 158 ing. The MTQP client and MTQP server then exchange commands and 159 responses (respectively) until the connection is closed or aborted. 161 2.1. Tracking Service DNS Considerations 163 Because of the ways server host lookups are performed, many dif- 164 ferent tracking server host configurations are supported. 166 A mail system that uses a single mail server host and has the MTQP 167 server host on the same server host will most likely have a single MX 168 record pointing at the server host, and if not, will have an address 169 record. Both mail and MTQP clients will access that host directly. 171 A mail system that uses a single mail server host, but wants track- 172 ing queries to be performed on a different machine, MUST have an SRV 173 MTQP record pointing at that different machine. 175 A mail system that uses multihomed mail servers has two choices for 176 providing tracking services: either all mail servers must be running 177 tracking servers that are able to retrieve information on all messages, 178 or the tracking service must be performed on one (or more) machine(s) 179 that are able to retrieve information on all messages. In the former 180 case, no additional DNS records are needed beyond the MX records already 181 in place for the mail system. In the latter case, SRV MTQP records are 182 needed that point at the machine(s) that are running the tracking ser- 183 vice. In both cases, note that the tracking service MUST be able to 184 handle the queries for all messages accepted by that mail system. 186 2.2. Commands 188 Commands in MTQP consist of a case-insensitive keyword, possibly 189 followed by one or more parameters. All commands are terminated by a 190 CRLF pair. Keywords and parameters consist of printable ASCII charac- 191 ters. Keywords and parameters are separated by whitespace (one or more 192 space or tab characters). A command line is limited to 998 characters 193 before the CRLF. 195 2.3. Responses 197 Responses in MTQP consist of a status indicator that indicates suc- 198 cess or failure. Successful commands may also be followed by additional 199 lines of data. All response lines are terminated by a CRLF pair and are 200 limited to 998 characters before the CRLF. There are several status 201 indicators: "+OK" indicates success; "+OK+" indicates a success fol- 202 lowed by additional lines of data, a multi-line success response; "- 203 TEMP" indicates a temporary failure; "-ERR" indicates a permanent 204 failure; and "-BAD" indicates a protocol error (such as for unrecognized 205 commands). 207 A status indicator MAY be followed by a series of machine-parsable, 208 case-insensitive response information giving more data about the errors. 209 These are separated from the status indicator and each other by a single 210 slash character ("/", decimal code 47). Following that, there MAY be 211 white space and a human-readable text message. The human-readable text 212 message is not intended to be presented to the end user, but should be 213 appropriate for putting in a log for use in debugging problems. 215 In a multi-line success response, each subsequent line is ter- 216 minated by a CRLF pair and limited to 998 characters before the CRLF. 217 When all lines of the response have been sent, a final line is sent con- 218 sisting of a single period (".", decimal code 046) and a CRLF pair. If 219 any line of the multi-line response begins with a period, the line is 220 "dot-stuffed" by prepending the period with a second period. When exa- 221 mining a multi-line response, the client checks to see if the line 222 begins with a period. If so, and octets other than CRLF follow, the 223 first octet of the line (the period) is stripped away. If so, and if 224 CRLF immediately follows the period, then the response from the MTQP 225 server is ended and the line containing the ".CRLF" is not considered 226 part of the multi-line response. 228 An MTQP server MUST respond to an unrecognized, unimplemented, or 229 syntactically invalid command by responding with a negative -BAD status 230 indicator. A server MUST respond to a command issued when the session 231 is in an incorrect state by responding with a negative -ERR status indi- 232 cator. 234 2.4. Optional Timers 236 An MTQP server MAY have an inactivity autologout timer. Such a 237 timer MUST be of at least 10 minutes in duration. The receipt of any 238 command from the client during that interval should suffice to reset the 239 autologout timer. An MTQP server MAY limit the number of commands, 240 unrecognized commands, or total connection time, or MAY use other 241 criteria, to prevent denial of service attacks. 243 2.5. Firewall Considerations 245 A firewall mail gateway has two choices when receiving a tracking 246 query for a host within its domain: it may return a response to the 247 query that says the message has been passed on, but no further informa- 248 tion is available; or it may perform a chaining operation itself, gath- 249 ering information on the message from the mail hosts behind the 250 firewall, and returning to the MTQP client the information for each 251 behind-the-firewall hop, or possibly just the final hop information, 252 possibly also disguising the names of any hosts behind the firewall. 253 Which option is picked is an administrative decision and is not further 254 mandated by this document. 256 3. Initialization and Option Response 258 Once the TCP connection has been opened by an MTQP client, the MTQP 259 server issues an initial status response that indicates its readiness. 260 If the status response is positive (+OK or +OK+), the client may proceed 261 with other commands. 263 The initial status response MUST include the response information 264 "/MTQP". Negative responses MUST include a reason code as response 265 information. The following reason codes are defined here; unrecognized 266 reason codes added in the future may be treated as equivalent to "una- 267 vailable". 268 "/" "unavailable" 269 "/" "admin" 271 The reason code "/admin" SHOULD be used when the service is una- 272 vailable for administrative reasons. The reason code "/unavailable" 273 SHOULD be used when the service is unavailable for other reasons. 275 If the server has any options enabled, they are listed as the 276 multi-line response of the initial status response, one per line. An 277 option specification consists of an identifier, optionally followed by 278 option-specific parameters. An option specification may be continued 279 onto additional lines by starting the continuation lines with white 280 space. The option identifier is case insensitive. Option identifiers 281 beginning with the characters "vnd." are reserved for vendor use. (See 282 below.) 284 One option specification is defined here: 286 STARTTLS 288 This capability MUST be listed if the optional STARTTLS command is 289 supported by the MTQP server. It has no parameters. 291 Example #1 (no options): 292 S: +OK/MTQP MTQP server ready 294 Example #2 (service temporarily unavailable): 295 S: -TEMP/MTQP/admin Service down for admin, call back later 297 Example #3 (service permanently unavailable): 298 S: -ERR/MTQP/unavailable Service down 300 Example #4 (alternative for no options): 301 S: +OK+/MTQP MTQP server ready 302 S: . 304 Example #5 (options available): 305 S: +OK+/MTQP MTQP server ready 306 S: starttls 307 S: vnd.com.example.option2 with parameters private to example.com 308 S: vnd.com.example.option3 with a very long 309 S: list of parameters 310 S: . 312 4. TRACK Command 314 Syntax: 315 "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF 317 mtrk-secret = base64 319 Envid is defined in [DRAFT-TRACK-ESMTP]. Mtrk-secret is the secret 320 A described in [DRAFT-TRACK-ESMTP], encoded using base64. 322 When the client issues the TRACK command, and the user is vali- 323 dated, the MTQP server retrieves tracking information about an email 324 message. To validate the user, the value of mtrk-secret is hashed using 325 SHA1, as described in [RFC-SHA1]. The hash value is then compared with 326 the value passed with the message when it was originally sent. If the 327 hash values match, the user is validated. 329 A successful response MUST be multi-line, consisting of a [RFC- 330 MIME] body part. The MIME body part MUST be of type multipart/related, 331 with subparts of message/tracking-status, as defined in [DRAFT-TRACK- 332 TSN]. The response contains the tracking information about the email 333 message that used the given tracking-id. 335 In each of the examples below, the envid is "<12345- 337 20010101@example.com>", the secret A is "abcdefgh", and the SHA1 hash B 338 is (in hex) "734ba8b31975d0dbae4d6e249f4e8da270796c94". The message 339 came from example.com and the MTQP server is example2.com. 341 Example #6 Message Delivered: 342 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 343 S: +OK+ Tracking information follows 344 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 345 S: 346 S: --%%%% 347 S: Content-Type: message/tracking-status 348 S: 349 S: Original-Envelope-Id: 12345-20010101@example.com 350 S: Reporting-MTA: dns; example2.com 351 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 352 S: 353 S: Original-Recipient: rfc822; user1@example1.com 354 S: Final-Recipient: rfc822; user1@example1.com 355 S: Action: delivered 356 S: Status: 2.5.0 357 S: 358 S: --%%%%-- 359 S: . 361 Example #7 Message Transferred: 362 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 363 S: +OK+ Tracking information follows 364 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 365 S: 366 S: --%%%% 367 S: Content-Type: message/tracking-status 368 S: 369 S: Original-Envelope-Id: 12345-20010101@example.com 370 S: Reporting-MTA: dns; example2.com 371 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 372 S: 373 S: Original-Recipient: rfc822; user1@example1.com 374 S: Final-Recipient: rfc822; user1@example1.com 375 S: Action: transferred 376 S: Remote-MTA: dns; example3.com 377 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 378 S: Status: 2.4.0 379 S: 380 S: --%%%%-- 381 S: . 383 Example #8 Message Delayed and a Dot-Stuffed Header: 384 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 385 S: +OK+ Tracking information follows 386 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 387 S: ..Dot-Stuffed-Header: as an example 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: rfc822; user1@example1.com 397 S: Final-Recipient: rfc822; user1@example1.com 398 S: Action: delayed 399 S: Status: 4.4.1 (No answer from host) 400 S: Remote-MTA: dns; example3.com 401 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 402 S: Will-Retry-Until: Thu, 4 Jan 2001 15:15:15 -0500 403 S: 404 S: --%%%%-- 405 S: . 407 Example #9 Two Users, One Relayed, One Failed: 408 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 409 S: +OK+ Tracking information follows 410 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 411 S: 412 S: --%%%% 413 S: Content-Type: message/tracking-status 414 S: 415 S: Original-Envelope-Id: 12345-20010101@example.com 416 S: Reporting-MTA: dns; example2.com 417 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 418 S: 419 S: Original-Recipient: rfc822; user1@example1.com 420 S: Final-Recipient: rfc822; user1@example1.com 421 S: Action: relayed 422 S: Status: 2.1.9 423 S: Remote-MTA: dns; example3.com 424 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 425 S: 426 S: Original-Recipient: rfc822; user2@example1.com 427 S: Final-Recipient: rfc822; user2@example1.com 428 S: Action: failed 429 S: Status 5.2.2 (Mailbox full) 430 S: Remote-MTA: dns; example3.com 431 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 432 S: 434 S: --%%%%-- 435 S: . 437 Example #10 Firewall: 438 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 439 S: +OK+ Tracking information follows 440 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 441 S: 442 S: --%%%% 443 S: Content-Type: message/tracking-status 444 S: 445 S: Original-Envelope-Id: 12345-20010101@example.com 446 S: Reporting-MTA: dns; example2.com 447 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 448 S: 449 S: Original-Recipient: rfc822; user1@example1.com 450 S: Final-Recipient: rfc822; user1@example1.com 451 S: Action: relayed 452 S: Status: 2.1.9 453 S: Remote-MTA: dns; smtp.example3.com 454 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 455 S: 456 S: --%%%% 457 S: Content-Type: message/tracking-status 458 S: 459 S: Original-Envelope-Id: 12345-20010101@example.com 460 S: Reporting-MTA: dns; smtp.example3.com 461 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 462 S: 463 S: Original-Recipient: rfc822; user2@example1.com 464 S: Final-Recipient: rfc822; user4@example3.com 465 S: Action: delivered 466 S: Status: 2.5.0 467 S: 468 S: --%%%%-- 469 S: . 471 Example #11 Firewall, Combining Per-Recipient Blocks: 472 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 473 S: +OK+ Tracking information follows 474 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 475 S: 476 S: --%%%% 477 S: Content-Type: message/tracking-status 478 S: 479 S: Original-Envelope-Id: 12345-20010101@example.com 480 S: Reporting-MTA: dns; example2.com 481 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 482 S: 483 S: Original-Recipient: rfc822; user1@example1.com 484 S: Final-Recipient: rfc822; user1@example1.com 485 S: Action: relayed 486 S: Status: 2.1.9 487 S: Remote-MTA: dns; smtp.example3.com 488 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 489 S: 490 S: Original-Recipient: rfc822; user2@example1.com 491 S: Final-Recipient: rfc822; user4@example3.com 492 S: Action: delivered 493 S: Status: 2.5.0 494 S: 495 S: --%%%%-- 496 S: . 498 Example #12 Firewall, Hiding System Names Behind the Firewall: 499 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 500 S: +OK+ Tracking information follows 501 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 502 S: 503 S: --%%%% 504 S: Content-Type: message/tracking-status 505 S: 506 S: Original-Envelope-Id: 12345-20010101@example.com 507 S: Reporting-MTA: dns; example2.com 508 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 509 S: 510 S: Original-Recipient: rfc822; user1@example1.com 511 S: Final-Recipient: rfc822; user1@example1.com 512 S: Action: relayed 513 S: Status: 2.1.9 514 S: Remote-MTA: dns; example2.com 515 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 516 S: 517 S: --%%%% 518 S: Content-Type: message/tracking-status 519 S: 520 S: Original-Envelope-Id: 12345-20010101@example.com 521 S: Reporting-MTA: dns; example2.com 522 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 523 S: 524 S: Original-Recipient: rfc822; user2@example1.com 525 S: Final-Recipient: rfc822; user4@example1.com 526 S: Action: delivered 527 S: Status: 2.5.0 528 S: 529 S: --%%%%-- 530 S: . 532 5. COMMENT Command 534 Syntax: 535 "COMMENT" opt-text CRLF 537 opt-text = [WSP *(VCHAR / WSP)] 539 When the client issues the COMMENT command, the MTQP server MUST 540 respond with a successful response (+OK or +OK+). All optional text 541 provided with the COMMENT command are ignored. 543 6. STARTTLS Command 545 Syntax: 546 "STARTTLS" [hostname] CRLF 548 TLS [TLS], more commonly known as SSL, is a popular mechanism for 549 enhancing TCP communications with privacy and authentication. An MTQP 550 server MAY support TLS. If an MTQP server supports TLS, it MUST include 551 "STARTTLS" in the option specifications list on protocol startup. 553 The optional parameter, if specified, MUST be a fully qualified 554 domain name. A client MAY specify the hostname it believes it is speak- 555 ing with so that the server may respond with the proper TLS certificate. 556 This is useful for virtual servers that provide message tracking for 557 multiple domains (i.e., virtual hosting). 559 If the server returns a negative response, it MAY use one of the 560 following response codes: 561 "/" "unsupported" 562 "/" "unavailable" 563 "/" "tlsinprogress" 565 If TLS is not supported, then a response code of "/unsupported" 566 SHOULD be used. If TLS is not available for some other reason, then a 567 response code of "/unavailable" SHOULD be used. If a TLS session is 568 already in progress, then it is a protocol error and "-BAD" MUST be 569 returned with a response code of "/tlsinprogress". 571 After receiving a positive response to a STARTTLS command, the 572 client MUST start the TLS negotiation before giving any other MTQP com- 573 mands. 575 If the MTQP client is using pipelining (see below), the STARTTLS 576 command must be the last command in a group. 578 6.1. Processing After the STARTTLS Command 580 If the TLS handshake fails, the server SHOULD abort the connection. 582 After the TLS handshake has been completed, both parties MUST 583 immediately decide whether or not to continue based on the authentica- 584 tion and privacy achieved. The MTQP client and server may decide to move 585 ahead even if the TLS negotiation ended with no authentication and/or no 586 privacy because most MTQP services are performed with no authentication 587 and no privacy, but some MTQP clients or servers may want to continue 588 only if a particular level of authentication and/or privacy was 589 achieved. 591 If the MTQP client decides that the level of authentication or 592 privacy is not high enough for it to continue, it SHOULD issue an MTQP 593 QUIT command immediately after the TLS negotiation is complete. If the 594 MTQP server decides that the level of authentication or privacy is not 595 high enough for it to continue, it SHOULD reply to every MTQP command 596 from the client (other than a QUIT command) with a negative "-ERR" 597 response and a response code of "/insecure". 599 6.2. Result of the STARTTLS Command 601 Upon completion of the TLS handshake, the MTQP protocol is reset to 602 the initial state (the state in MTQP after a server starts up). The 603 server MUST discard any knowledge obtained from the client prior to the 604 TLS negotiation itself. The client MUST discard any knowledge obtained 605 from the server, such as the list of MTQP options, which was not 606 obtained from the TLS negotiation itself. 608 At the end of the TLS handshake, the server acts as if the connec- 609 tion had been initiated and responds with an initial status response 610 and, optionally, a list of server options. The list of MTQP server 611 options received after the TLS handshake MUST be different than the list 612 returned before the TLS handshake. In particular, a server MUST NOT 613 return the STARTTLS option in the list of server options after a TLS 614 handshake has completed. 616 Both the client and the server MUST know if there is a TLS session 617 active. A client MUST NOT attempt to start a TLS session if a TLS ses- 618 sion is already active. 620 7. QUIT Command 622 Syntax: 623 "QUIT" CRLF 625 When the client issues the QUIT command, the MTQP session 627 terminates. The QUIT command has no parameters. The server MUST 628 respond with a successful response. The client MAY close the session 629 from its end immediately after issuing this command (if the client is on 630 an operating system where this does not cause problems). 632 8. Pipelining 634 The MTQP client may elect to transmit groups of MTQP commands in 635 batches without waiting for a response to each individual command. The 636 MTQP server MUST process the commands in the order received. 638 Specific commands may place further constraints on pipelining. For 639 example, STARTTLS must be the last command in a batch of MTQP commands. 641 The following two examples are identical: 643 Example #13 : 644 C: TRACK YWJjZGVmZ2gK 645 S: +OK+ Tracking information follows 646 S: 647 S: ... tracking details #1 go here ... 648 S: . 649 C: TRACK QUJDREVGR0gK 650 S: +OK+ Tracking information follows 651 S: 652 S: ... tracking details #2 go here ... 653 S: . 655 Example #14 : 656 C: TRACK YWJjZGVmZ2gK 657 C: TRACK QUJDREVGR0gK 658 S: +OK+ Tracking information follows 659 S: 660 S: ... tracking details #1 go here ... 661 S: . 662 S: +OK+ Tracking information follows 663 S: 664 S: ... tracking details #2 go here ... 665 S: . 667 9. URL Format 669 The MTQP URL scheme is used to designate MTQP servers on Internet 670 hosts accessible using the MTQP protocol. An MTQP URL takes one of the 671 following forms: 673 mtqp:///track// 674 mtqp://:/track// 675 The first form is used to refer to an MTQP server on the standard 676 port, while the second form specifies a non-standard port. Both of 677 these forms specify that the TRACK command is to be issued using the 678 given tracking id (envid) and authorization secret (mtrk-secret). The 679 path element "/track/" is case insensitive, but the envid and mtrk- 680 secret may not be. 682 9.1. MTQP URL Syntax 684 This is an ABNF description of the MTQP URL. 686 mtqp-url = "mtqp://" net_loc "/track/" envid "/" mtrk-secret 688 10. IANA Considerations 690 System port number XXXX - TBD by IANA 692 The service name to be registered with the Internet Assigned Number 693 Authority (IANA) is "MTQP". 695 This document requests that IANA maintain one new registry: MTQP 696 options. The registry's purpose is to register options to this proto- 697 col. Options whose names do not begin with "vnd." MUST be defined in a 698 standards track or IESG approved experimental RFC. New MTQP options 699 MUST include the following information as part of their definition: 701 option identifier 702 option parameters 703 added commands 704 standard commands affected 705 specification reference 706 discussion 708 One MTQP option is defined in this document, with the following 709 registration definition: 711 option identifier: STARTTLS 712 option parameters: none 713 added commands: STARTTLS 714 standard commands affected: none 715 specification reference: RFC TBD 716 discussion: see RFC TBD 718 Additional vendor-specific options for this protocol have names 719 that begin with "vnd.". After the "vnd." would appear the reversed 720 domain name of the vendor, another dot ".", and a name for the option 721 itself. For example, "vnd.com.example.extinfo" might represent a 722 vendor-specific extension providing extended information by the owner of 723 the "example.com" domain. These names MAY be registered with IANA. 725 11. Security Considerations 727 If the originator of a message were to delegate his or her tracking 728 request to a third party, this would be vulnerable to snooping over 729 unencrypted sessions. The user can decide on a message-by-message basis 730 if this risk is acceptable. 732 The security of tracking information is dependent on the randomness 733 of the secret chosen for each message and the level of exposure of that 734 secret. If different secrets are used for each message, then the max- 735 imum exposure from tracking any message will be that single message for 736 the time that the tracking information is kept on any MTQP server. If 737 this level of exposure is too much, TLS may be used to reduce the expo- 738 sure further. 740 It should be noted that message tracking is not an end-to-end 741 mechanism. Thus, if an MTQP client/server pair decide to use TLS 742 privacy, they are not securing tracking queries with any prior or suc- 743 cessive MTQP servers. 745 Both the MTQP client and server must check the result of the TLS 746 negotiation to see whether acceptable authentication or privacy was 747 achieved. Ignoring this step completely invalidates using TLS for secu- 748 rity. The decision about whether acceptable authentication or privacy 749 was achieved is made locally, is implementation-dependent, and is beyond 750 the scope of this document. 752 The MTQP client and server should note carefully the result of the 753 TLS negotiation. If the negotiation results in no privacy, or if it 754 results in privacy using algorithms or key lengths that are deemed not 755 strong enough, or if the authentication is not good enough for either 756 party, the client may choose to end the MTQP session with an immediate 757 QUIT command, or the server may choose to not accept any more MTQP com- 758 mands. 760 A man-in-the-middle attack can be launched by deleting the 761 "STARTTLS" option response from the server. This would cause the client 762 not to try to start a TLS session. An MTQP client can protect against 763 this attack by recording the fact that a particular MTQP server offers 764 TLS during one session and generating an alarm if it does not appear in 765 an option response for a later session. 767 If TLS is not used, a tracking request is vulnerable to replay 768 attacks, such that a snoop can later replay the same handshake again to 769 potentially gain more information about a message's status. 771 Before the TLS handshake has begun, any protocol interactions are 772 performed in the clear and may be modified by an active attacker. For 773 this reason, clients and servers MUST discard any knowledge obtained 774 prior to the start of the TLS handshake upon completion of the TLS 775 handshake. 777 If a client/server pair successfully performs a TLS handshake and 778 the server does chaining referrals, then the server SHOULD attempt to 779 negotiate TLS at the same security level at the next hop. In a hop-by- 780 hop scenario, STARTTLS is a request for "best effort" security and 781 should be treated as such. 783 SASL is not used because authentication is per message rather than 784 per user. 786 12. Protocol Syntax 788 This is a collected ABNF description of the MTQP protocol. 789 conversation = command-response *( client-command command-response ) 791 # client side 792 client-command = track-command / starttls-command / quit-command / comment-command 794 track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF 796 mtrk-secret = base64 798 starttls-command = "STARTTLS" [hostname] CRLF 800 quit-command = "QUIT" CRLF 802 comment-command = "COMMENT" opt-text CRLF 804 # server side 805 command-response = success-response / temp-response / error-response / bad-response 807 temp-response = "-TEMP" response-info opt-text CRLF 809 opt-text = [WSP *(VCHAR / WSP)] 811 error-response = "-ERR" response-info opt-text CRLF 813 bad-response = "-BAD" response-info opt-text CRLF 815 success-response = single-line-success / multi-line-success 817 single-line-success = "+OK" response-info opt-text CRLF 818 multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf 820 dataline = *998OCTET CRLF 822 dotcrlf = "." CRLF 824 option-list = *option-line 826 option-line = identifier opt-text *(CRLF WSP opt-text) CRLF 828 NAMECHAR = ALPHA / DIGIT / "-" / "_" 830 identifier = (ALPHA / "_") *NAMECHAR) 832 response-info = *( "/" ( "admin" / "unavailable" / "unsupported" / 833 "tlsinprogress" / "insecure" / 1*NAMECHAR ) ) 835 13. Acknowledgements 837 The description of STARTTLS is based on [RFC-SMTP-TLS]. 839 14. References 841 [RFC-SHA1] RFC TBD, D. Eastlake & P. Jones, "US Secure Hash Stan- 842 dard 1 (SHA1)", TBD 2001. 844 [RFC-MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Inter- 845 net Mail Extensions (MIME) Part One: Format of Internet Message Bodies", 846 Innosoft, First Virtual, November 1996. 848 [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented 849 BNF for Syntax Specifications: ABNF", Internet Mail Consortium, Demon 850 Internet Ltd., November 1997. 852 [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to 853 Indicate Requirement Levels", Harvard University, March 1997. 855 [RFC-SMTPEXT] RFC 2554, J. Myers, "SMTP Service Extension for 856 Authentication", Netscape Communications, March 1999. 858 [RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for 859 Secure SMTP over TLS", Internet Mail Consortium, January 1999. 861 [RFC-SRV] RFC 2782, A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR 862 for specifying the location of services (DNS SRV)" Troll Technologies, 863 Internet Software Consortium, Microsoft Corp., February 2000 865 [DRAFT-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T. 867 Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc., 868 AT&T Laboratories, TBD 2001. 870 [DRAFT-TRACK-MODEL] draft-ietf-msgtrk-model-*.txt, T. Hansen, "Mes- 871 sage Tracking Models and Requirements", AT&T Laboratories, TBD 2001. 873 [DRAFT-TRACK-TSN] draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The 874 Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2001. 876 [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni- 877 form Resource Identifiers (URI): Generic Syntax", MIT/LCS, U. C. Irvine, 878 Xerox Corporation, August 1998. 880 15. Author's Address 882 Tony Hansen 883 AT&T Laboratories 884 Middletown, NJ 07748 885 USA 887 Phone: +1.732.420.8934 888 E-Mail: tony@att.com 890 16. Full Copyright Statement 892 Copyright (C) The Internet Society (1999). All Rights Reserved. 894 This document and translations of it may be copied and furnished to 895 others, and derivative works that comment on or otherwise explain it or 896 assist in its implementation may be prepared, copied, published and dis- 897 tributed, in whole or in part, without restriction of any kind, provided 898 that the above copyright notice and this paragraph are included on all 899 such copies and derivative works. However, this document itself may not 900 be modified in any way, such as by removing the copyright notice or 901 references to the Internet Society or other Internet organizations, 902 except as needed for the purpose of developing Internet standards in 903 which case the procedures for copyrights defined in the Internet Stan- 904 dards process must be followed, or as required to translate it into 905 languages other than English. 907 The limited permissions granted above are perpetual and will not be 908 revoked by the Internet Society or its successors or assigns. 910 This document and the information contained herein is provided on 911 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 912 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 913 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 914 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 915 FITNESS FOR A PARTICULAR PURPOSE. 917 This document expires October 1, 2002.