idnits 2.17.1 draft-ietf-madman-trackmib-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 32 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 311 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '... Drafts are ...' == Line 16 has weird spacing: '...cuments of t...' == Line 17 has weird spacing: '... groups may ...' == Line 21 has weird spacing: '... Drafts may ...' == Line 22 has weird spacing: '...iate to use ...' == (16 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1997) is 9751 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1367 looks like a reference -- Missing reference section? '2' on line 1373 looks like a reference -- Missing reference section? '3' on line 1378 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MADMAN Working Group Bruce Ernst [bernst@softsw.ssw.com] 3 INTERNET-DRAFT Lotus Development Corporation 4 draft-ietf-madman-trackmib-00.txt Gordon Jones [gbjones@mitre.org] 5 MITRE Corporation 6 Jonathan Weintraub 7 Electronic Data Systems, Inc. 9 August 1997 11 Message Tracking MIB 13 Status of this Memo 15 This document is an Internet Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a "working 24 draft" or "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 29 munnari.oz.au. 31 Abstract 33 This document defines a message tracking Management Information Base 34 (MIB) for electronic messaging usage. Message tracking is the ability to find 35 out, after the fact, the path that a particular message took through the 36 messaging system and the current status of that message. 38 1. The SNMP Network Management Framework. 40 The major components of the SNMP Network Management framework are 41 described in the documents listed below. 43 o RFC 1902 [1] defines the Structure of Management Information 44 (SMI), the mechanisms used for describing and naming objects 45 for the purpose of management. 47 o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed 48 objects (MO) for the Internet suite of protocols. 50 o RFC 1905 [3] defines the protocol used for network access to 51 managed objects. 53 The framework is adaptable/extensible by defining new MIBs to suit the 54 requirements of specific applications/protocols/situations. 56 Managed objects are accessed via a virtual information store, the MIB. 57 Objects in the MIB are defined using the subset of Abstract Syntax 58 Notation One (ASN.1) defined in the SMI. In particular, each object type 59 is named by an OBJECT IDENTIFIER, which is an administratively assigned 60 name. The object type together with an object instance serves to 61 uniquely identify a specific instantiation of the object. For human 62 convenience, often a textual string, termed the descriptor, is used to 63 refer to the object type. 65 2. Message Tracking and the Need for Message Tracking 67 Message tracking refers, in its simplest form, to determining the path a message 68 has taken and it's current location. This capability is analogous to the service 69 provided by carriers of conventional paper mail - the ability to quickly locate 70 where a package is, and to determine whether or not the package has been 71 delivered to its destination. This document discusses a specific SNMP-based 72 per-message mechanism to query the messaging system to perform message 73 tracking. SNMP is an established network and application management 74 technology that provides an abundance of user tools and a cross-vendor, 75 cross-technology ubiquity. As SNMP continues to evolve (e.g. SNMPv3), 76 the mechanisms in this document will leverage those new technologies. 77 Use of the approach in this document will allow development of message 78 tracking applications that can operate in a multi-vendor messaging environment: 80 o When there is a lack of trust in the messaging system, such as when an 81 originator claims a message failed to be delivered, the point of failure may be 82 isolated. This includes messages that were never delivered of messages that were 83 delivered incorrectly. Message tracking thus adds to the overall reliability of the 84 mail system; 86 o Per-message information can be used for accounting, billing, and performance 87 purposes. Traffic can be itemized on a per-origin or per-destination basis by 88 system or originator. This typically involves two steps - collection of message 89 traffic data, followed by the generation of appropriate reports and/or billing. 91 o Message tracking information adds security in that the origins of potential 92 security threats can be more precisely determined. If a system were flooded 93 with traffic, for instance, the origin of this traffic would become known. 94 Message tracking information is suitable for routine securty audits containing 95 the details of messaging traffic over specific time intervals; 97 o The message tracking MIB would aid in message loop detection, since unique 98 message identifiers of looping messages, when these exist, would be recorded 99 multiple times; 101 o Performance characteristics about the type of messaging traffic could be 102 determined, such as when an inbound message causes the creation of multiple 103 outbound messages, and the percentage of messages that were actually delivery 104 reports or receipts. This is valuable for performance measurement, among other 105 reasons; 107 o Standardized message tracking information acts as a bridge between dissimilar 108 messaging systems and dissimilar messaging communities; 110 3. Requirements 112 The Messaging Manager must be able to trace a message on behalf of a user, to 113 discover whether the message was in fact delivered, or to determine where the 114 message may be stuck in the system. Message Tracking is often required more 115 by end users during times when they distrust the System - when moving from a 116 real-time delivery system to a store-and-forward system, or when the System is 117 new, or is undergoing significant change. The management information 118 described in this document provides for tracking on a per-message, per-recipient 119 basis. A message's current status, as well as the complete path taken by a 120 message, on a per-recipient basis, can be obtained by consulting Messaging 121 Management agents which comply with this specification. 123 As the Messaging System shifts to being used for applications which require 124 higher reliability (e.g., EDI), Message Tracking will be required to assure the 125 users that the requisite reliability is indeed in place. If a question of "lost mail" 126 arises, the mail manager must be able to track the message from its entry into 127 the mail system until it is delivered, non-delivered, or passes outside the 128 management sphere into another management sphere. The track must be able 129 to cross multiple messaging components from multiple vendors. There must be 130 provision for passing the query to the appropriate authority in the next 131 management sphere so that the track can be continued there. Cross-jurisdictional, 132 agent-based message tracking, as described in this document, addresses this 133 equirement. In addition to being multi-component and multi-vendor, this 134 specification also addresses multiple management technologies. 136 Messages must be trackable from point of origin, based on the sender providing 137 the posting date and time and destination. This includes one Mail Manager 138 asking the Mail Manager of the next management sphere to continue the track 139 of a message entering that sphere at a specific date and time from a stated point 140 of origin. Message tracking queries, filtered based on time and recipient (i.e., in 141 the case when a specific message ID is not known) is included in this 142 specification. Note however that support for this sort of filtering is optional. 144 Messages must also be trackable across domains - from one enterprise, across 145 the public wide-area network, and into the destination enterprise. 147 The Messaging Manager must be able to track a message on behalf of a user, 148 to discover whether the message was in fact delivered, or to determine where 149 the message may be stuck in the system. Message tracking is often required 150 more by end users during times when they distrust the System - when moving 151 from a real-time delivery system to a store-and-forward system, or when the 152 system is new, or is undergoing significant change. In other words, message 153 tracking will be critically important during times of downsizing. 155 As the Messaging System shifts to being used for applications which require 156 higher reliability, (e.g., EDI) Message Tracking will be required to assure the 157 users that the requisite reliability is indeed in place. If a question of "lost mail" 158 arises, the mail manager must be able to track the message from its entry into the 159 mail system until it is delivered, non-delivered, or passes outside the management 160 sphere into another management sphere. The track must be able to cross multiple 161 messaging components from multiple vendors. There must be provision for 162 passing the query to the appropriate authority in the next management sphere so 163 that the track can be continued there. 165 Messages must be trackable from point of origin, based on the sender providing 166 the posting date and time and destination. This included one Mail Manager 167 asking the Mail Manager of the next Management Sphere to continue the track 168 of a message entering that sphere at a specific date and time from a stated point 169 of origin. 171 4. MIB Data to Support Message Tracking 173 This MIB contains the syntax for message tracking via SNMP. The attributes 174 defined are identical to those defined for message tracking via e-mail, except 175 for those attributes that are required purely to enable SNMP-specific semantics. 177 When making use of SNMP, it is expected that the following mode of operation 178 will be used. The entity acting in the manager role issues one or more "SET" 179 operations filling in a row in a request table. The variables set in the request 180 table together comprise a message tracking query. The entity acting in the agent 181 role reads the values set in the request table, queries the local message store 182 (or usage logs), and returns information regarding messages that satify the query 183 criteria in a response table. The entity acting as the manager then reads the 184 response table and notifies an administrator or performs additional queries as 185 required. 187 In the message tracking MIB that follows, there are three tables: 189 1. the mtaInformationTable 190 2. the msgTrackRequestTable 191 3. the msgTrackResponseTable 193 The mtaInformationTable contains one entry for each MTA that is monitored 194 by this agent. The table contains information about the MTA as a whole, such 195 as: the name of the MTA and the length of time that the MTA has been recording 196 information. This last item is important to know, since if the MTA indicates that 197 it only has information about messages that have passed through it in the last two 198 days, and the administrator wishes to track a message that was sent four days ago, 199 then there will be no need to attempt to track the message through this MTA. 201 The msgTrackRequestTable is used by a manager to specify a query to be made 202 of the agent. It is not required that the manager have any knowledge of a unique 203 message identifier, but knowledge of some information pertaining to the message 204 in question is recommended. Since the query information may be matched by a 205 number of potential matches, it is possible to find out information about several 206 different messages. 208 The msgTrackResponseTable is a parallel to the msgTrackRequestTable in that it 209 holds the response(s) to the queries posed in the msgTrackRequestTable. The 210 manager reads this table to retrieve information about the messages that match 211 the input query information. The two tables share a common index to facilitate 212 navigation between them. 214 MESSAGE-TRACKING-MIB DEFINITIONS ::= BEGIN 216 IMPORTS 217 OBJECT-TYPE, MODULE-IDENTITY, Counter32 218 FROM SNMPv2-SMI 219 DisplayString, TimeInterval, DateAndTime 220 FROM SNMPv2-TC; 222 - -- Note that in SNMPv1 the IMPORTS section should look like the following: 223 - -- IMPORTS 224 - -- OBJECT-TYPE, enterprises, Counter, Gauge, TimeTicks 225 - -- FROM RFC1155-SMI 226 - -- DisplayString 227 - -- FROM RFC1213-MIB; 229 - -- OBJECT IDENTIFIERS 230 MsgTracking OBJECT IDENTIFIER ::= { experimental 73 2 } 232 - -- MODULE IDENTIFICATION use in V2 version only 233 mta-message-track MODULE-IDENTITY 234 LAST-UPDATED "9704110000Z" 235 ORGANIZATION "IETF" 236 CONTACT-INFO 237 "Gordon Jones 238 Postal: 1820 Dolly Madison Boulevard 239 Mc Lean, VA 22102-3481 240 Tel: +1 703 883 7670 241 Fax: +1 703 883 7670 242 E-mail: gbjones@mitre.org" 243 DESCRIPTION 244 "The MIB module describing message tracking" 245 ::= { MsgTracking 1 } 247 - -- Note that the MODULE-IDENTITY macro does not exist in SNMP version 1, 248 - -- for a V1 implementation, replace the above macro with the following line : 249 - -- mta-message-track OBJECT IDENTIFIER ::= {MsgTracking 1 } 251 - -- Note that the textual conventions DateAndTime and TimeInterval 252 - -- do not exist in SNMPv1, for a V1 implementation include the following 253 - -- 2 lines: 254 - -- DateAndTime ::= DisplayString 255 - -- TimeInterval ::= INTEGER (0..2147483647) 256 - -- Define the NameForm textual convention for originator and recipient 257 - -- names in this MIB 258 NameForm ::= INTEGER { 259 freeForm(1), 260 x400(2), 261 smtp(3) 262 } 264 - -- Define the DispositionStatus textual convention which indicates the 265 - -- disposition of a message by the MTA for a particular recipient. Values 266 - -- are: 267 - -- unknown - The disposition of the message could not be determined 268 - -- transferred - The message was forwarded to another MTA for 269 - -- delivery without name or content transformation. 270 - -- delivered - The message was delivered to the intended recipient. 271 - -- non-delivered - The message could not be delivered to the intended 272 - -- recipient. 273 - -- redirected - The message was forwarded to another MTA for 274 - -- delivery. The recipient name and/or messageId 275 - -- may have changed as a result of this process. 276 - -- dlist-expanded - The intended recipient was a distribution list 277 - -- which was expanded by the MTA. 278 - -- in-queue - The message for this recipient is currently being 279 - -- processed by the MTA. 281 DispositionStatus ::= INTEGER { 282 unknown(1), 283 transferred(2), 284 delivered(3), 285 non-delivered(4), 286 redirected(5), 287 dlist-expanded(6), 288 in-queue(7) 289 } 291 - -- Define the MsgType textual convention. Values are: 292 - -- 293 - -- data 294 - -- status 295 - -- probe 297 MsgType ::= INTEGER { 298 any(1), 299 data(2), 300 status(3), 301 probe(4) 302 } 304 - -- How this mib works : 305 - -- Most message tracking MIBs operate on the presupposition that the manager 306 - -- entering a query knows the unique message ID for the message being tracked. 307 - -- In practice, this is often not the case. This MIB allows for a 2-step 308 - -- query process - find the appropriate message, then track it. 310 - -- +==============+ 311 - -- | Manager | = 1 => +=====================================+ 312 - -- +==============+ = 6 => | msgTrackRequestTable | 313 - -- ^ +=====================================+ 314 - -- | | 315 - -- | 2 +=========+ 316 - -- | + => | Agent | 317 - -- | +=========+ 318 - -- 5 | +======================+ 319 - -- | + 3 => | Message Store | 320 - -- | += 4 ========== +======================+ 321 - -- | | 322 - -- | v 323 - -- | +========================================+ 324 - -- ===============> | msgTrackResponseTable | 325 - -- +========================================+ 326 - -- 327 - -- STEP 1: 328 - -- Using the index obtained from 'msgTrackNextRequestIndex', a manager 329 - -- creates a conceptual row in the 'msgTrackRequestTable', filling in 330 - -- as many message attributes as are known. The manager also specifies 331 - -- in 'reqMaxResponses', the maximim number of possible 'hits' for an 332 - -- underspecified query. 333 - -- STEP 2: 334 - -- When the agent detects a new conceptual row in 'msgTrackRequestTable', 335 - -- it forms a query to be executed against the message store(s). 336 - -- STEP 3: 337 - -- The agent issues the query against the message store and receives some 338 - -- response(s). 339 - -- STEP 4: 340 - -- The agent then transfers up to 'reqMaxResponses' possible responses 341 - -- to newly created conceptual rows in the 'msgTrackResponseTable'. The agent 342 - -- then sets the value of 'reqResponseStatus' in the 'msgTrackRequestTable' 343 - -- to notify the manager of the results of the query. 344 - -- STEP 5: 345 - -- The manager, having detected a change in 'reqResponseStatus', knows that 346 - -- the query is complete. It reads the potential responses from the 347 - -- 'msgTrackResponseTable' and presents them to the end-user. 349 - -- STEP 6: 350 - -- The manager then instructs the agent to destroy the conceptual row 351 - -- created in the 'msgTrackRequestTable', which causes the agent to 352 - -- destroy the corresponding entries in the 'msgTrackResponseTable'. 353 - -- STEP 7: (optional, not illustrated) 354 - -- If the original query did not produce an adequate response, a new entry 355 - -- is created in the 'msgTrackRequestTable'. Entries in this table are 356 - -- never reused! 357 - -- 358 - -- 360 - -- MESSAGE TRACKING REQUEST TABLE: 362 mtaInformationTable OBJECT-TYPE 363 SYNTAX SEQUENCE OF mtaInformationEntry 364 MAX-ACCESS not-accessible 365 STATUS current 366 DESCRIPTION 367 "The table holding information about the MTA being queried. A table 368 is used because there may be multiple MTAs at a single host." 369 ::= { mta-message-track 1 } 371 mtaInformationEntry OBJECT-TYPE 372 SYNTAX mtaInformationEntry 373 MAX-ACCESS not-accessible 374 STATUS current 375 DESCRIPTION 376 "One entry in the table holding information about the MTA being 377 queried" 378 INDEX { mtaIndex } 379 ::= { mtaInformationTable 1 } 381 mtaInformationEntry ::= SEQUENCE { 382 mtaIndex 383 INTEGER, 384 mtaName 385 DisplayString, 386 mtaMessagingType 387 DisplayString, 388 startTimeforRecordedInformation 389 DateAndTime, 390 alternativeAgent 391 DisplayString 392 } 393 mtaIndex OBJECT-TYPE 394 SYNTAX INTEGER (1..2147483647) 395 ACCESS read-only 396 STATUS current 397 DESCRIPTION 398 "The integer index into this table." 399 ::= { mtaInformationEntry 1 } 401 mtaName OBJECT-TYPE 402 SYNTAX DisplayString 403 ACCESS read-only 404 STATUS current 405 DESCRIPTION 406 "The name of the MTA described in this row of the table." 407 ::= { mtaInformationEntry 2 } 409 mtaMessagingType OBJECT-TYPE 410 SYNTAX DisplayString 411 ACCESS read-only 412 STATUS current 413 DESCRIPTION 414 " Common name of the messaging system of this MTA (e.g. X.400, SMTP)." 415 ::= { mtaInformationEntry 3 } 417 mtaStartTimeforRecordedInformation OBJECT-TYPE 418 SYNTAX DateAndTime 419 ACCESS read-only 420 STATUS current 421 DESCRIPTION 422 " The date/time of the oldest message tracking information 423 available from this MTA." 424 ::= { mtaInformationEntry 4 } 426 mtaAlternativeAgent OBJECT-TYPE 427 SYNTAX DisplayString 428 ACCESS read-only 429 STATUS current 430 DESCRIPTION 431 "The name (or address) of another agent that may have message 432 tracking information concerning this MTA." 433 ::= { mtaInformationEntry 5 } 435 msgTrackNextRequestIndex OBJECT-TYPE 436 SYNTAX Counter32 -- Note that in SNMPv1, the syntax is simply 437 'Counter' 438 ACCESS read-only 439 STATUS current 440 DESCRIPTION 441 "The index that may be used by a manager (requestor) on a 'set-request' PDU 442 to create a new conceptual row in the msgTrackRequestTable table (and 443 thereby issue a message tracking query)." 444 ::= { mta-message-track 2 } 446 msgTrackRequestTable OBJECT-TYPE 447 SYNTAX SEQUENCE OF MsgTrackRequestEntry 448 ACCESS not-accessible 449 STATUS current 450 DESCRIPTION 451 "The table holding all active message tracking requests." 452 ::= { mta-message-track 3 } 454 msgTrackRequestEntry OBJECT-TYPE 455 SYNTAX MsgTrackRequestEntry 456 ACCESS not-accessible 457 STATUS current 458 DESCRIPTION 459 "The entry associated with each request for message information." 460 INDEX { reqEntryIndex } 461 ::= { msgTrackRequestTable 1 } 463 MsgTrackRequestEntry ::= SEQUENCE { 464 reqEntryIndex 465 INTEGER, 466 reqRowStatus 467 INTEGER, 468 reqResponseStatus 469 INTEGER, 470 reqMaxResponses 471 INTEGER, 472 reqUniqueMsgId 473 DisplayString, 474 reqInboundMsgId 475 DisplayString, 476 reqOutboundMsgId 477 DisplayString, 478 reqInboundOriginator 479 DisplayString, 481 reqOutboundOriginator 482 DisplayString, 483 reqOriginatorNameForm 484 NameForm, 485 reqInboundRecipient 486 DisplayString, 487 reqOutboundRecipient 488 DisplayString, 489 reqRecipientNameForm 490 NameForm, 491 reqSubject 492 DisplayString, 493 reqMinMsgSize 494 INTEGER, 495 reqMaxMsgSize 496 INTEGER, 497 reqEarliestArrivalTime 498 DateAndTime, 499 reqLatestArrivalTime 500 DateAndTime, 501 reqDispositionStatus 502 DispositionStatus, 503 reqFailureReason 504 DisplayString, 505 reqMsgType 506 MsgType, 507 reqCollapseRecipients 508 INTEGER 509 } 511 reqEntryIndex OBJECT-TYPE 512 SYNTAX INTEGER (1..2147483647) 513 ACCESS read-only 514 STATUS current 515 DESCRIPTION 516 "The integer index into the msgTrackRequestTable table." 517 ::= { msgTrackRequestEntry 1 } 519 reqRowStatus OBJECT-TYPE 520 SYNTAX INTEGER { 521 active(1), 522 notInService(2), 523 notReady(3), 524 createAndGo(4), 525 createAndWait(5), 526 destroy(6) 527 } 528 ACCESS read-write 529 STATUS current 530 DESCRIPTION 531 "The status of the conceptual row. These are mapped to the same values as 532 the RowStatus textual conversion in SNMPv2 and carry the same semantics 533 with one exception: the exception is that when a manager (requestor) sets the 534 value to destroy(6), this also has the added semantics of deleting all 535 conceptual rows in the msgTrackResponseTable table whose respEntryIndex 536 matches the reqEntryIndex of this conceptual row." 537 ::= { msgTrackRequestEntry 2 } 539 reqResponseStatus OBJECT-TYPE 540 SYNTAX INTEGER { 541 unknown(1), 542 inProgress(2), 543 failedNoMatches(3), 544 failedInvalidQuery(4), 545 failedError(5), 546 successUnderqualified(6), 547 success(7) 548 } 549 ACCESS read-only 550 STATUS current 551 DESCRIPTION 552 "Indicates the status of this query and its responses in the 553 msgTrackResponseTable. Values are: 554 unknown - The status of this query is not known. 555 inProgress - The agent(responder) is still processing the request. 556 failedNoMatches - The query has been processed and has produced no 557 matches. 558 failedInvalidQuery - The query could not be processed due to invalid or 559 missing data in the original query. 560 FailedError - The query could not be processed due to an error in the 561 agent(responder). 562 successUnderqualified - The query was successfully processed, but the query 563 was found to be underqualified. That is, more reponses were found than were 564 specified in reqMaxResponses. reqMaxResponses entries were returned in the 565 msgTrackResponseTable. 566 success - The query succeeded, returning from 1 to reqMaxResponse 567 entries in the msgTrackResponseTable." 568 ::= { msgTrackRequestEntry 3 } 570 reqMaxResponses OBJECT-TYPE 571 SYNTAX INTEGER (1..100) 572 ACCESS read-write 573 STATUS current 574 DESCRIPTION 575 "Specifies the largest number of responses to be returned in the 576 msgTrackResponseTable on an underspecified query (i.e. the 577 maximum value of respMsgIndex in the msgTrackResponseTable 578 conceptual row whose respEntryIndex matches the reqEntryIndex of this 579 conceptual row)." 580 ::= { msgTrackRequestEntry 4 } 582 reqUniqueMsgId OBJECT-TYPE 583 SYNTAX DisplayString 584 ACCESS read-write 585 STATUS current 586 DESCRIPTION 587 "Specifies a unique message id used internally by the MTA for identification 588 of a message. This form of the message id may or may not be identical to the 589 inbound and/or outbound forms of the message id. If specified, this may be 590 the only search criteria required. If the entire unique message id is not 591 specified, prefix matching is assumed. Set to an empty (zero length) string if 592 unknown or irrelevant to query." 593 ::= { msgTrackRequestEntry 5 } 595 reqInboundMsgId OBJECT-TYPE 596 SYNTAX DisplayString 597 ACCESS read-write 598 STATUS current 599 DESCRIPTION 600 "Specifies a unique message id as received by the MTA for identification of 601 a message. This form of the message id may or may not be identical to the 602 internal and/or outbound forms of the message id. If specified, this may be the 603 only search criteria required. If the entire inbound message id is not specified, 604 prefix matching is assumed. Set to an empty (zero length) string if unknown or 605 irrelevant to query." 606 ::= { msgTrackRequestEntry 6 } 608 reqOutboundMsgId OBJECT-TYPE 609 SYNTAX DisplayString 610 ACCESS read-write 611 STATUS current 612 DESCRIPTION 613 "Specifies a unique message id as transmitted by the MTA for identification 614 of a message. This form of the message id may or may not be identical to the 615 internal and/or inbound forms of the message id. If specified, this may be the 616 only search criteria required. If the entire outbound message id is not 617 specified, prefix matching is assumed. Set to an empty (zero length) string if 618 unknown or irrelevant to query." 619 ::= { msgTrackRequestEntry 7 } 621 reqInboundOriginator OBJECT-TYPE 622 SYNTAX DisplayString 623 ACCESS read-write 624 STATUS current 625 DESCRIPTION 626 "Identifies the originator of the message in its received form, expressed in 627 string format. The style and format of this identifier varies according to a 628 specific messaging technology. As a result of potentially disparate messaging 629 technologies, this identifier is only guaranteed to be the name known to the 630 end-user on the first MTA in the delivery sequence. If 631 reqOriginatorNameForm is set to 'x.400(2)' or 'smtp(3)', the supplied 632 attributes will be considered in the match. Any attributes not supplied will be 633 wildcarded. If reqOriginatorNameForm is set to 'freeForm(1)', this value is 634 assumed to be a substring of the originator name. Set to an empty (zero 635 length) string if unknown or irrelevant to query." 636 ::= { msgTrackRequestEntry 8 } 638 reqOutboundOriginator OBJECT-TYPE 639 SYNTAX DisplayString 640 ACCESS read-write 641 STATUS current 642 DESCRIPTION 643 "Identifies the originator of the message in its transmitted form, expressed 644 in string format. The style and format of this identifier varies according to a 645 specific messaging technology. As a result of potentially disparate messaging 646 technologies this identifier is only guaranteed to be the name known to the 647 end-user on the last MTA in the delivery sequence. If 648 reqOriginatorNameForm is set to 'x.400(2)' or 'smtp(3)', the supplied attributes 649 will be considered in the match. Any attributes not supplied will be 650 wildcarded. If reqOriginatorNameForm is set to 'freeForm(1)', this value is 651 assumed to be a substring of the originator name. Set to an empty (zero 652 length) string if unknown or irrelevant to query." 653 ::= { msgTrackRequestEntry 9 } 655 reqOriginatorNameForm OBJECT-TYPE 656 SYNTAX NameForm 658 ACCESS read-write 659 STATUS current 660 DESCRIPTION 661 "Identifies the name form of originator strings supplied in the 662 reqInboundOriginator and/or reqOutboundOriginator values. This value is 663 used by the agent to perform name form dependant parsing of these values. 664 If neither of these strings are supplied, this name form value is irrelevant to 665 the query. A value of 'any(1)' implies that no special parsing should be 666 performed on the originator names supplied." 667 ::= { msgTrackRequestEntry 10 } 669 reqInboundRecipient OBJECT-TYPE 670 SYNTAX DisplayString 671 ACCESS read-write 672 STATUS current 673 DESCRIPTION 674 "Identifies one of the recipients (the one to be tracked) of the message in 675 its received form, expressed in string format. The style and format of this 676 identifier varies according to a specific messaging technology. As a result 677 of potentially disparate messaging technologies, this identifier is only 678 guaranteed to be the name an end-user knows the recipient by on the first 679 MTA in the delivery sequence. If reqRecipientNameForm is set to 'x.400(2)' 680 or 'smtp(3)', the supplied attributes will be considered in the match. Any 681 attributes not supplied will be wildcarded. If reqRecipientNameForm is set to 682 'freeForm(1)', this value is assumed to be a substring of the recipient name. 683 Set to an empty (zero length) string if unknown or irrelevant to query." 684 ::= { msgTrackRequestEntry 11 } 686 reqOutboundRecipient OBJECT-TYPE 687 SYNTAX DisplayString 688 ACCESS read-write 689 STATUS current 690 DESCRIPTION 691 "Identifies one of the recipients (the one to be tracked) of the message in 692 its transmitted form, expressed in string format. The style and format of this 693 identifier varies according to a specific messaging technology. As a result of 694 potentially disparate messaging technologies, this identifier is only guaranteed 695 to be the name an end-user knows the recipient by on the last MTA in the 696 delivery sequence. If reqRecipientNameForm is set to 'x.400(2)' or 'smtp(3)', 697 the supplied attributes will be considered in the match. Any attributes not 698 supplied will be wildcarded. If reqRecipientNameForm is set to 'freeForm(1)', 699 this value is assumed to be a substring of the recipient name. Set to an empty 700 (zero length) string if unknown or irrelevant to query." 701 ::= { msgTrackRequestEntry 12 } 703 reqRecipientNameForm OBJECT-TYPE 704 SYNTAX NameForm 705 ACCESS read-write 706 STATUS current 707 DESCRIPTION 708 "Identifies the name form of recipient strings supplied in the 709 reqInboundRecipient and/or reqOutboundRecipient values. This value is 710 used by the agent to perform name form dependant parsing of these values. 711 If neither of these strings are supplied, this name form value is irrelevant to 712 the query. A value of 'any(1)' implies that no special parsing should be 713 performed on the recipient names supplied." 714 ::= { msgTrackRequestEntry 13 } 716 reqSubject OBJECT-TYPE 717 SYNTAX DisplayString 718 ACCESS read-write 719 STATUS current 720 DESCRIPTION 721 "Identifies a substring of the text of the 'Subject' attribute of the message. 722 Since some messaging technologies make it difficult for an MTA to preserve 723 this data, it may not be supported by all agents. Set to an empty (zero length) 724 string if unknown or irrelevant to query." 725 ::= { msgTrackRequestEntry 14 } 727 reqMinMsgSize OBJECT-TYPE 728 SYNTAX INTEGER (1..2147483647) 729 ACCESS read-write 730 STATUS current 731 DESCRIPTION 732 "Specifies the minimum size of a message to be tracked (content, excluding 733 envelope), expressed in kilo-octets. Set both reqMinMsgSize and 734 reqMaxMsgSize to zero if message size is irrelevant to the query." 735 ::= { msgTrackRequestEntry 15 } 737 reqMaxMsgSize OBJECT-TYPE 738 SYNTAX INTEGER (1..2147483647) 739 ACCESS read-write 740 STATUS current 741 DESCRIPTION 742 "Specifies the maximum size of a message to be tracked (content, excluding 743 envelope), expressed in kilo-octets. Set both reqMinMsgSize and 744 reqMaxMsgSize to zero if message size is irrelevant to the query." 745 ::= { msgTrackRequestEntry 16 } 747 reqEarliestArrivalTime OBJECT-TYPE 748 SYNTAX DateAndTime 749 ACCESS read-write 750 STATUS current 751 DESCRIPTION 752 "Specifies the earliest arrival time, at this MTA, for a message to be 753 tracked. Set to an empty (zero length) string if unknown or irrelevant to 754 query." 755 ::= { msgTrackRequestEntry 17 } 757 reqLatestArrivalTime OBJECT-TYPE 758 SYNTAX DateAndTime 759 ACCESS read-write 760 STATUS current 761 DESCRIPTION 762 "Specifies the latest arrival time, at this MTA, for a message to be 763 tracked. Set to an empty (zero length) string if unknown or irrelevant to 764 query." 765 ::= { msgTrackRequestEntry 18 } 767 reqDispositionStatus OBJECT-TYPE 768 SYNTAX DispositionStatus 769 ACCESS read-write 770 STATUS current 771 DESCRIPTION 772 "Specifies the disposition status of the message for a particular 773 recipient. Set to 'unknown(1)' if unknown or irrelevant to the query." 774 ::= {msgTrackRequestEntry 19 } 776 reqMsgType OBJECT-TYPE 777 SYNTAX MsgType 778 ACCESS read-write 779 STATUS current 780 DESCRIPTION 781 "The type of message to be tracked. 782 Set to 'any(1)' if message type is unknown or irrelevant to the query." 783 ::= {msgTrackRequestEntry 20 } 785 reqCollapseRecipients OBJECT-TYPE 786 SYNTAX INTEGER { 787 false(1), 788 true(2) 789 } 790 ACCESS read-write 791 STATUS current 792 DESCRIPTION 793 "If a value of 'true(2)' is specified, a single msgTrackResponseEntry 794 will be created for each matching message regardless of the 795 number of recipients. If not specified or set to 'false(1)', 796 a msgTrackResponseEntry will be created for each matching message 797 and/or recipient. This variable may be used in the case of a 798 distribution list or a message with a large number of 799 recipients." 800 ::= { msgTrackRequestEntry 21 } 802 reqFailureReason OBJECT-TYPE 803 SYNTAX DisplayString 804 ACCESS read-only 805 STATUS current 806 DESCRIPTION 807 "A textual description of why a message tracking request failed. 808 This variable may be set by an agent when the reqResponseStatus 809 is set to either 'failedInvalidQuery(4)', or 'failedError(5)'." 810 ::= {msgTrackRequestEntry 22 } 812 - -- MESSAGE RESPONSE TABLE ( QUERY RESULTS ) 814 msgTrackResponseTable OBJECT-TYPE 815 SYNTAX SEQUENCE OF MsgTrackResponseEntry 816 ACCESS not-accessible 817 STATUS current 818 DESCRIPTION 819 "The table holding the response to all active message tracking requests." 820 ::= { mta-message-track 4 } 822 msgTrackResponseEntry OBJECT-TYPE 823 SYNTAX MsgTrackResponseEntry 824 ACCESS not-accessible 825 STATUS current 826 DESCRIPTION 827 "The entry associated with each response to a request for message 828 information." 829 INDEX { respEntryIndex, respMsgIndex } 830 ::= { msgTrackResponseTable 1 } 832 MsgTrackResponseEntry ::= SEQUENCE { 833 respEntryIndex 834 INTEGER, 835 respMsgIndex 836 INTEGER, 838 respDispositionStatus 839 DispositionStatus, 840 respDispositionTime 841 INTEGER, 842 respNextHopMta 843 DisplayString, 844 respPrevHopMta 845 DisplayString, 846 respNonDeliveryReason 847 DisplayString, 848 respMsgArrivalTime 849 DateAndTime, 850 respMsgSize 851 INTEGER, 852 respMsgPriority 853 DisplayString, 854 respUniqueMsgId 855 DisplayString, 856 respInboundMsgId 857 DisplayString, 858 respOutboundMsgId 859 DisplayString, 860 respInboundOriginator 861 DisplayString, 862 respOutboundOriginator 863 DisplayString, 864 respInboundRecipient 865 DisplayString, 866 respOutboundRecipient 867 DisplayString, 868 respSupplementalInformation 869 DisplayString, 870 respSubject 871 DisplayString, 872 respMsgType 873 MsgType 874 } 876 respEntryIndex OBJECT-TYPE 877 SYNTAX INTEGER (1..2147483647) 878 ACCESS read-only 879 STATUS current 880 DESCRIPTION 881 "The primary integer index into the msgTrackResponseTable table. It matches 882 the value of reqEntryIndex for the original request. " 883 ::= { msgTrackResponseEntry 1 } 885 respMsgIndex OBJECT-TYPE 886 SYNTAX INTEGER (1..2147483647) 887 ACCESS read-only 888 STATUS current 889 DESCRIPTION 890 "The secondary integer index into the msgTrackResponseTable table. For each 891 value of respEntryIndex in the table, there may be multiple conceptual rows 892 indexed by respMsgIndex, each denoting a possible response to the tracking 893 query. The maximum number of entries should have an upper bound of the 894 value of reqMaxResponses in the conceptual row of msgTrackRequestTable 895 that represents the original query request. " 896 ::= { msgTrackResponseEntry 2 } 898 respDispositionStatus OBJECT-TYPE 899 SYNTAX DispositionStatus 900 ACCESS read-only 901 STATUS current 902 DESCRIPTION 903 "Indicates the disposition of this message by this MTA for this recipient." 904 ::= { msgTrackResponseEntry 3 } 906 rspDispositionTime OBJECT-TYPE 907 SYNTAX DateAndTime 908 ACCESS read-only 909 STATUS current 910 DESCRIPTION 911 "Time at which this MTA disposed of this message for this recipient." 912 ::= { msgTrackResponseEntry 4 } 914 respNextHopMta OBJECT-TYPE 915 SYNTAX DisplayString 916 ACCESS read-only 917 STATUS current 918 DESCRIPTION 919 "Name of the MTA to which this message was sent. MADMAN-compliant 920 MTA's should be addressed in the form '(::)'." 921 ::= { msgTrackResponseEntry 5 } 923 respPrevHopMta OBJECT-TYPE 924 SYNTAX DisplayString 925 ACCESS read-only 926 STATUS current 927 DESCRIPTION 928 "Name of the MTA from which this message was received. MADMAN- 929 compliant MTA's should be addressed in the form 930 '(::)'." 931 ::= { msgTrackResponseEntry 6 } 933 respNonDeliveryReason OBJECT-TYPE 934 SYNTAX DisplayString 935 ACCESS read-only 936 STATUS current 937 DESCRIPTION 938 "A textual representation representing the reason for non-delivery to 939 this recipient. No attempt is made to normalize these non-delivered 940 reasons across systems, since this indicates a terminal condition." 941 ::= { msgTrackResponseEntry 7 } 943 respMsgArrivalTime OBJECT-TYPE 944 SYNTAX DateAndTime 945 ACCESS read-only 946 STATUS current 947 DESCRIPTION 948 "Represents the time at which this message for this recipient arrived at 949 this MTA." 950 ::= { msgTrackResponseEntry 8 } 952 respMsgSize OBJECT-TYPE 953 SYNTAX INTEGER(1..2147483647) 954 ACCESS read-only 955 STATUS current 956 DESCRIPTION 957 "Size of the message in kilo-octets." 958 ::= { msgTrackResponseEntry 9 } 960 respMsgPriority OBJECT-TYPE 961 SYNTAX DisplayString 962 ACCESS read-only 963 STATUS current 964 DESCRIPTION 965 "Textual representation of the priority of the message. No attempt is 966 made to normalize these values across disparate messaging technologies." 967 ::= { msgTrackResponseEntry 10 } 969 respUniqueMsgId OBJECT-TYPE 970 SYNTAX DisplayString 971 ACCESS read-only 972 STATUS current 974 DESCRIPTION 975 "The unique message identifier that the MTA assigned internally 976 to the message." 977 ::= { msgTrackResponseEntry 11 } 979 respInboundMsgId OBJECT-TYPE 980 SYNTAX DisplayString 981 ACCESS read-only 982 STATUS current 983 DESCRIPTION 984 "The unique message identifier that the 'previous hop' MTA assigned 985 to the message. If the 'previous' MTA uses a different messaging technology 986 or identifier scheme, this identifier serves to correlate the message from 987 MTA to MTA. If the 'previous' MTA uses the same technology, this value 988 is generally superfluous. If this is the first MTA in the delivery 989 sequence, or if the previous message id is unknown, this variable is null- 990 valued." 991 ::= { msgTrackResponseEntry 12 } 993 respOutboundMsgId OBJECT-TYPE 994 SYNTAX DisplayString 995 ACCESS read-only 996 STATUS current 997 DESCRIPTION 998 "The unique message identifier that the 'next hop' MTA assigned 999 to the message. If the 'next' MTA uses a different messaging technology 1000 or identifier scheme, this identifier serves to correlate the message from 1001 MTA to MTA. If the 'next' MTA uses the same technology, this value 1002 is generally superfluous. If this is the last MTA in the delivery sequence, 1003 or if the next hop message id is unknown, this variable is null-valued." 1004 ::= { msgTrackResponseEntry 13 } 1006 respInboundOriginator OBJECT-TYPE 1007 SYNTAX DisplayString 1008 ACCESS read-only 1009 STATUS current 1010 DESCRIPTION 1011 "Textual representation identifying the originator of the message as it was 1012 received from the 'previous hop' MTA. The style of this variable varies 1013 according to a specific messaging technology." 1014 ::= { msgTrackResponseEntry 14 } 1016 respOutboundOriginator OBJECT-TYPE 1017 SYNTAX DisplayString 1018 ACCESS read-only 1019 STATUS current 1021 DESCRIPTION 1022 "Textual representation identifying the originator of the message as it 1023 was (or will be) presented to the 'next hop' MTA. The style of this 1024 variable varies according to a specific messaging technology." 1025 ::= { msgTrackResponseEntry 15 } 1027 respInboundRecipient OBJECT-TYPE 1028 SYNTAX DisplayString 1029 ACCESS read-only 1030 STATUS current 1031 DESCRIPTION 1032 "Textual representation identifying the recipient of the message as it was 1033 received from the 'previous hop' MTA. The style of this variable varies 1034 according to a specific messaging technology.." 1035 ::= { msgTrackResponseEntry 16 } 1037 respOutboundRecipient OBJECT-TYPE 1038 SYNTAX DisplayString 1039 ACCESS read-only 1040 STATUS current 1041 DESCRIPTION 1042 "Textual representation identifying the recipient of the message as it 1043 was (or will be) presented to the 'next hop' MTA. The style of this 1044 variable varies according to a specific messaging technology." 1045 ::= { msgTrackResponseEntry 17 } 1047 respSupplementalInformation OBJECT-TYPE 1048 SYNTAX DisplayString 1049 ACCESS read-only 1050 STATUS current 1051 DESCRIPTION 1052 "Contains information provided by the agent to the manager that may be 1053 of use in identifying or tracking this message. No formal structure for 1054 this information is specified. Knowledge of the contents of this field 1055 is by bilateral agreement." 1056 ::= { msgTrackResponseEntry 18 } 1058 respSubject OBJECT-TYPE 1059 SYNTAX DisplayString 1060 ACCESS read-only 1061 STATUS current 1062 DESCRIPTION 1063 "The full text of the subject of the tracked message" 1064 ::= { msgTrackResponseEntry 19 } 1066 respMsgType OBJECT-TYPE 1067 SYNTAX MsgType 1068 ACCESS read-only 1069 STATUS current 1070 DESCRIPTION 1071 "The type of the tracked message" 1072 ::= { msgTrackResponseEntry 20 } 1074 - -- CONFORMANCE INFORMATION 1075 - -- Used ONLY in V2 MIBs 1076 messageTrackingConformance OBJECT IDENTIFIER ::= { 1077 mta-message-track 5 } 1078 messageTrackingGroups OBJECT IDENTIFIER ::= { 1079 messageTrackingConformance 1 } 1080 messageTrackingCompliances OBJECT IDENTIFIER ::= { 1081 messageTrackingConformance 2 } 1083 - -- COMPLIANCE STATEMENTS 1084 - -- Used ONLY in V2 MIBs 1085 limitedCompliance MODULE-COMPLIANCE 1086 STATUS current 1087 DESCRIPTION 1088 "The basic levels of compliance for SNMPv2 entities that implement this MIB 1089 for message tracking requiring the knowledge of a message Id." 1090 MODULE -- this module 1091 MANDATORY-GROUPS { msgIdGroup } 1092 ::= { messageTrackingCompliances 1 } 1094 basicCompliance MODULE-COMPLIANCE 1095 STATUS current 1096 DESCRIPTION 1097 "The basic levels of compliance for SNMPv2 entities that implement this MIB 1098 for message tracking without requiring the knowledge of a message Id." 1099 MODULE -- this module 1100 MANDATORY-GROUPS { msgIdGroup, basicGroup } 1101 ::= { messageTrackingCompliances 2 } 1103 enhancedCompliance MODULE-COMPLIANCE 1104 STATUS current 1105 DESCRIPTION 1106 "The basic levels of compliance for SNMPv2 entities that implement this MIB 1107 for message tracking without requiring the knowledge of a message Id and 1108 allowing an enhanced level of query capabilities." 1109 MODULE -- this module 1111 MANDATORY-GROUPS { msgIdGroup, basicGroup, enhancedGroup } 1112 ::= { messageTrackingCompliances 3 } 1114 gatewayCompliance MODULE-COMPLIANCE 1115 STATUS current 1116 DESCRIPTION 1117 "The basic levels of compliance for SNMPv2 entities that implement this MIB 1118 for message tracking across mta's that perform a gateway function." 1119 MODULE -- this module 1120 MANDATORY-GROUPS { msgIdGroup, basicGroup, enhancedGroup, 1121 gatewayGroup } 1122 ::= { messageTrackingCompliances 4 } 1124 - -- UNITS OF CONFORMANCE 1125 - -- Used ONLY in V2 MIBs 1126 msgIdGroup OBJECT-GROUP 1127 OBJECTS { 1128 msgTrackNextRequestIndex, reqRowStatus, 1129 reqResponseStatus, reqMaxResponses, reqUniqueMsgId, 1130 reqFailureReason, respDispositionStatus, respDispositionTime, 1131 respNonDeliveryReason, respMsgArrivalTime, respUniqueMsgId, 1132 respInboundOriginator, respInboundRecipient 1133 } 1134 STATUS current 1135 DESCRIPTION 1136 " A collection of objects for tracking messages where the messageId is 1137 known with responses containing basic message information." 1138 ::= { messageTrackingGroups 1 } 1140 basicGroup OBJECT-GROUP 1141 OBJECTS { 1142 reqInboundOriginator, reqInboundRecipient, reqOriginatorNameForm, 1143 reqRecipientNameForm, reqEarliestArrivalTime, reqLatestArrivalTime 1144 } 1145 STATUS current 1146 DESCRIPTION 1147 " A collection of objects for tracking messages where the messageId is not 1148 known 1149 with responses containing basic message information." 1150 ::= { messageTrackingGroups 2} 1152 enhancedGroup OBJECT-GROUP 1153 OBJECTS { 1154 reqSubject, reqMinMsgSize, reqMaxMsgSize, 1155 reqDispositionStatus, reqMsgType, reqCollapseRecipients, 1156 respMsgSize, respMsgPriority, respSupplementalInformation, 1157 respSubject, respMsgType 1158 } 1159 STATUS current 1160 DESCRIPTION 1161 " A collection of objects for tracking messages where the messageId is not 1162 known with responses containing enhanced message information as 1163 well as enhanced query capabilities." 1164 ::= { messageTrackingGroups 3} 1166 gatewayGroup OBJECT-GROUP 1167 OBJECTS { 1168 reqInboundMsgId, reqOutboundMsgId, reqOutboundOriginator, 1169 reqOutboundRecipient, respNextHopMta, respPrevHopMta, 1170 respInboundMsgId, respOutboundMsgId, respOutboundOriginator, 1171 respOutboundRecipient 1172 } 1173 STATUS current 1174 DESCRIPTION 1175 " A collection of object for tracking messages that have passed through a 1176 gateway mta." 1177 ::= { messageTrackingGroups 4} 1179 END 1181 5 Usages 1183 A general model of message flow between MTAs has to be presented before 1184 a MIB can be described. Generally speaking, message flow occurs in three 1185 steps. We use the term "MTA" loosely to refer to any processing entity that is 1186 responsible for message delivery: 1188 (1) Messages are received by the MTA from user agents, message stores, other 1189 MTAs, and gateways. 1190 (2) The "next hop" for the each message is determined. This is simply the 1191 destination the message is to be transmitted to; it may or may not be the final 1192 destination of the message. Next hop is established on a per-recipient basis. 1193 Next hop may be a User Agent, a Message Store, another MTA, or a gateway. 1195 (3) Information about the message and the next hop are written out to a log in 1196 some format. Messages are transmitted to the appropriate destination, which 1197 may be a user agent, message store, another MTA, or another gateway. 1199 In terms of message tracking, the key step is step number 3, the logging of 1200 information. Once information about a message is written to a log, it can be 1201 subsequently queried by any number of means. It is the intent of this 1202 specification to support the following general message tracking usages. 1204 Tracking an Individual Message 1206 It is often necessary for messaging operations to track down the whereabouts 1207 and/or history of an individual message managed object. This is typically in 1208 response to a particular user tracking request regarding a previously sent 1209 message. It might also be used by messaging operations to verify that one or 1210 more message paths are operating properly. 1212 Entire Path or Current Status 1214 For some inquiries, it is desired that the entire path taken by the message to 1215 date be discovered, including the current disposition of the message (for one 1216 or more recipients). For others, it is necessary only to discover the current 1217 disposition of the message. Note however that it may be necessary to uncover 1218 its entire path to date in order to determine its current disposition. 1219 To discover a message's entire path, it will be necessary to query the 1220 Management Agent (MA) of each MTA and/or gateway encountered by the 1221 message, beginning with the originating MTA, to discover the status of the 1222 message from that MTA or gateway's perspective. 1223 Dispositions include: Transferred-to another MTA or gateway, In-queue 1224 within an MTA or gateway, Delivered, Non-delivered, Redirected, or Dlist- 1225 expanded. If a message was relayed to another MTA or gateway, then the MA 1226 of that MTA or gateway must be queried in turn. This must be repeated until 1227 the MTA or gateway which currently has responsibility for the message is 1228 reached. 1230 To discover a message's current disposition, it might in fact be necessary to track 1231 the message's entire path, since typically the current status can only be 1232 discovered by a forward traversal through the message path. Alternatively, to 1233 minimize expense, the MA of any MTA/gateway which is estimated to be in the 1234 message path can be queried; if the message is shown to have reached this 1235 estimated point, then previous points in the path are irrelevant. Best estimate 1236 may therefore be the MA of the destination MTA, if known. Other estimates 1237 are made based on arbitrary intelligence which may be available. 1239 For a message with multiple recipients, a different path/ disposition may be 1240 relevant for each recipient. Thus, message tracking queries must be made to 1241 discover the path/disposition of each recipient of the message, or for each 1242 recipient explicitly identified in the tracking request. For cases in which multiple 1243 recipient message copies are transferred-to the same MTA or gateway, these 1244 queries may be combined into a single query, for convenience. 1246 Identifying Messages to Track 1248 In some cases, the user may have retained some sort of a unique identifier for 1249 the message of interest. This will be true, for example, because an explicit 1250 trackability service was requested for the message, or because the user logs all 1251 outgoing messages. In such cases, a message query can be made simply on the 1252 basis of providing this unique identifier to the message tracking system. 1254 Optionally, this query can be bounded by: 1256 o specific recipient(s) of interest; 1257 o time range of interest; 1258 o or other bounding information. 1260 In other cases, the user may only know some general descriptive information 1261 about the message. For example, the user may know who originated it, to 1262 whom it was sent, and roughly what time of day it was submitted. In such 1263 cases, it will be necessary to provide descriptive information to the message 1264 tracking system and allow it to respond with a list of matching messages which 1265 it knows about, along with their unique identifiers. 1267 In either case, the query can specify or imply a list of information which it 1268 wishes the query response to return to the requester. 1270 Query Responses 1272 The query response must then return the requested information, or return an 1273 indication as to why it cannot return the requested information. If the returned 1274 information includes an indication that the message has been further relayed, 1275 then a subsequent query must made to the transferred-to MTA or gateway. 1276 Specific response information must be provided/implied in order to allow for 1277 the creation of subsequent queries. For example: 1279 o the name of the transferred-to MTA or gateway 1280 o the name of the MA of the transferred-to MTA or gateway 1281 o the names/addresses of the recipient(s) of interest which have taken this relay 1282 path. Note that this may be a "redirected" recipient. 1283 o If this response comes from a gateway, the translated versions of key 1284 identification fields. 1286 This subsequent query can optionally be formulated automatically. 1287 See next section on "Automating Follow-up Queries" for details on follow-up 1288 query creation. 1290 Automating Follow-up Queries 1292 In order to support a fully automated path search, it is convenient and powerful 1293 for a management agent to be able to automatically make all of the queries 1294 required to discover the full path of an individual message. The MC can 1295 accomplish this by creating an initial query, and then creating a follow-on query 1296 utilizing information returned by the initial query, and repeating this process 1297 until the current disposition of the message is discovered. 1299 Follow-on queries will need to be generated on a per-recipient basis. For cases 1300 in which multiple recipient message copies were transferred-to the same MTA 1301 or gateway, these queries may be combined into a single query, for efficiency. 1303 In general, a follow-on query will need to: 1305 o Be directed at the MA which corresponds to the MTA or gateway to which 1306 the message (copy) was relayed. 1307 o Include the names/addresses of the recipient(s) which have taken this relay 1308 path. Note that this may be a "redirected" recipient. 1309 o Include the same bounding criteria as did the initial query, with the 1310 addition of the unique message identification if that information was not 1311 previously available. 1312 o If the just-completed query was to a gateway, then the new translated 1313 formats for the following will need to be used, if applicable: 1314 - Message ID 1315 - Recipient address 1316 - Originator address 1317 - Priority value 1318 - Size. 1320 Tracking Aggregates of Messages 1322 It is sometimes desirable for messaging operations to be able to determine 1323 information about the history/status of all messages which match a given set 1324 of characteristics that have passed through their systems. 1326 Identifying Messages to Track 1328 In some cases, messaging operations may have retained some sort of a unique 1329 identifier for the messages of interest. More probably, messaging operations is 1330 simply interested in the set of messages which: 1332 o went through its systems within a given time range, or 1333 o were sent through its systems by a given originator, or 1334 o were sent through its systems to a given recipient, or 1335 o were sent through its systems with a given size or priority 1337 In such cases, it will be necessary to provide descriptive information to the 1338 message tracking system and allow it to respond with information on all of the 1339 matching messages which it knows about. The query can specify or imply a list 1340 of information which it wishes the query response to return to the requester. 1342 Query Responses 1344 The query response must then return the requested information, or return an 1345 indication as to why it cannot return the requested information. 1347 6. Future Considerations 1349 A version of this information is also available in the Management Information 1350 Format (MIF) defined by the Desktop Management Task Force (DMTF). 1352 As SNMP continues to evolve (e.g. SNMPv3), 1353 the mechanisms in this document will leverage those new technologies. 1355 7. Acknowledgements 1357 This draft also incorporates the intellectual contributions of 1359 Bruce Greenblatt 1360 Niraj Jain 1361 Sue Lebeck 1362 Roger Mizumori 1363 Edward Owens 1365 8. References 1367 [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1368 of Management Information for version 2 of the Simple Network 1369 Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., 1370 Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1371 University, February 1996. 1373 [2] McCloghrie, K., and M. Rose, Editors, "Management Information 1374 Base for Network Management of TCP/IP-based internets: MIB-II", 1375 STD 17, RFC 1213, Hughes LAN Systems, Performance Systems 1376 International, March 1991. 1378 [3] Case, J., McCloghrie, K., Rose, M., and S, Waldbusser, "Protocol 1379 Operations for version 2 of the Simple Network Management 1380 Protocol (SNMPv2)", RFC 1905, SNMP Research,Inc., Hughes LAN 1381 Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1382 University, February 1996. 1384 Security Considerations 1386 Security issues are not discussed in this memo. 1388 Authors' Addresses 1390 Bruce Ernst 1391 Lotus Development Corporation 1393 Phone: +1 610 251 3404 1394 E-Mail: bernst@softsw.ssw.com 1396 Gordon Jones 1397 MITRE Corporation 1398 1820 Dolley Madison Blvd. 1399 McLean, VA 22102-3481 1401 Phone: +1 703 883 7670 1402 E-Mail: gbjones@mitre.org 1404 Jonathan Weintraub 1405 Electronic Data Systems, Inc. 1407 +1 301 619 3101