Re: Proposal for the interactive message tracking protocol

Steve Hole wrote:
> 
> 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.

Sounds reasonable.

> 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.

The above is concentrating on the aspect of finding out the status of a
message. We also need to design how to designate that a message is to be
tracked and how to identify that message for later queries.

> 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.

I agree that discussion on this aspect can be held off until later.

> 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.

I'm looking forward to it.

	Tony Hansen
	[email protected]