RE: Proposal for the interactive message tracking protocol

Have we thought about the desired use and potential use of this?  Depending
upon the results desired, we may need to approach the design from different
angles.

A few possible features come to mind.  We may want to realize a standardized
Receipt Notification that will allow users to send a message and request the
receipt notification.  We may want to have the Read Notification.  Other
things like this would happen almost entirely at the Application layer.
This could be done without modifying the function of SMTP.  If we want, for
example, to be able to troubleshoot an undelivered message by requesting
information from each SMTP relay along the path, we may need to implement
some sort of tracking log on each relay so that it can provide this
information upon request.  In any case, there must be some way to uniquely
identify each message.  This identifier may need to be the same across
different boundaries of management responsibility.

I am very much in favor of the message tracking concept.

Do we have a scope of requirements or even a wish-list?  Would we be the
ones to brainstorm about this list?

Jon Ward


-----Original Message-----
From: Tomorrow SystemsInc [mailto:[email protected]]
Sent: Thursday, November 04, 1999 10:00 AM
To: [email protected]
Subject: Re: Proposal for the interactive message tracking protocol


I think this idea is a good one. In order to trace the
complete path of a message, a "management station"
will go from MTA to MTA to MTA, piecing the
information together as it goes. This is a lot like
the model for classic network management, where each
"agent" is independent and aggregate staticstics about
the network must be deduced from information returned
from multiple agents.

As far as the following goes:

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

At what point does this apply ? Do you mean during the
setup phase of an SMTP session  only ?  MTAs pass some
very large messages, so the overhead of the message
tracking response is probably about the same as a
message unless there is a protocol-specific state
where MTAs traditionally don't want to see a "larger
than average SMTP response" as you describe above.
Otherwise, what is the anticipated ratio of message
tracking requests versus normal message traffic ?  Is
there a class of user who will want to saturate and
MTA with message tracking requests ?


Gordon


=====
Gordon Jones
Tomorrow Systems Incorporated
Internet Consulting - Internet Software
http://www.tomorrowsys.com
(703) 309 - 8859
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com