Internet Draft E. Allman draft-ietf-msgtrk-protocol-00.txt Sendmail, Inc. Valid for six months T. Hansen AT&T Laboratories March 10, 2000 SMTP Service Extension for Message Tracking Authors' version: 1.1 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This memo and its companions are discussed on the MSGTRK working group mailing list, ietf-msgtrk[-request]@imc.org. An archive of the mailing list may be found at http://www.ietf.org/archive/msgtrk. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the Allman,Hansen [Page 1] Internet Draft SMTP Message Tracking Extensions March 10, 2000 current routing status of that message. This document provides exten- sions to the ESMTP protocol to enhance its capabilities to include mes- sage tracking. 1. Introduction The Message Tracking Models and Requirements document [RFC-TRACK- MODEL] discusses the models that message tracking solutions could fol- low, along with requirements for a message tracking solution that can be used with the Internet-wide message infrastructure. This memo defines an extension to the SMTP service that provides a message tracking solu- tion that satisfies those requirements. Using the model document's ter- minology, it uses active enabling and active requests with request referrals. .... This document is very drafty; its purpose is to promote discussion. Sections that are obviously in need of filling out have comments begin- ning with "--". 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-KEYWORDS]. 2. Framework for the Message Tracking Service Extension The Message Trackng extension to SMTP is laid out as follows: ** the name of the SMTP service defined here is "Message Track- ing"; ** the EHLO keyword value associated with the extension is "TRACK"; ** the TRACK keyword has no parameters; ** the TRACKID parameter is added to the MAIL FROM command; ** a new SMTP verb, "MTRK", is defined. The rest of this memo defines how support for the extension effects the behavior of a message transfer agent. Allman,Hansen [Page 2] Internet Draft SMTP Message Tracking Extensions March 10, 2000 3. Message Tracking Enabling An SMTP client wishing to request message tracking support for a message may issue the EHLO command to start an SMTP session, to deter- mine if the server supports any of several service extensions. If the server responds with code 250 to the EHLO command, and the response includes the EHLO keyword TRACK, then the Message Tracking extension (as described in this memo) is supported. In general, an ESMTP server which implements this service extension will propagate message tracking infor- mation when relaying mail to other SMTP-based MTAs that also support this extension, and make a "best effort" to record when messages are passed into other environments. 4. Additional Parameter for the MAIL FROM Command The extended MAIL FROM command is issued by a client when it wishes to request that a server maintain tracking information for the message. The extended MAIL FROM command is identical to the MAIL commands defined in [RFC-821], except that the additional parameter may appear after the recipient address. The general syntax for extended SMTP commands is defined in [RFC-ESMTP]. 4.1. The TRACKID parameter of the ESMTP MAIL FROM Command The TRACKID esmtp-keyword on the extended MAIL FROM command speci- fies whether or not the message should be tracked by the server. If the TRACKID esmtp-keyword is used, it MUST have an associated esmtp-value, which is constructed as described next. 4.2. Creating the TRACKID Parameter The TRACKID parameter consists of two parts: a per-message authen- tication string, the Auth String, and a per-message tracking identifica- tion string, the Tracking ID. 4.2.1. Tracking ID A key requirement of message tracking is the ability to uniquely identify a message with a globally and temporally unique signature. The Message-Id: header is required by [RFC-822] to identify a message, and is usually required to be globally and temporally unique. So it is almost sufficient for tracking identification. However, a Message ID will be reused under certain circumstances, such as when a message is resent, and such messages must be able to be tracked separately from the original message. The Tracking ID is REQUIRED to be the same value as used for the Message ID, without the angle brackets, and augmented by a colon ":" and a generational counter. The generational counter will be an unsigned integer value that SHOULD start at the value of 0. For Allman,Hansen [Page 3] Internet Draft SMTP Message Tracking Extensions March 10, 2000 example, if the value of the Message-ID: header is "<123456.89012391@domain.example>", then the value of the tracking ID will be "123456.89012391@domain.example:0". If a message is ever resent or retransmitted for any other reason by an end-user client, then the generational counter MUST be incremented by one. (The generational counter MAY additionally be incremented by a small (<10) random number.) 4.2.2. Secret Value For messages to be tracked, the mail user agent must use a secret value. This secret value MAY be a per-message secret, such as a 128-bit (16-byte) random number. 4.2.3. Stored Authentication Value The value of the Tracking ID, T, is concatentated with the secret value, S, and passed through the [RFC-MD5] one-way hash function, to create the Stored Authentication Value, A. A = H(T + S) 4.2.4. Transmitted Authentication String The Transitted Authentication String, B, is created by passing the Stored Authentication Value, A, through the MD5 one-way hash function, producing a 16-byte value. This value is then expressed as a series of 32 hexadecimal digits, either lower- or upper-case, transmitted in internet byte order (low-endian ???? ) [RFC-????]. B = hex(H(A)) 4.2.5. The TRACKID Parameter The TRACKID parameter, P, is created from the transmitted authenti- cation string, B, a colon ":", and the tracking ID, T. P = B + ":" + T 5. Message Tracking Requests The MTRK command is issued by the client host when it wishes to determine the current status of a message previously sent to that server host. The syntax of this command is as follows: MTRK : Allman,Hansen [Page 4] Internet Draft SMTP Message Tracking Extensions March 10, 2000 is the tracking ID, T, of a message previously sent to this server. The is the Stored Authenti- cation Value A (as calculated above) for that message. The is expressed as a series of 32 hexadecimal digits, either lower- or upper-case, transmitted in internet byte order [RFC- ????]. This command may be issued at any time once a session is esta- blished, as long as there is not a transaction occurring. Thus, this command is illegal between a MAIL FROM: command and the end of the DATA commands and responses. things to add: -- data to be returned -- states to be returned -- format to be returned -- responses to the verb, 250, 4xx, 5xx other things to consider: -- firewalls? (treat as gateway MTAs and let them do chaining?) -- affect on SUBMIT? can we ask MSA to return the A and B hash? -- use message-id directly and require message-id to be in first 1k of message? 6. Examples -- examples go here 6.1. Message Tracking Enabling S: 220 smtp.example.com ESMTP server ready C: EHLO example.example.com S: 250-smtp.example.com S: 250 TRACK C: MAIL FROM: TRACKID=1234567890123456789012:12345.54321@example.com:0 S: 250 sender ok C: RCPT TO: S: 25o recipient ok C: DATA S: 354 okay, send message C: Message-Id: <12345.54321@example.com> C: (rest of message here) C: . S: 250 message accepted C: QUIT S: 221 goodbye Allman,Hansen [Page 5] Internet Draft SMTP Message Tracking Extensions March 10, 2000 6.2. Message Tracking Request S: 220 smtp.example.com ESMTP server ready C: EHLO example.example.com S: 250-smtp.example.com S: 250 TRACK C: MTRK 1234567890123456789012:12345.54321@example.com:0 S: -- response to be determined 7. Security Considerations things to add: -- text about no more than a single message can be lost -- man in the middle attack -- see RFC 1894 for security considerations on DSNs and RFC 2298 on MDNs -- We probably cannot get away with the following statement: This RFC does not discuss security issues and is not believed to raise any security issues not already endemic in electronic mail and present in fully conforming implementations of [RFC821], or otherwise made pos- sible by [MIME]. 8. References [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, University of Southern California / Information Sciences Institute, August 1982. [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982. [RFC-ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., Silicon Graphics, Inc., July 1994. [RFC-MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC-MODEL] Hansen, T., "Message Tracking Models and Requirements", RFC ????, AT&T Laboratories, ???? 2000. [RFC-????] something on internet byte order Allman,Hansen [Page 6] Internet Draft SMTP Message Tracking Extensions March 10, 2000 9. Authors' Addresses Eric Allman Sendmail, Inc. street address city, state zip Phone: +1 E-Mail: eric@sendmail.com Tony Hansen AT&T Laboratories Lincroft, NJ 07738 USA Phone: +1 732 576-3207 E-Mail: tony@att.com 10. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and dis- tributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organisations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Stan- dards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This document expires September 10, 2000. Allman,Hansen [Page 7] Internet Draft SMTP Message Tracking Extensions March 10, 2000 11. Appendix A -- Sample Code For the sake of illustration, we provide the following sample C code for the creation of the saved and transmitted authentication strings. The code is based on MD5 code as described in [RFC-MD5]. The input is a secret and transaction ID, the output is two 33-byte strings containing the values of the two authentication strings, encoded as hex digits, and NUL-terminated. -- I have not yet compiled this code or verified that it does indeed generate network byte order. /* ** Function: trackauth */ #include void trackauth( /* input parameters ... */ unsigned char* secret; /* pointer to secret */ int secret_len; /* length of secret */ unsigned char* transaction_id; /* pointer to transaction ID */ int transaction_id_len; /* length of transaction ID */ /* output parameters ... */ unsigned char saved_auth_str[33]; /* A: saved authentication string */ unsigned char trans_auth_str[33]; /* B: transmitted auth. string */ ) { MD5_CTX context; /* MD5 engine */ unsigned char outbuf[16]; /* where to store the context */ register int i, j; /* counters */ static char hexdigits[] = "0123456789abcdef"; MD5Init(&context); MD5Update(&context, secret, secret_len); MD5Update(&context, transaction_id, transaction_id_len); MD5Final(outbuf, &context); for (i = 0, j = 0; i < 16; i++) { saved_auth_str[j++] = hexdigits[outbuf[i] & 0xF]; saved_auth_str[j++] = hexdigits[(outbuf[i] >> 4) & 0xF]; } saved_auth_str[j] = '\0'; MD5Init(&context); MD5Update(&context, saved_auth_str, 16); MD5Final(outbuf, &context); for (i = 0, j = 0; i < 16; i++) Allman,Hansen [Page 8] Internet Draft SMTP Message Tracking Extensions March 10, 2000 { trans_auth_str[j++] = hexdigits[outbuf[i] & 0xF]; trans_auth_str[j++] = hexdigits[(outbuf[i] >> 4) & 0xF]; } trans_auth_str[j] = '\0'; } Allman,Hansen [Page 9]