idnits 2.17.1 draft-ietf-msgtrk-mtqp-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 1120 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** 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 586 instances of lines with control characters in the document. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2004) is 7358 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 454, but not defined == Missing Reference: 'RFC-ABNF' is mentioned on line 76, but not defined == Missing Reference: 'TLS' is mentioned on line 694, but not defined == Missing Reference: 'POP3' is mentioned on line 250, but not defined == Missing Reference: 'NNTP' is mentioned on line 250, but not defined == Missing Reference: 'RFC-SHA1' is mentioned on line 450, but not defined == Missing Reference: 'RFC-X509' is mentioned on line 723, 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' -- Possible downref: Non-RFC (?) normative reference: 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: 11 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft T. Hansen 3 draft-ietf-msgtrk-mtqp-12.txt AT&T Laboratories 4 Valid for six months March 3, 2004 6 Message Tracking Query Protocol 8 10 Authors' version: 1.27 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 -12 85 More IESG comments: 87 Section 3: It says that if TLS is required, the server "SHOULD" 88 specify the "required" parameter. Why isn't that a MUST? The document 89 itself uses the word "required", and the previous IESG comments demon- 90 strated the need for such a flag. 92 The word "privacy" is being used when "confidentiality" is really 93 meant. 95 Section 6.1: No real guidance is provided about peer identities 97 exchanged within TLS. Is there some reason that they shouldn't match 98 the FQDN? 100 If the peer's use of STARTTLS is cached, you should cache the cert 101 identity. 103 1.2.2. Changes Made for -11 105 More IESG comments: 107 Consider a server that requires TLS be negotiated before it will 108 respond to any queries. A client that doesn't normally use TLS connects 109 to this server. It issues a TRACK command and gets a /tls-required 110 back, which tells it it needs to use TLS. But at this point the damage 111 has already been done: The secret has been sent in the clear to the 112 server as part of the TRACK command. The way to resolve this is to have 113 an indicator on the STARTTLS option. The obvious thing would be to have 114 an option parameter "required" that says some domains this server han- 115 dles require TLS. 117 There's also a bit of confusion in the present draft between the 118 /tls-required error that appears in the text and the /insecure error 119 that appears in the ABNF. 121 Finally, section 6 begins with: "TLS [TLS], more commonly known as 122 SSL,". SSL is a somewhat different and earlier protocol; it is not the 123 same as TLS. The reference to SSL needs to be removed. 125 1.2.3. Changes Made for -10 127 Fixes for IESG comments: 129 Make the hostname parameter in the STARTTLS command mandatory. 131 Add a sentence clarifying that TLS is mandatory to implement, but 132 that administrators are free to disable it or that it might be disabled 133 if there's no certificate available. (NB. This implies also that TLS 134 support is a SHOULD instead of a MAY.) 136 IESG: An error response of "/insecure" from the server is too late, 137 in that the confidential information is already exposed. (Well, the 138 response isn't, but an eavesdropper can then request the response 139 itself.) That implies that a server that always wants TLS to be used 140 should indicate that at sign-on time, so that it doesn't get any non-TLS 141 queries. 142 This implies that if the server decides that the level of auth isn't 143 high enough to continue, it MAY abort the connection. 145 Fix ABNF: fix comment characters (";", not "#") 147 Fix ABNF: remove trailing ) from identifier definition 149 1.2.4. Changes Made for -09 151 Fixes for AD comments made on 8/21/2002: 153 The copyright date is 1999. This seems wrong... 155 Section 2.4. Should say something about client timeouts and how 156 long it is appropriate to wait for a server. 158 Section 4. It seems appropriate to have two qualified error 159 responses to TRACK: (1) An indication that TLS must be negotiated 160 before this message can be tracked and (2) An indication that the search 161 succeeded but found no result. 163 What happens when no informatio about the message is found? Does 164 this come back as an empty response or does it get a negative response? 166 The URL registration in section 9 doesn't seem to meet the require- 167 ments set forth in RFC 2717. In particular, the URL registration tem- 168 plate needs to be included. 170 Section 10. The IANA considerations should mention that this docu- 171 ment registers the MQTP URL scheme. 173 References need to be split into normative and informative. 175 1.2.5. Changes Made for -08 177 Change "Option Parameters" back to "none" in STARTTLS registration 178 definition. 180 1.2.6. Changes Made for -07 182 Added hostname to STARTTLS registration information. Corrected 183 ABNF for STARTTLS. 185 1.2.7. Changes Made for -06 187 Added opt-parameter to STARTTLS and description. 189 1.2.8. Changes Made for -05 191 STARTTLS error response changed from "/unsupported" to "/unavail- 192 able". 194 Fixed some minor nits in the examples and some typos. 196 1.2.9. Changes Made for -04 198 Reworked the SRV lookup description. 200 Other comments from the list. 202 Changes to the ABNF. 204 Changed "must" to "MUST" in section 4. 206 Changed "may" to "MAY" in section 4. 208 More examples. 210 Eliminated the registry of vnd. options. 212 Eliminated lots of unused references. 214 1.2.10. Changes Made for -03 216 Changed references. 218 Worked on error codes. 220 Made examples more real with secrets and hashes. 222 Fixes to examples. 224 Added dot-stuffed example. 226 Additional TLS info. 228 Better Security Considerations section. 230 1.2.11. Changes Made for -02 232 Provided information on lookup for an MTQP server: SRV MTQP, then 233 MX, then A. 235 Provided a section on firewall considerations 237 Provided a section on service DNS considerations 239 At IANA's request, left the port number as XXXX and added more 240 information on the option registry. 242 Added text on various error conditions and fixed ABNF for error 243 response codes. 245 Fleshed out the tracking examples. 247 2. Basic Operation 249 The Message Tracking Query Protocol (MTQP) is similar to many other 250 line-oriented Internet protocols, such as [POP3] and [NNTP]. Initially, 251 the server host starts the MTQP service by listening on TCP port XXXX 252 (TBD by IANA). 254 When an MTQP client wishes to make use of the message tracking ser- 255 vice, it establishes a TCP connection with the server host, as recorded 256 from the initial message submission or as returned by a previous track- 257 ing request. To find the server host, the MTQP client first does an SRV 258 lookup for the server host using DNS SRV records, with a service name of 259 "mtqp" and a protocol name of "tcp", as in _mtqp._tcp.smtp3.example.com. 260 (See the "Usage rules" section in [RFC-SRV] for details.) If the SRV 261 records do not exist, the MTQP client then does an address record lookup 262 for the server host. 264 When the connection is established, the MTQP server sends a greet- 265 ing. The MTQP client and MTQP server then exchange commands and 266 responses (respectively) until the connection is closed or aborted. 268 2.1. Tracking Service DNS Considerations 270 Because of the ways server host lookups are performed, many dif- 271 ferent tracking server host configurations are supported. 273 A mail system that uses a single mail server host and has the MTQP 274 server host on the same server host will most likely have a single MX 275 record pointing at the server host, and if not, will have an address 276 record. Both mail and MTQP clients will access that host directly. 278 A mail system that uses a single mail server host, but wants track- 279 ing queries to be performed on a different machine, MUST have an SRV 280 MTQP record pointing at that different machine. 282 A mail system that uses multihomed mail servers has two choices for 283 providing tracking services: either all mail servers must be running 284 tracking servers that are able to retrieve information on all messages, 285 or the tracking service must be performed on one (or more) machine(s) 286 that are able to retrieve information on all messages. In the former 287 case, no additional DNS records are needed beyond the MX records already 288 in place for the mail system. In the latter case, SRV MTQP records are 289 needed that point at the machine(s) that are running the tracking 290 service. In both cases, note that the tracking service MUST be able to 291 handle the queries for all messages accepted by that mail system. 293 2.2. Commands 295 Commands in MTQP consist of a case-insensitive keyword, possibly 296 followed by one or more parameters. All commands are terminated by a 297 CRLF pair. Keywords and parameters consist of printable ASCII charac- 298 ters. Keywords and parameters are separated by whitespace (one or more 299 space or tab characters). A command line is limited to 998 characters 300 before the CRLF. 302 2.3. Responses 304 Responses in MTQP consist of a status indicator that indicates suc- 305 cess or failure. Successful commands may also be followed by additional 306 lines of data. All response lines are terminated by a CRLF pair and are 307 limited to 998 characters before the CRLF. There are several status 308 indicators: "+OK" indicates success; "+OK+" indicates a success fol- 309 lowed by additional lines of data, a multi-line success response; "- 310 TEMP" indicates a temporary failure; "-ERR" indicates a permanent 311 failure; and "-BAD" indicates a protocol error (such as for unrecognized 312 commands). 314 A status indicator MAY be followed by a series of machine-parsable, 315 case-insensitive response information giving more data about the errors. 316 These are separated from the status indicator and each other by a single 317 slash character ("/", decimal code 47). Following that, there MAY be 318 white space and a human-readable text message. The human-readable text 319 message is not intended to be presented to the end user, but should be 320 appropriate for putting in a log for use in debugging problems. 322 In a multi-line success response, each subsequent line is ter- 323 minated by a CRLF pair and limited to 998 characters before the CRLF. 324 When all lines of the response have been sent, a final line is sent con- 325 sisting of a single period (".", decimal code 046) and a CRLF pair. If 326 any line of the multi-line response begins with a period, the line is 327 "dot-stuffed" by prepending the period with a second period. When exa- 328 mining a multi-line response, the client checks to see if the line 329 begins with a period. If so, and octets other than CRLF follow, the 330 first octet of the line (the period) is stripped away. If so, and if 331 CRLF immediately follows the period, then the response from the MTQP 332 server is ended and the line containing the ".CRLF" is not considered 333 part of the multi-line response. 335 An MTQP server MUST respond to an unrecognized, unimplemented, or 336 syntactically invalid command by responding with a negative -BAD status 337 indicator. A server MUST respond to a command issued when the session 338 is in an incorrect state by responding with a negative -ERR status indi- 339 cator. 341 2.4. Firewall Considerations 343 A firewall mail gateway has two choices when receiving a tracking 344 query for a host within its domain: it may return a response to the 345 query that says the message has been passed on, but no further informa- 346 tion is available; or it may perform a chaining operation itself, gath- 347 ering information on the message from the mail hosts behind the 348 firewall, and returning to the MTQP client the information for each 349 behind-the-firewall hop, or possibly just the final hop information, 350 possibly also disguising the names of any hosts behind the firewall. 351 Which option is picked is an administrative decision and is not further 352 mandated by this document. 354 If a server chooses to perform a chaining operation itself, it MUST 355 provide a response within 2 minutes, and SHOULD return a "no further 356 information is available" response if it cannot provide an answer at the 357 end of that time limit. 359 2.5. Optional Timers 361 An MTQP server MAY have an inactivity autologout timer. Such a 362 timer MUST be of at least 10 minutes in duration. The receipt of any 363 command from the client during that interval should suffice to reset the 364 autologout timer. An MTQP server MAY limit the number of commands, 365 unrecognized commands, or total connection time, or MAY use other cri- 366 teria, to prevent denial of service attacks. 368 An MTQP client MAY have an inactivity autologout timer while wait- 369 ing for a response from the server. Since an MTQP server may be a 370 firewall, and may be chaining information from other servers, such a 371 timer MUST be at least 2 minutes in duration. 373 3. Initialization and Option Response 375 Once the TCP connection has been opened by an MTQP client, the MTQP 376 server issues an initial status response that indicates its readiness. 377 If the status response is positive (+OK or +OK+), the client may proceed 378 with other commands. 380 The initial status response MUST include the response information 381 "/MTQP". Negative responses MUST include a reason code as response 382 information. The following reason codes are defined here; unrecognized 383 reason codes added in the future may be treated as equivalent to "una- 384 vailable". 385 "/" "unavailable" 386 "/" "admin" 388 The reason code "/admin" SHOULD be used when the service is una- 389 vailable for administrative reasons. The reason code "/unavailable" 390 SHOULD be used when the service is unavailable for other reasons. 392 If the server has any options enabled, they are listed as the 393 multi-line response of the initial status response, one per line. An 394 option specification consists of an identifier, optionally followed by 395 option-specific parameters. An option specification may be continued 396 onto additional lines by starting the continuation lines with white 397 space. The option identifier is case insensitive. Option identifiers 398 beginning with the characters "vnd." are reserved for vendor use. (See 399 below.) 401 One option specification is defined here: 403 STARTTLS [1*WSP "required"] 405 This capability MUST be listed if the optional STARTTLS command is 406 enabled on the MQTP server and one or more certificates have been prop- 407 erly installed. 409 It has one optional parameter: the word "required". (The parame- 410 ters for STARTTLS are case-insensitive.) If the server requires that 411 TLS be used for some of the domains the server handles, the server MUST 412 specify the "required" parameter. 414 3.1. Examples 416 Example #1 (no options): 417 S: +OK/MTQP MTQP server ready 419 Example #2 (service temporarily unavailable): 420 S: -TEMP/MTQP/admin Service down for admin, call back later 422 Example #3 (service permanently unavailable): 423 S: -ERR/MTQP/unavailable Service down 425 Example #4 (alternative for no options): 426 S: +OK+/MTQP MTQP server ready 427 S: . 429 Example #5 (options available): 430 S: +OK+/MTQP MTQP server ready 431 S: starttls 432 S: vnd.com.example.option2 with parameters private to example.com 433 S: vnd.com.example.option3 with a very long 434 S: list of parameters 435 S: . 437 4. TRACK Command 439 Syntax: 440 "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF 442 mtrk-secret = base64 444 Envid is defined in [DRAFT-MTRK-ESMTP]. Mtrk-secret is the secret 445 A described in [DRAFT-MTRK-ESMTP], encoded using base64. 447 When the client issues the TRACK command, and the user is vali- 448 dated, the MTQP server retrieves tracking information about an email 449 message. To validate the user, the value of mtrk-secret is hashed using 450 SHA1, as described in [RFC-SHA1]. The hash value is then compared with 451 the value passed with the message when it was originally sent. If the 452 hash values match, the user is validated. 454 A successful response MUST be multi-line, consisting of a [RFC- 455 MIME] body part. The MIME body part MUST be of type multipart/related, 456 with subparts of message/tracking-status, as defined in [DRAFT-MTRK- 457 TSN]. The response contains the tracking information about the email 458 message that used the given tracking-id. 460 A negative response to the TRACK command may include these reason 461 codes: 462 "/" "tls-required" 463 "/" "admin" 464 "/" "unavailable" 465 "/" "noinfo" 466 "/" "insecure" 468 The reason code "/tls-required" SHOULD be used when the server has 469 decided to require TLS. The reason code "/admin" SHOULD be used when 470 the server has become unavailable, due to administrative reasons, since 471 the connection was initialized. The reason code "/unavailable" SHOULD 472 be used when the server has become unavailable, for other reasons, since 473 the connection was initialized. The reason code "/insecure" is 474 described later. 476 If a message has not been seen by the MTQP server, the server MUST 477 choose between two choices: it MAY return a positive response with an 478 action field of "opaque" in the tracking information, or it MAY return a 479 negative response with a reason code of "noinfo". 481 4.1. Examples 483 In each of the examples below, the envid is "<12345- 484 20010101@example.com>", the secret A is "abcdefgh", and the SHA1 hash B 485 is (in hex) "734ba8b31975d0dbae4d6e249f4e8da270796c94". The message 486 came from example.com and the MTQP server is example2.com. 488 Example #6 Message Delivered: 489 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 490 S: +OK+ Tracking information follows 491 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 492 S: 493 S: --%%%% 494 S: Content-Type: message/tracking-status 495 S: 496 S: Original-Envelope-Id: 12345-20010101@example.com 497 S: Reporting-MTA: dns; example2.com 498 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 499 S: 500 S: Original-Recipient: rfc822; user1@example1.com 501 S: Final-Recipient: rfc822; user1@example1.com 502 S: Action: delivered 503 S: Status: 2.5.0 504 S: 505 S: --%%%%-- 506 S: . 508 Example #7 Message Transferred: 509 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 510 S: +OK+ Tracking information follows 511 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 512 S: 513 S: --%%%% 514 S: Content-Type: message/tracking-status 515 S: 516 S: Original-Envelope-Id: 12345-20010101@example.com 517 S: Reporting-MTA: dns; example2.com 518 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 519 S: 520 S: Original-Recipient: rfc822; user1@example1.com 521 S: Final-Recipient: rfc822; user1@example1.com 522 S: Action: transferred 523 S: Remote-MTA: dns; example3.com 524 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 525 S: Status: 2.4.0 526 S: 527 S: --%%%%-- 528 S: . 530 Example #8 Message Delayed and a Dot-Stuffed Header: 531 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 532 S: +OK+ Tracking information follows 533 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 534 S: ..Dot-Stuffed-Header: as an example 535 S: 536 S: --%%%% 537 S: Content-Type: message/tracking-status 538 S: 539 S: Original-Envelope-Id: 12345-20010101@example.com 540 S: Reporting-MTA: dns; example2.com 541 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 542 S: 543 S: Original-Recipient: rfc822; user1@example1.com 544 S: Final-Recipient: rfc822; user1@example1.com 545 S: Action: delayed 546 S: Status: 4.4.1 (No answer from host) 547 S: Remote-MTA: dns; example3.com 548 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 549 S: Will-Retry-Until: Thu, 4 Jan 2001 15:15:15 -0500 550 S: 551 S: --%%%%-- 552 S: . 554 Example #9 Two Users, One Relayed, One Failed: 555 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 556 S: +OK+ Tracking information follows 557 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 558 S: 559 S: --%%%% 560 S: Content-Type: message/tracking-status 561 S: 562 S: Original-Envelope-Id: 12345-20010101@example.com 563 S: Reporting-MTA: dns; example2.com 564 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 565 S: 566 S: Original-Recipient: rfc822; user1@example1.com 567 S: Final-Recipient: rfc822; user1@example1.com 568 S: Action: relayed 569 S: Status: 2.1.9 570 S: Remote-MTA: dns; example3.com 571 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 572 S: 573 S: Original-Recipient: rfc822; user2@example1.com 574 S: Final-Recipient: rfc822; user2@example1.com 575 S: Action: failed 576 S: Status 5.2.2 (Mailbox full) 577 S: Remote-MTA: dns; example3.com 578 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 579 S: 580 S: --%%%%-- 581 S: . 583 Example #10 Firewall: 584 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 585 S: +OK+ Tracking information follows 586 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 587 S: 588 S: --%%%% 589 S: Content-Type: message/tracking-status 590 S: 591 S: Original-Envelope-Id: 12345-20010101@example.com 592 S: Reporting-MTA: dns; example2.com 593 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 594 S: 595 S: Original-Recipient: rfc822; user1@example1.com 596 S: Final-Recipient: rfc822; user1@example1.com 597 S: Action: relayed 598 S: Status: 2.1.9 599 S: Remote-MTA: dns; smtp.example3.com 600 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 601 S: 602 S: --%%%% 603 S: Content-Type: message/tracking-status 604 S: 605 S: Original-Envelope-Id: 12345-20010101@example.com 606 S: Reporting-MTA: dns; smtp.example3.com 607 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 608 S: 609 S: Original-Recipient: rfc822; user2@example1.com 610 S: Final-Recipient: rfc822; user4@example3.com 611 S: Action: delivered 612 S: Status: 2.5.0 613 S: 614 S: --%%%%-- 615 S: . 617 Example #11 Firewall, Combining Per-Recipient Blocks: 618 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 619 S: +OK+ Tracking information follows 620 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 621 S: 622 S: --%%%% 623 S: Content-Type: message/tracking-status 624 S: 625 S: Original-Envelope-Id: 12345-20010101@example.com 626 S: Reporting-MTA: dns; example2.com 627 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 628 S: 629 S: Original-Recipient: rfc822; user1@example1.com 630 S: Final-Recipient: rfc822; user1@example1.com 631 S: Action: relayed 632 S: Status: 2.1.9 633 S: Remote-MTA: dns; smtp.example3.com 634 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 635 S: 636 S: Original-Recipient: rfc822; user2@example1.com 637 S: Final-Recipient: rfc822; user4@example3.com 638 S: Action: delivered 639 S: Status: 2.5.0 640 S: 641 S: --%%%%-- 642 S: . 644 Example #12 Firewall, Hiding System Names Behind the Firewall: 645 C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 646 S: +OK+ Tracking information follows 647 S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status 648 S: 649 S: --%%%% 650 S: Content-Type: message/tracking-status 651 S: 652 S: Original-Envelope-Id: 12345-20010101@example.com 653 S: Reporting-MTA: dns; example2.com 654 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 655 S: 656 S: Original-Recipient: rfc822; user1@example1.com 657 S: Final-Recipient: rfc822; user1@example1.com 658 S: Action: relayed 659 S: Status: 2.1.9 660 S: Remote-MTA: dns; example2.com 661 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 662 S: 663 S: --%%%% 664 S: Content-Type: message/tracking-status 665 S: 666 S: Original-Envelope-Id: 12345-20010101@example.com 667 S: Reporting-MTA: dns; example2.com 668 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 669 S: 670 S: Original-Recipient: rfc822; user2@example1.com 671 S: Final-Recipient: rfc822; user4@example1.com 672 S: Action: delivered 673 S: Status: 2.5.0 674 S: 675 S: --%%%%-- 676 S: . 678 5. COMMENT Command 680 Syntax: 681 "COMMENT" opt-text CRLF 683 opt-text = [WSP *(VCHAR / WSP)] 685 When the client issues the COMMENT command, the MTQP server MUST 686 respond with a successful response (+OK or +OK+). All optional text 687 provided with the COMMENT command are ignored. 689 6. STARTTLS Command 691 Syntax: 692 "STARTTLS" 1*WSP hostname *WSP CRLF 694 TLS [TLS] is a popular mechanism for enhancing TCP communications 695 with confidentiality and authentication. All MTQP servers MUST imple- 696 ment TLS. However, TLS MAY be disabled by by a server administrator, 697 either explicitly or by failing to install any certificates for TLS to 698 use. If an MTQP server supports TLS and has one or more certificates 699 available it MUST include "STARTTLS" in the option specifications list 700 on protocol startup. 702 Note: TLS SHOULD be enabled on MQTP servers whenever possible. 704 The parameter MUST be a fully qualified domain name (FQDN). A 705 client MUST specify the hostname it believes it is speaking with so that 706 the server may respond with the proper TLS certificate. This is useful 707 for virtual servers that provide message tracking for multiple domains 708 (i.e., virtual hosting). 710 If the server returns a negative response, it MAY use one of the 711 following response codes: 712 "/" "unsupported" 713 "/" "unavailable" 714 "/" "tls-in-progress" 715 "/" "bad-fqdn" 717 If TLS is not supported, then a response code of "/unsupported" 718 SHOULD be used. If TLS is not available for some other reason, then a 719 response code of "/unavailable" SHOULD be used. If a TLS session is 720 already in progress, then it is a protocol error and "-BAD" MUST be 721 returned with a response code of "/tls-in-progress". If there is a 722 mismatch between the supplied FQDN and the FQDN found in the dNSName 723 field of the subjectAltName extension of the server's certificate [RFC- 724 X509], then it is a protocol error and "-BAD" MUST be returned with a 725 response code of "/bad-fqdn". 727 After receiving a positive response to a STARTTLS command, the 728 client MUST start the TLS negotiation before giving any other MTQP com- 729 mands. 731 If the MTQP client is using pipelining (see below), the STARTTLS 732 command must be the last command in a group. 734 6.1. Processing After the STARTTLS Command 736 If the TLS handshake fails, the server SHOULD abort the connection. 738 After the TLS handshake has been completed, both parties MUST 739 immediately decide whether or not to continue based on the authentica- 740 tion and confidentiality achieved. The MTQP client and server may 741 decide to move ahead even if the TLS negotiation ended with no authenti- 742 cation and/or no confidentiality because most MTQP services are per- 743 formed with no authentication and no confidentiality, but some MTQP 744 clients or servers may want to continue only if a particular level of 745 authentication and/or confidentiality was achieved. 747 If the MTQP client decides that the level of authentication or con- 748 fidentiality is not high enough for it to continue, it SHOULD issue an 749 MTQP QUIT command immediately after the TLS negotiation is complete. 751 If the MTQP server decides that the level of authentication or con- 752 fidentiality is not high enough for it to continue, it MAY abort the 753 connection. If it decides that the level of authentication or confiden- 754 tiality is not high enough for it to continue, and it does not abort the 755 connection, it SHOULD reply to every MTQP command from the client (other 756 than a QUIT command) with a negative "-ERR" response and a response code 757 of "/insecure". 759 6.2. Result of the STARTTLS Command 761 Upon completion of the TLS handshake, the MTQP protocol is reset to 762 the initial state (the state in MTQP after a server starts up). The 763 server MUST discard any knowledge obtained from the client prior to the 764 TLS negotiation itself. The client MUST discard any knowledge obtained 765 from the server, such as the list of MTQP options, which was not 766 obtained from the TLS negotiation itself. 768 At the end of the TLS handshake, the server acts as if the connec- 769 tion had been initiated and responds with an initial status response 770 and, optionally, a list of server options. The list of MTQP server 771 options received after the TLS handshake MUST be different than the list 772 returned before the TLS handshake. In particular, a server MUST NOT 773 return the STARTTLS option in the list of server options after a TLS 774 handshake has completed. 776 Both the client and the server MUST know if there is a TLS session 777 active. A client MUST NOT attempt to start a TLS session if a TLS ses- 778 sion is already active. 780 7. QUIT Command 782 Syntax: 783 "QUIT" CRLF 785 When the client issues the QUIT command, the MTQP session ter- 786 minates. The QUIT command has no parameters. The server MUST respond 787 with a successful response. The client MAY close the session from its 788 end immediately after issuing this command (if the client is on an 789 operating system where this does not cause problems). 791 8. Pipelining 793 The MTQP client may elect to transmit groups of MTQP commands in 794 batches without waiting for a response to each individual command. The 795 MTQP server MUST process the commands in the order received. 797 Specific commands may place further constraints on pipelining. For 798 example, STARTTLS must be the last command in a batch of MTQP commands. 800 8.1. Examples 802 The following two examples are identical: 804 Example #13 : 805 C: TRACK YWJjZGVmZ2gK 806 S: +OK+ Tracking information follows 807 S: 808 S: ... tracking details #1 go here ... 809 S: . 810 C: TRACK QUJDREVGR0gK 811 S: +OK+ Tracking information follows 812 S: 813 S: ... tracking details #2 go here ... 814 S: . 816 Example #14 : 817 C: TRACK YWJjZGVmZ2gK 818 C: TRACK QUJDREVGR0gK 819 S: +OK+ Tracking information follows 820 S: 821 S: ... tracking details #1 go here ... 822 S: . 823 S: +OK+ Tracking information follows 824 S: 825 S: ... tracking details #2 go here ... 826 S: . 828 9. The MTQP URI Scheme 830 9.1. Intended usage 832 The MTQP URI scheme is used to designate MTQP servers on Internet 833 hosts accessible using the MTQP protocol. It performs an MTQP query and 834 returns tracking status information. 836 9.2. URI Scheme Name 838 The name of the URI scheme is "mtqp". 840 9.3. URI Scheme Syntax 842 An MTQP URI takes one of the following forms: 844 mtqp:///track// 845 mtqp://:/track// 847 The first form is used to refer to an MTQP server on the standard 848 port, while the second form specifies a non-standard port. Both of 849 these forms specify that the TRACK command is to be issued using the 850 given tracking id (envid) and authorization secret (mtrk-secret). The 851 path element "/track/" MUST BE treated case insensitively, but the envid 852 and mtrk-secret MUST NOT be. 854 9.3.1. Formal Syntax 856 This is an ABNF description of the MTQP URI. 858 mtqp-uri = "mtqp://" net_loc "/track/" envid "/" mtrk-secret 860 9.4. Encoding Rules 862 The encoding of envid is discussed in [DRAFT-MTRK-ESMTP]. Mtrk- 863 secret is required to be base64 encoded. If the "/", "?" and "%" octets 864 appear in envid or mtrk-secret, they are further required to be 865 represented by a "%" followed by two hexadecimal characters. (The two 866 characters give the hexadecimal representation of that octet.) 868 10. IANA Considerations 870 System port number XXXX - TBD by IANA 872 The service name to be registered with the Internet Assigned Number 873 Authority (IANA) is "MTQP". 875 The IANA is asked to register the URI registration template found 876 in Appendix A in accordance with [BCP35]. 878 This document requests that IANA maintain one new registry: MTQP 879 options. The registry's purpose is to register options to this proto- 880 col. Options whose names do not begin with "vnd." MUST be defined in a 881 standards track or IESG approved experimental RFC. New MTQP options 882 MUST include the following information as part of their definition: 884 option identifier 885 option parameters 886 added commands 887 standard commands affected 888 specification reference 889 discussion 891 One MTQP option is defined in this document, with the following 892 registration definition: 894 option identifier: STARTTLS 895 option parameters: none 896 added commands: STARTTLS 897 standard commands affected: none 898 specification reference: RFC TBD 899 discussion: see RFC TBD 901 Additional vendor-specific options for this protocol have names 902 that begin with "vnd.". After the "vnd." would appear the reversed 903 domain name of the vendor, another dot ".", and a name for the option 904 itself. For example, "vnd.com.example.extinfo" might represent a 905 vendor-specific extension providing extended information by the owner of 906 the "example.com" domain. These names MAY be registered with IANA. 908 11. Security Considerations 910 If the originator of a message were to delegate his or her tracking 911 request to a third party, this would be vulnerable to snooping over 912 unencrypted sessions. The user can decide on a message-by-message basis 913 if this risk is acceptable. 915 The security of tracking information is dependent on the randomness 916 of the secret chosen for each message and the level of exposure of that 917 secret. If different secrets are used for each message, then the max- 918 imum exposure from tracking any message will be that single message for 919 the time that the tracking information is kept on any MTQP server. If 920 this level of exposure is too much, TLS may be used to reduce the expo- 921 sure further. 923 It should be noted that message tracking is not an end-to-end 924 mechanism. Thus, if an MTQP client/server pair decide to use TLS confi- 925 dentiality, they are not securing tracking queries with any prior or 926 successive MTQP servers. 928 Both the MTQP client and server must check the result of the TLS 929 negotiation to see whether acceptable authentication or confidentiality 930 was achieved. Ignoring this step completely invalidates using TLS for 931 security. The decision about whether acceptable authentication or con- 932 fidentiality was achieved is made locally, is implementation-dependent, 933 and is beyond the scope of this document. 935 The MTQP client and server should note carefully the result of the 936 TLS negotiation. If the negotiation results in no confidentiality, or 937 if it results in confidentiality using algorithms or key lengths that 938 are deemed not strong enough, or if the authentication is not good 939 enough for either party, the client may choose to end the MTQP session 940 with an immediate QUIT command, or the server may choose to not accept 941 any more MTQP commands. 943 A man-in-the-middle attack can be launched by deleting the 944 "STARTTLS" option response from the server. This would cause the client 945 not to try to start a TLS session. An MTQP client can protect against 946 this attack by recording the fact that a particular MTQP server offers 947 TLS during one session and generating an alarm if it does not appear in 948 an option response for a later session. 950 Similarly, the identity of the server as expressed in the server's 951 certificate should be cached, and an alarm generated if they do not 952 match in a later session. 954 If TLS is not used, a tracking request is vulnerable to replay 955 attacks, such that a snoop can later replay the same handshake again to 956 potentially gain more information about a message's status. 958 Before the TLS handshake has begun, any protocol interactions are 959 performed in the clear and may be modified by an active attacker. For 960 this reason, clients and servers MUST discard any knowledge obtained 961 prior to the start of the TLS handshake upon completion of the TLS 962 handshake. 964 If a client/server pair successfully performs a TLS handshake and 965 the server does chaining referrals, then the server SHOULD attempt to 966 negotiate TLS at the same (or better) security level at the next hop. 967 In a hop-by-hop scenario, STARTTLS is a request for "best effort" secu- 968 rity and should be treated as such. 970 SASL is not used because authentication is per message rather than 971 per user. 973 12. Protocol Syntax 975 This is a collected ABNF description of the MTQP protocol. 976 conversation = command-response *( client-command command-response ) 978 ; client side 979 client-command = track-command / starttls-command / quit-command / comment-command 981 track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF 983 mtrk-secret = base64 985 starttls-command = "STARTTLS" 1*WSP hostname *WSP CRLF 987 quit-command = "QUIT" CRLF 989 comment-command = "COMMENT" opt-text CRLF 991 ; server side 992 command-response = success-response / temp-response / error-response / bad-response 994 temp-response = "-TEMP" response-info opt-text CRLF 996 opt-text = [WSP *(VCHAR / WSP)] 998 error-response = "-ERR" response-info opt-text CRLF 1000 bad-response = "-BAD" response-info opt-text CRLF 1002 success-response = single-line-success / multi-line-success 1004 single-line-success = "+OK" response-info opt-text CRLF 1006 multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf 1008 dataline = *998OCTET CRLF 1009 dotcrlf = "." CRLF 1011 option-list = *option-line 1013 option-line = identifier opt-text *(CRLF WSP opt-text) CRLF 1015 NAMECHAR = ALPHA / DIGIT / "-" / "_" 1017 identifier = (ALPHA / "_") *NAMECHAR 1019 response-info = *( "/" ( "admin" / "unavailable" / "unsupported" / 1020 "tls-in-progress" / "insecure" / "tls-required" / 1*NAMECHAR ) ) 1022 13. Acknowledgements 1024 The description of STARTTLS is based on [RFC-SMTP-TLS]. 1026 14. Normative References 1028 [RFC-MIME]RFC 2045, N. Freed & N. Borenstein, "Multipurpose Inter- 1029 net Mail Extensions (MIME) Part One: Format of Internet 1030 Message Bodies", Innosoft, First Virtual, November 1996. 1032 [RFC-ABNF]RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented 1033 BNF for Syntax Specifications: ABNF", Internet Mail Con- 1034 sortium, Demon Internet Ltd., November 1997. 1036 [RFC-SRV] RFC 2782, A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR 1037 for specifying the location of services (DNS SRV)" Troll 1038 Technologies, Internet Software Consortium, Microsoft 1039 Corp., February 2000 1041 [RFC-SMTPEXT] 1042 RFC 2554, J. Myers, "SMTP Service Extension for Authenti- 1043 cation", Netscape Communications, March 1999. 1045 [DRAFT-MTRK-ESMTP] 1046 draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T. Hansen, 1047 "SMTP Service Extension for Message Tracking", Sendmail, 1048 Inc., AT&T Laboratories, TBD 2002. 1050 [DRAFT-MTRK-MODEL] 1051 draft-ietf-msgtrk-model-*.txt, T. Hansen, "Message Track- 1052 ing Models and Requirements", AT&T Laboratories, TBD 1053 2002. 1055 [DRAFT-MTRK-TSN] 1057 draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The 1058 Message/Tracking-Status MIME Extension", Sendmail, Inc., 1059 TBD 2002. 1061 [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni- 1062 form Resource Identifiers (URI): Generic Syntax", 1063 MIT/LCS, U. C. Irvine, Xerox Corporation, August 1998. 1065 15. Informational References 1067 [BCP35] BCP 35, RFC 2717, R. Petke, I. King, "Registration Pro- 1068 cedures for URL Scheme Names", November 1999. 1070 [RFC-SHA1]RFC 3184, D. Eastlake & P. Jones, "US Secure Hash Stan- 1071 dard 1 (SHA1)", September 2001. 1073 [RFC-KEYWORDS] 1074 RFC 2119, S. Bradner, "Key words for use in RFCs to Indi- 1075 cate Requirement Levels", Harvard University, March 1997. 1077 [RFC-SMTP-TLS] 1078 RFC2487, P. Hoffman, "SMTP Service Extension for Secure 1079 SMTP over TLS", Internet Mail Consortium, January 1999. 1081 [RFC-X509]RFC3280, R. Housley, W. Polk, W. Ford, D. Solo, "Internet 1082 X.509 Public Key Infrastructure Certificate and Certifi- 1083 cate Revocation List (CRL) Profile", RSA Laboratories, 1084 NIST, VeriSign, Citigroup, April 2002. 1086 Appendix A. MTQP URI Registration Template 1088 Scheme name: mtqp 1090 Scheme syntax: see section 9.1 1092 Character encoding considerations: see section 9.4 1094 Intended usage: see section 9.3 1096 Applications and/or protocols which use this scheme: MTQP 1098 Interoperability considerations: as specified for MTQP 1100 Security considerations: see section 11.0 1102 Relevant publications: [DRAFT-MTRK-ESMTP], [DRAFT-MTRK-MODEL], 1103 [DRAFT-MTRK-TSN] 1104 Contact: MSGTRK Working Group 1106 Author/Change Controller: IESG 1108 16. Author's Address 1110 Tony Hansen 1111 AT&T Laboratories 1112 Middletown, NJ 07748 1113 USA 1115 Phone: +1.732.420.8934 1116 E-Mail: tony@att.com 1118 17. Full Copyright Statement 1120 Copyright (C) The Internet Society (%Dy%). All Rights Reserved. 1122 This document and translations of it may be copied and furnished to 1123 others, and derivative works that comment on or otherwise explain it or 1124 assist in its implementation may be prepared, copied, published and dis- 1125 tributed, in whole or in part, without restriction of any kind, provided 1126 that the above copyright notice and this paragraph are included on all 1127 such copies and derivative works. However, this document itself may not 1128 be modified in any way, such as by removing the copyright notice or 1129 references to the Internet Society or other Internet organizations, 1130 except as needed for the purpose of developing Internet standards in 1131 which case the procedures for copyrights defined in the Internet Stan- 1132 dards process must be followed, or as required to translate it into 1133 languages other than English. 1135 The limited permissions granted above are perpetual and will not be 1136 revoked by the Internet Society or its successors or assigns. 1138 This document and the information contained herein is provided on 1139 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1140 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1141 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1142 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1143 FITNESS FOR A PARTICULAR PURPOSE. 1145 This document expires September 3, 2004.