msgtrk

9 files changed, 4248 insertions, 0 deletions

diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-model-00.txt b/Documentation/en/I-D/draft-ietf-msgtrk-model-00.txt
new file mode 100644
index 00000000..7a8b3285
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-model-00.txt
@@ -0,0 +1,444 @@
+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]
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-model-01.txt b/Documentation/en/I-D/draft-ietf-msgtrk-model-01.txt
new file mode 100644
index 00000000..c7c32d24
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-model-01.txt
@@ -0,0 +1,562 @@
+
+
+
+
+
+
+Internet Draft						       T. Hansen
+draft-ietf-msgtrk-model-01.txt			       AT&T Laboratories
+Valid for six months						  K. Lin
+					   Lotus Development Corporation
+							  March	10, 2000
+
+
+
+		Message	Tracking Model and Requirements
+
+		    <draft-ietf-msgtrk-model-01.txt>
+
+			 Authors' version: 1.11
+
+     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 and Requirements	  March	10, 2000
+
+
+message	infrastructure and to further enhance those capabilities to
+include	message	tracking, as well as requirements for proposed message
+tracking solutions.
+
+1.  Problem Statement
+
+     Consider sending a	package	through	a package delivery company.
+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.
+
+     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT",	"RECOMMENDED",	"MAY", and "OPTIONAL" in this
+document are to	be interpreted as described in RFC 2119	[RFC-KEYWORDS].
+
+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
+
+
+
+Hansen,Lin						        [Page 2]
+
+Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
+
+
+	       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.
+
+     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
+
+
+
+Hansen,Lin						        [Page 3]
+
+Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
+
+
+	       message 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
+	       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.  Requirements
+
+     These are requirements that any message tracking solution must be
+able to	satisfy:
+
+     The message tracking solution:
+
+     **	  MUST scale to	the internet.
+
+     **	  MUST be easy to deploy.
+
+     **	  SHOULD maximize the reuse of existing, already deployed tech-
+	  nology and infrastructure.
+
+     **	  SHOULD extend	existing protocols and not invent new ones.
+
+     **	  SHOULD have a	low implementation cost.  (This	makes it easy to
+	  incorporate into existing products.)
+
+     **	  MUST restrict	tracking of a message to the originator	of the
+	  message (or a	delegate).
+
+     **	  MUST be able to do authentication.
+
+     **	  MAY allow an originator to delegate this responsibility to a
+	  third	party.
+
+     **	  SHOULD have the property that	they would allow per-message
+	  delegation of	the tracking responsibility.
+
+     **	  MUST require a tracking user agent to	prove that they	are
+
+
+
+Hansen,Lin						        [Page 4]
+
+Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
+
+
+	  permitted to request the tracking information.
+
+     **	  MUST be able to uniquely identify messages.
+
+     **	  MUST require every message to	have unique identification.
+
+5.  Interaction	Models
+
+     There are several models by which tracking	of messages can	be
+enabled, by which messages can be tracked, and by which	information can
+be requested and gathered.
+
+5.1.  Tracking Enabling	Models
+
+     Either the	envelope or message header must	contain	enough informa-
+tion to	track a	message	and securely retrieve information about	the mes-
+sage.  Any message that	does have enough information to	track it is by
+definition not trackable.
+
+     If	there is not enough information	available in current standard
+envelopes or message headers, then the current standards will need to be
+extended.  Either the MUA or MSA must determine	the additional informa-
+tion and enable	the tracking by	adding the additional information to
+either the envelope or header.
+
+     This leads	to two tracking	enabling models:  passive enabling and
+active enabling.
+
+5.1.1.	Passive	Enabling Model
+The "passive enabling" model assumes that there	is sufficient informa-
+tion available.	 No UA or MSA interaction occurs to turn tracking on; it
+is on by default.
+
+5.1.2.	Active Enabling	Model
+
+     The "active  enabling" model requires that	the MUA	and MSA	exchange
+information when the message is	submitted.  This exchange indicates that
+logging	of the message's traversal should be performed,	as well	as pro-
+viding enough additional information to	allow the message to be	tracked.
+This information will need to be passed	on to subsequent MTAs as needed.
+
+5.2.  Tracking Request Models
+There are several models by which tracking information may be requested.
+
+5.2.1.	Passive	Request	Model
+
+     The "passive request" model requires active enabling to indicate
+that some form of tracking is to be performed.	The tracking information
+
+
+
+Hansen,Lin						        [Page 5]
+
+Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
+
+
+can be sent back immediately (as a form	of telemetry) or sent to a 3rd
+party for later	retrieval.
+
+5.2.2.	Passive	Request	Tracking Information
+
+     Forms of passive tracking information that	could potentially be
+requested are  as  follows.  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-DELIVER-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]
+
+     **	  (+) send an MDN of a message being read by an	end user [RFC-
+	  MDN]
+
+5.3.  Active Request Model
+
+     The "active request" model	requires an active query by a user's
+user agent to either the intermediate MTAs and final MTA, or to	a third
+party, to find the message's status as known by	that MTA.  Active
+request	will work with either passive enabling or active enabling.
+
+5.3.1.	Server Chaining	vs. Server Referrals
+When a tracking	server has been	asked for tracking information,	and the
+message	has been passed	on to another MTA of which this	tracking server
+has no tracking	knowledge, there are two modelling choices:
+
+     **	  the first tracking server will contact the next tracking
+	  server to query for status and pass back the combined	status
+	  (server chaining), or
+
+
+
+
+Hansen,Lin						        [Page 6]
+
+Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
+
+
+     **	  the first tracking server will return	the address of the next
+	  MTA and the tracking client has the responsibility of	contact-
+	  ing the next tracking	server (server referrals).
+
+5.3.2.	Active Request Tracking	Information
+Forms of active	tracking information that could	potentially be requested
+are as follows.	 (Note that no mechanisms currently exist for requesting
+such information.)
+
+     **	  the message has been queued for later	delivery
+
+     **	  the message was delivered locally
+
+     **	  the message was delivered to another MTA,
+
+     **	  the message was delivered to a foreign MTA
+
+     **	  ask a	different tracking server,
+
+     **	  I know but can't tell	you,
+
+     **	  I don't know.
+
+5.4.  Combining	DSN and	MDN Information	with Message Tracking Informa-
+tion
+
+     The information that would	be retrieved by	message	tracking and the
+information that is returned for DSN and MDN requests all attempt to
+answer the question of "what happened to message XX"?  The information
+provided by each is complementary in nature, but similar.  A tracking
+user agent could use all three possible	information  sources  to present
+a total	view of	the status of a	message.
+
+     Both DSN and MDN notifications utilize the	formats	defined	by RFC
+1892 [RFC-REPORT].  This suggests that the information returned	by mes-
+sage tracking solutions	should also be similar.
+
+6.  Security
+
+     This is a security	model for message identification and authentica-
+tion that could	be deployed.  (There may be others.)
+
+     A Tracking	User Agent must	prove that they	are permitted to request
+tracking information about a message.  Every [RFC-822]-compliant message
+is supposed to contain a Message-Id header.  One possible mechanism 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
+
+
+
+Hansen,Lin						        [Page 7]
+
+Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
+
+
+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)
+
+Another	possible mechanism for A is to ignore the message ID and time
+stamp and just use a one-way hash from a large (>128 bits) random
+number.	 B would be calculated as before.  In summary,
+
+     A = H(large-random-number)
+
+     B = H(A)
+
+This is	similar	in technique to	the methods used for One-Time Passwords
+[RFC-OTP].  The	success	of these techniques is dependent on the	random-
+ness of	the per-user secret or the large random	number,	which can be
+incredibly difficult in	some environments.
+
+     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.
+
+7.  References
+
+
+     [RFC-822] Crocker,	D., "Standard for the Format of	ARPA Internet
+	       Text Messages", STD 11, RFC 822,	UDEL, August 1982.
+
+     [RFC-DELIVER-BY]
+	       Newman, D., "Deliver By SMTP Service Extension",	draft-
+	       newman-deliver-02.txt, Innosoft,	January	1999.
+
+     [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-KEYWORDS]
+
+
+
+Hansen,Lin						        [Page 8]
+
+Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
+
+
+	       Bradner,	S., "Key words for use in RFCs to Indicate
+	       Requirement Levels", RFC	2119, Harvard University, March
+	       1997.
+
+     [RFC-MDN] Fajman, R., "An Extensible Message Format for Message
+	       Disposition Notifications", RFC 2298, National Institutes
+	       of Health, March	1998.
+
+     [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.
+
+     [RFC-REPORT]
+	       Vaudreuil, G., "The Multipart/Report Content Type for the
+	       Reporting of Mail System	Administrative Messages", RFC
+	       1892, Octel Network Services, January 1996.
+
+     [RFC-SMTP]Postel, J., "Simple Mail	Transfer Protocol", STD	10, RFC
+	       821, USC/Information Sciences Institute,	August 1982.
+
+8.  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.
+
+9.  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
+
+10.  Full Copyright Statement
+
+     Copyright (C) The Internet	Society	(1999).	 All Rights Reserved.
+
+
+
+
+Hansen,Lin						        [Page 9]
+
+Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
+
+
+     This document and translations of it may be copied	and furnished to
+others,	and derivative works that comment on or	otherwise explain it or
+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 September 10, 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen,Lin					               [Page 10]
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-model-02.txt b/Documentation/en/I-D/draft-ietf-msgtrk-model-02.txt
new file mode 100644
index 00000000..9f928637
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-model-02.txt
@@ -0,0 +1,556 @@
+Internet Draft                                                 T. Hansen
+draft-ietf-msgtrk-model-02.txt                         AT&T Laboratories
+Valid for six months                                              K. Lin
+                                           Lotus Development Corporation
+                                                           July 14, 2000
+
+
+
+                Message Tracking Model and Requirements
+
+                    <draft-ietf-msgtrk-model-02.txt>
+
+                         Authors' version: 1.12
+
+     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@imc.org.  To subscribe, send a message
+with the word "subscribe" in the body (on a line by itself) to the
+address ietf-msgtrk-request@imc.org.  An archive of the mailing list may
+be found at http://www.ietf.org/archive/msgtrk.
+
+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
+
+
+
+Hansen,Lin                                                      [Page 1]
+
+Internet Draft  Message Tracking Model and Requirements    July 14, 2000
+
+
+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
+message infrastructure and to further enhance those capabilities to
+include message tracking, as well as requirements for proposed message
+tracking solutions.
+
+1.  Problem Statement
+
+     Consider sending a package through a package delivery company.
+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.
+
+     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in RFC 2119 [RFC-KEYWORDS].
+
+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.  An MSA is used, in lieu of the first MTA
+               by MUA's that do not create fully-compliant Internet mes-
+               sages, to submit messages into the SMTP delivery network.
+
+
+
+Hansen,Lin                                                      [Page 2]
+
+Internet Draft  Message Tracking Model and Requirements    July 14, 2000
+
+
+     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.
+
+     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).  (Intermediate MTA's may also
+               send a DSN if it relays to a non-DSN aware MTA.)
+
+     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, to a
+               local delivery agent, or a non-DSN aware MTA.  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
+
+
+
+Hansen,Lin                                                      [Page 3]
+
+Internet Draft  Message Tracking Model and Requirements    July 14, 2000
+
+
+               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
+               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.  Requirements
+
+     These are requirements that any message tracking solution must be
+able to satisfy:
+
+     The message tracking solution:
+
+     **   MUST scale to the internet.
+
+     **   MUST be easy to deploy.
+
+     **   SHOULD maximize the reuse of existing, already deployed tech-
+          nology and infrastructure.
+
+     **   SHOULD extend existing protocols and not invent new ones.
+
+     **   SHOULD have a low implementation cost.  (This makes it easy to
+          incorporate into existing products.)
+
+     **   MUST restrict tracking of a message to the originator of the
+          message (or a delegate).
+
+     **   MUST be able to do authentication.
+
+     **   MAY allow an originator to delegate this responsibility to a
+          third party.
+
+
+
+Hansen,Lin                                                      [Page 4]
+
+Internet Draft  Message Tracking Model and Requirements    July 14, 2000
+
+
+     **   SHOULD have the property that they would allow per-message
+          delegation of the tracking responsibility.
+
+     **   MUST require a tracking user agent to prove that they are per-
+          mitted to request the tracking information.
+
+     **   MUST be able to uniquely identify messages.
+
+     **   MUST require every message to have unique identification.
+
+5.  Interaction Models
+
+     There are several models by which tracking of messages can be
+enabled, by which messages can be tracked, and by which information can
+be requested and gathered.
+
+5.1.  Tracking Enabling Models
+
+     Either the envelope or message header must contain enough informa-
+tion to track a message and securely retrieve information about the mes-
+sage.  Any message that does not have enough information to track it is
+by definition not trackable.
+
+     If there is not enough information available in current standard
+envelopes or message headers, then the current standards will need to be
+extended.  Either the MUA or MSA must determine the additional informa-
+tion and enable the tracking by adding the additional information to
+either the envelope or header.
+
+     This leads to two tracking enabling models:  passive enabling and
+active enabling.
+
+5.1.1.  Passive Enabling Model
+The "passive enabling" model assumes that there is sufficient informa-
+tion available.  No UA or MSA interaction occurs to turn tracking on; it
+is on by default.
+
+5.1.2.  Active Enabling Model
+
+     The "active  enabling" model requires that the MUA and MSA exchange
+information when the message is submitted.  This exchange indicates that
+logging of the message's traversal should be performed, as well as pro-
+viding enough additional information to allow the message to be tracked.
+This information will need to be passed on to subsequent MTAs as needed.
+
+5.2.  Tracking Request Models
+There are several models by which tracking information may be requested.
+
+
+
+
+Hansen,Lin                                                      [Page 5]
+
+Internet Draft  Message Tracking Model and Requirements    July 14, 2000
+
+
+5.2.1.  Passive Request Model
+
+     The "passive request" model requires active enabling to indicate
+that some form of tracking is to be performed.  The tracking information
+can be sent back immediately (as a form of telemetry) or sent to a 3rd
+party for later retrieval.
+
+5.2.2.  Passive Request Tracking Information
+
+     Forms of passive tracking information that could potentially be
+requested are  as  follows.  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-DELIVER-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]
+
+     **   (+) send an MDN of a message being read by an end user [RFC-
+          MDN]
+
+5.3.  Active Request Model
+
+     The "active request" model requires an active query by a user's
+user agent to the MSA, intermediate MTAs and final MTA, or to a third
+party, to find the message's status as known by that MTA.  Active
+request will work with either passive enabling or active enabling.
+
+5.3.1.  Server Chaining vs. Server Referrals
+When a tracking server has been asked for tracking information, and the
+message has been passed on to another MTA of which this tracking server
+has no tracking knowledge, there are two modelling choices:
+
+
+
+
+Hansen,Lin                                                      [Page 6]
+
+Internet Draft  Message Tracking Model and Requirements    July 14, 2000
+
+
+     **   the first tracking server will contact the next tracking
+          server to query for status and pass back the combined status
+          (server chaining), or
+
+     **   the first tracking server will return the address of the next
+          MTA and the tracking client has the responsibility of contact-
+          ing the next tracking server (server referrals).
+
+5.3.2.  Active Request Tracking Information
+Forms of active tracking information that could potentially be requested
+are as follows.  (Note that no mechanisms currently exist for requesting
+such information.)
+
+     **   the message has been queued for later delivery
+
+     **   the message was delivered locally
+
+     **   the message was delivered to another MTA,
+
+     **   the message was delivered to a foreign MTA
+
+     **   ask a different tracking server,
+
+     **   I know but can't tell you,
+
+     **   I don't know.
+
+5.4.  Combining DSN and MDN Information with Message Tracking Informa-
+tion
+
+     The information that would be retrieved by message tracking and the
+information that is returned for DSN and MDN requests all attempt to
+answer the question of "what happened to message XX"?  The information
+provided by each is complementary in nature, but similar.  A tracking
+user agent could use all three possible information  sources  to present
+a total view of the status of a message.
+
+     Both DSN and MDN notifications utilize the formats defined by RFC
+1892 [RFC-REPORT].  This suggests that the information returned by mes-
+sage tracking solutions should also be similar.
+
+6.  Security
+
+     This is a security model for message identification and authentica-
+tion that could be deployed.  (There may be others.)
+
+     A Tracking User Agent must prove that they are permitted to request
+tracking information about a message.  Every [RFC-822]-compliant message
+
+
+
+Hansen,Lin                                                      [Page 7]
+
+Internet Draft  Message Tracking Model and Requirements    July 14, 2000
+
+
+is supposed to contain a Message-Id header.  One possible mechanism 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)
+
+Another possible mechanism for A is to ignore the message ID and time
+stamp and just use a one-way hash from a large (>128 bits) random
+number.  B would be calculated as before.  In summary,
+
+     A = H(large-random-number)
+
+     B = H(A)
+
+This is similar in technique to the methods used for One-Time Passwords
+[RFC-OTP].  The success of these techniques is dependent on the random-
+ness of the per-user secret or the large random number, which can be
+incredibly difficult in some environments.
+
+     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.
+
+7.  References
+
+
+     [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
+               Text Messages", STD 11, RFC 822, UDEL, August 1982.
+
+     [RFC-DELIVER-BY]
+               Newman, D., "Deliver By SMTP Service Extension", draft-
+               newman-deliver-02.txt, Innosoft, January 1999.
+
+     [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
+
+
+
+Hansen,Lin                                                      [Page 8]
+
+Internet Draft  Message Tracking Model and Requirements    July 14, 2000
+
+
+               Notifications", RFC 1891, University of Tennessee, Janu-
+               ary 1996.
+
+     [RFC-KEYWORDS]
+               Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", RFC 2119, Harvard University, March
+               1997.
+
+     [RFC-MDN] Fajman, R., "An Extensible Message Format for Message
+               Disposition Notifications", RFC 2298, National Institutes
+               of Health, March 1998.
+
+     [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.
+
+     [RFC-REPORT]
+               Vaudreuil, G., "The Multipart/Report Content Type for the
+               Reporting of Mail System Administrative Messages", RFC
+               1892, Octel Network Services, January 1996.
+
+     [RFC-SMTP]Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+               821, USC/Information Sciences Institute, August 1982.
+
+8.  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.
+
+9.  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
+
+
+
+
+Hansen,Lin                                                      [Page 9]
+
+Internet Draft  Message Tracking Model and Requirements    July 14, 2000
+
+
+10.  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
+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 January 14, 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen,Lin                                                     [Page 10]
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-00.txt b/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-00.txt
new file mode 100644
index 00000000..f7f485a1
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-00.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Draft                                                 T. Hansen
+draft-ietf-msgtrk-mtqp-00.txt                          AT&T Laboratories
+Valid for six months
+                                                            July 1, 2000
+
+
+
+                    Message Tracking Query Protocol
+
+                    <draft-ietf-msgtrk-mtqp-00.txt>
+
+                         Authors' version: 1.3
+
+     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@imc.org.  To subscribe, send a message
+with the word "subscribe" in the body (on a line by itself) to the
+address ietf-msgtrk-request@imc.org.  An archive of the mailing list may
+be found at http://www.ietf.org/archive/msgtrk.
+
+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
+
+
+
+Hansen,Allman                                                   [Page 1]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2000
+
+
+current routing status of that message.  This document describes the
+Message Tracking Query Protocol that is used in conjunction with exten-
+sions to the ESMTP protocol to provide a complete message tracking solu-
+tion for the Internet.
+
+     NOTE: This is a straw proposal for the Message Tracking Query Pro-
+tocol.
+
+1.  Introduction
+
+     The Message Tracking Models and Requirements document [RFC-TRACK-
+MODEL] discusses the models that message tracking solutions could fol-
+low, along with requirements for a message tracking solution that can be
+used with the Internet-wide message infrastructure.  This memo and its
+companions, [RFC-TRACK-ESMTP] and [RFC-TRACK-TSN], describe a complete
+message tracking solution that satisfies those requirements.  The memo
+[RFC-TRACK-ESMTP] defines an extension to the SMTP service that provides
+the information necessary to track messages.  This memo defines a proto-
+col that can be used to query the status of messages that have been
+transmitted on the Internet via SMTP.  The memo [RFC-TRACK-TSN]
+describes the message/tracking-status MIME media type that is used to
+report tracking status information.  Using the model document's termi-
+nology, this solution uses active enabling and active requests with both
+request and chaining referrals.
+
+1.1.  Terminology
+
+     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in [RFC-KEYWORDS].
+
+     All syntax descriptions use the ABNF specified by [RFC-ABNF].
+Unless otherwise noted, any terminal nodes not defined here are defined
+in [RFC-ABNF].
+
+2.  Basic Operation
+
+     The Message Tracking Query Protocol (MTQP) is similar to many other
+line-oriented Internet protocols, such as [POP3] and [NNTP].  Initially,
+the server host starts the MTQP service by listening on TCP port ????.
+When a client wishes to make use of the service, it establishes a TCP
+connection with the server host.  When the connection is established,
+the MTQP SERVER SENDS A GREETING.  The client and MTQP server then
+exchange commands and responses (respectively) until the connection is
+closed or aborted.
+
+     Commands in MTQP consist of a case-insensitive keyword, possibly
+followed by one or more parameters.  All commands are terminated by a
+
+
+
+Hansen,Allman                                                   [Page 2]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2000
+
+
+CRLF pair.  Keywords and parameters consist of printable ASCII charac-
+ters.  Keywords and parameters are separated by whitespace (one or more
+space or tab characters).  A command line is limited to 998 characters
+before the CRLF.
+
+     Responses in MTQP consist of a status indicator that indicates suc-
+cess or failure, possibly followed by whitespace and additional informa-
+tion.  Successful commands may also be followed by additional lines of
+data.  All response lines are terminated by a CRLF pair and are limited
+to 998 characters before the CRLF.  There are several status indicators:
+"+OK" indicates success; "+OK+" indicates a success followed by addi-
+tional lines of data, a multi-line success response; "-TEMP" indicates a
+temporary failure; "-ERR" indicates a permanent failure; and "-BAD"
+indicates a protocol error (such as for unrecognized commands).
+
+     A multi-line success response may take one of two forms.  If the
+end of the +OK+ line contains the character "{", a number, and the char-
+acter "}" before the CRLF, then the rest of the response consists of
+that number of characters.
+
+     If the multi-line success response does not end with "{number}",
+each subsequent line is terminated by a CRLF pair and limited to 998
+characters before the CRLF.  When all lines of the response have been
+sent, a final line is sent consisting of a single period (".", decimal
+code 046) and a CRLF pair.  If any line of the multi-line response
+begins with a period, the line is "dot-stuffed" by prepending the period
+with a second period.  When examining a multi-line response, the client
+checks to see if the line begins with a period.  If so, and other octets
+other than CRLF follow, the first octet of the line (the period) is
+stripped away.  If so, and if CRLF immediately follows the period, then
+the response from the MTQP server is ended and the line containing the
+".CRLF" is not considered part of the multi-line response.
+
+     An MTQP server MUST respond to an unrecognized, unimplemented, or
+syntactically invalid command by responding with a negative -BAD status
+indicator.  A server MUST respond to a command issued when the session
+is in an incorrect state by responding with a negative -ERR status indi-
+cator.
+
+     An MTQP server MAY have an inactivity autologout timer.  Such a
+timer MUST be of at least 10 minutes' duration.  The receipt of any com-
+mand from the client during that interval should suffice to reset the
+autologout timer.
+
+3.  Initialization
+
+     Once the TCP connection has been opened by an MTQP client, the MTQP
+server issues an initial status response indicates its readiness.  If
+
+
+
+Hansen,Allman                                                   [Page 3]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2000
+
+
+the status response is positive (+OK or +OK+), the client may proceed
+with other commands.
+
+     If the server has any options enabled, they are listed as the
+multi-line response of the initial status response, one per line.  An
+option specification consists of an identifier, optionally followed by
+option-specific parameters.  An option specification may be continued
+onto additional lines by starting the continuation lines with white
+space.
+
+     No options are defined in this document.
+
+     Example #1 (no options):
+     S: +OK MTQ server ready
+
+     Example #2 (service temporarily unavailable):
+     S: -TEMP Service down for admin, call back later
+
+     Example #3 (service permanently unavailable):
+     S: -ERR Service down
+
+     Example #4 (alternative for no options):
+     S: +OK+ MTQ server ready
+     S: .
+
+     Example #5 (options available):
+     S: +OK+ MTQ server ready
+     S: Option1 parameters
+     S: Option2
+     S: Option3 a very long
+     S:  list of parameters
+     S: .
+
+4.  TRACK Command
+
+     Syntax:
+          "TRACK" 1*WS tracking-id 1*WS authorization-cookie *WS CRLF
+
+          tracking-id = TBD
+
+          authorization-cookie = TBD
+
+     When the client issues the TRACK command, the MTQP server retrieves
+tracking information about an email message.  A successful response MUST
+be multi-line, consisting of a [MIME] mail message whose default
+content-type is message/tracking-status, as defined in [RFC-TRACK-TSN].
+This message contains the tracking information about the email message
+that used the given tracking-id.  The tracking-id and authorization-
+
+
+
+Hansen,Allman                                                   [Page 4]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2000
+
+
+cookie are defined in [RFC-TRACK-ESMTP].  The authorization-cookie is
+expressed in hexadecimal.
+
+     Example #6
+     C: TRACK <tracking-id> 1234567890ABCDEF
+     S: +OK+ Tracking information follows
+     S: Content-Type: message/tracking-status
+     S:
+     S: ... details go here ...
+     S: .
+
+5.  NOOP Command
+
+     Syntax:
+          "NOOP" opt-text CRLF
+
+     When the client issues the NOOP command, the MTQP server resets the
+inactivity autologout timer.  The server MUST respond with a successful
+response (+OK or +OK+).  All parameters to the NOOP command are ignored.
+
+6.  QUIT Command
+
+     Syntax:
+          "QUIT" *WS CRLF
+
+     When the client issues the QUIT command, the MTQP session ter-
+minates.  The QUIT command has no parameters.  The server MUST respond
+with a successful response.  The client may close the session from its
+end immediately after issuing this command.
+
+7.  Pipelining
+
+     The MTQP client may elect to transmit groups of MTQP commands in
+batches without waiting for a response to each individual command.  The
+MTQP server MUST process the commands in the order received.  The fol-
+lowing two examples are identical:
+
+     Example #7
+     C: TRACK <tracking-id> 1234567890ABCDEF
+     S: +OK+ Tracking information follows
+     S:
+     S: ... details go here ...
+     S: .
+     C: NOOP
+     S: +OK Status okay
+
+     Example #8
+     C: TRACK <tracking-id> 1234567890ABCDEF
+
+
+
+Hansen,Allman                                                   [Page 5]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2000
+
+
+     C: NOOP
+     S: +OK+ Tracking information follows
+     S:
+     S: ... details go here ...
+     S: .
+     S: +OK Status okay
+
+8.  URL Format
+
+     The MTQP URL scheme is used to designate MTQP servers on Internet
+hosts accessible using the MTQP protocol.  An MTQP URL takes one of the
+following forms:
+
+     mtqp://<mserver>/track/<tracking-id>:<cookie>
+     mtqp://<mserver>:<port>/track/<tracking-id>:<cookie>
+
+     The first form is used to refer to an MTQP server on the standard
+port, while the second form specifies a non-standard port.  Both of
+these forms specify that the TRACK command is to be issued using the
+given tracking id and authorization cookie.  The path element "/track/"
+is case insensitive, but the tracking id may not be.
+
+8.1.  MTQP URL Syntax
+
+     This is an ABNF description of the MTQP URL.  Terminal nodes not
+defined here are defined in either [RFC-URL] or [RFC-ABNF].
+
+     mtqp-url = "mtqp://" net_loc "/track/" tracking-id ":" cookie
+
+     tracking-id = TBD
+
+     cookie = 16HEXDIG
+
+9.  IANA Considerations
+
+     TBD - registering extensions
+
+10.  Security Considerations
+
+     Security considerations discussed in [RFC-TRACK-MODEL] and [RFC-
+TRACK-ESMTP] are relevant.
+
+11.  Protocol Syntax
+
+     This is an ABNF description of MTQP.
+     command-response = success-response / temp-response / error-response / bad-response
+
+     temp-response = "-TEMP" opt-text CRLF
+
+
+
+Hansen,Allman                                                   [Page 6]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2000
+
+
+     opt-text = [WSP *(VCHAR / WSP)]
+
+     error-response = "-ERR" opt-text CRLF
+
+     bad-response = "-BAD" opt-text CRLF
+
+     success-response = single-line-success / multi-line-success / multi-char-success
+
+     single-line-success = "+OK" opt-text CRLF
+
+     multi-char-success = "+OK+" opt-text "{" 1*DIGIT "}" *WSP CRLF *OCTET
+          ; the number of characters specified by {number} ; must be
+          sent
+
+     multi-line-success = "+OK+" opt-text CRLF *dataline dotcrlf
+
+     dataline = *998OCTET CRLF
+
+     dotcrlf = "." CRLF
+
+     option-list = *option-line
+
+     option-line = rulename opt-text *[CRLF WSP opt-text] CRLF
+
+12.  References
+
+     [MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Internet
+Mail Extensions (MIME) Part One: Format of Internet Message Bodies",
+November 1996.
+
+
+     [RFC-821] STD 10, RFC 821, J. Postel, "Simple Mail Transfer Proto-
+col", University of Southern California / Information Sciences Insti-
+tute, August 1982.
+
+     [RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of
+ARPA Internet Text Messages", University of Delaware, August 1982.
+
+     [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented
+BNF for Syntax Specifications: ABNF", November 1997.
+
+     [RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud,
+and D. Crocker, "SMTP Service Extensions", Silicon Graphics, Inc., July
+1994.
+
+     [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to
+Indicate Requirement Levels", March 1997.
+
+
+
+
+Hansen,Allman                                                   [Page 7]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2000
+
+
+     [RFC-MD5] RFC 1321, R. Rivest, "The MD5 Message-Digest Algorithm",
+April 1992.
+
+     [RFC-TRACK-MODEL] draft-ietf-msgtrk-model-02.txt, T. Hansen, K.
+Lin, "Message Tracking Models and Requirements", AT&T Laboratories,
+Lotus Development Corporation, ???? 2000.
+
+     [RFC-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, "SMTP
+Service Extension for Message Tracking", Sendmail, Inc., ???? 2000.
+
+     [RFC-TRACK-TSN] draft-ietf-msgtrk-trkstat-00.txt, E. Allman, "The
+Message/Tracking-Status MIME Extension", Sendmail, Inc., ???? 2000.
+
+     [RFC-URL] RFC 1808, R. Fielding, "Relative Uniform Resource Loca-
+tors", June 1995.
+
+13.  Authors' Addresses
+
+     Tony Hansen
+     AT&T Laboratories
+     Lincroft, NJ 07738
+     USA
+
+     Phone: +1.732.576.3207
+     E-Mail: tony@att.com
+
+14.  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
+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
+
+
+
+Hansen,Allman                                                   [Page 8]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2000
+
+
+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 January 1, 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen,Allman                                                   [Page 9]
+
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-01.txt b/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-01.txt
new file mode 100644
index 00000000..fc6bc4ae
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-01.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Draft                                                 T. Hansen
+draft-ietf-msgtrk-mtqp-01.txt                          AT&T Laboratories
+Valid for six months                                   November 21, 2000
+
+
+
+                    Message Tracking Query Protocol
+
+                    <draft-ietf-msgtrk-mtqp-01.txt>
+
+                         Authors' version: 1.5
+
+     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@imc.org.  To subscribe, send a message
+with the word "subscribe" in the body (on a line by itself) to the
+address ietf-msgtrk-request@imc.org.  An archive of the mailing list may
+be found at http://www.ietf.org/archive/msgtrk.
+
+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 describes the
+
+
+
+Hansen                                                          [Page 1]
+
+Internet Draft      Message Tracking Query Protocol    November 21, 2000
+
+
+Message Tracking Query Protocol that is used in conjunction with exten-
+sions to the ESMTP protocol to provide a complete message tracking solu-
+tion for the Internet.
+
+1.  Introduction
+
+     The Message Tracking Models and Requirements document [RFC-TRACK-
+MODEL] discusses the models that message tracking solutions could fol-
+low, along with requirements for a message tracking solution that can be
+used with the Internet-wide message infrastructure.  This memo and its
+companions, [RFC-TRACK-ESMTP] and [RFC-TRACK-TSN], describe a complete
+message tracking solution that satisfies those requirements.  The memo
+[RFC-TRACK-ESMTP] defines an extension to the SMTP service that provides
+the information necessary to track messages.  This memo defines a proto-
+col that can be used to query the status of messages that have been
+transmitted on the Internet via SMTP.  The memo [RFC-TRACK-TSN]
+describes the message/tracking-status MIME media type that is used to
+report tracking status information.  Using the model document's termi-
+nology, this solution uses active enabling and active requests with both
+request and chaining referrals.
+
+1.1.  Terminology
+
+     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in [RFC-KEYWORDS].
+
+     All syntax descriptions use the ABNF specified by [RFC-ABNF].  Ter-
+minal nodes not defined elsewhere in this document are defined in [RFC-
+ABNF], [RFC-URI], [RFC-TRACK-ESMTP] or [RFC-SMTPEXT].
+
+1.2.  To Do
+
+     provide information on finding an MTQP server
+
+     provide TTL info, maximum times for keeping info
+
+     determine the TCP port to use
+
+2.  Basic Operation
+
+     The Message Tracking Query Protocol (MTQP) is similar to many other
+line-oriented Internet protocols, such as [POP3] and [NNTP].  Initially,
+the server host starts the MTQP service by listening on TCP port TBD.
+When a client wishes to make use of the service, it establishes a TCP
+connection with the server host.  When the connection is established,
+the MTQP server sends a greeting.  The client and MTQP server then
+exchange commands and responses (respectively) until the connection is
+
+
+
+Hansen                                                          [Page 2]
+
+Internet Draft      Message Tracking Query Protocol    November 21, 2000
+
+
+closed or aborted.
+
+2.1.  Commands
+
+     Commands in MTQP consist of a case-insensitive keyword, possibly
+followed by one or more parameters.  All commands are terminated by a
+CRLF pair.  Keywords and parameters consist of printable ASCII charac-
+ters.  Keywords and parameters are separated by whitespace (one or more
+space or tab characters).  A command line is limited to 998 characters
+before the CRLF.
+
+2.2.  Responses
+
+     Responses in MTQP consist of a status indicator that indicates suc-
+cess or failure.  Successful commands may also be followed by additional
+lines of data.  All response lines are terminated by a CRLF pair and are
+limited to 998 characters before the CRLF.  There are several status
+indicators:  "+OK" indicates success; "+OK+" indicates a success fol-
+lowed by additional lines of data, a multi-line success response; "-
+TEMP" indicates a temporary failure; "-ERR" indicates a permanent
+failure; and "-BAD" indicates a protocol error (such as for unrecognized
+commands).
+
+     A status indicator MAY be followed by a series of machine-
+parseable, case-insensitive response information giving more data about
+the errors.  These are separated from the status indicator and each
+other by a single slash character ("/", decimal code 47).  Following
+that, there MAY be white space and a human-readable text message.
+
+     In a multi-line success response, each subsequent line is ter-
+minated by a CRLF pair and limited to 998 characters before the CRLF.
+When all lines of the response have been sent, a final line is sent con-
+sisting of a single period (".", decimal code 046) and a CRLF pair.  If
+any line of the multi-line response begins with a period, the line is
+"dot-stuffed" by prepending the period with a second period.  When exa-
+mining a multi-line response, the client checks to see if the line
+begins with a period.  If so, and octets other than CRLF follow, the
+first octet of the line (the period) is stripped away.  If so, and if
+CRLF immediately follows the period, then the response from the MTQP
+server is ended and the line containing the ".CRLF" is not considered
+part of the multi-line response.
+
+     An MTQP server MUST respond to an unrecognized, unimplemented, or
+syntactically invalid command by responding with a negative -BAD status
+indicator.  A server MUST respond to a command issued when the session
+is in an incorrect state by responding with a negative -ERR status indi-
+cator.
+
+
+
+
+Hansen                                                          [Page 3]
+
+Internet Draft      Message Tracking Query Protocol    November 21, 2000
+
+
+2.3.  Optional Timers
+
+     An MTQP server MAY have an inactivity autologout timer.  Such a
+timer MUST be of at least 10 minutes in duration.  The receipt of any
+command from the client during that interval should suffice to reset the
+autologout timer.  An MTQP server MAY limit the number of commands or
+total connection time to prevent denial of service attacks.
+
+3.  Initialization and Option Response
+
+     Once the TCP connection has been opened by an MTQP client, the MTQP
+server issues an initial status response indicates its readiness.  If
+the status response is positive (+OK or +OK+), the client may proceed
+with other commands.
+
+     The initial status response MUST include the response information
+"/MTQP".  Negative responses MUST include a reason code as response
+information.  The following reason codes are defined here; unrecognized
+reason codes added in the future may be treated as equivalent to
+"unknown".
+     "/" "unavailable"
+     "/" "admin"
+     "/" "unknown"
+     "/" "referral" "=" net_loc
+
+     If the server has any options enabled, they are listed as the
+multi-line response of the initial status response, one per line.  An
+option specification consists of an identifier, optionally followed by
+option-specific parameters.  An option specification may be continued
+onto additional lines by starting the continuation lines with white
+space.  The option identifier is case insensitive.  Option identifiers
+beginning with the characters "vnd." are reserved for vendor use.
+
+     One option specification is defined here:
+
+     STARTTLS
+
+This capability MUST be listed if the optional STARTTLS command is sup-
+ported by the MTQP server.  It has no parameters.
+
+     Example #1 (no options):
+     S: +OK/MTQP MTQP server ready
+
+     Example #2 (service temporarily unavailable):
+     S: -TEMP/MTQP/admin Service down for admin, call back later
+
+     Example #3 (service permanently unavailable):
+     S: -ERR/MTQP/unavailable Service down
+
+
+
+Hansen                                                          [Page 4]
+
+Internet Draft      Message Tracking Query Protocol    November 21, 2000
+
+
+     Example #4 (alternative for no options):
+     S: +OK+/MTQP MTQP server ready
+     S: .
+
+     Example #5 (options available):
+     S: +OK+/MTQP MTQP server ready
+     S: starttls
+     S: Option2 with parameters
+     S: Option3 with a very long
+     S:  list of parameters
+     S: .
+
+     Example #6 (Referred to another server):
+     S: -ERR/MTQP/referral=server42.example.com:37
+
+4.  TRACK Command
+
+     Syntax:
+          "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF
+
+          mtrk-secret = base64
+
+     Envid is defined in [RFC-TRACK-ESMTP].  Mtrk-secret is the secret S
+described in [RFC-TRACK-ESMTP], encoded using base64.
+
+     When the client issues the TRACK command, the MTQP server retrieves
+tracking information about an email message.  A successful response MUST
+be multi-line, consisting of a [MIME] body part.  The default content-
+type for this MIME body part is message/tracking-status, as defined in
+[RFC-TRACK-TSN].  The response contains the tracking information about
+the email message that used the given tracking-id.  Multiple responses
+would be reported using a multipart/mixed body part with
+message/tracking-status internals.  The tracking-id and authorization-
+cookie are defined in [RFC-TRACK-ESMTP].
+
+     TBD: Give details on different modes of responses and how they map
+into message/tracking-status
+
+     Example #7 :
+     C: TRACK <tracking-id> 1234567890ABCDEF
+     S: +OK+ Tracking information follows
+     S: Content-Type: message/tracking-status
+     S:
+     S: ... details go here when ...
+     S: ... draft-ietf-msgtrk-trkstat becomes available ...
+     S: .
+
+
+
+
+
+Hansen                                                          [Page 5]
+
+Internet Draft      Message Tracking Query Protocol    November 21, 2000
+
+
+5.  COMMENT Command
+
+     Syntax:
+          "COMMENT" opt-text CRLF
+
+          opt-text = [WSP *(VCHAR / WSP)]
+
+     When the client issues the COMMENT command, the MTQP server MUST
+respond with a successful response (+OK or +OK+).  All optional text
+provided with the COMMENT command are ignored.
+
+6.  STARTTLS Command
+
+     Syntax:
+          "STARTTLS" CRLF
+
+     TLS [TLS], more commonly known as SSL, is a popular mechanism for
+enhancing TCP communications with privacy and authentication.  An MTQP
+server MAY support TLS.  If an MTQP server supports TLS, it MUST include
+"STARTTLS" in the option specifications list on protocol startup.
+
+     If the server returns a negative response, it MAY use one of the
+following response codes:
+     "/" "unsupported"
+     "/" "unavailable"
+
+     After receiving a positive response to a STARTTLS command, the
+client MUST start the TLS negotiation before giving any other MTQP com-
+mands.
+
+     If the MTQP client is using pipelining, the STARTTLS command must
+be the last command in a group.
+
+6.1.  Processing After the STARTTLS Command
+
+     After the TLS handshake has been completed, both parties MUST
+immediately decide whether or not to continue based on the authentica-
+tion and privacy achieved. The MTQP client and server may decide to move
+ahead even if the TLS negotiation ended with no authentication and/or no
+privacy because most MTQP services are performed with no authentication
+and no privacy, but some MTQP clients or servers may want to continue
+only if a particular level of authentication and/or privacy was
+achieved.
+
+     If the MTQP client decides that the level of authentication or
+privacy is not high enough for it to continue, it SHOULD issue an MTQP
+QUIT command immediately after the TLS negotiation is complete.  If the
+MTQP server decides that the level of authentication or privacy is not
+
+
+
+Hansen                                                          [Page 6]
+
+Internet Draft      Message Tracking Query Protocol    November 21, 2000
+
+
+high enough for it to continue, it SHOULD reply to every MTQP command
+from the client (other than a QUIT command) with a negative "-BAD"
+response and a response code of "/insecure".
+
+6.2.  Result of the STARTTLS Command
+
+     Upon completion of the TLS handshake, the MTQP protocol is reset to
+the initial state (the state in MTQP after a server starts up).  The
+server MUST discard any knowledge obtained from the client prior to the
+TLS negotiation itself. The client MUST discard any knowledge obtained
+from the server, such as the list of MTQP options, which was not
+obtained from the TLS negotiation itself.
+
+     At the end of the TLS handshake, the server acts as if the connec-
+tion had been initiated and responds with an initial status response
+and, optionally, a list of server options.  The list of MTQP server
+options received after the TLS handshake MUST be different than the list
+returned before the TLS handshake.  In particular, a server MUST NOT
+return the STARTTLS option in the list of server options after a TLS
+handshake has completed.
+
+     Both the client and the server MUST know if there is a TLS session
+active.  A client MUST NOT attempt to start a TLS session if a TLS ses-
+sion is already active.
+
+7.  QUIT Command
+
+     Syntax:
+          "QUIT" CRLF
+
+     When the client issues the QUIT command, the MTQP session ter-
+minates.  The QUIT command has no parameters.  The server MUST respond
+with a successful response.  The client may close the session from its
+end immediately after issuing this command.
+
+8.  Pipelining
+
+     The MTQP client may elect to transmit groups of MTQP commands in
+batches without waiting for a response to each individual command.  The
+MTQP server MUST process the commands in the order received.
+
+     Specific commands may place further constraints on pipelining.  For
+example, STARTTLS must be the last command in a batch of MTQP commands.
+
+     The following two examples are identical:
+
+     Example #8 :
+     C: TRACK <tracking-id> 1234567890ABCDEF
+
+
+
+Hansen                                                          [Page 7]
+
+Internet Draft      Message Tracking Query Protocol    November 21, 2000
+
+
+     S: +OK+ Tracking information follows
+     S:
+     S: ... details go here ...
+     S: .
+     C: TRACK <tracking-id-2> ABCDEF1234567890
+     S: +OK+ Tracking information follows
+     S:
+     S: ... details #2 go here ...
+     S: .
+
+     Example #9 :
+     C: TRACK <tracking-id> 1234567890ABCDEF
+     C: TRACK <tracking-id-2> ABCDEF1234567890
+     S: +OK+ Tracking information follows
+     S:
+     S: ... details go here ...
+     S: .
+     S: +OK+ Tracking information follows
+     S:
+     S: ... details #2 go here ...
+     S: .
+
+9.  URL Format
+
+     The MTQP URL scheme is used to designate MTQP servers on Internet
+hosts accessible using the MTQP protocol.  An MTQP URL takes one of the
+following forms:
+
+     mtqp://<mserver>/track/<envid>/<mtrk-secret>
+     mtqp://<mserver>:<port>/track/<envid>/<mtrk-secret>
+
+     The first form is used to refer to an MTQP server on the standard
+port, while the second form specifies a non-standard port.  Both of
+these forms specify that the TRACK command is to be issued using the
+given tracking id and authorization cookie.  The path element "/track/"
+is case insensitive, but the envid and mtrk-secret may not be.
+
+9.1.  MTQP URL Syntax
+
+     This is an ABNF description of the MTQP URL.
+
+     mtqp-url = "mtqp://" net_loc "/track/" envid ":" mtrk-secret
+
+10.  IANA Considerations
+
+     The service name to be registered with the Internet Assigned Number
+Authority (IANA) is "MTQP".
+
+
+
+
+Hansen                                                          [Page 8]
+
+Internet Draft      Message Tracking Query Protocol    November 21, 2000
+
+
+     This document requests that IANA maintain one new registry: MTQP
+options.
+
+     Additional options for this protocol whose names do not begin with
+"vnd."  MUST be defined in a standards track or IESG approved experimen-
+tal RFC.  New MTQP options MUST include the following information:
+
+     option identifier
+     option parameters
+     added commands
+     standard commands affected
+     specification reference
+     discussion
+
+     Additional options for this protocol whose names begin with "vnd."
+MUST be registered with IANA on a Firt Come First Served basis.
+
+11.  Security Considerations
+
+     Security considerations discussed in [RFC-TRACK-MODEL] and [RFC-
+TRACK-ESMTP] are relevant.
+
+     The security of tracking information is dependent on the randomness
+of the secret chosen for each message and the level of exposure of that
+secret.  If different secrets are used for each message, then the max-
+imum exposure from tracking any message will be that single message for
+the time that the tracking information is kept on any MTQP server.  If
+this level of exposure is too much, TLS may be used to reduce the expo-
+sure further.
+
+     It should be noted that message tracking is not an end-to-end
+mechanism.  Thus, if an MTQP client/server pair decide to use TLS
+privacy, they are not securing tracking queries with any prior or suc-
+cessive MTQP servers.
+
+     Both the STMP client and server must check the result of the TLS
+negotiation to see whether acceptable authentication or privacy was
+achieved.  Ignoring this step completely invalidates using TLS for secu-
+rity.  The decision about whether acceptable authentication or privacy
+was achieved is made locally, is implementation-dependant, and is beyond
+the scope of this document.
+
+     The SMTP client and server should note carefully the result of the
+TLS negotiation.  If the negotiation results in no privacy, or if it
+results in privacy using algorithms or key lengths that are deemed not
+strong enough, or if the authentication is not good enough for either
+party, the client may choose to end the MTQP session with an immediate
+QUIT command, or the server may choose to not accept any more MTQP
+
+
+
+Hansen                                                          [Page 9]
+
+Internet Draft      Message Tracking Query Protocol    November 21, 2000
+
+
+commands.
+
+     A man-in-the-middle attack can be launched by deleting the
+"STARTTLS" option response from the server.  This would cause the client
+not to try to start a TLS session.  An MTQP client can protect against
+this attack by recording the fact that a particular MTQP server offers
+TLS during one session and generating an alarm if it does not appear in
+an option response for a later session.
+
+     If TLS is not used, a tracking request is vulnerable to replay
+attacks, such that a snoop can later replay the same handshake again to
+potentially gain more information about a message's status.
+
+     Before the TLS handshake has begun, any protocol interactions are
+performed in the clear and may be modified by an active attacker.  For
+this reason, clients and servers MUST discard any knowledge obtained
+prior to the start of the TLS handshake upon completion of the TLS
+handshake.
+
+12.  Protocol Syntax
+
+     This is a collected ABNF description of the MTQP protocol.
+     conversation = command-response *( client-command command-response )
+
+     # client side
+     client-command = track-command / starttls-command / quit-command / comment-command
+
+     track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF
+
+     mtrk-secret = base64
+
+     starttls-command = "STARTTLS" CRLF
+
+     quit-command = "QUIT" CRLF
+
+     comment-command = "COMMENT" opt-text CRLF
+
+     # server side
+     command-response = success-response / temp-response / error-response / bad-response
+
+     temp-response = "-TEMP" response-info opt-text CRLF
+
+     opt-text = [WSP *(VCHAR / WSP)]
+
+     error-response = "-ERR" response-info opt-text CRLF
+
+     bad-response = "-BAD" response-info opt-text CRLF
+
+
+
+
+Hansen                                                         [Page 10]
+
+Internet Draft      Message Tracking Query Protocol    November 21, 2000
+
+
+     success-response = single-line-success / multi-line-success
+
+     single-line-success = "+OK" response-info opt-text CRLF
+
+     multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf
+
+     dataline = *998OCTET CRLF
+
+     dotcrlf = "." CRLF
+
+     option-list = *option-line
+
+     option-line = identifier opt-text *[CRLF WSP opt-text] CRLF
+
+     identifier = (ALPHA / "_") *(ALPHA / DIGIT / "-" / "_")
+
+
+13.  Acknowledgements
+
+     The description of STARTTLS is based on [RFC-SMTP-TLS].
+
+14.  References
+
+     [MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Internet
+Mail Extensions (MIME) Part One: Format of Internet Message Bodies",
+November 1996.
+
+     [RFC-821] STD 10, RFC 821, J. Postel, "Simple Mail Transfer Proto-
+col", University of Southern California / Information Sciences Insti-
+tute, August 1982.
+
+     [RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of
+ARPA Internet Text Messages", University of Delaware, August 1982.
+
+     [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented
+BNF for Syntax Specifications: ABNF", November 1997.
+
+     [RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud,
+and D. Crocker, "SMTP Service Extensions", Silicon Graphics, Inc., July
+1994.
+
+     [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to
+Indicate Requirement Levels", March 1997.
+
+     [RFC-MD5] RFC 1321, R. Rivest, MIT Laboratory for Computer Science
+and RSA Data Security, Inc., "The MD5 Message-Digest Algorithm", April
+1992.
+
+
+
+
+Hansen                                                         [Page 11]
+
+Internet Draft      Message Tracking Query Protocol    November 21, 2000
+
+
+     [RFC-SMTPEXT] RFC 2554, J. Myers, Netscape Communications, "SMTP
+Service Extension for Authentication", March 1999.
+
+     [RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for
+Secure SMTP over TLS", Internet Mail Consortium, January 1999.
+
+     [RFC-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-00.txt, E. Allman, T.
+Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc.,
+AT&T Laboratories, TBD 2000.
+
+     [RFC-TRACK-MODEL] draft-ietf-msgtrk-model-03.txt, T. Hansen, "Mes-
+sage Tracking Models and Requirements", AT&T Laboratories, November
+2000.
+
+     [RFC-TRACK-TSN] draft-ietf-msgtrk-trkstat-00.txt, E. Allman, "The
+Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2000.
+
+     [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni-
+form Resource Identifiers (URI): Generic Syntax", August 1998.
+
+15.  Authors' Addresses
+
+     Tony Hansen
+     AT&T Laboratories
+     Lincroft, NJ 07738
+     USA
+
+     Phone: +1.732.576.3207
+     E-Mail: tony@att.com
+
+16.  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
+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
+
+
+
+Hansen                                                         [Page 12]
+
+Internet Draft      Message Tracking Query Protocol    November 21, 2000
+
+
+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 May 21, 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen                                                         [Page 13]
+
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-protocol-00.txt b/Documentation/en/I-D/draft-ietf-msgtrk-protocol-00.txt
new file mode 100644
index 00000000..e223f995
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-protocol-00.txt
@@ -0,0 +1,500 @@
+Internet Draft						       E. Allman
+draft-ietf-msgtrk-protocol-00.txt			  Sendmail, Inc.
+Valid for six months					       T. Hansen
+						       AT&T Laboratories
+							  March	10, 2000
+
+
+
+			 SMTP Service Extension
+			  for Message Tracking
+
+		  <draft-ietf-msgtrk-protocol-00.txt>
+
+			 Authors' version: 1.1
+
+     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.  An archive of the
+mailing	list may be found at http://www.ietf.org/archive/msgtrk.
+
+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
+
+
+
+Allman,Hansen						        [Page 1]
+
+Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
+
+
+current	routing	status of that message.	 This document provides	exten-
+sions to the ESMTP protocol to enhance its capabilities	to include mes-
+sage tracking.
+
+1.  Introduction
+
+     The Message Tracking Models and Requirements document [RFC-TRACK-
+MODEL] discusses the models that message tracking solutions could fol-
+low, along with	requirements for a message tracking solution that can be
+used with the Internet-wide message infrastructure.  This memo defines
+an extension to	the SMTP service that provides a message tracking solu-
+tion that satisfies those requirements.	 Using the model document's ter-
+minology, it uses active enabling and active requests with request
+referrals.
+
+....
+
+This document is very drafty; its purpose is to	promote	discussion.
+Sections that are obviously in need of filling out have	comments begin-
+ning with "--".
+
+
+1.1.  Terminology
+
+     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT",	"RECOMMENDED", "MAY", and "OPTIONAL" in	this
+document are to	be interpreted as described in RFC 2119	[RFC-KEYWORDS].
+
+
+
+2.  Framework for the Message Tracking Service Extension
+
+     The Message Trackng extension to SMTP is laid out as follows:
+
+     **	  the name of the SMTP service defined here is "Message	Track-
+	  ing";
+
+     **	  the EHLO keyword value associated with the extension is
+	  "TRACK";
+
+     **	  the TRACK keyword has	no parameters;
+
+     **	  the TRACKID parameter	is added to the	MAIL FROM command;
+
+     **	  a new	SMTP verb, "MTRK", is defined.
+
+     The rest of this memo defines how support for the extension effects
+     the behavior of a message transfer	agent.
+
+
+
+Allman,Hansen						        [Page 2]
+
+Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
+
+
+3.  Message Tracking Enabling
+
+     An	SMTP client wishing to request message tracking	support	for a
+message	may issue the EHLO command to start an SMTP session, to	deter-
+mine if	the server supports any	of several service extensions.	If the
+server responds	with code 250 to the EHLO command, and the response
+includes the EHLO keyword TRACK, then the Message Tracking extension (as
+described in this memo)	is supported.  In general, an ESMTP server which
+implements this	service	extension will propagate message tracking infor-
+mation when relaying mail to other SMTP-based MTAs that	also support
+this extension,	and make a "best effort" to record when	messages are
+passed into other environments.
+
+4.  Additional Parameter for the MAIL FROM Command
+
+     The extended MAIL FROM command is issued by a client when it wishes
+to request that	a server maintain tracking information for the message.
+The extended MAIL FROM command is identical to the MAIL	commands defined
+in [RFC-821], except that the additional parameter may appear after the
+recipient address.  The	general	syntax for extended SMTP commands is
+defined	in [RFC-ESMTP].
+
+4.1.  The TRACKID parameter of the ESMTP MAIL FROM Command
+
+     The TRACKID esmtp-keyword on the extended MAIL FROM command speci-
+fies whether or	not the	message	should be tracked by the server.  If the
+TRACKID	esmtp-keyword is used, it MUST have an associated esmtp-value,
+which is constructed as	described next.
+
+4.2.  Creating the TRACKID Parameter
+
+     The TRACKID parameter consists of two parts: a per-message	authen-
+tication string, the Auth String, and a	per-message tracking identifica-
+tion string, the Tracking ID.
+
+4.2.1.	Tracking ID
+
+     A key requirement of message tracking is the ability to uniquely
+identify a message with	a globally and temporally unique signature.  The
+Message-Id: header is required by [RFC-822] to identify	a message, and
+is usually required to be globally and temporally unique.  So it is
+almost sufficient for tracking identification.	However, a Message ID
+will be	reused under certain circumstances, such as when a message is
+resent,	and such messages must be able to be tracked separately	from the
+original message.  The Tracking	ID is REQUIRED to be the same value as
+used for the Message ID, without the angle brackets, and augmented by a
+colon ":" and a	generational counter.  The generational	counter	will be
+an unsigned integer value that SHOULD start at the value of 0.	For
+
+
+
+Allman,Hansen						        [Page 3]
+
+Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
+
+
+example, if the	value of the Message-ID: header	is
+"<123456.89012391@domain.example>", then the value of the tracking ID
+will be	"123456.89012391@domain.example:0".  If	a message is ever resent
+or retransmitted for any other reason by an end-user client, then the
+generational counter MUST be incremented by one.  (The generational
+counter	MAY additionally be incremented	by a small (<10) random	number.)
+
+4.2.2.	Secret Value
+
+     For messages to be	tracked, the mail user agent must use a	secret
+value.	This secret value MAY be a per-message secret, such as a 128-bit
+(16-byte) random number.
+
+4.2.3.	Stored Authentication Value
+
+     The value of the Tracking ID, T, is concatentated with the	secret
+value, S, and passed through the [RFC-MD5] one-way hash	function, to
+create the Stored Authentication Value,	A.
+
+     A = H(T + S)
+
+
+4.2.4.	Transmitted Authentication String
+
+     The Transitted Authentication String, B, is created by passing the
+Stored Authentication Value, A,	through	the MD5	one-way	hash function,
+producing a 16-byte value.  This value is then expressed as a series of
+32 hexadecimal digits, either lower- or	upper-case, transmitted	in
+internet byte order (low-endian	???? ) [RFC-????].
+
+     B = hex(H(A))
+
+4.2.5.	The TRACKID Parameter
+
+     The TRACKID parameter, P, is created from the transmitted authenti-
+cation string, B, a colon ":", and the tracking	ID, T.
+
+     P = B + ":" + T
+
+
+5.  Message Tracking Requests
+
+     The MTRK command is issued	by the client host when	it wishes to
+determine the current status of	a message previously sent to that server
+host.  The syntax of this command is as	follows:
+
+     MTRK <stored-authentication-value>:<tracking-id><CR><LF>
+
+
+
+
+Allman,Hansen						        [Page 4]
+
+Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
+
+
+<tracking-id> is the tracking ID, T, of	a message previously sent to
+this server.  The <stored-authentication-value>	is the Stored Authenti-
+cation Value A (as calculated above) for that message.	The <stored-
+authentication-value> is expressed as a	series of 32 hexadecimal digits,
+either lower- or upper-case, transmitted in internet byte order	[RFC-
+????].	This command may be issued at any time once a session is esta-
+blished, as long as there is not a transaction occurring.  Thus, this
+command	is illegal between a MAIL FROM:	command	and the	end of the DATA
+commands and responses.
+
+things to add:
+-- data	to be returned
+-- states to be	returned
+-- format to be	returned
+-- responses to	the verb, 250, 4xx, 5xx
+
+
+other things to	consider:
+-- firewalls? (treat as	gateway	MTAs and let them do chaining?)
+-- affect on SUBMIT? can we ask	MSA to return the A and	B hash?
+-- use message-id directly and require message-id to be	in first 1k of
+message?
+
+
+6.  Examples
+
+     --	examples go here
+
+6.1.  Message Tracking Enabling
+
+
+     S:	220 smtp.example.com ESMTP server ready
+     C:	EHLO example.example.com
+     S:	250-smtp.example.com
+     S:	250 TRACK
+     C:	MAIL FROM:<user@example.com>
+	 TRACKID=1234567890123456789012:12345.54321@example.com:0
+     S:	250 <user@example.com> sender ok
+     C:	RCPT TO:<user2@example.com>
+     S:	25o <user2@example.com>	recipient ok
+     C:	DATA
+     S:	354 okay, send message
+     C:	Message-Id: <12345.54321@example.com>
+     C:	(rest of message here)
+     C:	.
+     S:	250 message accepted
+     C:	QUIT
+     S:	221 goodbye
+
+
+
+Allman,Hansen						        [Page 5]
+
+Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
+
+
+6.2.  Message Tracking Request
+
+     S:	220 smtp.example.com ESMTP server ready
+     C:	EHLO example.example.com
+     S:	250-smtp.example.com
+     S:	250 TRACK
+     C:	MTRK 1234567890123456789012:12345.54321@example.com:0
+     S:	-- response to be determined
+
+7.  Security Considerations
+
+     things to add:
+-- text	about no more than a single message can	be lost
+-- man in the middle attack
+-- see RFC 1894	for security considerations on DSNs and	RFC 2298 on MDNs
+
+-- We probably cannot get away with the	following statement:
+
+This RFC does not discuss security issues and is not believed to raise
+any security issues not	already	endemic	in electronic mail and present
+in fully conforming implementations of [RFC821], or otherwise made pos-
+sible by [MIME].
+
+
+8.  References
+
+     [RFC-821] Postel, J., "Simple Mail	Transfer Protocol", STD	10, RFC
+821, University	of Southern California / Information Sciences Institute,
+August 1982.
+
+[RFC-822] Crocker, D., "Standard for the Format	of ARPA	Internet Text
+Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+[RFC-ESMTP] Klensin, J., Freed,	N., Rose, M., Stefferud, E., and D.
+Crocker, "SMTP Service Extensions", RFC	1651, MCI, Innosoft, Dover Beach
+Consulting, Inc., Network Management Associates, Inc., Silicon Graphics,
+Inc., July 1994.
+
+[RFC-MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+April 1992.
+
+[RFC-MODEL] Hansen, T.,	"Message Tracking Models and Requirements", RFC
+????, AT&T Laboratories, ???? 2000.
+
+[RFC-????]  something on internet byte order
+
+
+
+
+
+
+Allman,Hansen						        [Page 6]
+
+Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
+
+
+9.  Authors' Addresses
+
+     Eric Allman
+     Sendmail, Inc.
+     street address
+     city, state zip
+
+     Phone: +1
+     E-Mail: eric@sendmail.com
+
+     Tony Hansen
+     AT&T Laboratories
+     Lincroft, NJ 07738
+     USA
+
+     Phone: +1 732 576-3207
+     E-Mail: tony@att.com
+
+10.  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
+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 September 10, 2000.
+
+
+
+
+
+Allman,Hansen						        [Page 7]
+
+Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
+
+
+11.  Appendix A	-- Sample Code
+
+     For the sake of illustration, we provide the following sample C
+code for the creation of the saved and transmitted authentication
+strings.  The code is based on MD5 code	as described in	[RFC-MD5].  The
+input is a secret and transaction ID, the output is two	33-byte	strings
+containing the values of the two authentication	strings, encoded as hex
+digits,	and NUL-terminated.
+
+-- I have not yet compiled this	code or	verified that it does indeed
+generate network byte order.
+     /*
+     **	Function: trackauth
+     */
+     #include <md5.h>
+
+     void
+     trackauth(
+		     /*	input parameters ... */
+	 unsigned char*	secret;		    /* pointer to secret */
+	 int secret_len;		    /* length of secret	*/
+	 unsigned char*	transaction_id;	    /* pointer to transaction ID */
+	 int transaction_id_len;	    /* length of transaction ID	*/
+		     /*	output parameters ... */
+	 unsigned char saved_auth_str[33];  /* A: saved	authentication string */
+	 unsigned char trans_auth_str[33];  /* B: transmitted auth. string */
+     )
+     {
+	 MD5_CTX context;		    /* MD5 engine */
+	 unsigned char outbuf[16];	    /* where to	store the context */
+	 register int i, j;		    /* counters	*/
+	 static	char hexdigits[] = "0123456789abcdef";
+
+	 MD5Init(&context);
+	 MD5Update(&context, secret, secret_len);
+	 MD5Update(&context, transaction_id, transaction_id_len);
+	 MD5Final(outbuf, &context);
+	 for (i	= 0, j = 0; i <	16; i++)
+	     {
+	     saved_auth_str[j++] = hexdigits[outbuf[i] & 0xF];
+	     saved_auth_str[j++] = hexdigits[(outbuf[i]	>> 4) &	0xF];
+	     }
+	 saved_auth_str[j] = '\0';
+
+	 MD5Init(&context);
+	 MD5Update(&context, saved_auth_str, 16);
+	 MD5Final(outbuf, &context);
+	 for (i	= 0, j = 0; i <	16; i++)
+
+
+
+Allman,Hansen						        [Page 8]
+
+Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
+
+
+	     {
+	     trans_auth_str[j++] = hexdigits[outbuf[i] & 0xF];
+	     trans_auth_str[j++] = hexdigits[(outbuf[i]	>> 4) &	0xF];
+	     }
+	 trans_auth_str[j] = '\0';
+     }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman,Hansen						        [Page 9]
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-00.txt b/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-00.txt
new file mode 100644
index 00000000..dc8e5758
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-00.txt
@@ -0,0 +1,498 @@
+Internet Draft                                               E. Allman
+draft-ietf-msgtrk-trkstat-00.txt                        Sendmail, Inc.
+Valid for six months                                 December 14, 2000
+Updates: RFC 1893
+
+
+
+
+              The Message/Tracking-Status MIME Extension
+
+                  <draft-ietf-msgtrk-trkstat-00.txt>
+
+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  dis-
+tribute 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 document is a submission by the MSGTRK Working Group of  the
+Internet  Engineering Task Force (IETF).  Comments should be submitted
+to the msgtrk@imc.org mailing list.  An archive of  the  mailing  list
+may be found at
+
+    http://www.ietf.org/archive/msgtrk
+
+
+     Distribution of this memo is unlimited.
+
+1.  Abstract
+
+        Message  Tracking is expected to be used to determine the sta-
+   tus of undelivered e-mail upon request.  Tracking is used  in  con-
+   junction with Delivery Status Notifications [RFC-DSN-SMTP] and Mes-
+   sage Disposition  Notifications  [RFC-MDN];  generally,  a  message
+   tracking request will be issued only when a DSN or MDN has not been
+   received within a reasonable timeout period.
+
+        This memo defines a MIME [RFC-MIME] content-type  for  message
+   tracking  status  in  the  same spirit as RFC 1894, ``An Extensible
+   Message Format for Delivery Status Notifications''  [RFC-DSN-STAT].
+
+Internet Draft          Message/Tracking-Status      December 14, 2000
+
+
+   It  is to be issued upon a request as described in ``Message Track-
+   ing Query Protocol'' [DRAFT-MTRK-MTQP].  This memo defines only the
+   format of the status information.  An extension to SMTP [RFC-ESMTP]
+   to label messages for further tracking and request tracking  status
+   is defined in a separate memo [DRAFT-MTRK-SMTPEXT].
+
+2.  Other Documents and Conformance
+
+        The  model  used  for Message Tracking is described in [DRAFT-
+   MTRK-MODEL].
+
+        Message tracking is intended for use as a "last resort" mecha-
+   nism.   Normally,  Delivery  Status  Notifications (DSNs) [RFC-DSN-
+   SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN]  would
+   provide  the  primary  delivery  status.   Only if no response from
+   either of these mechanisms would Message Tracking be used.
+
+        This document is based on [RFC-DSN-STAT].  Sections 1.3  (Ter-
+   minology),  2.1.1  (General  conventions  for  DSN  fields),  2.1.2
+   ("*-type" subfields), and 2.1.3 (Lexical tokens imported  from  RFC
+   822)  of  [RFC-DSN-STAT]  are included into this document by refer-
+   ence.  Other sections are further incorporated as described herein.
+
+        Syntax notation in this document conforms to [RFC-ABNF].
+
+        The  following  lexical  tokens,  defined in [RFC-MSGFMT], are
+   used in the ABNF grammar for MTSNs: atom, CHAR, comment, CR,  CRLF,
+   DIGIT,  LF, linear-white-space, SPACE, text.  The date-time lexical
+   token is defined in [RFC-HOSTREQ].
+
+        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",  "SHALL
+   NOT",  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
+   in this document are to be interpreted as  described  in  RFC  2119
+   [RFC-KEYWORDS].
+
+
+3.  Format of a Message Tracking Status Notification
+
+        A  Message  Tracking Status Notification (MTSN) is intended to
+   be returned as the body of a Message Tracking request  [DRAFT-MTRK-
+   MTQP].   The  actual body MUST be a multipart/related [RFC-RELATED]
+   with type of "tracking-status"; each subpart  MUST  be  type  "mes-
+   sage/tracking-status" as described herein.
+
+   3.1.  The message/tracking-status content-type
+
+           The message/tracking-status content-type is defined as fol-
+      lows:
+
+          MIME type name:           message
+          MIME subtype name:        tracking-status
+          Optional parameters:      none
+          Encoding considerations:  "7bit" encoding is sufficient and
+                                    MUST be used to maintain readability
+                                    when viewed by non-MIME mail readers.
+          Security considerations:  discussed in section 4 of this memo.
+
+
+Allman                                                        [Page 2]
+
+Internet Draft          Message/Tracking-Status      December 14, 2000
+
+
+           The body of  a  message/tracking-status  is  modeled  after
+      [RFC-DSN-STAT].  That body consists of one or more "fields" for-
+      matted to according to the ABNF of RFC 822 headers "fields" (see
+      [RFC-MSGFMT]).  The per-message fields appear first, followed by
+      a blank line.  Following the per-message fields are one or  more
+      groups  of  per-recipient  fields.   Each group of per-recipient
+      fields is preceded by a blank line.  Formally, the syntax of the
+      message/tracking-status content is as follows:
+
+          tracking-status-content =
+                    per-message-fields 1*( CRLF per-recipient-fields )
+
+      The  per-message  fields are described in section 3.2.  The per-
+      recipient fields are described in section 3.3.
+
+      3.1.1.  General conventions for MTSN fields
+
+              Section 2.1.1 (General conventions for  DSN  fields)  of
+         [RFC-DSN-STAT] is included herein by reference.  Notably, the
+         definition of xtext is identical to that of that document.
+
+      3.1.2.  *-type subfields
+
+              Section 2.1.2 (*-type subfields)  of  [RFC-DSN-STAT]  is
+         included  herein  by  reference.  Notably, the definitions of
+         address-type, diagnostic-type, and MTA-name type are  identi-
+         cal to that of RFC 1894.
+
+
+   3.2.  Per-Message MTSN Fields
+
+           Some  fields  of an MTSN apply to all of the addresses in a
+      single envelope.  These fields may appear at most  once  in  any
+      MTSN.   These  fields  are  used  to correlate the MTSN with the
+      original message transaction and to provide additional  informa-
+      tion which may be useful to gateways.
+
+          per-message-fields =
+                    original-envelope-id-field CRLF
+                    reporting-mta-field CRLF
+                    arrival-date CRLF
+                    *( extension-field CRLF )
+
+
+      3.2.1.  The Original-Envelope-Id field
+
+              The optional Original-Envelope-Id field is defined as in
+         section 2.2.1 of [RFC-DSN-STAT].  This field is REQUIRED.
+
+      3.2.2.  The Reporting-MTA field
+
+              The Reporting-MTA field is defined as in  section  2.2.2
+         of [RFC-DSN-STAT].  This field is REQUIRED.
+
+
+
+
+
+Allman                                                        [Page 3]
+
+Internet Draft          Message/Tracking-Status      December 14, 2000
+
+
+      3.2.3.  The Arrival-Date field
+
+              The Arrival-Date field is defined as in section 2.2.5 of
+         [RFC-DSN-STAT].  This field is REQUIRED.
+
+
+   3.3.  Per-Recipient MTSN fields
+
+           An MTSN contains information about attempts  to  deliver  a
+      message to one or more recipients.  The delivery information for
+      any particular recipient is contained in a group  of  contiguous
+      per-recipient  fields.   Each  group  of per-recipient fields is
+      preceded by a blank line.
+
+           The syntax for the group of per-recipient fields is as fol-
+      lows:
+
+          per-recipient-fields =
+                    original-recipient-field CRLF
+                    final-recipient-field CRLF
+                    action-field CRLF
+                    status-field CRLF
+                    [ remote-mta-field CRLF ]
+                    [ last-attempt-date-field CRLF ]
+                    [ will-retry-until-field CRLF ]
+                    *( extension-field CRLF )
+
+
+      3.3.1.  Original-Recipient field
+
+              The  optional  Original-Recipient field is defined as in
+         section 2.3.1 of [RFC-DSN-STAT].  This field is REQUIRED.
+
+      3.3.2.  Final-Recipient field
+
+              The required Final-Recipient field is defined as in sec-
+         tion 2.3.2 of [RFC-DSN-STAT].  This field is REQUIRED.
+
+      3.3.3.  Action field
+
+              The required Action field indicates the action performed
+         by the Reporting-MTA as a result of its attempt  to  delivery
+         the  message  to  this recipient address.  This field MUST be
+         present for each recipient named in the MTSN.  The syntax  is
+         as  defined  in  section  2.3.3  of  RFC 1894.  This field is
+         REQUIRED.
+
+              Valid actions are:
+
+         failed       The message could not  be  delivered.   If  DSNs
+                      have been enabled, a "failed" DSN should already
+                      have been returned.
+
+         delayed      The message is  currently  waiting  in  the  MTA
+                      queue  for  future  delivery.  Essentially, this
+                      action means "the message is located, and it  is
+
+
+Allman                                                        [Page 4]
+
+Internet Draft          Message/Tracking-Status      December 14, 2000
+
+
+                      here."
+
+         delivered    The  message  has been successfully delivered to
+                      the final recipient.  This  includes  "delivery"
+                      to a mailing list exploder.  No further informa-
+                      tion is available; in particular,  the  tracking
+                      agent  SHOULD  NOT  attempt further "downstream"
+                      tracking requests.
+
+         relayed      The message has been delivered into an  environ-
+                      ment that does not support message tracking.  No
+                      further information is available; in particular,
+                      the  tracking  agent  SHOULD NOT attempt further
+                      "downstream" tracking requests.
+
+         transferred  The message  has  been  transferred  to  another
+                      MTRK-compliant  MTA.   The tracking agent SHOULD
+                      attempt further "downstream" tracking  requests.
+
+         opaque       The  message  may  or  may not have been seen by
+                      this system.  No further information  is  avail-
+                      able or forthcoming.
+
+      3.3.4.  Status field
+
+              The  Status  field  is  defined  as  in RFC 1894 section
+         2.3.4.   A  new  code  is  added  to  RFC  1893  [RFC-EMSSC],
+         "Enhanced Mail System Status Codes",
+
+             X.1.9   Message relayed to non-compliant mailer"
+
+                 The mailbox address specified was valid, but the mes-
+                 sage has been relayed to a system that does not speak
+                 this  protocol;  no  further  information can be pro-
+                 vided.
+         A  2.1.9  Status  field  MUST  be  used  exclusively  with  a
+         "relayed" Action field.  This field is REQUIRED.
+
+      3.3.5.  Remote-MTA field
+
+              The  Remote-MTA field is defined as in section Reference
+         2.3.5 of [RFC-DSN-STAT].  This field MUST NOT be included  if
+         no  delivery  attempts  have been made or if the Action field
+         has value "opaque".  If delivery to some agent other than  an
+         MTA (for example, a Local Delivery Agent) then this field MAY
+         be included, giving the name of the host on which that  agent
+         was contacted.
+
+      3.3.6.  Last-Attempt-Date field
+
+              The  Last-Attempt-Date  field  is  defined as in section
+         Reference 2.3.7 of [RFC-DSN-STAT].  This field is REQUIRED if
+         any  delivery  attempt  has  been made, in which case it will
+         specify when it last attempted to  deliver  this  message  to
+         another  MTA or other Delivery Agent.  This field MUST NOT be
+         included if no delivery attempts have been made.
+
+
+Allman                                                        [Page 5]
+
+Internet Draft          Message/Tracking-Status      December 14, 2000
+
+
+      3.3.7.  Will-Retry-Until field
+
+              The Will-Retry-Until field is defined as in section Ref-
+         erence  2.3.8  of  [RFC-DSN-STAT].  This field is REQUIRED if
+         the message is still in the MTA queue.  This field  MUST  NOT
+         be included if the message is not in the local queue.
+
+   3.4.  Extension fields
+
+           Future  extension  fields may be defined as defined in sec-
+      tion 2.4 of [RFC-DSN-STAT].
+
+   3.5.  Interaction Between MTAs and LDAs
+
+           A message that has been delivered to  an  LDA  that  under-
+      stands  message  tracking  (in  particular, an LDA speaking LMTP
+      [RFC-LMTP] that supports the MTRK  extension)  SHOULD  pass  the
+      tracking request to the LDA.  In this case, the Action field for
+      the MTA->LDA exchange will look the same as a transfer to a com-
+      pliant  MTA;  that  is,  a "transferred" tracking status will be
+      issued.
+
+
+4.  Security Issues
+
+   4.1.  Forgery
+
+           Malicious servers may attempt to subvert  message  tracking
+      and return false information.  This could result in misdirection
+      or misinterpretation of results.
+
+   4.2.  Confidentiality
+
+           Another dimension of security  is  confidentiality.   There
+      may be cases in which a message recipient is autoforwarding mes-
+      sages but does not wish to divulge the address to which the mes-
+      sages  are  autoforwarded.   The desire for such confidentiality
+      will probably be heightened as  "wireless  mailboxes",  such  as
+      pagers, become more widely used as autoforward addresses.
+
+           MTA  authors  are  encouraged  to provide a mechanism which
+      enables the end user to preserve the confidentiality of  a  for-
+      warding  address.   Depending  on  the degree of confidentiality
+      required, and the nature of the environment to which  a  message
+      were  being forwarded, this might be accomplished by one or more
+      of:
+
+      (a)  respond with a "relayed" tracking status when a message  is
+           forwarded  to  a  confidential forwarding address, and dis-
+           abling further message tracking requests.
+
+      (b)  declaring the message to be delivered,  issuing  a  "deliv-
+           ered" tracking status, re-sending the message to the confi-
+           dential forwarding address, and disabling  further  message
+           tracking requests.
+
+
+
+Allman                                                        [Page 6]
+
+Internet Draft          Message/Tracking-Status      December 14, 2000
+
+
+           The  tracking  algorithms  MUST  NOT allow tracking through
+      list expansions.  When a message  is  delivered  to  a  list,  a
+      tracking request MUST respond with an "expanded" tracking status
+      and MUST NOT display the contents of the list.
+
+5.  References
+
+   [DRAFT-MTRK-MODEL]
+        T.  Hansen,  ``Message  Tracking  Model  and   Requirements.''
+        draft-ietf-msgtrk-model-03.txt.  November 2000.
+
+   [DRAFT-MTRK-MTQP]
+        T.  Hansen,  ``Message Tracking Query Protocol.''  draft-ietf-
+        msgtrk-mtqp-01.txt.  November 2000.
+
+   [DRAFT-MTRK-SMTPEXT]
+        E. Allman, ``SMTP Service Extension  for  Message  Tracking.''
+        draft-ietf-msgtrk-smtpext-00.txt.  December 2000.
+
+   [RFC-ABNF]
+        Crocker,  D., Editor, and P. Overell, ``Augmented BNF for Syn-
+        tax Specifications: ABNF'', RFC 2234, November 1997.
+
+   [RFC-DSN-REPT]
+        G. Vaudreuil, ``The  Multipart/Report  Content  Type  for  the
+        Reporting of Mail System Administrative Messages.''  RFC 1892.
+        January 1996.
+
+   [RFC-DSN-SMTP]
+        K. Moore, ``SMTP Service Extension for Delivery Status Notifi-
+        cations.''  RFC 1891.  January 1996.
+
+   [RFC-DSN-STAT]
+        K.  Moore and G. Vaudreuil, ``An Extensible Message Format for
+        Delivery Status Notifications.''  RFC 1894.  January 1996.
+
+   [RFC-EMSSC]
+        G. Vaudreuil, ``Enhanced  Mail  System  Status  Codes.''   RFC
+        1893.  January 1996.
+
+   [RFC-ESMTP]
+        Rose,  M.,  Stefferud,  E.,  Crocker,  D.,  Klensin, J. and N.
+        Freed, ``SMTP Service Extensions.''  STD 10, RFC 1869.  Novem-
+        ber 1995.
+
+   [RFC-HOSTREQ]
+        R. Braden (ed.), ``Requirements for Internet Hosts -- Applica-
+        tion and Support.''  STD 3, RFC 1123.  October 1989.
+
+   [RFC-KEYWORDS]
+        S. Bradner, ``Key words for use in RFCs to  Indicate  Require-
+        ment Levels.''  RFC 2119.  March 1997.
+
+   [RFC-LMTP]
+        J.  Myers, ``Local Mail Transfer Protocol.''  RFC 2033.  Octo-
+        ber 1996.
+
+
+Allman                                                        [Page 7]
+
+Internet Draft          Message/Tracking-Status      December 14, 2000
+
+
+   [RFC-MDN]
+        R. Fajman, ``An Extensible Message Format for Message Disposi-
+        tion Notifications.''  RFC 2298.  March 1998.
+
+   [RFC-MIME]
+        N.  Freed  and  N.  Borenstein,  ``Multipurpose  Internet Mail
+        Extensions (MIME) Part One: Format of  Internet  Message  Bod-
+        ies.''  RFC 2045.  November 1996.
+
+   [RFC-MSGFMT]
+        D.  Crocker,  ``Standard  for the Format of ARPA Internet Text
+        Messages.''  RFC 822.  August 1982.
+
+   [RFC-RELATED]
+        E. Levinson, ``The MIME Multipart/Related Content-type.''  RFC
+        2387.  August 1998.
+
+6.  Author's Address
+
+       Eric Allman
+       Sendmail, Inc.
+       6603 Shellmound
+       Emeryville, CA  94608
+       U.S.A.
+
+       E-Mail: eric@Sendmail.COM
+       Phone: +1 510 594 5501
+       Fax: +1 510 594 5411
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman                                                        [Page 8]
+
diff --git a/Documentation/en/I-D/draft-jones-msgtrk-def-00.txt b/Documentation/en/I-D/draft-jones-msgtrk-def-00.txt
new file mode 100644
index 00000000..adf5910a
--- /dev/null
+++ b/Documentation/en/I-D/draft-jones-msgtrk-def-00.txt
@@ -0,0 +1,222 @@
+MSGTRK BOF                             G. Jones [gbjones@mitre.org]
+INTERNET-DRAFT                         B. Ernst [bruce_ernst@lotus.ssw.com]
+draft-ietf-jones-msgtrk-def-00.txt     G. Vaudreuil [gregv@ons.octel.com]
+Expires: February 1999
+
+
+
+
+
+                 Basic Definition of Message Tracking
+
+
+Status of this Memo
+
+This document is an  Internet  Draft.  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.  Internet  Drafts  may  be updated, replaced, or obsoleted by   
+other documents at any time.  It is not appropriate to  use  Internet   
+Drafts as reference material or to cite them other than as a "working
+draft" or "work in progress."
+
+To view the entire list of current Internet-Drafts, please check
+the "1id-abstracts.txt" listing contained in the Internet-Drafts     
+Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 
+Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
+ftp.ietf.org (US East Coast), or ftp.isi.edu(US West Coast).
+
+
+Abstract
+
+This document defines message tracking as a prelude to the creation of 
+a message tracking model. Message tracking is a messaging  management 
+function; it provides the ability to find out, after the fact, the path 
+that a particular message took through the messaging  system, the current 
+status of that message, and its characteristics.
+
+
+Definition
+
+Message tracking refers, in its simplest form, to determining the path an 
+RFC822 message has taken, its current location, and its characteristics. 
+Message tracking allows the originator of a message to issue a request 
+about a previously sent message, the answer to which contains the delivery
+status, delivery time, delivered recipients, and other information about 
+the message. This is different from the delivery status notification (DSN) 
+function in use today, because DSNs are requested at the time of submission
+and are generated automatically; alternatively a tracking request is 
+generated independently of the previously submitted message's status and is
+done so on demand. 
+
+This capability is  analogous to the service provided by carriers of 
+conventional paper mail - the  ability to quickly locate where a package is, 
+and to determine whether or not  the package has been delivered to its
+destination. An Internet-standard approach will allow development of  
+message tracking applications that can operate in a multi-vendor messaging
+environment, and will encourage operation of the function across 
+administrative boundaries.
+
+One might ask: why should there be a standard for message tracking when 
+Internet domains will be unwilling to open themselves up to outside 
+tracking requests ?  This is one reason why we design and implement 
+Internet standards. So that there is a reliable, secure, agreed upon 
+mechanism for message tracking that people will be willing to use. 
+
+Companies have implemented and are implementing message tracking today. 
+Standardization of this technique will aid the Internet user community, 
+make Internet messaging more profitable, and fulfill a key messaging 
+management need.
+
+
+Reasons for Message Tracking
+
+Message tracking is useful for determining the whereabouts and status of 
+"lost" messages, and for several other purposes:
+
+o When there is a lack of trust in the messaging system, such as when an 
+originator claims a message failed to be delivered, the point of failure 
+may be isolated. This includes messages that were never delivered or 
+messages that were delivered incorrectly. Message tracking thus adds to the 
+overall reliability of the mail system;
+
+o Per-message information can be used for accounting, billing, and 
+performance purposes. Traffic can be itemized on a per-origin or per-
+destination basis by system or originator. This typically involves two
+steps - collection of message traffic data, followed by the gehe time they 
+are submitted to an MTA up until the time a network of MTAs discharges the 
+message onward to another entity (e.g. a proprietary mail server, IMAP 
+server, and so on).
+
+o Message tracking information adds security in that the origins of  
+potential security threats can be more precisely determined. If a system 
+were flooded with traffic, for instance, the origin of this traffic would
+become known. Message tracking information is suitable for routine security 
+audits containing the details of messaging traffic over specific time 
+intervals;
+
+o End-to-end delivery time could be measured;
+
+o Message tracking would aid in message loop detection, since unique 
+message identifiers of looping messages, when these exist, would be 
+recorded multiple times;
+
+o Performance characteristics about the type of messaging traffic could be 
+determined, such as when an inbound message causes the creation of multiple 
+outbound messages, and the percentage of messages that were actually 
+delivery reports or receipts.  This is valuable for performance 
+measurement, among other reasons;
+
+o Standardized message tracking information acts as a bridge between 
+dissimilar messaging systems and dissimilar messaging communities;
+
+
+Tracking Messages on the Public Internet
+
+One might ask: why bother to track messages if a majority of public 
+Internet traffic is point to point; messages don't live long enough to be 
+trackable, and are not an interesting event to track since you always 
+know the next point ? Just because you know where a message went that 
+doesn't mean you know what happened to it, how fast it got there, or what 
+was in it. As the Internet is used more and more for commercial/official 
+purposes a logging function is commonly embedded in the messaging system 
+internally. Even if most of the message traffic is point to point, this 
+point-to-point traffic is inter-domain, across firewalls, and thus it is 
+even more important to have a reliable tracking mechanism that 
+organizations can agree on. It is something that intra-domain messaging 
+users want. Even if 95% of transactions are point to point, the 5% that is 
+non point-to-point is still a huge amount of traffic, and this is exactly 
+the traffic that users will want to track. Once messaging traffic enters an 
+intranet or domain of any size it invariably encounters a more hierarchical 
+routing structure. 
+
+
+Who is Allowed to Track Messages
+
+Only the originators of messages are allowed to track their messages. 
+Optionally, an originator may delegate this responsibility to a third 
+party, but this is left for future study.
+
+
+How Tracking is Done: Requests and Responses
+
+The originator will issue a message tracking request using the Unique 
+Message Identifier plus security information. The originator (of both 
+the message and the query at this point) will receive optional response 
+criteria such as the message disposition, delivered recipients, delivery 
+time, and the names of MTAs that handled the message.
+
+
+Security for Message Originators
+
+One option for message security is that the originator calculates a hash A 
+to be equal to the hash of the message ID + time stamp + a per-user secret.
+The user then calculates 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 racking 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. Summarily
+
+A = H(message ID + time stamp + secret)
+B = H(A)
+
+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, but the user can decide on a message-by-message
+basis if this risk is acceptable.
+
+
+Three Possible Architectures
+
+There are ways of accomplishing message tracking without mandating the 
+addition of large amounts of new infrastructure on the participants. 
+Optionally, if more infrastructure is proven to be a good and necessary 
+thing, it should be considered. 
+
+In all cases, messages are only tracked from the time they are submitted 
+to an MTA up until the time a network of MTAs discharges the message 
+onward to another entity (e.g. a proprietary mail server, IMAP server, and 
+so on).
+
+The three architectural alternatives offered by the start-up working group 
+to date might be called "ask later", "ask now", and "ask someone else." 
+
+Under "ask later", a user requests tracking as a service when submitting a 
+message, and then at a later time issues a separate tracking request to the
+mail system. The user receives a response to the request from the tracking
+entity. This has the advantage of being deployable within the existing SMTP 
+infrastructure.
+
+Under "ask now", a user requests tracking as a service while submitting a 
+message, and receives a step-by-step report contemporaneously from each MTA
+that handles the message. This provides the user with a high level of 
+service, but also causes extra overhead: an additional message generated 
+for each hop the original message takes.
+
+Under "ask someone else", the user issues a separate message tracking 
+request to an entity other than the messaging system at a later time. 
+The user receives a response to the request from this same third-party 
+tracking entity. This has the advantage of allowing tracking to occur when
+the messaging process has failed but the platform is still working. It also 
+off-loads the tracking function from the messaging system itself. It may, 
+however, require new infrastructure in order to support it.
+
+One possibility would be to implement "ask now" and "ask later" as SMTP 
+extensions. One could implement "ask someone else" as a UDP- or TCP-based
+protocol, among other options.
+
+
+Acknowledgments
+
+Thanks to all those who participated in the message tracking meetings.
+Many thanks to Ned Freed and Harald Alvesrand for the hashing material.
+
+
+Internet Draft              Expires February 1999           Internet Draft
+
+
+
diff --git a/Documentation/en/I-D/draft-jones-msgtrk-def-01.txt b/Documentation/en/I-D/draft-jones-msgtrk-def-01.txt
new file mode 100644
index 00000000..61c405bf
--- /dev/null
+++ b/Documentation/en/I-D/draft-jones-msgtrk-def-01.txt
@@ -0,0 +1,228 @@
+
+MSGTRK BOF                             G. Jones [TomorrowSys@yahoo.com]
+INTERNET-DRAFT                         B. Ernst [bruce_ernst@lotus.ssw.com]
+draft-jones-msgtrk-def-01.txt	       G. Vaudreuil [gregv@ons.octel.com]
+Expires: September 1999
+
+
+
+
+
+                 Basic Definition of Message Tracking
+
+
+Status of this Memo
+
+This document is an Internet-Draft and is in full conformance with 
+all provisions of Section 10 of RFC2026.
+
+This document is an  Internet  Draft.  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.  Internet  Drafts  may  be updated, replaced, or obsoleted by   
+other documents at any time.  It is not appropriate to  use  Internet   
+Drafts as reference material or to cite them other than as a "working
+draft" or "work in progress."
+
+To view the entire list of current Internet-Drafts, please check
+the "1id-abstracts.txt" listing contained in the Internet-Drafts     
+Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 
+Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
+ftp.ietf.org (US East Coast), or ftp.isi.edu(US West Coast).
+
+
+Abstract
+
+This document defines message tracking as a prelude to the creation of 
+a message tracking model. Message tracking is a messaging  management 
+function; it provides the ability to find out, after the fact, the path 
+that a particular message took through the messaging  system, the current 
+status of that message, and its characteristics.
+
+
+Definition
+
+Message tracking refers, in its simplest form, to determining the path an 
+RFC822 message has taken, its current location, and its characteristics. 
+Message tracking allows the originator of a message to issue a request 
+about a previously sent message, the answer to which contains the delivery
+status, delivery time, delivered recipients, and other information about 
+the message. This is different from the delivery status notification (DSN) 
+function in use today, because DSNs are requested at the time of submission
+and are generated automatically; alternatively a tracking request is 
+generated independently of the previously submitted message's status and is
+done so on demand. 
+
+This capability is  analogous to the service provided by carriers of 
+conventional paper mail - the  ability to quickly locate where a package is, 
+and to determine whether or not  the package has been delivered to its
+destination. An Internet-standard approach will allow development of  
+message tracking applications that can operate in a multi-vendor messaging
+environment, and will encourage operation of the function across 
+administrative boundaries.
+
+One might ask: why should there be a standard for message tracking when 
+Internet domains will be unwilling to open themselves up to outside 
+tracking requests ?  This is one reason why we design and implement 
+Internet standards. So that there is a reliable, secure, agreed upon 
+mechanism for message tracking that people will be willing to use. 
+
+Companies have implemented and are implementing message tracking today. 
+Standardization of this technique will aid the Internet user community, 
+make Internet messaging more profitable, and fulfill a key messaging 
+management need.
+
+
+Reasons for Message Tracking
+
+Message tracking is useful for determining the whereabouts and status of 
+"lost" messages, and for several other purposes:
+
+o When there is a lack of trust in the messaging system, such as when an 
+originator claims a message failed to be delivered, the point of failure 
+may be isolated. This includes messages that were never delivered or 
+messages that were delivered incorrectly. Message tracking thus adds to the 
+overall reliability of the mail system;
+
+o Per-message information can be used for accounting, billing, and 
+performance purposes. Traffic can be itemized on a per-origin or per-
+destination basis by system or originator. This typically involves two
+steps - collection of message traffic data, followed by the gehe time they 
+are submitted to an MTA up until the time a network of MTAs discharges the 
+message onward to another entity (e.g. a proprietary mail server, IMAP 
+server, and so on).
+
+o Message tracking information adds security in that the origins of  
+potential security threats can be more precisely determined. If a system 
+were flooded with traffic, for instance, the origin of this traffic would
+become known. Message tracking information is suitable for routine security 
+audits containing the details of messaging traffic over specific time 
+intervals;
+
+o End-to-end delivery time could be measured;
+
+o Message tracking would aid in message loop detection, since unique 
+message identifiers of looping messages, when these exist, would be 
+recorded multiple times;
+
+o Performance characteristics about the type of messaging traffic could be 
+determined, such as when an inbound message causes the creation of multiple 
+outbound messages, and the percentage of messages that were actually 
+delivery reports or receipts.  This is valuable for performance 
+measurement, among other reasons;
+
+o Standardized message tracking information acts as a bridge between 
+dissimilar messaging systems and dissimilar messaging communities;
+
+
+Tracking Messages on the Public Internet
+
+One might ask: why bother to track messages if a majority of public 
+Internet traffic is point to point; messages don't live long enough to be 
+trackable, and are not an interesting event to track since you always 
+know the next point ? Just because you know where a message went that 
+doesn't mean you know what happened to it, how fast it got there, or what 
+was in it. As the Internet is used more and more for commercial/official 
+purposes a logging function is commonly embedded in the messaging system 
+internally. Even if most of the message traffic is point to point, this 
+point-to-point traffic is inter-domain, across firewalls, and thus it is 
+even more important to have a reliable tracking mechanism that 
+organizations can agree on. It is something that intra-domain messaging 
+users want. Even if 95% of transactions are point to point, the 5% that is 
+non point-to-point is still a huge amount of traffic, and this is exactly 
+the traffic that users will want to track. Once messaging traffic enters an 
+intranet or domain of any size it invariably encounters a more hierarchical 
+routing structure. 
+
+
+Who is Allowed to Track Messages
+
+Only the originators of messages are allowed to track their messages. 
+Optionally, an originator may delegate this responsibility to a third 
+party, but this is left for future study.
+
+
+How Tracking is Done: Requests and Responses
+
+The originator will issue a message tracking request using the Unique 
+Message Identifier plus security information. The originator (of both 
+the message and the query at this point) will receive optional response 
+criteria such as the message disposition, delivered recipients, delivery 
+time, and the names of MTAs that handled the message.
+
+
+Security for Message Originators
+
+One option for message security is that the originator calculates a hash A 
+to be equal to the hash of the message ID + time stamp + a per-user secret.
+The user then calculates 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 racking 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. Summarily
+
+A = H(message ID + time stamp + secret)
+B = H(A)
+
+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, but the user can decide on a message-by-message
+basis if this risk is acceptable.
+
+
+Three Possible Architectures
+
+There are ways of accomplishing message tracking without mandating the 
+addition of large amounts of new infrastructure on the participants. 
+Optionally, if more infrastructure is proven to be a good and necessary 
+thing, it should be considered. 
+
+In all cases, messages are only tracked from the time they are submitted 
+to an MTA up until the time a network of MTAs discharges the message 
+onward to another entity (e.g. a proprietary mail server, IMAP server, and 
+so on).
+
+The three architectural alternatives offered by the start-up working group 
+to date might be called "ask later", "ask now", and "ask someone else." 
+
+Under "ask later", a user requests tracking as a service when submitting a 
+message, and then at a later time issues a separate tracking request to the
+mail system. The user receives a response to the request from the tracking
+entity. This has the advantage of being deployable within the existing SMTP 
+infrastructure.
+
+Under "ask now", a user requests tracking as a service while submitting a 
+message, and receives a step-by-step report contemporaneously from each MTA
+that handles the message. This provides the user with a high level of 
+service, but also causes extra overhead: an additional message generated 
+for each hop the original message takes.
+
+Under "ask someone else", the user issues a separate message tracking 
+request to an entity other than the messaging system at a later time. 
+The user receives a response to the request from this same third-party 
+tracking entity. This has the advantage of allowing tracking to occur when
+the messaging process has failed but the platform is still working. It also 
+off-loads the tracking function from the messaging system itself. It may, 
+however, require new infrastructure in order to support it.
+
+One possibility would be to implement "ask now" and "ask later" as SMTP 
+extensions. One could implement "ask someone else" as a UDP- or TCP-based
+protocol, among other options.
+
+
+Acknowledgments
+
+Thanks to all those who participated in the message tracking meetings.
+Many thanks to Ned Freed and Harald Alvesrand for the hashing material.
+
+
+Internet Draft              Expires September 1999           Internet Draft
+
+
+
+
+