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]
