INTERNET-DRAFT C. Harrison Intended Category: Standards Track 9th February, 2005 Expires: 10th August, 2005 Reciprocation of SMTP Trace Record draft-harrison-email-tracking-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on 10th August, 2005. Abstract In much the same way one can track a parcel, this document proposes a simple method for returning the trace record of an e-mail to the SMTP originator (sender) as it passes through relays and gateways; passively, without the recipient's intervention. Delays can thus be explained and important e-mails (or paranoid e-mailers) can rest knowing their message has at least arrived at its destination. Much like parcel tracking, this is more of a gimmick than useful! Harrison [Page 1] Internet Draft Reciprocation of SMTP Trace Record February 2005 To break the rules... To Her Royal Highness, Princess Michelle of Choctopia, Duchess-Regent of Fruitopia without whom, none of this would have been possible. ...and keep a promise ;) Harrison [Page 2] Internet Draft Reciprocation of SMTP Trace Record February 2005 Table of Contents 1. Introduction ................................................ 4 2. SMTP Overview ............................................... 4 3. The Tracking Process ........................................ 4 3.1. Requesting Tracking with Mail Headers ..................... 4 3.2. Returning the Data ........................................ 5 3.3. Collation and Parsing ..................................... 5 3.3.1. An Example .............................................. 5 4. Infrastructure .............................................. 5 5. References .................................................. 6 6. Author's Address ............................................ 6 7. Legalese .................................................... 6 Harrison [Page 3] Internet Draft Reciprocation of SMTP Trace Record February 2005 1. Introduction The online tracking of deliveries -- parcels, documents, etc -- has been a service provided by logistics companies for some time. Although largely seen as an executive toy, one is led to believe that it must serve some purpose for UPS, FedEx and the like to go to the trouble! Although e-mails can be sent to their destinations in moments, this tracking facility can be applied to the SMTP (simple mail transfer protocol) process analogously. In fact, an e-mail's route is already recorded; but this data is never (automatically) reciprocated to the originator. Often, e-mails aren't sent instantaneously; they are delayed along the line for whatever reason. Furthermore, when an e-mail reaches the final recipient, there's no way of telling that it has! Save a return receipt, that is at the recipient's discretion, one is left in the dark! This method allows the SMTP originator (the sender of the e-mail) to track his or her message across the ether, unobtrusively. 2. SMTP Overview We give a synopsis of the SMTP process, to help illustrate this tracking method more clearly. The e-mail originator initiates communication with an SMTP server (the SMTP delivery), which starts the e-mail's journey to its final destination. The e-mail passes through several (maybe none) relays (or gateways, if the transmission environment changes); whereby previous relays (the delivery server can be thought of as the first relay) echo the message to each other. These relays are chosen by the DNS Mail eXchanger mechanism, whose address is stored in the e-mail's trace record. Herein lies our tracking data. This is currently used to produce the reverse path (i.e. back to the originator) in the case of an e-mail being undeliverable. 3. The Tracking Process 3.1. Requesting Tracking with Mail Headers First of all, the originator's permission to reciprocate tracking data is required; rather than performing the operation ubiquitously. In the same way a return receipt is requested, an e-mail header is used to specify that the e-mail is to be tracked. In this way, the final recipient is also privy to this tracking process taking place (whether he or she likes it or not!). Harrison [Page 4] Internet Draft Reciprocation of SMTP Trace Record February 2005 The header will be "Content-Track"; taking a parameter given by the originator's local mail client software. This parameter would consist of some kind of unique key or signature for the e-mail in question. How it is defined is up to software vendors, but is arbitrary (e.g. MD5 hash of e-mail body, etc.). 3.2. Returning the Data If the Content-Track header is detected whilst relays are echoing data, the tracking data (that is, the e-mail's trace record, after it has been amended by the current relay) is sent back to the originator. This is done by following the reverse path, as when an e-mail is rendered undeliverable. What is returned is a very simple e-mail; again, similar to that returned by a return receipt. The subject of this e-mail will be "TRACK: " followed by the parameter given by the Content-Track header. The body of the e-mail will be the tracked e-mail's complete trace record. 3.3. Collation and Parsing As a tracked e-mail passes through relays, the originator will receive a tracking report from each compatible server. It is up to the originator's local mail client software to both collate these data as they come and to parse them on request. 3.3.1. An Example For example, each incoming tracking report could be hidden from the user and the details appended to the appropriate tracked e-mail's record; however that may work is the software's concern. On inspecting said e-mail, the user (i.e. the originator) would be shown the parsed trace record. For instance, with geographic IP mapping (which works reasonably well), a map could be shown displaying the e-mail's route. Furthermore, if a return receipt was also requested, this could be incorporated into how any software displays tracking data... Now wouldn't that be cool? 4. Infrastructure The purpose of using a mail header to initiate tracking provides backward compatibility. That is, older server software in relays, not accustomed to this, will just see it as another bit of data to be echoed. This means that, as relays' software is upgraded, more and more tracking reports will be returned. This also enables client software to be developed immediately to take advantage of this mechanism, even though it is not in place. Harrison [Page 5] Internet Draft Reciprocation of SMTP Trace Record February 2005 Of course, the change to relay software is what is most important. The ability to send a return following an e-mail's reverse path is already in place, it just needs adaptation. There is, however, the issue of detecting the Content-Track header. Although it would be a trivial operation, it would mean that an e-mail would, technically, have to be analysed by a third-party. Although it's only checking for a string match within the e-mail's header, and it's a completely autonomous process, this may be seen as a breach of privacy/security. Moreover, even though the returned tracking report is of very small size (a few hundred bytes, at most); proliferation would induce an increased bandwidth cost. 5. References RFC 2821 Simple Mail Transfer Protocol 6. Author's Address Christopher Harrison Comments@Prof.ChrisHarrison.co.uk 7. Legalese Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. UPS is copyright (C) 1994-2005 United Parcel Service of America, Inc. FedEx is copyright (C) 1995-2005 FedEx. Harrison [Page 6]