Internet DRAFT - draft-ernst-msgmib
draft-ernst-msgmib
MADMAN Working Group Bruce Ernst [bruce_ernst@lotus.com]
INTERNET-DRAFT Lotus Development Corporation
draft-ernst-msgmib-00.txt Gordon Jones [gbjones@mitre.org]
MITRE Corporation
Jonathan Weintraub
Electronic Data Systems, Inc.
March 1998
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 management. 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: 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.
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
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. For a detailed definition of message tracking, and the need
for message
tracking, refer to [MODEL].
Expires: September 1, 1998 [Page 2]
Internet Draft March 1998
3. 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: September 1, 1998 [Page 3]
Internet Draft March 1998
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: September 1, 1998 [Page 4]
Internet Draft March 1998
-- 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: September 1, 1998 [Page 5]
Internet Draft March 1998
-- 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: September 1, 1998 [Page 6]
Internet Draft March 1998
-- 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: September 1, 1998 [Page 7]
Internet Draft March 1998
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: September 1, 1998 [Page 8]
Internet Draft March 1998
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: September 1, 1998 [Page 9]
Internet Draft March 1998
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: September 1, 1998 [Page 10]
Internet Draft March 1998
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: September 1, 1998 [Page 11]
Internet Draft March 1998
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: September 1, 1998 [Page 12]
Internet Draft March 1998
"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: September 1, 1998 [Page 13]
Internet Draft March 1998
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: September 1, 1998 [Page 14]
Internet Draft March 1998
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: September 1, 1998 [Page 15]
Internet Draft March 1998
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: September 1, 1998 [Page 16]
Internet Draft March 1998
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: September 1, 1998 [Page 17]
Internet Draft March 1998
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: September 1, 1998 [Page 18]
Internet Draft March 1998
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: September 1, 1998 [Page 19]
Internet Draft March 1998
"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: September 1, 1998 [Page 20]
Internet Draft March 1998
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: September 1, 1998 [Page 21]
Internet Draft March 1998
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: September 1, 1998 [Page 22]
Internet Draft March 1998
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: September 1, 1998 [Page 23]
Internet Draft March 1998
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: September 1, 1998 [Page 24]
Internet Draft March 1998
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
4 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: September 1, 1998 [Page 25]
Internet Draft March 1998
(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: September 1, 1998 [Page 26]
Internet Draft March 1998
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: September 1, 1998 [Page 27]
Internet Draft March 1998
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: September 1, 1998 [Page 28]
Internet Draft March 1998
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.
4.1 Security
[TBD]
5. 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.
6. Acknowledgements
This draft also incorporates the intellectual contributions of
Bruce Greenblatt
Niraj Jain
Sue Lebeck
Roger Mizumori
Edward Owens
Expires: September 1, 1998 [Page 31]
Internet Draft March 1998
7. 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, September 1996.
[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, September 1996.
[MODEL] Case, J., McCloghrie, K., Rose, M., and S, Waldbusser,
"Protocol
Operations for version 2 of the Simple Network Management
Authors' Addresses
Bruce Ernst
Lotus Development Corporation
Phone: +1 610 251 3404
E-Mail: bruce_ernst@lotus.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: September 1, 1998 [Page 32]
