Fwd: thoughts on message tracking models

This message from Tony Hansen nicely summarizes some of the hallway 
discussion in Minneapolis.   Note that the conversation resulted from 
queries at the general apps area meeting about the status of message 
tracking, where it was going etc.   There are many participants who were 
not present and this certainly goes over some things that have been 
discussed already (presumably).

I would like to take the approach that we are hitting the "reset" button 
on the working group.   As such, this and the draft serve as a basis point
for discussion on the model.  If we find that we have good concensus on 
the model, then this should go quickly.   As I don't have good evidence 
either way, I'll presume that we need to review everything and make sure 
that we are in good standing before moving on.

I'll post my own thoughts on this later this evening.

Cheers.

--- Begin Forwarded Message ---

Date: Wed, 17 Mar 1999 22:40:22 -0500
From: Tony Hansen <[email protected]>
Subject: thoughts on message tracking models
Sender: Tony Hansen <[email protected]>
To: [email protected], [email protected]
Reply-To: Tony Hansen <[email protected]>
Message-ID: <[email protected]>


I wanted to capture some of our conversations regarding message tracking
and subsequent thoughts I've had on the topic. This can probably form
the genesis of a model document.

				Message Tracking Models

There are a number of dimensions across which the message tracking
solution space can be split:

How is message tracking enabled?

	Tracking is automatically done for all messages using information
extracted from the message header and body.

	A request to enable tracking is carried within the envelope, e.g., an
ESMTP extension request would indicate that tracking should occur.

	A request to enable tracking is carried within the message, e.g., a
special header.

How is the information gathered?

	The information is sent back to the user, e.g., using email messages
similar to DSNs and MDNs.

	The information is transmitted by each MTA to a third party (identified
somehow) using some sort of protocol.

	The information is kept locally to each MTA server or set of servers.

What message transitions will cause message tracking to be declared
finished?

	Deposit into a mailbox.

	Crossing a firewall?

	Forwarded by an MTA as specified by a user?

	Forwarded by a sieve filter?

	Sent on by a reflector list exploder?

	Sent on by a mailing list exploder?

How is information gathered by a tracking client?

	In the case of DSN/MDN-like messages being sent back to the user, it's
automatic.

	An ESMTP extension would provide a new verb to query message tracking
instead of sending a new message.

	A new TCP protocol would provide a way of querying message tracking.

	A new UDP protocol would provide a way of querying message tracking.

How are hops from one machine to another handled?

	The server on one machine queries the next machine in the list before
returning info. (forwarding)

	The server provides information on the next machine and the tracking
client queries the next machine. (referral)

What format should the information be provided in?

	key: value

	DSN

	XML

Is information from DSNs and MDNs merged in with tracking information by
the tracking client?

What information is reported?

	time of entry

	time of delivery

	time (queued for exit | exited)

	time (queued for exit | exited to tracking host | exited to
non-tracking host)

	system exited to

Are MX names or A names recorded?

How is authentication of a tracking requester done?

	various token exchange / validation schemes exist
--- End Forwarded Message ---


---  
Steve Hole                           
Execmail Inc.
Mailto:[email protected] 
Phone: 780-424-4922