[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 3888

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/