Internet Draft						       T. Hansen
draft-ietf-msgtrk-model-00.txt			       AT&T Laboratories
Valid for six months						  K. Lin
					   Lotus Development Corporation
						       September 8, 1999



			 Message Tracking Model

		    <draft-ietf-msgtrk-model-00.txt>

			 Authors' version: 1.6

     Status of this Memo

     This document is an Internet-Draft	and is in full conformance  with
all provisions of Section 10 of	RFC2026.

     Internet-Drafts are working documents of the  Internet  Engineering
Task  Force  (IETF), its areas,	and its	working	groups.	 Note that other
groups may also	distribute working documents as	Internet-Drafts.

     Internet-Drafts are draft documents valid	for  a	maximum	 of  six
months	and may	be updated, replaced, or obsoleted by other documents at
any time.  It is  inappropriate	 to  use  Internet-Drafts  as  reference
material or to cite them other than as "work in	progress."

     The  list	of  current   Internet-Drafts	can   be   accessed   at
http://www.ietf.org/ietf/1id-abstracts.txt.

     The list of Internet-Draft	Shadow Directories can	be  accessed  at
http://www.ietf.org/shadow.html.

     This memo and its companions are discussed	on  the	 MSGTRK	 working
group mailing list, ietf-msgtrk[-request]@imc.org.

Copyright Notice

     Copyright (C) The Internet	Society	(1999).	 All Rights Reserved.

Abstract

     Customers buying enterprise message systems often ask: Can	I  track
the messages?  Message tracking	is the ability to find out the path that
a particular message has  taken	 through  a  messaging	system	and  the
current	 routing status	of that	message.  This document	provides a model
of message tracking that can be	used for understanding the Internet-wide



Hansen,Lin						        [Page 1]

Internet Draft		 Message Tracking Model	       September 8, 1999


message	 infrastructure	 and  to  further  enhance those capabilities to
include	message	tracking.

1.  Problem Statement

     Consider sending a	package	through	 a  package  delivery  companys.
Once you've sent a package, you	would like to be able to find out if the
package	has been delivered or  not,  and  if  not,  where  that	 package
currently  is and what its status is.  Note that the status of a package
may not	include	whether	it was delivered to its	addressee, but just  the
destination.   Many  package carriers provide such services today, often
via a web interface.

     Message tracking extends that capability to the Internet-wide  mes-
sage  infrastructure,  analogous to the	service	provided by package car-
riers:	the ability to quickly locate where a message (package)	is,  and
to  determine whether or not the message (package) has been delivered to
its final destination.	An Internet-standard  approach	will  allow  the
development  of	 message  tracking  applications  that	can operate in a
multi-vendor messaging environment, and	will encourage the operation  of
the function across administrative boundaries.

2.  Definitions
The following terms are	relevant to message tracking.  The terms  Track-
ing  User  Agent and Tracking Server are new, while all	other terms have
been collected here from other sources.

     Originating Mail User Agent (MUA)
	       The originating mail user agent is the software	used  to
	       compose and originate a message.	 It is the software sit-
	       ting on a person's desktop.

     Originating Mail Submission Agent (MSA)
	       The Mail	Submission Agent accepts a message from	 a  User
	       Agent,  adds or modifies	whatever headers are appropriate
	       for the message's traversal  through  the  Internet,  and
	       injects	the  message  into  the	 network  via  a Message
	       Transfer	Agent.	(The UA	and MSA	are often combined  into
	       the same	program.)

     Message Transfer Agent (MTA)
	       A Message Transfer Agent	accepts	a message and  moves  it
	       forward towards its destination.	 That destination may be
	       local or	reached	via another MTA.  It  may  use	a  local
	       queue   to  store  the  message	before	transferring  it
	       further.	 Any MTA may generate a	 Non-Delivery  Notifica-
	       tion.




Hansen,Lin						        [Page 2]

Internet Draft		 Message Tracking Model	       September 8, 1999


     Intermediate Message Transfer Agent (MTA)
	       An Intermediate MTA is an MTA that accepts a message  for
	       transfer	somewhere else.

     Final Message Transfer Agent (MTA)
	       A Final MTA is an MTA that accepts a  message  for  local
	       delivery.   It  is  the	final  place  that  a message is
	       accepted.  The final  MTA  is  what  sends  any	Delivery
	       Status Notificatons (DSNs).

     Foreign Message Transfer Agent
	       A foreign MTA provides delivery of messages  using  other
	       protocols than those specified for Internet mail, such as
	       an X.400	mail system.

     Gateway Message Transfer Agent (GW-MTA)
	       A gateway MTA accepts a message for transfer to a foreign
	       MTA outside of the Internet protocol space.

     Local Delivery Agent (DA)
	       The local Delivery Agent	 delivers  the	message	 to  the
	       local  message store.  (The MTA and DA are often	combined
	       into the	same program.)

     Delivery Status Notification (DSN)
	       A Delivery Status Notification [RFC-DSN]	is  produced  by
	       an MTA when a message is	unsuccessfully delivered, either
	       to its next hop or the final message store, or when it is
	       successfully  delivered,	 either	to a foreign MTA or to a
	       local delivery agent.  Positive	notifications  are  only
	       performed [RFC-ESMTP-DSN] when specifically requested.

     Non-Delivery Notification (NDN)
	       A non-delivery notification is  a  special  form	 of  DSN
	       indicating unsuccessful delivery.

     Message Disposition Notification (MDN)
	       A Message Disposition Notification is used to report  the
	       disposition  of	a message after	it has been successfully
	       delivered to a recipient.

     Tracking User Agent (TUA)
	       A tracking user agent wants to find information on a mes-
	       sage  on	 the  behalf  of a user.  It is	the requestor or
	       initiator of such a request.  (The MUA and TUA  could  be
	       combined	into the same program.)

     Tracking Server



Hansen,Lin						        [Page 3]

Internet Draft		 Message Tracking Model	       September 8, 1999


	       A tracking server  provides  tracking  information  to  a
	       tracking	client.	 It is the repository of the information
	       about a message for the traversal  through  a  particular
	       MTA.   (The  tracking  server and MTA may run on	the same
	       system.)

3.  Entities

     The entities  involved  in	 message  tracking  are:   message  user
agents,	 message  submission  agents,  message transfer	agents,	tracking
user agents and	tracking servers.

4.  Interaction	Models

     There are several models by which messages	can be tracked,	 and  by
which information can be requested and gathered.

4.1.  Pre-Hoc Model

     The pre-hoc model,	also known as the "passive or "ask now"	 models,
requires  the  user agent to put into the message envelope an indication
that some form of tracking is to be performed.	The tracking information
can  be	 sent  back  immediately  (as a	form of	telemetry) or stored for
later retrieval.

     Forms of tracking information that	could potentially  be  requested
are  as	 follow.   Note	that mechanisms	already	exist for requesting the
information marked with	a (+).	The references for such	 mechanisms  are
listed at the end of each such entry.

     **	  send a DSN of	a message arriving at an intermediate MTA

     **	  (+) send a DSN of a message being rejected while at an  inter-
	  mediate MTA [RFC-DSN]

     **	  (+) send a DSN of a message leaving an  intermediate	MTA  and
	  going	to another MTA [RFC-DELIVERY-BY]

     **	  send a DSN of	a message arriving at a	final MTA

     **	  (+) send a DSN of a message being rejected while  at	a  final
	  MTA [RFC-DSN]

     **	  (+) send a DSN of a message being delivered to a  user's  mes-
	  sage store [RFC-DSN]

     **	  (+) send a DSN of a message being delivered to a  foreign  MTA
	  [RFC-DSN]



Hansen,Lin						        [Page 4]

Internet Draft		 Message Tracking Model	       September 8, 1999


     **	  (+) send an MDN of a message being read by an	end  user  [RFC-
	  MDN]

     **	  indicate that	logging	of the	message's  traversal  should  be
	  performed for	later retrieval

     **	  indicate that	logging	of the	message's  traversal  should  be
	  sent to a 3rd	party

4.2.  Post-Hoc Model

     The post-hoc model, also known as the "query" or "ask later" model,
requires an active query by a user's user agent	to either the intermedi-
ate MTAs and final MTA,	or to a	 third	party,	to  find  the  message's
status	as  known  by  that MTA.  The responses	might be something like:
the message  has  been	queued	for  later  delivery,  the  message  was
delivered  locally, the	message	was delivered to another MTA, ask a dif-
ferent tracking	server,	I know but can't tell you, or I	don't know.  The
post-hoc  model	 may  or  may not require an earlier pre-hoc declaration
that logging of	the message's traversal	should	occur.	 (Note	that  no
mechanisms currently exist for requesting such information.)

4.3.  Hybrid Models

     A number of hybrid	 models	 exist.	  In  a	 hybrid	 model,	 pre-hoc
mechanisms are combined	with post-hoc mechanisms to provide a total mes-
sage tracking  solution.   The	model  would  include  existing	 pre-hoc
mechanisms,  possible  new  pre-hoc  mechanisms,  and new mechanisms for
post-hoc tracking.  A UA may be	required to start the process by  estab-
lishing	pre-hoc	information which is then communicated with the	MTAs.  A
tracking user agent would then use all possible	information  sources  to
answer the question of "what happened to message XX"?

5.  Security

     The security aspects of message tracking revolve around the follow-
ing areas:

     **	  Who is permitted to request tracking information?

     **	  How does a tracking user agent prove that they  are  permitted
	  to request such information?

     **	  How does the tracking	user agent identify the	 messages  being
	  tracked?






Hansen,Lin						        [Page 5]

Internet Draft		 Message Tracking Model	       September 8, 1999


5.1.  Who is Permitted to Request Tracking Information?

     Only the originators of messages are allowed to  track  their  mes-
sages.	An originator may delegate this	responsibility to a third party.

5.2.  How Does a Tracking User Agent Prove that	They  are  Permitted  to
Request	Such Information?

     One possible mechanism to prove that a tracking request  comes  the
originator  is for the originator to calculate a one-way hash A	from the
message	ID + time stamp	+ a per-user secret.  The user	then  calculates
another	 one-way hash B	to be the hash of A.  The user includes	B in the
submitted message, and retains A.  Later, when the user	makes a	 message
tracking  request to the messaging system or tracking entity, it submits
A in the tracking request.  The	entity receiving  the  tracking	 request
then  uses  A to calculate B, since it was already provided B, verifying
that the requestor is authentic.  In summary,

     A = H(message ID +	time stamp + secret)

     B = H(A)

This is	similar	in technique to	the methods used for One-Time  Passwords
[RFC-OTP].

     If	the originator of a message were to delegate his or her	tracking
request	 to a third party by sending them A, this would	be vulnerable to
snooping over unencrypted sessions.  The user can decide on  a	message-
by-message basis if this risk is acceptable.

5.3.  How does the tracking  user  agent  identify  the	 messages  being
tracked?

     Every  [RFC-822]-compliant	 message  is  supposed	to   contain   a
Message-Id header.  This header	could be used to be the	primary	means of
message	identification.

6.  References


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



Hansen,Lin						        [Page 6]

Internet Draft		 Message Tracking Model	       September 8, 1999


     [RFC-SMTP]Postel, J., "Simple Mail	Transfer Protocol", STD	10,  RFC
	       821, USC/Information Sciences Institute,	August 1982.

     [RFC-822] Crocker,	D., "Standard for the Format  of  ARPA	Internet
	       Text Messages", STD 11, RFC 822,	UDEL, August 1982.

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

     [RFC-DELIVER-BY]
	       Newman, D., "Deliver By SMTP Service  Extension",  draft-
	       newman-deliver-02.txt, Innosoft,	January	1999.

     [RFC-OTP] Haller, N., Metz, C., Nesser, P., Straw,	M., "A	One-Time
	       Password	System", RFC 2289, Bellcore, Kaman Sciences Cor-
	       poration, Nesser	& Nesser Consulting, Bellcore,	February
	       1998.

7.  Acknowledgements

     This document is the product of input from	 many  people  and  many
sources.   It owes much	to earlier work	by Gordon Jones, Bruce Ernst and
Greg Vaudreuil.

8.  Authors' Addresses
     Tony Hansen
     AT&T Laboratories
     Lincroft, NJ 07738
     USA

     Phone: +1 732 576-3207
     E-Mail: tony@att.com

     Ken Lin
     Lotus Development Corporation
     640 Lee Road
     Wayne, PA 19087

     Phone: +1 610 251-3380
     E-Mail: ken_lin@lotus.com

9.  Full Copyright Statement

     Copyright (C) The Internet	Society	(1999).	 All Rights Reserved.

     This document and translations of it may be copied	and furnished to
others,	 and derivative	works that comment on or otherwise explain it or



Hansen,Lin						        [Page 7]

Internet Draft		 Message Tracking Model	       September 8, 1999


assist in its implmentation may	be prepared, copied, published and  dis-
tributed, in whole or in part, without restriction of any kind,	provided
that the above copyright notice	and this paragraph are included	 on  all
such copies and	derivative works.  However, this document itself may not
be modified in any way,	such as	by  removing  the  copyright  notice  or
references  to	the  Internet  Society	or other Internet organisations,
except as needed for the purpose of  developing	 Internet  standards  in
which  case  the procedures for	copyrights defined in the Internet Stan-
dards process must be followed,	or as  required	 to  translate	it  into
languages other	than English.

     The limited permissions granted above are perpetual and will not be
revoked	by the Internet	Society	or its successors or assigns.

     This document and the information contained herein	is  provided  on
an  "AS	 IS" basis and THE INTERNET SOCIETY AND	THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR	IMPLIED,  INCLUDING  BUT
NOT  LIMITED TO	ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS	OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY  OR
FITNESS	FOR A PARTICULAR PURPOSE.

     This document expires March 2000.





























Hansen,Lin						        [Page 8]
