MSGTRK BOF G. Jones [TomorrowSys@yahoo.com] INTERNET-DRAFT B. Ernst [bruce_ernst@lotus.ssw.com] draft-jones-msgtrk-def-01.txt G. Vaudreuil [gregv@ons.octel.com] Expires: September 1999 Basic Definition of Message Tracking Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu(US West Coast). Abstract This document defines message tracking as a prelude to the creation of a message tracking model. Message tracking is a messaging management function; it provides the ability to find out, after the fact, the path that a particular message took through the messaging system, the current status of that message, and its characteristics. Definition Message tracking refers, in its simplest form, to determining the path an RFC822 message has taken, its current location, and its characteristics. Message tracking allows the originator of a message to issue a request about a previously sent message, the answer to which contains the delivery status, delivery time, delivered recipients, and other information about the message. This is different from the delivery status notification (DSN) function in use today, because DSNs are requested at the time of submission and are generated automatically; alternatively a tracking request is generated independently of the previously submitted message's status and is done so on demand. This capability is analogous to the service provided by carriers of conventional paper mail - the ability to quickly locate where a package is, and to determine whether or not the package has been delivered to its destination. An Internet-standard approach will allow development of message tracking applications that can operate in a multi-vendor messaging environment, and will encourage operation of the function across administrative boundaries. One might ask: why should there be a standard for message tracking when Internet domains will be unwilling to open themselves up to outside tracking requests ? This is one reason why we design and implement Internet standards. So that there is a reliable, secure, agreed upon mechanism for message tracking that people will be willing to use. Companies have implemented and are implementing message tracking today. Standardization of this technique will aid the Internet user community, make Internet messaging more profitable, and fulfill a key messaging management need. Reasons for Message Tracking Message tracking is useful for determining the whereabouts and status of "lost" messages, and for several other purposes: o When there is a lack of trust in the messaging system, such as when an originator claims a message failed to be delivered, the point of failure may be isolated. This includes messages that were never delivered or messages that were delivered incorrectly. Message tracking thus adds to the overall reliability of the mail system; o Per-message information can be used for accounting, billing, and performance purposes. Traffic can be itemized on a per-origin or per- destination basis by system or originator. This typically involves two steps - collection of message traffic data, followed by the gehe time they are submitted to an MTA up until the time a network of MTAs discharges the message onward to another entity (e.g. a proprietary mail server, IMAP server, and so on). o Message tracking information adds security in that the origins of potential security threats can be more precisely determined. If a system were flooded with traffic, for instance, the origin of this traffic would become known. Message tracking information is suitable for routine security audits containing the details of messaging traffic over specific time intervals; o End-to-end delivery time could be measured; o Message tracking would aid in message loop detection, since unique message identifiers of looping messages, when these exist, would be recorded multiple times; o Performance characteristics about the type of messaging traffic could be determined, such as when an inbound message causes the creation of multiple outbound messages, and the percentage of messages that were actually delivery reports or receipts. This is valuable for performance measurement, among other reasons; o Standardized message tracking information acts as a bridge between dissimilar messaging systems and dissimilar messaging communities; Tracking Messages on the Public Internet One might ask: why bother to track messages if a majority of public Internet traffic is point to point; messages don't live long enough to be trackable, and are not an interesting event to track since you always know the next point ? Just because you know where a message went that doesn't mean you know what happened to it, how fast it got there, or what was in it. As the Internet is used more and more for commercial/official purposes a logging function is commonly embedded in the messaging system internally. Even if most of the message traffic is point to point, this point-to-point traffic is inter-domain, across firewalls, and thus it is even more important to have a reliable tracking mechanism that organizations can agree on. It is something that intra-domain messaging users want. Even if 95% of transactions are point to point, the 5% that is non point-to-point is still a huge amount of traffic, and this is exactly the traffic that users will want to track. Once messaging traffic enters an intranet or domain of any size it invariably encounters a more hierarchical routing structure. Who is Allowed to Track Messages Only the originators of messages are allowed to track their messages. Optionally, an originator may delegate this responsibility to a third party, but this is left for future study. How Tracking is Done: Requests and Responses The originator will issue a message tracking request using the Unique Message Identifier plus security information. The originator (of both the message and the query at this point) will receive optional response criteria such as the message disposition, delivered recipients, delivery time, and the names of MTAs that handled the message. Security for Message Originators One option for message security is that the originator calculates a hash A to be equal to the hash of the message ID + time stamp + a per-user secret. The user then calculates hash B to be the hash of A. The user includes B in the submitted message, and retains A. Later, when the user makes a message tracking request to the messaging system or tracking entity, it submits A in the racking request. The entity receiving the tracking request then uses A to calculate B, since it was already provided B, verifying that the requestor is authentic. Summarily A = H(message ID + time stamp + secret) B = H(A) If the originator of a message were to delegate his or her tracking request to a third party by sending them A, this would be vulnerable to snooping over unencrypted sessions, but the user can decide on a message-by-message basis if this risk is acceptable. Three Possible Architectures There are ways of accomplishing message tracking without mandating the addition of large amounts of new infrastructure on the participants. Optionally, if more infrastructure is proven to be a good and necessary thing, it should be considered. In all cases, messages are only tracked from the time they are submitted to an MTA up until the time a network of MTAs discharges the message onward to another entity (e.g. a proprietary mail server, IMAP server, and so on). The three architectural alternatives offered by the start-up working group to date might be called "ask later", "ask now", and "ask someone else." Under "ask later", a user requests tracking as a service when submitting a message, and then at a later time issues a separate tracking request to the mail system. The user receives a response to the request from the tracking entity. This has the advantage of being deployable within the existing SMTP infrastructure. Under "ask now", a user requests tracking as a service while submitting a message, and receives a step-by-step report contemporaneously from each MTA that handles the message. This provides the user with a high level of service, but also causes extra overhead: an additional message generated for each hop the original message takes. Under "ask someone else", the user issues a separate message tracking request to an entity other than the messaging system at a later time. The user receives a response to the request from this same third-party tracking entity. This has the advantage of allowing tracking to occur when the messaging process has failed but the platform is still working. It also off-loads the tracking function from the messaging system itself. It may, however, require new infrastructure in order to support it. One possibility would be to implement "ask now" and "ask later" as SMTP extensions. One could implement "ask someone else" as a UDP- or TCP-based protocol, among other options. Acknowledgments Thanks to all those who participated in the message tracking meetings. Many thanks to Ned Freed and Harald Alvesrand for the hashing material. Internet Draft Expires September 1999 Internet Draft