[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
MSGMIB Working Group (proposed)                              G. Jones
INTERNET-DRAFT                                      MITRE Corporation
                                                  [gbjones@mitre.org]

                                                          Bruce Ernst
                                        Lotus Development Corporation
                                              [bernst@softsw.ssw.com]

                                                       Greg Vaudreuil
                                               Octel  Network Service
                                           [greg.vaudreuil@octel.com]



                        March 1998

                        Message Tracking Model
                   <draft-jones-msgmib-model-00.txt>


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 learn the current status of any Internet-Draft, please  check  the
   1id-abstracts.txt  listing  contained  in  the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net,  ftp.nisc.sri.com,  or
   munnari.oz.au.


Abstract

This document defines an SNMP-based message tracking model  for
electronic messaging  management usage. Message tracking is 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.

This document defines the model, architecture, and requirements for message
tracking. An SNMP MIB to support message tracking is found in a related
document.






Expires: September 1, 1998                                     [Page 1]


Internet Draft                                             March 1998


1.  The SNMP Network Management Framework.

   The major components of the SNMP Network Management framework  are
   described in the documents listed below.


        o RFC 1902 [1] defines the Structure of Management Information
           (SMI), the mechanisms used for describing and naming objects
           for the purpose of management.

        o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed
           objects (MO) for the Internet suite of protocols.

        o RFC 1905 [3] defines the protocol used for network access to
           managed objects.

        o [ADD SNMPv3 HERE]


The framework is adaptable/extensible by defining new MIBs to  suit  the
requirements of specific applications/protocols/situations.

Managed objects are accessed via a virtual information store,  the  MIB.
Objects  in  the  MIB  are  defined  using the subset of Abstract Syntax
Notation One (ASN.1) defined in the SMI. In particular, each object type
is  named by an OBJECT IDENTIFIER, which is an administratively assigned
name. The object  type  together  with  an  object  instance  serves  to
uniquely  identify  a  specific  instantiation  of the object. For human
convenience, often a textual string, termed the descriptor, is  used  to
refer to the object type.



2. Message Tracking and the Need for Message Tracking

Message tracking refers, in its simplest form, to determining the path a message
has taken, its current location, and its characteristics.  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. This document discusses a
specific SNMP-based per-message mechanism to query the messaging system
to perform message tracking. SNMP is an established network and application
management technology that provides an abundance of user tools and a cross-
vendor, cross-technology ubiquity. As SNMP continues to evolve (e.g.
SNMPv3), the mechanisms in this document will leverage those new
technologies.  Use of the approach in this document will allow development of
message tracking applications that can operate in a multi-vendor messaging
environment:




Expires: September 1, 1998                                     [Page 2]


Internet Draft                                             March 1998

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 of 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 generation of appropriate reports and/or billing.

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 securty audits containing
the details of messaging traffic over specific time intervals;

o The message tracking MIB 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;


3. Requirements

The following requirements and definitions are agreed upon by the group:

o  A query is a question that a user asks to get message tracking
information. One or more SNMP operations may be necessary to complete a
query.

o  A user is either an individual mail user or a mail system
administrator.

o  A message tracking domain consists of all MTAs under the control of
an administrator.





Expires: September 1, 1998                                     [Page 3]


Internet Draft                                             March 1998



o  The user should be able to query based upon
   - unique message identifier
   - recipient
   - originator
   - time range (start time-to-end time)

o  The user should be able to use wild-carded values.

o  The user should be able to narrow the scope of the query using
multiple criteria and combinations of criteria from items (3) and (4).

o  End users should only be able to get responses to queries about mail
they have sent or received.

o  Privileged persons (system administrators) should be able to get
responses to queries about mail sent by or received by people for whom
they are designated or trusted administrators. (Remember one may be a
self-appointed yet legitimate system administer for a domain of only 2
mailboxes....)

o  "Queries" that span domain boundaries have to be restricted to
traffic that left one domain for another

o  The system must scale to the size of the email Internet

o  The system must respond within a reasonable period to any request.
We would propose 10 seconds for a 3 hop path as reasonable.

o  Queries should place no unreasonable burden upon the managed
systems.  We propose an assumption of 1 query per 5,000 messages for
purpose of evaluating this requirement.


[THE FOLLOWING MATERIAL WAS PREVIOUSLY POSTED AND
MUST AGREE WITH THE ABOVE LIST]

The Messaging Manager must be able to trace a message on behalf of a user, to
discover whether the message was in fact delivered, or to determine where the
message may be stuck in the system.  Message Tracking is often required more
by end users during times when they distrust the System - when moving from a
real-time delivery system to a store-and-forward system, or when the System is
new, or is undergoing significant change.  The management information
described in this document provides for tracking on a per-message, per-recipient
basis.  A message's current status, as well as the complete path taken by a
message, on a per-recipient basis, can be obtained by consulting Messaging
Management agents which comply with this specification.



Expires: February 1, 1998                                     [Page 4]


Internet Draft                                             March 1998

As the Messaging System shifts to being used for applications which require
higher reliability (e.g., EDI), Message Tracking will be required to assure the
users that the requisite reliability is indeed in place.  If a question of "lost mail"
arises, the mail manager must be able to track the message from its entry into
the mail system until it is delivered, non-delivered, or passes outside the
management sphere into another management sphere.  The track must be able
to cross multiple messaging components from multiple vendors.  There must be
provision for passing the query to the appropriate authority in the next
management sphere so that the track can be continued there. Cross-jurisdictional,
agent-based message tracking, as described in this document, addresses this
equirement.  In addition to being multi-component and multi-vendor, this
specification also addresses multiple management technologies.

Messages must be trackable from point of origin, based on the sender providing
the posting date and time and destination.  This includes one Mail Manager
asking the Mail Manager of the next management sphere to continue the track
of a message entering that sphere at a specific date and time from a stated point
of origin. Message tracking queries, filtered based on time and recipient (i.e., in
the case when a specific message ID is not known) is included in this
specification.  Note however that support for this sort of filtering is optional.

Messages must also be trackable across domains - from one enterprise, across
the public wide-area network, and into the destination enterprise.


4. Architecture

Let [us] define three actors for the message trace model.

        The first is the MTA that may have knowledge of a message and is
the target of the query.

        The second is the email system used to send messages.  This
sending email system is broadly defined such that sending system is able
to provide to the originator or recipient key information necessary to
initiate a trace.  This information may include anything available in a
message header including date, recipient, and message-ID plus important
attributes such as the first-hop MTA the message was sent to.  This is
more broadly defined than a typical email user agent in that the senders
email gateway may be considered part of the sending system.  (For this
model, the sendmail that adds the date and message-ID is part of the
sending "system".  The proprietary-to-Internet gateway that creates
internet-legal email addresses and message-id's is also part of the
sending system).







Expires: September 1, 1998                                     [Page 5]


Internet Draft                                             March 1998


        The third is a message tracking client.  This may be integrated
into the email client, stand-alone, hosted on a web server, or otherwise
able to generate an SNMP query in response to input from an end user or
administrator.


        The following "use case" illustrate the relationships between
the actors.


        a. End users creates a email messages from the sending system
through one or more MTA's.

        b. The originator desires a trace and forms a query from the
message tracking client using available from the message sending system.

        c. The message trace clients issues the query to the first MTA
in the path.  If successful, the MTA returns information regarding the
message including the canonical name of the next MTA in the path.  The
message trace issues a subsequent query against the next MTA in the path
until either the query fails of the MTA indicates the delivery was
successful.
[NOTE: You need to expand item 3 to add the following: a utility might
also want to visit a list of MTAs simulataneously, in parallel, and later
correlate the information about path in a central place. You also might
not know the starting point, so you have to kick off a parallel trace to a
(hopefully limited) number of candidate MTAs in order to find out the
starting point. Thirdly, it might make sense to set up a periodic "pull" of
information from a list of MTAs at predefined intervals.]

        The Outbox Model.

        In the message trace model, the sending system is considered to
be atomic.  In the current universe, there are various boundaries
between the user agent and the balance of the sending system.  In some
cases the sending system is an all-in-one mail system.  In others the
traditional Unix email client/Sendmail split is present.  In many
corporate and proprietary email systems, the client, intermediate post
offices, and the Internet gateway together are a sending system.
Further, these systems have varying trust relationships between the
various part of the system.

        It may be useful to define a separate model for those
implementations where the user interface portion of the sending system
does not have sufficient information to create a message trace query and
must rely upon a repository of general information stored elsewhere in
the sending system.



Expires: September 1, 1998                                     [Page 6]


Internet Draft                                             March 1998


        If one defines there to be an outbox agent as part of the
balance of the message sending system, one may consider there to be a
query protocol between the message trace client and the outbox agent.
This protocol must provide an authenticated link between the user and
the information necessary to create a message trace query.

Okay then, have we answered all of the following questions (probably not yet):

a. What components are in the messaging system ?  The management system ? Define each one
      (MTA, UA, agent, manager). Is a "message store" the same as an MTA for our purposes ?
      Is a "gateway" the same as an MTA ?  What components are out of scope ?
b. What does it mean to "track" a message ? What is the path of the message through the
      components; e.g., what are we tracking and what are we not tracking ?  (the charter says
      we only track a message from the time an MTA accepts it to the time it is handed off to
      something other than an MTA. This should be restated here)
c. What is routing ?  What is a "previous hop" MTA and what is a "next hop" MTA ?
d. What is a MIB and what is SNMP ?
e. Which versions of SNMP are we using (assume both v1 and v3) and what are their differences ?
f. Are we addressing control functions; that is, the ability to control individual messages (beware,
      if this genie gets out of the bottle I'm going to ask whoever proposes it to write a separate
      document)



5. Security Topics


5.1    Tracking under SNMPv1

     a. What technical information is available in SNMPv1 to support security ?  We may have to mention
         the definition of community string, access controls, additional MIB variables to support security
         since MIB variables in v1 might have to serve as replacement for functions in v3
     b. What types of users will be allowed to track messages ?  Perhaps there should be two levels of
         access: an "ordinary" user and an "adminstrative" user. For example, the ordinary user will have
         to have an exact-match message ID; the administrative user will be allowed to get messages using
         the delivery time and other people's e-mail addresses
      c. An SNMPv1 community string serves as a password. If an e-mail user asks his/her provider to
         track a message given a (sufficiently long) message ID and a community string, isn't this the same
         as or better than a customer calling his/her bank with a social security ID and a mother's maiden
         name on an unsecured phone line ?    Note: such a scheme is still vulnerable to replay attack.
         What about router management today. The control of IP routers is performed using community
         strings in the clear, so why not message tracking ?








Expires: September 1, 1998                                     [Page 7]


Internet Draft                                             March 1998

     d. Can we restrict requests to certain recipient names or ranges of message IDs ?  For example, bar
         the ability to track messages going to/from the president of the company ?  Could high-importance
         messages be assigned IDs in a particular range to soignify their importance (note this is probably
         too complicated to implement) ?


5.2   Tracking under SNMPv3

At the moment, the SNMPv3 security model that exists (user-based) assumes
that there are a countable number of interested parties, and an agent will have
a trust relationship with each one. Access by "a fairly sophisticated application" may mean 2 different things, like this:

 o  User -----|-----> Application -----> SNMP agent
            trust boundary
            non-SNMP proto         SNMP

 o  User ---------> Application  -----|----> SNMP agent
            anything                  trust boundary
                                                   SNMP


In the first case, the application is trusted by the SNMP agent, and has the job of
verifying what the user is allowed to see. In this case, we should be designing
the non-SNMP protocol, not the MIB, since that's the interface that has to be
open.

In the second case, the application has exactly the same trust as the user, and
adding it into the chain contributes *nothing* to the trust model; the
application is, conceptually, just part of the user's User Interface.

The idea of "locally applied policy" is reasonable, but the protocol MUST
supply enough handles for at least ONE reasonable security policy
to work (apart from "everyone can see everything).

That said, we must look at the following:

     a. What technical information is available in SNMPv3 to support security ?  SNMPv3 has
         authentication features (USM) and access controls (VACM).  Additional MIBs were defined
         to support security, we think
      b. We still want to have levels of users. Here is an example: when there is no authentication, use the
         scheme defined above for SNMPv1. When an "ordinary" user authenticates, allow that user to
         track only those messages he/she is the originator or recipient of. When an "administrative"
         user authenticates, allow tracking using full range of criteria including time ranges and wild-cards.
      c. Note about the authentication feature in SNMPv3: when a user requests to authenticate, asks to
         track a message, claims to be the originator of the message, and supplies the e-mail address to
         be tracked, there has to be a way to correlate the authentication key with the e-mail address of
         the requestor



Expires: September 1, 1998                                     [Page 8]


Internet Draft                                             March 1998

5.3   For both v1 and v3

      a. What is the role of access control ?  Can we use built-in access control mechanisms to restrict access
          to certain ranges of OIDs for certain lists of users ?
      b. What is the role of firewalls and transport layer security ?  Is there something we can leverage here ?
      c. We can restrict the information that queries contain but we can also restrict the information returned
         in the response; for instance, I can limit the response to contain only the message disposition status (it
         got there or it didn't) if I really wanted to be fussy about it



6. Inter-domain Tracking

   a. There are two walls we hit here: when a request to track a message reaches a "domain boundary" it
      gets  complicated EITHER because the IP address of the next hop MTA is not known (needs to be
      looked  up) OR access to the agent at the next hop is denied. In the first case, should mention that
      there must be a way to look these things up (DNS, SQL database, table lookup) ? For the second case,
      read on...
   b. Should out-of-domain access be treated as a MAY ?
   c. Do we need to define a class of user like an "out of domain" user, who can only track messages
      entering or leaving their domain ?  Could we use the domain names in the e-mail addresses they are
      tracking to support this ?  Can we limit the amount of information in the query response so we don't
      give away important operational information ?
   d. When a tracking request reaches a domain "boundary", do we want to issue a referral such as the
      e-mail address of an administrator, a phone number, a person's name, or an IP address ?
   e. Should we specify that each domain supply a special "boundary agent", which, when it receives a
      request, queries other agents in the domain and correlates the responses ?
   f. In all cases, should we declare that the responsiblity for delivering a message stops at the domain
      boundary ?























Expires: September 1, 1998                                     [Page 9]

Internet Draft                                             March 1998


7. Authors Addresses


   Gordon  Jones
   MITRE  Corporation
   1820 Dolley Madison Blvd.
   McLean, VA 22102-3481

   Phone: +1 703 883 7670
   E-Mail: gbjones@mitre.org


   Bruce Ernst
   Lotus Development Corporation

   Phone: +1 610 251 3404
   E-Mail: bernst@softsw.ssw.com


   Gregory M. Vaudreuil
   Octel Network Services
   17080 Dallas Parkway
   Dallas, TX 75248-1905

   Phone/Fax: +1-214-733-2722
   E-Mail: Greg.Vaudreuil@Octel.Com