Subject: RE: Proposal for the interactive message tracking protocol

From: "Ward, Jon" <[email-masked]>
Date: Thu, 4 Nov 1999 13:59:13 -0500

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-masked]]
Sent: Thursday, November 04, 1999 10:00 AM
To: [email-masked]
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

---

From: Tony Hansen <[email-masked]>
Date: Fri, 05 Nov 1999 00:35:02 -0500

"Ward, Jon" wrote:
> 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.
>

Jon,

Be sure and re-read the model document: draft-ietf-msgtrk-model-00.txt.
Also re-read the following documents referenced by the model document:

     [RFC-DSN] Moore, K., and G. Vaudreuil, "An	Extensible Message  For-
	       mat for Delivery	Status Notifications", RFC 1894, Univer-
	       sity of Tennessee, Octel	Network	Services, January 1996.

     [RFC-ESMTP-DSN]
	       Moore, K., "SMTP	Service	Extension  for	Delivery  Status
	       Notifications",	RFC 1891, University of	Tennessee, Janu-
	       ary 1996.

     [RFC-MDN] Fajman, R., "An Extensible  Message  Format  for	 Message
	       Disposition Notifications", RFC 2298, National Institutes
	       of Health, March	1998.

Many of your questions and comments are covered by the above references.

	Tony Hansen
	[email-masked]