Internet DRAFT - draft-harrison-email-tracking
draft-harrison-email-tracking
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]
