Proposal for the interactive message tracking protocol

I would like to start discussion on the solution space for message
tracking.  To do this I am going to propose a solution strawman that I
have discussed with a few other design team members (specifically Tony
Hansen and Eric Allman).  There are a number of other possible solution
models and it would be nice to get more of them on the table.

In addition to the requirements defined in the model document, I have
added the following:

1.  MUST be easy to deploy.   The corollary of this is that SHOULD
    maximize reuse of existing, already deployed technology and
    infrastructure.

2.  SHOULD extend existing protocols and not invent new ones.

3.  SHOULD have a low implementation cost.   This makes it easy to
    incorporate into existing products.

As an aside, if people agree that these are a good set of requirements
in general, we should probably add them in a requirements section of the
model document.

Interactive DSN.

This solution fits into the "hybrid model" defined in the model
document.   I propose to add a "MTRK" extension command to SMTP that
requests tracking information for a message from an MTA.  The message is
identified using a unique tracking identifier as described in the model
document.   The tracking agent requesting the tracking information is
authenticated using some form of authenticator, not unlike the example
used in the model document.   The "MTRK" command returns to the tracking
agent the computer parseable part of a DSN with the tracking information
in it, or an error result.   Possible errors would include "no
permission", "never heard of this message", etc.

We will want to extend the number of disposition states in DSN's to
account for "in transit" states that result from interactive tracking.

I haven't thought too much about the syntax of the SMTP request
response.   Didn't feel like it until there was some idea whether the
idea has merit or not.   There might be an issue with handing back
response data like this in SMTP in that it would be somewhat larger than
your average SMTP response.

The things that I like about this solution are:

1.  It leverages the existing support for DSN in tracking software.
    You clearly will want to be able to accept existing DSN information
    in a tracking agent, so using the existing syntax (even slightly
    extended) makes good use of existing implementations (if any).

2.  It would be pretty simple to implement.   It would be a single
    command/response extension using the standard SMTP extension
    framework. 

3.  It talks directly to MTAs which clearly are the source for tracking
    information.

It is my intention to raise this as a potential solution during the
working group meeting in next week.   It would be nice to have some
discussion about it on the list prior to the meeting.

Cheers.
---  
Steve Hole                      
MessagingDirect
Mailto:[email protected] 
Phone: 780-424-4922