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

Versions: 00                                                            
MADMAN Working Group                    Bruce Ernst [bernst@softsw.ssw.com]
INTERNET-DRAFT                          Lotus Development Corporation
draft-ietf-madman-trackmib-00.txt       Gordon Jones [gbjones@mitre.org]
                                        MITRE Corporation
                                        Jonathan Weintraub
                                        Electronic Data Systems, Inc.


                        August 1997

                     Message Tracking MIB


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 a message tracking Management Information Base
(MIB) for electronic messaging usage. Message tracking is the ability to find
out, after the fact, the path that a particular message took through the
messaging system and the current status of that message.













Expires: February 1, 1997                                     [Page 1]


Internet Draft                                             August 1997


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.


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 and it's current location.  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: February 1, 1997                                     [Page 2]


Internet Draft                                             August 1997

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 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, 1997                                     [Page 3]


Internet Draft                                             August 1997

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.

The Messaging Manager must be able to track 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.  In other words, message
tracking will be critically important during times of downsizing.

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.

Messages must be trackable from point of origin, based on the sender providing
the posting date and time and destination.  This included 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.



Expires: February 1, 1997                                     [Page 4]


Internet Draft                                             August 1997



4. MIB Data to Support Message Tracking

This MIB contains the syntax for message tracking via SNMP.  The attributes
defined are identical to those defined for message tracking via e-mail, except
for those attributes that are required purely to enable SNMP-specific semantics.

When making use of SNMP, it is expected that the following mode of operation
will be used.  The entity acting in the manager role issues one or more "SET"
operations filling in a row in a request table.  The variables set in the request
table together comprise a message tracking query. The entity acting in the agent
role reads the values set in the request table, queries the local message store
(or usage logs), and returns information regarding messages that satify the query
criteria in a response table.  The entity acting as the manager then reads the
response table and notifies an administrator or performs additional queries as
required.

In the message tracking MIB that follows, there are three tables:

1. the mtaInformationTable
2. the msgTrackRequestTable
3. the msgTrackResponseTable

The mtaInformationTable contains one entry for each MTA that is monitored
by this agent.  The table contains information about the MTA as a whole, such
as: the name of the MTA and the length of time that the MTA has been recording
information.  This last item is important to know, since if the MTA indicates that
it only has information about messages that have passed through it in the last two
days, and the administrator wishes to track a message that was sent four days ago,
then there will be no need to attempt to track the message through this MTA.

The msgTrackRequestTable is used by a manager to specify a query to be made
of the agent.  It is not required that the manager have any knowledge of a unique
message identifier, but knowledge of some information pertaining to the message
in question is recommended.  Since the query information may be matched by a
number of potential matches, it is possible to find out information about several
different messages.

The msgTrackResponseTable is a parallel to the msgTrackRequestTable in that it
holds the response(s) to the queries posed in the msgTrackRequestTable. The
manager reads this table to retrieve information about the messages that match
the input query information.  The two tables share a common index to facilitate
navigation between them.






Expires: February 1, 1997                                     [Page 5]


Internet Draft                                             August 1997


MESSAGE-TRACKING-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       OBJECT-TYPE, MODULE-IDENTITY, Counter32
   FROM SNMPv2-SMI
       DisplayString, TimeInterval, DateAndTime
   FROM SNMPv2-TC;

- --   Note that in SNMPv1 the IMPORTS section should look like the following:
- --   IMPORTS
- --       OBJECT-TYPE, enterprises, Counter, Gauge, TimeTicks
- --              FROM RFC1155-SMI
- --       DisplayString
- --             FROM RFC1213-MIB;


- -- OBJECT IDENTIFIERS
  MsgTracking   OBJECT IDENTIFIER ::= { experimental 73 2 }

- -- MODULE IDENTIFICATION   use in V2 version only
mta-message-track MODULE-IDENTITY
       LAST-UPDATED "9704110000Z"
       ORGANIZATION "IETF"
       CONTACT-INFO
             "Gordon  Jones
               Postal: 1820 Dolly Madison Boulevard
                           Mc Lean, VA 22102-3481
               Tel:    +1 703 883 7670
               Fax:    +1 703 883 7670
               E-mail: gbjones@mitre.org"
       DESCRIPTION
         "The MIB module describing message tracking"
       ::= { MsgTracking 1 }

- -- Note that the MODULE-IDENTITY macro does not exist in SNMP version 1,
- -- for a V1 implementation, replace the above macro with the following line :
- --  mta-message-track OBJECT IDENTIFIER ::= {MsgTracking 1 }


- -- Note that the textual conventions DateAndTime and TimeInterval
- -- do not exist in SNMPv1, for a V1 implementation include the following
- -- 2 lines:
- --   DateAndTime ::= DisplayString
- --   TimeInterval ::= INTEGER (0..2147483647)





Expires: February 1, 1997                                     [Page 6]


Internet Draft                                             August 1997


- -- Define the NameForm textual convention for originator and recipient
- -- names in this MIB
NameForm ::= INTEGER {
   freeForm(1),
   x400(2),
   smtp(3)
 }

- -- Define the DispositionStatus textual convention which indicates the
- -- disposition of a message by the MTA for a particular recipient. Values
- -- are:
- -- unknown   - The disposition of the message could not be determined
- -- transferred - The message was forwarded to another MTA for
- -- delivery without name or content transformation.
- -- delivered - The message was delivered to the intended recipient.
- -- non-delivered - The message could not be delivered to the intended
- -- recipient.
- -- redirected - The message was forwarded to another MTA for
- -- delivery.  The recipient name and/or messageId
- -- may have changed as a result of this process.
- -- dlist-expanded - The intended recipient was a distribution list
- -- which was expanded by the MTA.
- -- in-queue - The message for this recipient is currently being
- -- processed by the MTA.

DispositionStatus ::= INTEGER {
   unknown(1),
   transferred(2),
   delivered(3),
   non-delivered(4),
   redirected(5),
   dlist-expanded(6),
   in-queue(7)
   }

- -- Define the MsgType textual convention. Values are:
- --
- -- data
- -- status
- -- probe

MsgType ::= INTEGER {
  any(1),
  data(2),
  status(3),
  probe(4)
  }


Expires: February 1, 1997                                     [Page 7]


Internet Draft                                             August 1997


- -- How this mib works :
- -- Most message tracking MIBs operate on the presupposition that the manager
- -- entering a query knows the unique message ID for the message being tracked.
- -- In practice, this is often not the case.  This MIB allows for a 2-step
- -- query process - find the appropriate message, then track it.


- --     +==============+
- --     | Manager      | = 1 => +=====================================+
- --     +==============+ = 6 => | msgTrackRequestTable                |
- --           ^                 +=====================================+
- --           |                           |
- --           |                           2    +=========+
- --           |                           + => | Agent   |
- --           |                                +=========+
- --           5                                      |      +======================+
- --           |                                      + 3 => | Message Store        |
- --           |                             += 4 ========== +======================+
- --           |                             |
- --           |                             v
- --           |                +========================================+
- --           ===============> | msgTrackResponseTable                  |
- --                            +========================================+
- --
- --  STEP 1:
- -- Using the index obtained from 'msgTrackNextRequestIndex', a manager
- -- creates a conceptual row in the 'msgTrackRequestTable', filling in
- -- as many message attributes as are known.  The manager also specifies
- -- in 'reqMaxResponses', the maximim number of possible 'hits' for an
- -- underspecified query.
- --  STEP 2:
- -- When the agent detects a new conceptual row in 'msgTrackRequestTable',
- -- it forms a query to be executed against the message store(s).
- --  STEP 3:
- -- The agent issues the query against the message store and receives some
- -- response(s).
- --  STEP 4:
- -- The agent then transfers up to 'reqMaxResponses' possible responses
- -- to newly created conceptual rows in the 'msgTrackResponseTable'. The agent
- -- then sets the value of 'reqResponseStatus' in the 'msgTrackRequestTable'
- -- to notify the manager of the results of the query.
- --  STEP 5:
- -- The manager, having detected a change in 'reqResponseStatus', knows that
- -- the query is complete.  It reads the potential responses from the
- -- 'msgTrackResponseTable' and presents them to the end-user.




Expires: February 1, 1997                                     [Page 8]


Internet Draft                                             August 1997



- --  STEP 6:
- -- The manager then instructs the agent to destroy the conceptual row
- -- created in the 'msgTrackRequestTable', which causes the agent to
- -- destroy the corresponding entries in the 'msgTrackResponseTable'.
- --  STEP 7:  (optional, not illustrated)
- -- If the original query did not produce an adequate response, a new entry
- -- is created in the 'msgTrackRequestTable'.  Entries in this table are
- -- never reused!
- --
- --

- -- MESSAGE TRACKING REQUEST TABLE:

mtaInformationTable OBJECT-TYPE
 SYNTAX SEQUENCE OF mtaInformationEntry
 MAX-ACCESS not-accessible
 STATUS current
 DESCRIPTION
   "The table holding information about the MTA being queried.  A table
     is used because there may be multiple MTAs at a single host."
       ::= { mta-message-track 1 }


mtaInformationEntry OBJECT-TYPE
 SYNTAX  mtaInformationEntry
 MAX-ACCESS not-accessible
 STATUS current
 DESCRIPTION
   "One entry in the table holding information about the MTA being
     queried"
 INDEX { mtaIndex }
       ::= { mtaInformationTable 1 }

mtaInformationEntry ::=  SEQUENCE {
 mtaIndex
     INTEGER,
 mtaName
    DisplayString,
 mtaMessagingType
    DisplayString,
 startTimeforRecordedInformation
    DateAndTime,
 alternativeAgent
    DisplayString
}



Expires: February 1, 1997                                     [Page 9]


Internet Draft                                             August 1997



mtaIndex   OBJECT-TYPE
 SYNTAX      INTEGER (1..2147483647)
 ACCESS      read-only
 STATUS      current
 DESCRIPTION
   "The integer index into this table."
 ::= { mtaInformationEntry 1 }

mtaName  OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS      read-only
 STATUS      current
 DESCRIPTION
  "The name of the MTA described in this row of the table."
 ::= { mtaInformationEntry 2 }

mtaMessagingType  OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS      read-only
 STATUS      current
 DESCRIPTION
   " Common name of the messaging system of this MTA (e.g. X.400, SMTP)."
 ::= { mtaInformationEntry 3 }

mtaStartTimeforRecordedInformation  OBJECT-TYPE
 SYNTAX      DateAndTime
 ACCESS      read-only
 STATUS      current
 DESCRIPTION
   " The date/time of the oldest message tracking information
      available from this MTA."
 ::= { mtaInformationEntry 4 }

mtaAlternativeAgent  OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS      read-only
 STATUS      current
 DESCRIPTION
   "The name (or address) of another agent  that may have message
                   tracking information concerning this MTA."
 ::= { mtaInformationEntry 5 }







Expires: February 1, 1997                                     [Page 10]


Internet Draft                                             August 1997


msgTrackNextRequestIndex  OBJECT-TYPE
 SYNTAX      Counter32      -- Note that in SNMPv1, the syntax is simply
'Counter'
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "The index that may be used by a manager (requestor) on a 'set-request' PDU
    to create a new conceptual row in the msgTrackRequestTable table (and
    thereby issue a message tracking query)."
 ::= { mta-message-track 2 }

msgTrackRequestTable OBJECT-TYPE
 SYNTAX     SEQUENCE OF MsgTrackRequestEntry
 ACCESS    not-accessible
 STATUS     current
 DESCRIPTION
   "The table holding all active message tracking requests."
 ::= { mta-message-track 3 }

msgTrackRequestEntry OBJECT-TYPE
 SYNTAX      MsgTrackRequestEntry
 ACCESS     not-accessible
 STATUS      current
 DESCRIPTION
   "The entry associated with each request for message information."
 INDEX { reqEntryIndex }
 ::= { msgTrackRequestTable 1 }

MsgTrackRequestEntry ::= SEQUENCE {
 reqEntryIndex
     INTEGER,
 reqRowStatus
     INTEGER,
 reqResponseStatus
     INTEGER,
 reqMaxResponses
     INTEGER,
 reqUniqueMsgId
     DisplayString,
 reqInboundMsgId
     DisplayString,
 reqOutboundMsgId
     DisplayString,
 reqInboundOriginator
     DisplayString,




Expires: February 1, 1997                                     [Page 11]


Internet Draft                                             August 1997



reqOutboundOriginator
     DisplayString,
 reqOriginatorNameForm
     NameForm,
 reqInboundRecipient
     DisplayString,
 reqOutboundRecipient
     DisplayString,
 reqRecipientNameForm
     NameForm,
 reqSubject
     DisplayString,
reqMinMsgSize
     INTEGER,
 reqMaxMsgSize
     INTEGER,
 reqEarliestArrivalTime
     DateAndTime,
 reqLatestArrivalTime
     DateAndTime,
 reqDispositionStatus
     DispositionStatus,
 reqFailureReason
     DisplayString,
 reqMsgType
     MsgType,
 reqCollapseRecipients
     INTEGER
}

reqEntryIndex  OBJECT-TYPE
 SYNTAX     INTEGER (1..2147483647)
 ACCESS    read-only
 STATUS     current
 DESCRIPTION
   "The integer index into the msgTrackRequestTable table."
 ::= { msgTrackRequestEntry 1 }

reqRowStatus  OBJECT-TYPE
 SYNTAX     INTEGER {
   active(1),
   notInService(2),
   notReady(3),





Expires: February 1, 1997                                     [Page 12]


Internet Draft                                             August 1997


   createAndGo(4),
   createAndWait(5),
   destroy(6)
        }
 ACCESS    read-write
 STATUS     current
 DESCRIPTION
   "The status of the conceptual row. These are mapped to the same values as
     the RowStatus textual conversion in SNMPv2 and carry the same semantics
     with one exception: the exception is that when a manager (requestor) sets the
     value to destroy(6), this also has the added semantics of deleting all
     conceptual rows in the msgTrackResponseTable table whose respEntryIndex
     matches the reqEntryIndex of this conceptual row."
 ::= { msgTrackRequestEntry 2 }

reqResponseStatus  OBJECT-TYPE
 SYNTAX       INTEGER {
   unknown(1),
   inProgress(2),
   failedNoMatches(3),
   failedInvalidQuery(4),
   failedError(5),
   successUnderqualified(6),
   success(7)
         }
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "Indicates the status of this query and its responses in the
    msgTrackResponseTable. Values are:
    unknown  -  The status of this query is not known.
    inProgress  -  The agent(responder) is still processing the request.
    failedNoMatches    -  The query has been processed and has produced no
    matches.
    failedInvalidQuery  -  The query could not be processed  due to invalid or
    missing data in the original query.
    FailedError  -  The query could not be processed due to an error in the
    agent(responder).
    successUnderqualified  -  The query was successfully processed, but the query
    was found to be underqualified.  That is, more reponses were found than were
    specified in reqMaxResponses. reqMaxResponses entries were returned in the
    msgTrackResponseTable.
    success  -  The query succeeded, returning from 1 to reqMaxResponse
    entries in the msgTrackResponseTable."
 ::= { msgTrackRequestEntry 3 }




Expires: February 1, 1997                                     [Page 13]


Internet Draft                                             August 1997



reqMaxResponses  OBJECT-TYPE
 SYNTAX       INTEGER (1..100)
 ACCESS     read-write
 STATUS      current
 DESCRIPTION
   "Specifies the largest number of responses to be returned in the
    msgTrackResponseTable on an underspecified query (i.e. the
    maximum value of respMsgIndex in the msgTrackResponseTable
    conceptual row whose  respEntryIndex matches the reqEntryIndex of this
    conceptual row)."
 ::= { msgTrackRequestEntry 4 }

reqUniqueMsgId  OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-write
 STATUS      current
 DESCRIPTION
   "Specifies a unique message id used internally by the MTA for identification
    of a message.  This form of the message id may or may not be identical to the
    inbound and/or outbound forms of the message id.  If specified, this may be
    the only search criteria required. If the entire unique message id is not
    specified, prefix matching is assumed. Set to an empty (zero length) string if
    unknown or irrelevant to query."
 ::= { msgTrackRequestEntry 5 }

reqInboundMsgId  OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-write
 STATUS      current
 DESCRIPTION
   "Specifies a unique message id as received by the MTA for identification of
    a message.  This form of the message id may or may not be identical to the
    internal and/or outbound forms of the message id.  If specified, this may be the
    only search criteria required.  If the entire inbound message id is not specified,
    prefix matching is assumed.  Set to an empty (zero length) string if unknown or
    irrelevant to query."
 ::= { msgTrackRequestEntry 6 }

reqOutboundMsgId  OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-write
 STATUS      current
 DESCRIPTION





Expires: February 1, 1997                                     [Page 14]


Internet Draft                                             August 1997



   "Specifies a unique message id as transmitted by the MTA for identification
    of a message.  This form of the message id may or may not be identical to the
    internal and/or inbound forms of the message id.  If specified, this may be the
    only search criteria required.  If the entire outbound message id is not
    specified, prefix matching is assumed.  Set to an empty (zero length) string if
    unknown or irrelevant to query."
 ::= { msgTrackRequestEntry 7 }

reqInboundOriginator  OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-write
 STATUS      current
 DESCRIPTION
"Identifies the originator of the message in its received form, expressed in
    string format.  The style and format of this identifier varies according to a
    specific messaging technology. As a result of potentially disparate messaging
    technologies, this identifier is only guaranteed to be the name known to the
    end-user on the first  MTA in the delivery sequence.  If
    reqOriginatorNameForm is set to 'x.400(2)' or 'smtp(3)', the supplied
    attributes will be considered in the match.  Any attributes not supplied will be
    wildcarded.  If reqOriginatorNameForm is set to 'freeForm(1)', this value is
    assumed to be a substring of the originator name. Set to an empty (zero
    length) string if unknown or irrelevant to query."
 ::= { msgTrackRequestEntry 8 }

reqOutboundOriginator  OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-write
 STATUS      current
 DESCRIPTION
   "Identifies the originator of the message in its transmitted form, expressed
    in string format.  The style and format of this identifier varies according to a
    specific messaging technology. As a result of potentially disparate messaging
    technologies this identifier is only guaranteed to be the name known to the
    end-user on the last  MTA in the delivery sequence.   If
    reqOriginatorNameForm is set to 'x.400(2)' or 'smtp(3)', the supplied attributes
    will be considered in the match.  Any attributes not supplied will be
    wildcarded. If reqOriginatorNameForm is set to 'freeForm(1)', this value is
    assumed to be a substring of the originator name.  Set to an empty (zero
    length) string if unknown or irrelevant to query."
 ::= { msgTrackRequestEntry 9 }

reqOriginatorNameForm  OBJECT-TYPE
 SYNTAX      NameForm




Expires: February 1, 1997                                     [Page 15]


Internet Draft                                             August 1997



ACCESS     read-write
 STATUS      current
 DESCRIPTION
   "Identifies the name form of originator strings supplied in the
    reqInboundOriginator and/or reqOutboundOriginator values.  This value is
    used by the agent to perform name form dependant parsing of these values.
    If neither of these strings are supplied, this name form value is irrelevant to
    the query.  A value of 'any(1)' implies that  no special parsing should be
    performed on the originator names supplied."
 ::= { msgTrackRequestEntry 10 }

reqInboundRecipient  OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-write
 STATUS      current
 DESCRIPTION
   "Identifies one of the recipients (the one to be tracked) of the message in
    its received form, expressed in string format.  The style and format of this
    identifier varies according to a specific messaging technology.  As a result
    of potentially disparate messaging technologies, this identifier is only
    guaranteed to be the name an end-user  knows the recipient by on the first
    MTA in the delivery sequence. If reqRecipientNameForm is set to 'x.400(2)'
    or 'smtp(3)', the supplied attributes will be considered in the match.  Any
    attributes not supplied will be wildcarded. If reqRecipientNameForm is set to
    'freeForm(1)', this value is assumed to be a substring of the recipient name.
    Set to an empty (zero length) string if unknown or irrelevant to query."
 ::= { msgTrackRequestEntry 11 }

reqOutboundRecipient  OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-write
 STATUS      current
 DESCRIPTION
   "Identifies one of the recipients (the one to be tracked) of the message in
    its transmitted form, expressed in string format.  The style and format of this
    identifier varies according to a specific messaging technology.  As a result of
    potentially disparate messaging technologies, this identifier is only guaranteed
    to be the name an end-user knows the recipient by on the last MTA in the
    delivery sequence. If reqRecipientNameForm is set to 'x.400(2)' or 'smtp(3)',
    the supplied attributes will be considered in the match.  Any attributes not
    supplied will be wildcarded. If reqRecipientNameForm is set to 'freeForm(1)',
    this value is assumed to be a substring of the recipient name.  Set to an empty
    (zero length) string if unknown or irrelevant to query."
 ::= { msgTrackRequestEntry 12 }




Expires: February 1, 1997                                     [Page 16]


Internet Draft                                             August 1997



reqRecipientNameForm  OBJECT-TYPE
 SYNTAX      NameForm
 ACCESS     read-write
 STATUS      current
 DESCRIPTION
   "Identifies the name form of recipient strings supplied in the
    reqInboundRecipient and/or reqOutboundRecipient values.  This value is
    used by the agent to perform  name form dependant parsing of these values.
    If neither of these strings are supplied, this name form value is irrelevant to
    the query.  A value of 'any(1)' implies that no special parsing should be
    performed on the recipient names supplied."
 ::= { msgTrackRequestEntry 13 }

reqSubject  OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-write
 STATUS      current
 DESCRIPTION
   "Identifies a substring of the text of the 'Subject' attribute of the message.
    Since some messaging technologies make it difficult for an MTA to preserve
    this data, it may not be supported by all agents. Set to an empty (zero length)
    string if unknown or irrelevant to query."
 ::= { msgTrackRequestEntry 14 }

reqMinMsgSize  OBJECT-TYPE
 SYNTAX      INTEGER (1..2147483647)
 ACCESS     read-write
 STATUS      current
 DESCRIPTION
   "Specifies the minimum size of a message to be tracked (content, excluding
    envelope), expressed in kilo-octets. Set both reqMinMsgSize and
    reqMaxMsgSize to zero if message size is irrelevant to the query."
 ::= { msgTrackRequestEntry 15 }

reqMaxMsgSize  OBJECT-TYPE
 SYNTAX      INTEGER (1..2147483647)
 ACCESS     read-write
 STATUS      current
 DESCRIPTION
   "Specifies the maximum size of a message to be tracked (content, excluding
   envelope), expressed in kilo-octets. Set both reqMinMsgSize and
   reqMaxMsgSize to zero if message size is irrelevant to the query."
 ::= { msgTrackRequestEntry 16 }





Expires: February 1, 1997                                     [Page 17]


Internet Draft                                             August 1997



reqEarliestArrivalTime  OBJECT-TYPE
 SYNTAX      DateAndTime
 ACCESS      read-write
 STATUS      current
 DESCRIPTION
   "Specifies the earliest arrival time, at this MTA, for a message to be
    tracked. Set to an empty (zero length) string if unknown or irrelevant to
    query."
 ::= { msgTrackRequestEntry 17 }

reqLatestArrivalTime  OBJECT-TYPE
 SYNTAX      DateAndTime
 ACCESS      read-write
 STATUS      current
 DESCRIPTION
   "Specifies the latest arrival time, at this MTA, for a message to be
    tracked. Set to an empty (zero length) string if unknown or irrelevant to
    query."
 ::= { msgTrackRequestEntry 18 }

reqDispositionStatus  OBJECT-TYPE
 SYNTAX     DispositionStatus
 ACCESS     read-write
 STATUS     current
 DESCRIPTION
   "Specifies the disposition status of the message for a particular
    recipient. Set to 'unknown(1)' if unknown or irrelevant to the query."
 ::= {msgTrackRequestEntry 19 }

reqMsgType OBJECT-TYPE
 SYNTAX    MsgType
 ACCESS     read-write
 STATUS      current
 DESCRIPTION
   "The type of message to be tracked.
    Set to 'any(1)' if message type is unknown or irrelevant to the query."
 ::= {msgTrackRequestEntry 20 }

reqCollapseRecipients  OBJECT-TYPE
 SYNTAX       INTEGER {
                        false(1),
                        true(2)
                        }
 ACCESS     read-write
 STATUS      current



Expires: February 1, 1997                                     [Page 18]


Internet Draft                                             August 1997



 DESCRIPTION
   "If a value of 'true(2)' is specified, a single msgTrackResponseEntry
    will be created for each matching message regardless of the
    number of recipients.  If not specified or set to 'false(1)',
    a msgTrackResponseEntry will be created for each matching message
    and/or recipient.  This variable may be used in the case of a
    distribution list or a message with a large number of
    recipients."
 ::= { msgTrackRequestEntry 21 }

reqFailureReason OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "A textual description of why a message tracking request failed.
    This variable may be set by an agent when the reqResponseStatus
    is set to either 'failedInvalidQuery(4)', or 'failedError(5)'."
 ::= {msgTrackRequestEntry 22 }

- -- MESSAGE RESPONSE TABLE ( QUERY RESULTS )

msgTrackResponseTable OBJECT-TYPE
 SYNTAX     SEQUENCE OF MsgTrackResponseEntry
 ACCESS    not-accessible
 STATUS     current
 DESCRIPTION
   "The table holding the response to all active message tracking requests."
 ::= { mta-message-track 4 }

msgTrackResponseEntry OBJECT-TYPE
 SYNTAX      MsgTrackResponseEntry
 ACCESS     not-accessible
 STATUS      current
 DESCRIPTION
   "The entry associated with each response to a request for message
     information."
 INDEX { respEntryIndex, respMsgIndex }
 ::= { msgTrackResponseTable 1 }

MsgTrackResponseEntry ::= SEQUENCE {
 respEntryIndex
     INTEGER,
 respMsgIndex
     INTEGER,



Expires: February 1, 1997                                     [Page 19]


Internet Draft                                             August 1997



respDispositionStatus
     DispositionStatus,
 respDispositionTime
     INTEGER,
 respNextHopMta
     DisplayString,
 respPrevHopMta
     DisplayString,
 respNonDeliveryReason
     DisplayString,
 respMsgArrivalTime
    DateAndTime,
 respMsgSize
     INTEGER,
 respMsgPriority
     DisplayString,
 respUniqueMsgId
     DisplayString,
 respInboundMsgId
     DisplayString,
respOutboundMsgId
     DisplayString,
 respInboundOriginator
     DisplayString,
 respOutboundOriginator
     DisplayString,
 respInboundRecipient
     DisplayString,
 respOutboundRecipient
     DisplayString,
 respSupplementalInformation
     DisplayString,
 respSubject
     DisplayString,
 respMsgType
     MsgType
}

respEntryIndex  OBJECT-TYPE
 SYNTAX     INTEGER (1..2147483647)
 ACCESS    read-only
 STATUS     current
 DESCRIPTION
   "The primary integer index into the msgTrackResponseTable table. It matches
     the value of reqEntryIndex for the original request. "
 ::= { msgTrackResponseEntry 1 }


Expires: February 1, 1997                                     [Page 20]


Internet Draft                                             August 1997



respMsgIndex OBJECT-TYPE
 SYNTAX      INTEGER (1..2147483647)
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "The secondary integer index into the msgTrackResponseTable table. For each
    value of respEntryIndex in the table, there may be multiple conceptual rows
    indexed by respMsgIndex, each denoting a possible response to the tracking
    query.  The maximum number of entries should have an upper bound of the
    value of reqMaxResponses in the conceptual row of msgTrackRequestTable
    that represents the original query request. "
 ::= { msgTrackResponseEntry 2 }

respDispositionStatus OBJECT-TYPE
 SYNTAX      DispositionStatus
 ACCESS      read-only
 STATUS      current
 DESCRIPTION
   "Indicates the disposition of this message by this MTA for this recipient."
 ::= { msgTrackResponseEntry 3 }

rspDispositionTime OBJECT-TYPE
 SYNTAX      DateAndTime
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "Time at which this MTA disposed of this message for this recipient."
 ::= { msgTrackResponseEntry 4 }

respNextHopMta OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "Name of the MTA to which this message was sent. MADMAN-compliant
    MTA's should be addressed in the form '(<host-id>::<mtaName>)'."
 ::= { msgTrackResponseEntry 5 }

respPrevHopMta OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current
 DESCRIPTION





Expires: February 1, 1997                                     [Page 21]


Internet Draft                                             August 1997



   "Name of the MTA from which this message was received. MADMAN-
    compliant MTA's should be addressed in the form
    '(<host-id>::<mtaName>)'."
 ::= { msgTrackResponseEntry 6 }

respNonDeliveryReason OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "A textual representation representing the reason for non-delivery to
    this recipient.  No attempt is made to normalize these non-delivered
    reasons across systems, since this indicates a terminal condition."
 ::= { msgTrackResponseEntry 7 }

respMsgArrivalTime OBJECT-TYPE
 SYNTAX      DateAndTime
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "Represents the time at which this message for this recipient arrived at
    this MTA."
 ::= { msgTrackResponseEntry 8 }

respMsgSize OBJECT-TYPE
 SYNTAX      INTEGER(1..2147483647)
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "Size of the message in kilo-octets."
 ::= { msgTrackResponseEntry 9 }

respMsgPriority OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "Textual representation of the priority of the message.  No attempt is
    made to normalize these values across disparate messaging technologies."
 ::= { msgTrackResponseEntry 10 }

respUniqueMsgId OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current



Expires: February 1, 1997                                     [Page 22]


Internet Draft                                             August 1997



DESCRIPTION
   "The unique message identifier that the MTA assigned internally
    to the message."
 ::= { msgTrackResponseEntry 11 }

respInboundMsgId OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "The unique message identifier that the 'previous hop' MTA assigned
    to the message.  If the 'previous' MTA uses a different messaging technology
    or identifier scheme, this identifier serves to correlate the message from
    MTA to MTA. If the 'previous' MTA uses the same technology, this value
    is generally superfluous.  If this is the first MTA in the delivery
    sequence, or if the previous message id is unknown, this variable is null-
    valued."
 ::= { msgTrackResponseEntry 12 }

respOutboundMsgId OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "The unique message identifier that the 'next hop' MTA assigned
    to the message.  If the 'next' MTA uses a different messaging technology
    or identifier scheme, this identifier serves to correlate the message from
    MTA to MTA. If the 'next' MTA uses the same technology, this value
    is generally superfluous.  If this is the last MTA in the delivery sequence,
    or if the next hop message id is unknown, this variable is null-valued."
 ::= { msgTrackResponseEntry 13 }

respInboundOriginator OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "Textual representation identifying the originator of the message as it was
    received from the 'previous hop' MTA. The style of this variable varies
    according to a specific messaging technology."
 ::= { msgTrackResponseEntry 14 }

respOutboundOriginator OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current


Expires: February 1, 1997                                     [Page 23]


Internet Draft                                             August 1997




DESCRIPTION
   "Textual representation identifying the originator of the message as it
    was (or will be) presented to the 'next hop' MTA. The style of this
    variable varies according to a specific messaging technology."
 ::= { msgTrackResponseEntry 15 }

respInboundRecipient OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "Textual representation identifying the recipient of the message as it was
    received from the 'previous hop' MTA. The style of this variable varies
    according to a specific messaging technology.."
 ::= { msgTrackResponseEntry 16 }

respOutboundRecipient OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "Textual representation identifying the recipient of the message as it
    was (or will be) presented to the 'next hop' MTA. The style of this
    variable varies according to a specific messaging technology."
 ::= { msgTrackResponseEntry 17 }

respSupplementalInformation OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "Contains information provided by the agent to the manager that may be
    of use in identifying or tracking this message. No formal structure for
    this information is specified.  Knowledge of the contents of this field
    is by bilateral agreement."
 ::= { msgTrackResponseEntry 18 }

respSubject OBJECT-TYPE
 SYNTAX      DisplayString
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "The full text of the subject of the tracked message"
 ::= { msgTrackResponseEntry 19 }



Expires: February 1, 1997                                     [Page 24]


Internet Draft                                             August 1997



respMsgType OBJECT-TYPE
 SYNTAX      MsgType
 ACCESS     read-only
 STATUS      current
 DESCRIPTION
   "The type of the tracked message"
 ::= { msgTrackResponseEntry 20 }

- -- CONFORMANCE INFORMATION
- -- Used ONLY in V2 MIBs
messageTrackingConformance OBJECT IDENTIFIER ::= {
   mta-message-track 5 }
messageTrackingGroups          OBJECT IDENTIFIER ::= {
   messageTrackingConformance 1 }
messageTrackingCompliances OBJECT IDENTIFIER ::= {
   messageTrackingConformance 2 }


- -- COMPLIANCE STATEMENTS
- -- Used ONLY in V2 MIBs
limitedCompliance       MODULE-COMPLIANCE
 STATUS current
 DESCRIPTION
    "The basic levels of compliance for SNMPv2 entities that implement this MIB
      for message tracking requiring the knowledge of a message Id."
 MODULE      -- this module
 MANDATORY-GROUPS { msgIdGroup }
 ::= { messageTrackingCompliances 1 }

basicCompliance       MODULE-COMPLIANCE
 STATUS current
 DESCRIPTION
    "The basic levels of compliance for SNMPv2 entities that implement this MIB
      for message tracking without requiring the knowledge of a message Id."
 MODULE      -- this module
 MANDATORY-GROUPS { msgIdGroup, basicGroup }
 ::= { messageTrackingCompliances 2 }

enhancedCompliance       MODULE-COMPLIANCE
 STATUS current
 DESCRIPTION
    "The basic levels of compliance for SNMPv2 entities that implement this MIB
      for message tracking without requiring the knowledge of a message Id and
      allowing an enhanced level of query capabilities."
 MODULE      -- this module



Expires: February 1, 1997                                     [Page 25]


Internet Draft                                             August 1997



MANDATORY-GROUPS { msgIdGroup, basicGroup, enhancedGroup }
 ::= { messageTrackingCompliances 3 }

gatewayCompliance       MODULE-COMPLIANCE
 STATUS current
 DESCRIPTION
    "The basic levels of compliance for SNMPv2 entities that implement this MIB
      for message tracking across mta's that perform a gateway function."
 MODULE      -- this module
 MANDATORY-GROUPS { msgIdGroup, basicGroup, enhancedGroup,
                                                gatewayGroup }
 ::= { messageTrackingCompliances 4 }

- -- UNITS OF CONFORMANCE
- -- Used ONLY in V2 MIBs
msgIdGroup OBJECT-GROUP
 OBJECTS {
      msgTrackNextRequestIndex,  reqRowStatus,
      reqResponseStatus, reqMaxResponses,  reqUniqueMsgId,
      reqFailureReason,  respDispositionStatus,  respDispositionTime,
      respNonDeliveryReason, respMsgArrivalTime, respUniqueMsgId,
      respInboundOriginator, respInboundRecipient
 }
 STATUS current
 DESCRIPTION
    "  A collection of objects for tracking messages where the messageId is
       known with responses containing basic message information."
    ::= { messageTrackingGroups 1 }

basicGroup OBJECT-GROUP
 OBJECTS {
      reqInboundOriginator, reqInboundRecipient, reqOriginatorNameForm,
      reqRecipientNameForm, reqEarliestArrivalTime,  reqLatestArrivalTime
 }
 STATUS current
 DESCRIPTION
    "  A collection of objects for tracking messages where the messageId is not
known
                      with responses containing basic message information."
    ::= { messageTrackingGroups 2}








Expires: February 1, 1997                                     [Page 26]


Internet Draft                                             August 1997



enhancedGroup OBJECT-GROUP
 OBJECTS {
      reqSubject,           reqMinMsgSize,    reqMaxMsgSize,
      reqDispositionStatus,  reqMsgType,         reqCollapseRecipients,
      respMsgSize,               respMsgPriority,   respSupplementalInformation,
      respSubject,                 respMsgType
 }
 STATUS current
 DESCRIPTION
    " A collection of objects for tracking messages where the messageId is not
      known with responses containing enhanced message information as
      well as enhanced query capabilities."
    ::= { messageTrackingGroups 3}

gatewayGroup OBJECT-GROUP
 OBJECTS {
      reqInboundMsgId,           reqOutboundMsgId,    reqOutboundOriginator,
      reqOutboundRecipient,   respNextHopMta,        respPrevHopMta,
      respInboundMsgId,         respOutboundMsgId,  respOutboundOriginator,
      respOutboundRecipient
 }
 STATUS current
 DESCRIPTION
    "  A collection of object for tracking messages that have passed through a
       gateway mta."
    ::= { messageTrackingGroups 4}


END



5 Usages

A general model of message flow between MTAs has to be presented before
a MIB can be described.  Generally speaking, message flow occurs in three
steps. We use the term "MTA" loosely to refer to any processing entity that is
responsible for message delivery:

(1) Messages are received by the MTA from user agents, message stores, other
MTAs, and gateways.
(2) The "next hop" for the each message is determined.  This is simply the
destination the message is to be transmitted to; it may or may not be the final
destination of the message.  Next hop is established on a per-recipient basis.
Next hop may be a User Agent, a Message Store, another MTA, or a gateway.



Expires: February 1, 1997                                     [Page 27]


Internet Draft                                             August 1997



(3) Information about the message and the next hop are written out to a log in
some format. Messages are transmitted to the appropriate destination, which
may be a user agent, message store, another MTA, or another gateway.

In terms of message tracking, the key step is step number 3, the logging of
information.  Once information about a message is written to a log, it can be
subsequently queried by any number of means. It is the intent of this
specification to support the following general message tracking usages.

Tracking an Individual Message

It is often necessary for messaging operations to track down the whereabouts
and/or history of an individual message managed object.  This is typically in
response to a particular user tracking request regarding a previously sent
message.  It might also be used by messaging operations to verify that one or
more message paths are operating properly.

Entire Path or Current Status

For some inquiries, it is desired that the entire path taken by the message to
date be discovered, including the current disposition of the message (for one
or more recipients). For others, it is necessary only to discover the current
disposition of the message.  Note however that it may be necessary to uncover
its entire path to date in order to determine its current disposition.
To discover a message's entire path, it will be necessary to query the
Management Agent (MA) of each MTA and/or gateway encountered by the
message, beginning with the originating MTA, to discover the status of the
message from that MTA or gateway's perspective.
Dispositions include: Transferred-to another MTA or gateway, In-queue
within an MTA or gateway, Delivered, Non-delivered, Redirected, or Dlist-
expanded. If a message was relayed to another MTA or gateway, then the MA
of that MTA or gateway must be queried in turn.  This must be repeated until
the MTA or gateway which currently has responsibility for the message is
reached.

To discover a message's current disposition, it might in fact be necessary to track
the message's entire path, since typically the current status can only be
discovered by a forward traversal through the message path. Alternatively, to
minimize expense, the MA of any MTA/gateway which is estimated to be in the
message path can be queried; if the message is shown to have reached this
estimated point, then previous points in the path are irrelevant.  Best estimate
may therefore be the MA of the destination MTA, if known.  Other estimates
are made based on arbitrary intelligence which may be available.





Expires: February 1, 1997                                     [Page 28]


Internet Draft                                             August 1997



For a message with multiple recipients, a different path/ disposition may be
relevant for each recipient.  Thus, message tracking queries must be made to
discover the path/disposition of each recipient of the message, or for each
recipient explicitly identified in the tracking request. For cases in which multiple
recipient message copies are transferred-to the same MTA or gateway, these
queries may be combined into a single query, for convenience.

Identifying Messages to Track

In some cases, the user may have retained some sort of a unique identifier for
the message of interest.  This will be true, for example, because an explicit
trackability service was requested for the message,  or because the user logs all
outgoing messages.  In such cases, a message query can be made simply on the
basis of providing this unique identifier to the message tracking system.

Optionally, this query can be bounded by:

o specific recipient(s) of interest;
o time range of interest;
o or other bounding information.

In other cases, the user may only know some general descriptive information
about the message.  For example, the user may know who originated it, to
whom it was sent, and roughly what time of day it was submitted.  In such
cases, it will be necessary to provide descriptive information to the message
tracking system and allow it to respond with a list of matching messages which
it knows about, along with their unique identifiers.

In either case, the query can specify or imply a list of information which it
wishes the query response to return to the requester.

Query Responses

The query response must then return the requested information, or return an
indication as to why it cannot return the requested information. If the returned
information includes an indication that the message has been further relayed,
then a subsequent query must made to the transferred-to MTA or gateway.
Specific response information must be provided/implied in order to allow for
the creation of subsequent queries.  For example:

o the name of the transferred-to MTA or gateway
o the name of the MA of the transferred-to MTA or gateway
o the names/addresses of the recipient(s) of interest which have taken this relay
path. Note that this may be a "redirected" recipient.
o If this response comes from a gateway, the translated versions of key
identification fields.


Expires: February 1, 1997                                     [Page 29]


Internet Draft                                             August 1997



This subsequent query can optionally be formulated automatically.
See next section on "Automating Follow-up Queries" for details on follow-up
query creation.

Automating Follow-up Queries

In order to support a fully automated path search, it is convenient and powerful
for a management agent to be able to automatically make all of the queries
required to discover the full path of an individual message. The MC can
accomplish this by creating an initial query, and then creating a follow-on query
utilizing information returned by the initial query, and repeating this process
until the current disposition of the message is discovered.

Follow-on queries will need to be generated on a per-recipient basis.  For cases
in which multiple recipient message copies were transferred-to the same MTA
or gateway, these queries may be combined into a single query, for efficiency.

In general, a follow-on query will need to:

o Be directed at the MA which corresponds to the MTA or gateway to which
the message (copy) was relayed.
o Include the names/addresses of the recipient(s) which have taken this relay
path. Note that this may be a "redirected" recipient.
o Include the same bounding criteria as did the initial query, with the
addition of the unique message identification if that information was not
previously available.
o If the just-completed query was to a gateway, then the new translated
formats for the following will need to be used, if applicable:
  - Message ID
  - Recipient address
  - Originator address
  - Priority value
  - Size.

Tracking Aggregates of Messages

It is sometimes desirable for messaging operations to be able to determine
information about the history/status of all messages which match a given set
of characteristics that have passed through their systems.

Identifying Messages to Track

In some cases, messaging operations may have retained some sort of a unique
identifier for the messages of interest. More probably, messaging operations is
simply interested in the set of messages which:



Expires: February 1, 1997                                     [Page 30]


Internet Draft                                             August 1997



o went through its systems within a given time range, or
o were sent through its systems by a given originator, or
o were sent through its systems to a given recipient, or
o were sent through its systems with a given size or priority

In such cases, it will be necessary to provide descriptive information to the
message tracking system and allow it to respond with information on all of the
matching messages which it knows about. The query can specify or imply a list
of information which it wishes the query response to return to the requester.

Query Responses

The query response must then return the requested information, or return an
indication as to why it cannot return the requested information.


6. Future Considerations

A version of this information is also available in the Management Information
Format (MIF) defined by the Desktop Management Task Force (DMTF).

As SNMP continues to evolve (e.g. SNMPv3),
the mechanisms in this document will leverage those new technologies.


7.  Acknowledgements

This draft also incorporates the intellectual contributions of

            Bruce Greenblatt
            Niraj Jain
            Sue Lebeck
            Roger Mizumori
            Edward Owens



8.  References


   [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
       of Management Information for version 2 of the Simple Network
       Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc.,
       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
       University, February 1996.



Expires: February 1, 1997                                     [Page 31]


Internet Draft                                             August 1997



   [2] McCloghrie, K., and M. Rose, Editors, "Management Information
       Base for Network Management of TCP/IP-based internets: MIB-II",
       STD 17, RFC 1213, Hughes LAN Systems, Performance Systems
       International, March 1991.

   [3] Case, J., McCloghrie, K., Rose, M., and S, Waldbusser, "Protocol
       Operations for version 2 of the Simple Network Management
       Protocol (SNMPv2)", RFC 1905, SNMP Research,Inc., Hughes LAN
       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
       University, February 1996.


Security Considerations

   Security issues are not discussed in this memo.



Authors' Addresses

  Bruce Ernst
  Lotus Development Corporation

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


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

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


  Jonathan Weintraub
  Electronic Data Systems, Inc.

  +1 301 619 3101






Expires: February 1, 1997                                     [Page 32]