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