idnits 2.17.1 draft-ernst-msgmib-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-18) 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 == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 3) being 82 lines == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '... Drafts are ...' == Line 15 has weird spacing: '...cuments of t...' == Line 16 has weird spacing: '... groups may ...' == Line 20 has weird spacing: '... Drafts may ...' == Line 21 has weird spacing: '...iate to use ...' == (15 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 (March 1998) is 9531 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: 'TBD' is mentioned on line 1500, but not defined ** Obsolete normative reference: RFC 1902 (ref. '1') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1905 (ref. '3') (Obsoleted by RFC 3416) -- Possible downref: Non-RFC (?) normative reference: ref. 'MODEL' Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MADMAN Working Group Bruce Ernst [bruce_ernst@lotus.com] 2 INTERNET-DRAFT Lotus Development Corporation 3 draft-ernst-msgmib-00.txt Gordon Jones [gbjones@mitre.org] 4 MITRE Corporation 5 Jonathan Weintraub 6 Electronic Data Systems, Inc. 8 March 1998 10 Message Tracking MIB 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 28 munnari.oz.au. 30 Abstract 32 This document defines a message tracking Management Information Base 33 (MIB) for electronic messaging management. Message tracking is the 34 ability to find out, after the fact, the path that a particular message 35 took through the messaging system and the current status of that message. 37 1. The SNMP Network Management Framework. 39 The major components of the SNMP Network Management framework are 40 described in the documents listed below. 42 o RFC 1902 [1] defines the Structure of Management Information 43 (SMI), the mechanisms used for describing and naming objects 44 for the purpose of management. 46 o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed 47 objects (MO) for the Internet suite of protocols. 49 o RFC 1905 [3] defines the protocol used for network access to 50 managed objects. 52 The framework is adaptable/extensible by defining new MIBs to suit the 53 requirements of specific applications/protocols/situations. 55 Managed objects are accessed via a virtual information store, the MIB. 56 Objects in the MIB are defined using the subset of Abstract Syntax 57 Notation One (ASN.1) defined in the SMI. In particular, each object type 58 is named by an OBJECT IDENTIFIER, which is an administratively assigned 59 name. The object type together with an object instance serves to 60 uniquely identify a specific instantiation of the object. For human 61 convenience, often a textual string, termed the descriptor, is used to 62 refer to the object type. 64 2. Message Tracking 66 Message tracking refers, in its simplest form, to determining the path 67 a message 68 has taken and it's current location. This capability is analogous to 69 the service 70 provided by carriers of conventional paper mail - the ability to 71 quickly locate 72 where a package is, and to determine whether or not the package has 73 been 74 delivered to its destination. This document discusses a specific 75 SNMP-based 76 per-message mechanism to query the messaging system to perform message 77 tracking. For a detailed definition of message tracking, and the need 78 for message 79 tracking, refer to [MODEL]. 81 3. MIB Data to Support Message Tracking 83 This MIB contains the syntax for message tracking via SNMP. The 84 attributes 85 defined are identical to those defined for message tracking via e-mail, 86 except 87 for those attributes that are required purely to enable SNMP-specific 88 semantics. 90 When making use of SNMP, it is expected that the following mode of 91 operation 92 will be used. The entity acting in the manager role issues one or more 93 "SET" 94 operations filling in a row in a request table. The variables set in 95 the request 96 table together comprise a message tracking query. The entity acting in 97 the agent 98 role reads the values set in the request table, queries the local 99 message store 100 (or usage logs), and returns information regarding messages that satify 101 the query 102 criteria in a response table. The entity acting as the manager then 103 reads the 104 response table and notifies an administrator or performs additional 105 queries as 106 required. 108 In the message tracking MIB that follows, there are three tables: 110 1. the mtaInformationTable 111 2. the msgTrackRequestTable 112 3. the msgTrackResponseTable 114 The mtaInformationTable contains one entry for each MTA that is 115 monitored 116 by this agent. The table contains information about the MTA as a 117 whole, such 118 as: the name of the MTA and the length of time that the MTA has been 119 recording 120 information. This last item is important to know, since if the MTA 121 indicates that 122 it only has information about messages that have passed through it in 123 the last two 124 days, and the administrator wishes to track a message that was sent 125 four days ago, 126 then there will be no need to attempt to track the message through this 127 MTA. 129 The msgTrackRequestTable is used by a manager to specify a query to be 130 made 131 of the agent. It is not required that the manager have any knowledge 132 of a unique 133 message identifier, but knowledge of some information pertaining to the 134 message 135 in question is recommended. Since the query information may be matched 136 by a 137 number of potential matches, it is possible to find out information 138 about several 139 different messages. 141 The msgTrackResponseTable is a parallel to the msgTrackRequestTable in 142 that it 143 holds the response(s) to the queries posed in the msgTrackRequestTable. 144 The 145 manager reads this table to retrieve information about the messages 146 that match 147 the input query information. The two tables share a common index to 148 facilitate 149 navigation between them. 151 MESSAGE-TRACKING-MIB DEFINITIONS ::= BEGIN 153 IMPORTS 154 OBJECT-TYPE, MODULE-IDENTITY, Counter32 155 FROM SNMPv2-SMI 156 DisplayString, TimeInterval, DateAndTime 157 FROM SNMPv2-TC; 159 -- Note that in SNMPv1 the IMPORTS section should look like the 160 following: 161 -- IMPORTS 162 -- OBJECT-TYPE, enterprises, Counter, Gauge, TimeTicks 163 -- FROM RFC1155-SMI 164 -- DisplayString 165 -- FROM RFC1213-MIB; 167 -- OBJECT IDENTIFIERS 168 MsgTracking OBJECT IDENTIFIER ::= { experimental 73 2 } 170 -- MODULE IDENTIFICATION use in V2 version only 171 mta-message-track MODULE-IDENTITY 172 LAST-UPDATED "9704110000Z" 173 ORGANIZATION "IETF" 174 CONTACT-INFO 175 "Gordon Jones 176 Postal: 1820 Dolly Madison Boulevard 177 Mc Lean, VA 22102-3481 178 Tel: +1 703 883 7670 179 Fax: +1 703 883 7670 180 E-mail: gbjones@mitre.org" 181 DESCRIPTION 182 "The MIB module describing message tracking" 183 ::= { MsgTracking 1 } 185 -- Note that the MODULE-IDENTITY macro does not exist in SNMP version 1, 186 -- for a V1 implementation, replace the above macro with the following 187 line : 188 -- mta-message-track OBJECT IDENTIFIER ::= {MsgTracking 1 } 190 -- Note that the textual conventions DateAndTime and TimeInterval 191 -- do not exist in SNMPv1, for a V1 implementation include the following 192 -- 2 lines: 193 -- DateAndTime ::= DisplayString 194 -- TimeInterval ::= INTEGER (0..2147483647) 195 -- Define the NameForm textual convention for originator and recipient 196 -- names in this MIB 197 NameForm ::= INTEGER { 198 freeForm(1), 199 x400(2), 200 smtp(3) 201 } 203 -- Define the DispositionStatus textual convention which indicates the 204 -- disposition of a message by the MTA for a particular recipient. 205 Values 206 -- are: 207 -- unknown - The disposition of the message could not be determined 208 -- transferred - The message was forwarded to another MTA for 209 -- delivery without name or content transformation. 210 -- delivered - The message was delivered to the intended recipient. 211 -- non-delivered - The message could not be delivered to the intended 212 -- recipient. 213 -- redirected - The message was forwarded to another MTA for 214 -- delivery. The recipient name and/or messageId 215 -- may have changed as a result of this process. 216 -- dlist-expanded - The intended recipient was a distribution list 217 -- which was expanded by the MTA. 218 -- in-queue - The message for this recipient is currently being 219 -- processed by the MTA. 221 DispositionStatus ::= INTEGER { 222 unknown(1), 223 transferred(2), 224 delivered(3), 225 non-delivered(4), 226 redirected(5), 227 dlist-expanded(6), 228 in-queue(7) 229 } 231 -- Define the MsgType textual convention. Values are: 232 -- 233 -- data 234 -- status 235 -- probe 237 MsgType ::= INTEGER { 238 any(1), 239 data(2), 240 status(3), 241 probe(4) 242 } 244 -- How this mib works : 245 -- Most message tracking MIBs operate on the presupposition that the 246 manager 247 -- entering a query knows the unique message ID for the message being 248 tracked. 249 -- In practice, this is often not the case. This MIB allows for a 250 2-step 251 -- query process - find the appropriate message, then track it. 253 -- +==============+ 254 -- | Manager | = 1 => +=====================================+ 255 -- +==============+ = 6 => | msgTrackRequestTable | 256 -- ^ +=====================================+ 257 -- | | 258 -- | 2 +=========+ 259 -- | + => | Agent | 260 -- | +=========+ 261 -- 5 | 262 +======================+ 263 -- | + 3 => | Message 264 Store | 265 -- | += 4 ========== 266 +======================+ 267 -- | | 268 -- | v 269 -- | +========================================+ 270 -- ===============> | msgTrackResponseTable | 271 -- +========================================+ 272 -- 273 -- STEP 1: 274 -- Using the index obtained from 'msgTrackNextRequestIndex', a manager 275 -- creates a conceptual row in the 'msgTrackRequestTable', filling in 276 -- as many message attributes as are known. The manager also specifies 277 -- in 'reqMaxResponses', the maximim number of possible 'hits' for an 278 -- underspecified query. 279 -- STEP 2: 280 -- When the agent detects a new conceptual row in 281 'msgTrackRequestTable', 282 -- it forms a query to be executed against the message store(s). 283 -- STEP 3: 284 -- The agent issues the query against the message store and receives 285 some 286 -- response(s). 287 -- STEP 4: 288 -- The agent then transfers up to 'reqMaxResponses' possible responses 289 -- to newly created conceptual rows in the 'msgTrackResponseTable'. The 290 agent 291 -- then sets the value of 'reqResponseStatus' in the 292 'msgTrackRequestTable' 293 -- to notify the manager of the results of the query. 294 -- STEP 5: 295 -- The manager, having detected a change in 'reqResponseStatus', knows 296 that 297 -- the query is complete. It reads the potential responses from the 298 -- 'msgTrackResponseTable' and presents them to the end-user. 300 -- STEP 6: 301 -- The manager then instructs the agent to destroy the conceptual row 302 -- created in the 'msgTrackRequestTable', which causes the agent to 303 -- destroy the corresponding entries in the 'msgTrackResponseTable'. 304 -- STEP 7: (optional, not illustrated) 305 -- If the original query did not produce an adequate response, a new 306 entry 307 -- is created in the 'msgTrackRequestTable'. Entries in this table are 308 -- never reused! 309 -- 310 -- 312 -- MESSAGE TRACKING REQUEST TABLE: 314 mtaInformationTable OBJECT-TYPE 315 SYNTAX SEQUENCE OF mtaInformationEntry 316 MAX-ACCESS not-accessible 317 STATUS current 318 DESCRIPTION 319 "The table holding information about the MTA being queried. A table 320 is used because there may be multiple MTAs at a single host." 321 ::= { mta-message-track 1 } 323 mtaInformationEntry OBJECT-TYPE 324 SYNTAX mtaInformationEntry 325 MAX-ACCESS not-accessible 326 STATUS current 327 DESCRIPTION 328 "One entry in the table holding information about the MTA being 329 queried" 330 INDEX { mtaIndex } 331 ::= { mtaInformationTable 1 } 333 mtaInformationEntry ::= SEQUENCE { 334 mtaIndex 335 INTEGER, 336 mtaName 337 DisplayString, 338 mtaMessagingType 339 DisplayString, 340 startTimeforRecordedInformation 341 DateAndTime, 342 alternativeAgent 343 DisplayString 344 } 345 mtaIndex OBJECT-TYPE 346 SYNTAX INTEGER (1..2147483647) 347 ACCESS read-only 348 STATUS current 349 DESCRIPTION 350 "The integer index into this table." 351 ::= { mtaInformationEntry 1 } 353 mtaName OBJECT-TYPE 354 SYNTAX DisplayString 355 ACCESS read-only 356 STATUS current 357 DESCRIPTION 358 "The name of the MTA described in this row of the table." 359 ::= { mtaInformationEntry 2 } 361 mtaMessagingType OBJECT-TYPE 362 SYNTAX DisplayString 363 ACCESS read-only 364 STATUS current 365 DESCRIPTION 366 " Common name of the messaging system of this MTA (e.g. X.400, 367 SMTP)." 368 ::= { mtaInformationEntry 3 } 370 mtaStartTimeforRecordedInformation OBJECT-TYPE 371 SYNTAX DateAndTime 372 ACCESS read-only 373 STATUS current 374 DESCRIPTION 375 " The date/time of the oldest message tracking information 376 available from this MTA." 377 ::= { mtaInformationEntry 4 } 379 mtaAlternativeAgent OBJECT-TYPE 380 SYNTAX DisplayString 381 ACCESS read-only 382 STATUS current 383 DESCRIPTION 384 "The name (or address) of another agent that may have message 385 tracking information concerning this MTA." 386 ::= { mtaInformationEntry 5 } 388 msgTrackNextRequestIndex OBJECT-TYPE 389 SYNTAX Counter32 -- Note that in SNMPv1, the syntax is simply 390 'Counter' 391 ACCESS read-only 392 STATUS current 393 DESCRIPTION 394 "The index that may be used by a manager (requestor) on a 395 'set-request' PDU 396 to create a new conceptual row in the msgTrackRequestTable table 397 (and 398 thereby issue a message tracking query)." 399 ::= { mta-message-track 2 } 401 msgTrackRequestTable OBJECT-TYPE 402 SYNTAX SEQUENCE OF MsgTrackRequestEntry 403 ACCESS not-accessible 404 STATUS current 405 DESCRIPTION 406 "The table holding all active message tracking requests." 407 ::= { mta-message-track 3 } 409 msgTrackRequestEntry OBJECT-TYPE 410 SYNTAX MsgTrackRequestEntry 411 ACCESS not-accessible 412 STATUS current 413 DESCRIPTION 414 "The entry associated with each request for message information." 415 INDEX { reqEntryIndex } 416 ::= { msgTrackRequestTable 1 } 418 MsgTrackRequestEntry ::= SEQUENCE { 419 reqEntryIndex 420 INTEGER, 421 reqRowStatus 422 INTEGER, 423 reqResponseStatus 424 INTEGER, 425 reqMaxResponses 426 INTEGER, 427 reqUniqueMsgId 428 DisplayString, 429 reqInboundMsgId 430 DisplayString, 431 reqOutboundMsgId 432 DisplayString, 433 reqInboundOriginator 434 DisplayString, 436 reqOutboundOriginator 437 DisplayString, 438 reqOriginatorNameForm 439 NameForm, 440 reqInboundRecipient 441 DisplayString, 442 reqOutboundRecipient 443 DisplayString, 444 reqRecipientNameForm 445 NameForm, 446 reqSubject 447 DisplayString, 448 reqMinMsgSize 449 INTEGER, 450 reqMaxMsgSize 451 INTEGER, 452 reqEarliestArrivalTime 453 DateAndTime, 454 reqLatestArrivalTime 455 DateAndTime, 456 reqDispositionStatus 457 DispositionStatus, 458 reqFailureReason 459 DisplayString, 460 reqMsgType 461 MsgType, 462 reqCollapseRecipients 463 INTEGER 464 } 466 reqEntryIndex OBJECT-TYPE 467 SYNTAX INTEGER (1..2147483647) 468 ACCESS read-only 469 STATUS current 470 DESCRIPTION 471 "The integer index into the msgTrackRequestTable table." 472 ::= { msgTrackRequestEntry 1 } 474 reqRowStatus OBJECT-TYPE 475 SYNTAX INTEGER { 476 active(1), 477 notInService(2), 478 notReady(3), 479 createAndGo(4), 480 createAndWait(5), 481 destroy(6) 482 } 483 ACCESS read-write 484 STATUS current 485 DESCRIPTION 486 "The status of the conceptual row. These are mapped to the same 487 values as 488 the RowStatus textual conversion in SNMPv2 and carry the same 489 semantics 490 with one exception: the exception is that when a manager 491 (requestor) sets the 492 value to destroy(6), this also has the added semantics of deleting 493 all 494 conceptual rows in the msgTrackResponseTable table whose 495 respEntryIndex 496 matches the reqEntryIndex of this conceptual row." 497 ::= { msgTrackRequestEntry 2 } 499 reqResponseStatus OBJECT-TYPE 500 SYNTAX INTEGER { 501 unknown(1), 502 inProgress(2), 503 failedNoMatches(3), 504 failedInvalidQuery(4), 505 failedError(5), 506 successUnderqualified(6), 507 success(7) 508 } 509 ACCESS read-only 510 STATUS current 511 DESCRIPTION 512 "Indicates the status of this query and its responses in the 513 msgTrackResponseTable. Values are: 514 unknown - The status of this query is not known. 515 inProgress - The agent(responder) is still processing the request. 516 failedNoMatches - The query has been processed and has produced 517 no 518 matches. 519 failedInvalidQuery - The query could not be processed due to 520 invalid or 521 missing data in the original query. 522 FailedError - The query could not be processed due to an error in 523 the 524 agent(responder). 525 successUnderqualified - The query was successfully processed, but 526 the query 527 was found to be underqualified. That is, more reponses were found 528 than were 529 specified in reqMaxResponses. reqMaxResponses entries were returned 530 in the 531 msgTrackResponseTable. 532 success - The query succeeded, returning from 1 to reqMaxResponse 533 entries in the msgTrackResponseTable." 534 ::= { msgTrackRequestEntry 3 } 536 reqMaxResponses OBJECT-TYPE 537 SYNTAX INTEGER (1..100) 538 ACCESS read-write 539 STATUS current 540 DESCRIPTION 541 "Specifies the largest number of responses to be returned in the 542 msgTrackResponseTable on an underspecified query (i.e. the 543 maximum value of respMsgIndex in the msgTrackResponseTable 544 conceptual row whose respEntryIndex matches the reqEntryIndex of 545 this 546 conceptual row)." 547 ::= { msgTrackRequestEntry 4 } 549 reqUniqueMsgId OBJECT-TYPE 550 SYNTAX DisplayString 551 ACCESS read-write 552 STATUS current 553 DESCRIPTION 554 "Specifies a unique message id used internally by the MTA for 555 identification 556 of a message. This form of the message id may or may not be 557 identical to the 558 inbound and/or outbound forms of the message id. If specified, 559 this may be 560 the only search criteria required. If the entire unique message id 561 is not 562 specified, prefix matching is assumed. Set to an empty (zero 563 length) string if 564 unknown or irrelevant to query." 565 ::= { msgTrackRequestEntry 5 } 567 reqInboundMsgId OBJECT-TYPE 568 SYNTAX DisplayString 569 ACCESS read-write 570 STATUS current 571 DESCRIPTION 572 "Specifies a unique message id as received by the MTA for 573 identification of 574 a message. This form of the message id may or may not be identical 575 to the 576 internal and/or outbound forms of the message id. If specified, 577 this may be the 578 only search criteria required. If the entire inbound message id is 579 not specified, 580 prefix matching is assumed. Set to an empty (zero length) string 581 if unknown or 582 irrelevant to query." 583 ::= { msgTrackRequestEntry 6 } 585 reqOutboundMsgId OBJECT-TYPE 586 SYNTAX DisplayString 587 ACCESS read-write 588 STATUS current 589 DESCRIPTION 590 "Specifies a unique message id as transmitted by the MTA for 591 identification 592 of a message. This form of the message id may or may not be 593 identical to the 594 internal and/or inbound forms of the message id. If specified, 595 this may be the 596 only search criteria required. If the entire outbound message id 597 is not 598 specified, prefix matching is assumed. Set to an empty (zero 599 length) string if 600 unknown or irrelevant to query." 601 ::= { msgTrackRequestEntry 7 } 603 reqInboundOriginator OBJECT-TYPE 604 SYNTAX DisplayString 605 ACCESS read-write 606 STATUS current 607 DESCRIPTION 608 "Identifies the originator of the message in its received form, 609 expressed in 610 string format. The style and format of this identifier varies 611 according to a 612 specific messaging technology. As a result of potentially disparate 613 messaging 614 technologies, this identifier is only guaranteed to be the name 615 known to the 616 end-user on the first MTA in the delivery sequence. If 617 reqOriginatorNameForm is set to 'x.400(2)' or 'smtp(3)', the 618 supplied 619 attributes will be considered in the match. Any attributes not 620 supplied will be 621 wildcarded. If reqOriginatorNameForm is set to 'freeForm(1)', this 622 value is 623 assumed to be a substring of the originator name. Set to an empty 624 (zero 625 length) string if unknown or irrelevant to query." 626 ::= { msgTrackRequestEntry 8 } 628 reqOutboundOriginator OBJECT-TYPE 629 SYNTAX DisplayString 630 ACCESS read-write 631 STATUS current 632 DESCRIPTION 633 "Identifies the originator of the message in its transmitted form, 634 expressed 635 in string format. The style and format of this identifier varies 636 according to a 637 specific messaging technology. As a result of potentially disparate 638 messaging 639 technologies this identifier is only guaranteed to be the name 640 known to the 641 end-user on the last MTA in the delivery sequence. If 642 reqOriginatorNameForm is set to 'x.400(2)' or 'smtp(3)', the 643 supplied attributes 644 will be considered in the match. Any attributes not supplied will 645 be 646 wildcarded. If reqOriginatorNameForm is set to 'freeForm(1)', this 647 value is 648 assumed to be a substring of the originator name. Set to an empty 649 (zero 650 length) string if unknown or irrelevant to query." 651 ::= { msgTrackRequestEntry 9 } 653 reqOriginatorNameForm OBJECT-TYPE 654 SYNTAX NameForm 656 ACCESS read-write 657 STATUS current 658 DESCRIPTION 659 "Identifies the name form of originator strings supplied in the 660 reqInboundOriginator and/or reqOutboundOriginator values. This 661 value is 662 used by the agent to perform name form dependant parsing of these 663 values. 664 If neither of these strings are supplied, this name form value is 665 irrelevant to 666 the query. A value of 'any(1)' implies that no special parsing 667 should be 668 performed on the originator names supplied." 669 ::= { msgTrackRequestEntry 10 } 671 reqInboundRecipient OBJECT-TYPE 672 SYNTAX DisplayString 673 ACCESS read-write 674 STATUS current 675 DESCRIPTION 676 "Identifies one of the recipients (the one to be tracked) of the 677 message in 678 its received form, expressed in string format. The style and 679 format of this 680 identifier varies according to a specific messaging technology. As 681 a result 682 of potentially disparate messaging technologies, this identifier is 683 only 684 guaranteed to be the name an end-user knows the recipient by on 685 the first 686 MTA in the delivery sequence. If reqRecipientNameForm is set to 687 'x.400(2)' 688 or 'smtp(3)', the supplied attributes will be considered in the 689 match. Any 690 attributes not supplied will be wildcarded. If reqRecipientNameForm 691 is set to 692 'freeForm(1)', this value is assumed to be a substring of the 693 recipient name. 694 Set to an empty (zero length) string if unknown or irrelevant to 695 query." 696 ::= { msgTrackRequestEntry 11 } 698 reqOutboundRecipient OBJECT-TYPE 699 SYNTAX DisplayString 700 ACCESS read-write 701 STATUS current 702 DESCRIPTION 703 "Identifies one of the recipients (the one to be tracked) of the 704 message in 705 its transmitted form, expressed in string format. The style and 706 format of this 707 identifier varies according to a specific messaging technology. As 708 a result of 709 potentially disparate messaging technologies, this identifier is 710 only guaranteed 711 to be the name an end-user knows the recipient by on the last MTA 712 in the 713 delivery sequence. If reqRecipientNameForm is set to 'x.400(2)' or 714 'smtp(3)', 715 the supplied attributes will be considered in the match. Any 716 attributes not 717 supplied will be wildcarded. If reqRecipientNameForm is set to 718 'freeForm(1)', 719 this value is assumed to be a substring of the recipient name. Set 720 to an empty 721 (zero length) string if unknown or irrelevant to query." 722 ::= { msgTrackRequestEntry 12 } 724 reqRecipientNameForm OBJECT-TYPE 725 SYNTAX NameForm 726 ACCESS read-write 727 STATUS current 728 DESCRIPTION 729 "Identifies the name form of recipient strings supplied in the 730 reqInboundRecipient and/or reqOutboundRecipient values. This value 731 is 732 used by the agent to perform name form dependant parsing of these 733 values. 734 If neither of these strings are supplied, this name form value is 735 irrelevant to 736 the query. A value of 'any(1)' implies that no special parsing 737 should be 738 performed on the recipient names supplied." 739 ::= { msgTrackRequestEntry 13 } 741 reqSubject OBJECT-TYPE 742 SYNTAX DisplayString 743 ACCESS read-write 744 STATUS current 745 DESCRIPTION 746 "Identifies a substring of the text of the 'Subject' attribute of 747 the message. 748 Since some messaging technologies make it difficult for an MTA to 749 preserve 750 this data, it may not be supported by all agents. Set to an empty 751 (zero length) 752 string if unknown or irrelevant to query." 753 ::= { msgTrackRequestEntry 14 } 755 reqMinMsgSize OBJECT-TYPE 756 SYNTAX INTEGER (1..2147483647) 757 ACCESS read-write 758 STATUS current 759 DESCRIPTION 760 "Specifies the minimum size of a message to be tracked (content, 761 excluding 762 envelope), expressed in kilo-octets. Set both reqMinMsgSize and 763 reqMaxMsgSize to zero if message size is irrelevant to the query." 764 ::= { msgTrackRequestEntry 15 } 766 reqMaxMsgSize OBJECT-TYPE 767 SYNTAX INTEGER (1..2147483647) 768 ACCESS read-write 769 STATUS current 770 DESCRIPTION 771 "Specifies the maximum size of a message to be tracked (content, 772 excluding 773 envelope), expressed in kilo-octets. Set both reqMinMsgSize and 774 reqMaxMsgSize to zero if message size is irrelevant to the query." 775 ::= { msgTrackRequestEntry 16 } 777 reqEarliestArrivalTime OBJECT-TYPE 778 SYNTAX DateAndTime 779 ACCESS read-write 780 STATUS current 781 DESCRIPTION 782 "Specifies the earliest arrival time, at this MTA, for a message to 783 be 784 tracked. Set to an empty (zero length) string if unknown or 785 irrelevant to 786 query." 787 ::= { msgTrackRequestEntry 17 } 789 reqLatestArrivalTime OBJECT-TYPE 790 SYNTAX DateAndTime 791 ACCESS read-write 792 STATUS current 793 DESCRIPTION 794 "Specifies the latest arrival time, at this MTA, for a message to be 795 tracked. Set to an empty (zero length) string if unknown or 796 irrelevant to 797 query." 798 ::= { msgTrackRequestEntry 18 } 800 reqDispositionStatus OBJECT-TYPE 801 SYNTAX DispositionStatus 802 ACCESS read-write 803 STATUS current 804 DESCRIPTION 805 "Specifies the disposition status of the message for a particular 806 recipient. Set to 'unknown(1)' if unknown or irrelevant to the 807 query." 808 ::= {msgTrackRequestEntry 19 } 810 reqMsgType OBJECT-TYPE 811 SYNTAX MsgType 812 ACCESS read-write 813 STATUS current 814 DESCRIPTION 815 "The type of message to be tracked. 816 Set to 'any(1)' if message type is unknown or irrelevant to the 817 query." 818 ::= {msgTrackRequestEntry 20 } 820 reqCollapseRecipients OBJECT-TYPE 821 SYNTAX INTEGER { 822 false(1), 823 true(2) 824 } 825 ACCESS read-write 826 STATUS current 827 DESCRIPTION 828 "If a value of 'true(2)' is specified, a single msgTrackResponseEntry 829 will be created for each matching message regardless of the 830 number of recipients. If not specified or set to 'false(1)', 831 a msgTrackResponseEntry will be created for each matching message 832 and/or recipient. This variable may be used in the case of a 833 distribution list or a message with a large number of 834 recipients." 835 ::= { msgTrackRequestEntry 21 } 837 reqFailureReason OBJECT-TYPE 838 SYNTAX DisplayString 839 ACCESS read-only 840 STATUS current 841 DESCRIPTION 842 "A textual description of why a message tracking request failed. 843 This variable may be set by an agent when the reqResponseStatus 844 is set to either 'failedInvalidQuery(4)', or 'failedError(5)'." 845 ::= {msgTrackRequestEntry 22 } 847 -- MESSAGE RESPONSE TABLE ( QUERY RESULTS ) 849 msgTrackResponseTable OBJECT-TYPE 850 SYNTAX SEQUENCE OF MsgTrackResponseEntry 851 ACCESS not-accessible 852 STATUS current 853 DESCRIPTION 854 "The table holding the response to all active message tracking 855 requests." 856 ::= { mta-message-track 4 } 858 msgTrackResponseEntry OBJECT-TYPE 859 SYNTAX MsgTrackResponseEntry 860 ACCESS not-accessible 861 STATUS current 862 DESCRIPTION 863 "The entry associated with each response to a request for message 864 information." 865 INDEX { respEntryIndex, respMsgIndex } 866 ::= { msgTrackResponseTable 1 } 868 MsgTrackResponseEntry ::= SEQUENCE { 869 respEntryIndex 870 INTEGER, 871 respMsgIndex 872 INTEGER, 874 respDispositionStatus 875 DispositionStatus, 876 respDispositionTime 877 INTEGER, 878 respNextHopMta 879 DisplayString, 880 respPrevHopMta 881 DisplayString, 882 respNonDeliveryReason 883 DisplayString, 884 respMsgArrivalTime 885 DateAndTime, 886 respMsgSize 887 INTEGER, 888 respMsgPriority 889 DisplayString, 890 respUniqueMsgId 891 DisplayString, 892 respInboundMsgId 893 DisplayString, 894 respOutboundMsgId 895 DisplayString, 896 respInboundOriginator 897 DisplayString, 898 respOutboundOriginator 899 DisplayString, 900 respInboundRecipient 901 DisplayString, 902 respOutboundRecipient 903 DisplayString, 904 respSupplementalInformation 905 DisplayString, 906 respSubject 907 DisplayString, 908 respMsgType 909 MsgType 910 } 912 respEntryIndex OBJECT-TYPE 913 SYNTAX INTEGER (1..2147483647) 914 ACCESS read-only 915 STATUS current 916 DESCRIPTION 917 "The primary integer index into the msgTrackResponseTable table. It 918 matches 919 the value of reqEntryIndex for the original request. " 920 ::= { msgTrackResponseEntry 1 } 922 respMsgIndex OBJECT-TYPE 923 SYNTAX INTEGER (1..2147483647) 924 ACCESS read-only 925 STATUS current 926 DESCRIPTION 927 "The secondary integer index into the msgTrackResponseTable table. 928 For each 929 value of respEntryIndex in the table, there may be multiple 930 conceptual rows 931 indexed by respMsgIndex, each denoting a possible response to the 932 tracking 933 query. The maximum number of entries should have an upper bound of 934 the 935 value of reqMaxResponses in the conceptual row of 936 msgTrackRequestTable 937 that represents the original query request. " 938 ::= { msgTrackResponseEntry 2 } 940 respDispositionStatus OBJECT-TYPE 941 SYNTAX DispositionStatus 942 ACCESS read-only 943 STATUS current 944 DESCRIPTION 945 "Indicates the disposition of this message by this MTA for this 946 recipient." 947 ::= { msgTrackResponseEntry 3 } 949 rspDispositionTime OBJECT-TYPE 950 SYNTAX DateAndTime 951 ACCESS read-only 952 STATUS current 953 DESCRIPTION 954 "Time at which this MTA disposed of this message for this recipient." 955 ::= { msgTrackResponseEntry 4 } 957 respNextHopMta OBJECT-TYPE 958 SYNTAX DisplayString 959 ACCESS read-only 960 STATUS current 961 DESCRIPTION 962 "Name of the MTA to which this message was sent. MADMAN-compliant 963 MTA's should be addressed in the form '(::)'." 964 ::= { msgTrackResponseEntry 5 } 966 respPrevHopMta OBJECT-TYPE 967 SYNTAX DisplayString 968 ACCESS read-only 969 STATUS current 970 DESCRIPTION 971 "Name of the MTA from which this message was received. MADMAN- 972 compliant MTA's should be addressed in the form 973 '(::)'." 974 ::= { msgTrackResponseEntry 6 } 976 respNonDeliveryReason OBJECT-TYPE 977 SYNTAX DisplayString 978 ACCESS read-only 979 STATUS current 980 DESCRIPTION 981 "A textual representation representing the reason for non-delivery to 982 this recipient. No attempt is made to normalize these non-delivered 983 reasons across systems, since this indicates a terminal condition." 984 ::= { msgTrackResponseEntry 7 } 986 respMsgArrivalTime OBJECT-TYPE 987 SYNTAX DateAndTime 988 ACCESS read-only 989 STATUS current 990 DESCRIPTION 991 "Represents the time at which this message for this recipient 992 arrived at 993 this MTA." 994 ::= { msgTrackResponseEntry 8 } 996 respMsgSize OBJECT-TYPE 997 SYNTAX INTEGER(1..2147483647) 998 ACCESS read-only 999 STATUS current 1000 DESCRIPTION 1001 "Size of the message in kilo-octets." 1002 ::= { msgTrackResponseEntry 9 } 1004 respMsgPriority OBJECT-TYPE 1005 SYNTAX DisplayString 1006 ACCESS read-only 1007 STATUS current 1008 DESCRIPTION 1009 "Textual representation of the priority of the message. No attempt 1010 is 1011 made to normalize these values across disparate messaging 1012 technologies." 1013 ::= { msgTrackResponseEntry 10 } 1015 respUniqueMsgId OBJECT-TYPE 1016 SYNTAX DisplayString 1017 ACCESS read-only 1018 STATUS current 1020 DESCRIPTION 1021 "The unique message identifier that the MTA assigned internally 1022 to the message." 1023 ::= { msgTrackResponseEntry 11 } 1025 respInboundMsgId OBJECT-TYPE 1026 SYNTAX DisplayString 1027 ACCESS read-only 1028 STATUS current 1029 DESCRIPTION 1030 "The unique message identifier that the 'previous hop' MTA assigned 1031 to the message. If the 'previous' MTA uses a different messaging 1032 technology 1033 or identifier scheme, this identifier serves to correlate the 1034 message from 1035 MTA to MTA. If the 'previous' MTA uses the same technology, this 1036 value 1037 is generally superfluous. If this is the first MTA in the delivery 1038 sequence, or if the previous message id is unknown, this variable 1039 is null- 1040 valued." 1041 ::= { msgTrackResponseEntry 12 } 1043 respOutboundMsgId OBJECT-TYPE 1044 SYNTAX DisplayString 1045 ACCESS read-only 1046 STATUS current 1047 DESCRIPTION 1048 "The unique message identifier that the 'next hop' MTA assigned 1049 to the message. If the 'next' MTA uses a different messaging 1050 technology 1051 or identifier scheme, this identifier serves to correlate the 1052 message from 1053 MTA to MTA. If the 'next' MTA uses the same technology, this value 1054 is generally superfluous. If this is the last MTA in the delivery 1055 sequence, 1056 or if the next hop message id is unknown, this variable is 1057 null-valued." 1058 ::= { msgTrackResponseEntry 13 } 1060 respInboundOriginator OBJECT-TYPE 1061 SYNTAX DisplayString 1062 ACCESS read-only 1063 STATUS current 1064 DESCRIPTION 1065 "Textual representation identifying the originator of the message as 1066 it was 1067 received from the 'previous hop' MTA. The style of this variable 1068 varies 1069 according to a specific messaging technology." 1070 ::= { msgTrackResponseEntry 14 } 1072 respOutboundOriginator OBJECT-TYPE 1073 SYNTAX DisplayString 1074 ACCESS read-only 1075 STATUS current 1077 DESCRIPTION 1078 "Textual representation identifying the originator of the message as 1079 it 1080 was (or will be) presented to the 'next hop' MTA. The style of this 1081 variable varies according to a specific messaging technology." 1082 ::= { msgTrackResponseEntry 15 } 1084 respInboundRecipient OBJECT-TYPE 1085 SYNTAX DisplayString 1086 ACCESS read-only 1087 STATUS current 1088 DESCRIPTION 1089 "Textual representation identifying the recipient of the message as 1090 it was 1091 received from the 'previous hop' MTA. The style of this variable 1092 varies 1093 according to a specific messaging technology.." 1094 ::= { msgTrackResponseEntry 16 } 1096 respOutboundRecipient OBJECT-TYPE 1097 SYNTAX DisplayString 1098 ACCESS read-only 1099 STATUS current 1100 DESCRIPTION 1101 "Textual representation identifying the recipient of the message as 1102 it 1103 was (or will be) presented to the 'next hop' MTA. The style of this 1104 variable varies according to a specific messaging technology." 1105 ::= { msgTrackResponseEntry 17 } 1107 respSupplementalInformation OBJECT-TYPE 1108 SYNTAX DisplayString 1109 ACCESS read-only 1110 STATUS current 1111 DESCRIPTION 1112 "Contains information provided by the agent to the manager that may 1113 be 1114 of use in identifying or tracking this message. No formal structure 1115 for 1116 this information is specified. Knowledge of the contents of this 1117 field 1118 is by bilateral agreement." 1119 ::= { msgTrackResponseEntry 18 } 1121 respSubject OBJECT-TYPE 1122 SYNTAX DisplayString 1123 ACCESS read-only 1124 STATUS current 1125 DESCRIPTION 1126 "The full text of the subject of the tracked message" 1127 ::= { msgTrackResponseEntry 19 } 1129 respMsgType OBJECT-TYPE 1130 SYNTAX MsgType 1131 ACCESS read-only 1132 STATUS current 1133 DESCRIPTION 1134 "The type of the tracked message" 1135 ::= { msgTrackResponseEntry 20 } 1137 -- CONFORMANCE INFORMATION 1138 -- Used ONLY in V2 MIBs 1139 messageTrackingConformance OBJECT IDENTIFIER ::= { 1140 mta-message-track 5 } 1141 messageTrackingGroups OBJECT IDENTIFIER ::= { 1142 messageTrackingConformance 1 } 1143 messageTrackingCompliances OBJECT IDENTIFIER ::= { 1144 messageTrackingConformance 2 } 1146 -- COMPLIANCE STATEMENTS 1147 -- Used ONLY in V2 MIBs 1148 limitedCompliance MODULE-COMPLIANCE 1149 STATUS current 1150 DESCRIPTION 1151 "The basic levels of compliance for SNMPv2 entities that implement 1152 this MIB 1153 for message tracking requiring the knowledge of a message Id." 1154 MODULE -- this module 1155 MANDATORY-GROUPS { msgIdGroup } 1156 ::= { messageTrackingCompliances 1 } 1158 basicCompliance MODULE-COMPLIANCE 1159 STATUS current 1160 DESCRIPTION 1161 "The basic levels of compliance for SNMPv2 entities that implement 1162 this MIB 1163 for message tracking without requiring the knowledge of a message 1164 Id." 1165 MODULE -- this module 1166 MANDATORY-GROUPS { msgIdGroup, basicGroup } 1167 ::= { messageTrackingCompliances 2 } 1169 enhancedCompliance MODULE-COMPLIANCE 1170 STATUS current 1171 DESCRIPTION 1172 "The basic levels of compliance for SNMPv2 entities that implement 1173 this MIB 1174 for message tracking without requiring the knowledge of a message 1175 Id and 1176 allowing an enhanced level of query capabilities." 1177 MODULE -- this module 1179 MANDATORY-GROUPS { msgIdGroup, basicGroup, enhancedGroup } 1180 ::= { messageTrackingCompliances 3 } 1182 gatewayCompliance MODULE-COMPLIANCE 1183 STATUS current 1184 DESCRIPTION 1185 "The basic levels of compliance for SNMPv2 entities that implement 1186 this MIB 1187 for message tracking across mta's that perform a gateway 1188 function." 1189 MODULE -- this module 1190 MANDATORY-GROUPS { msgIdGroup, basicGroup, enhancedGroup, 1191 gatewayGroup } 1192 ::= { messageTrackingCompliances 4 } 1194 -- UNITS OF CONFORMANCE 1195 -- Used ONLY in V2 MIBs 1196 msgIdGroup OBJECT-GROUP 1197 OBJECTS { 1198 msgTrackNextRequestIndex, reqRowStatus, 1199 reqResponseStatus, reqMaxResponses, reqUniqueMsgId, 1200 reqFailureReason, respDispositionStatus, respDispositionTime, 1201 respNonDeliveryReason, respMsgArrivalTime, respUniqueMsgId, 1202 respInboundOriginator, respInboundRecipient 1203 } 1204 STATUS current 1205 DESCRIPTION 1206 " A collection of objects for tracking messages where the 1207 messageId is 1208 known with responses containing basic message information." 1209 ::= { messageTrackingGroups 1 } 1211 basicGroup OBJECT-GROUP 1212 OBJECTS { 1213 reqInboundOriginator, reqInboundRecipient, reqOriginatorNameForm, 1214 reqRecipientNameForm, reqEarliestArrivalTime, 1215 reqLatestArrivalTime 1216 } 1217 STATUS current 1218 DESCRIPTION 1219 " A collection of objects for tracking messages where the 1220 messageId is not 1221 known 1222 with responses containing basic message 1223 information." 1224 ::= { messageTrackingGroups 2} 1226 enhancedGroup OBJECT-GROUP 1227 OBJECTS { 1228 reqSubject, reqMinMsgSize, reqMaxMsgSize, 1229 reqDispositionStatus, reqMsgType, reqCollapseRecipients, 1230 respMsgSize, respMsgPriority, 1231 respSupplementalInformation, 1232 respSubject, respMsgType 1233 } 1234 STATUS current 1235 DESCRIPTION 1236 " A collection of objects for tracking messages where the messageId 1237 is not 1238 known with responses containing enhanced message information as 1239 well as enhanced query capabilities." 1240 ::= { messageTrackingGroups 3} 1242 gatewayGroup OBJECT-GROUP 1243 OBJECTS { 1244 reqInboundMsgId, reqOutboundMsgId, 1245 reqOutboundOriginator, 1246 reqOutboundRecipient, respNextHopMta, respPrevHopMta, 1247 respInboundMsgId, respOutboundMsgId, 1248 respOutboundOriginator, 1249 respOutboundRecipient 1250 } 1251 STATUS current 1252 DESCRIPTION 1253 " A collection of object for tracking messages that have passed 1254 through a 1255 gateway mta." 1256 ::= { messageTrackingGroups 4} 1258 END 1260 4 Usages 1262 A general model of message flow between MTAs has to be presented before 1263 a MIB can be described. Generally speaking, message flow occurs in 1264 three 1265 steps. We use the term "MTA" loosely to refer to any processing entity 1266 that is 1267 responsible for message delivery: 1269 (1) Messages are received by the MTA from user agents, message stores, 1270 other 1271 MTAs, and gateways. 1272 (2) The "next hop" for the each message is determined. This is simply 1273 the 1274 destination the message is to be transmitted to; it may or may not be 1275 the final 1276 destination of the message. Next hop is established on a per-recipient 1277 basis. 1278 Next hop may be a User Agent, a Message Store, another MTA, or a 1279 gateway. 1281 (3) Information about the message and the next hop are written out to a 1282 log in 1283 some format. Messages are transmitted to the appropriate destination, 1284 which 1285 may be a user agent, message store, another MTA, or another gateway. 1287 In terms of message tracking, the key step is step number 3, the 1288 logging of 1289 information. Once information about a message is written to a log, it 1290 can be 1291 subsequently queried by any number of means. It is the intent of this 1292 specification to support the following general message tracking usages. 1294 Tracking an Individual Message 1296 It is often necessary for messaging operations to track down the 1297 whereabouts 1298 and/or history of an individual message managed object. This is 1299 typically in 1300 response to a particular user tracking request regarding a previously 1301 sent 1302 message. It might also be used by messaging operations to verify that 1303 one or 1304 more message paths are operating properly. 1306 Entire Path or Current Status 1308 For some inquiries, it is desired that the entire path taken by the 1309 message to 1310 date be discovered, including the current disposition of the message 1311 (for one 1312 or more recipients). For others, it is necessary only to discover the 1313 current 1314 disposition of the message. Note however that it may be necessary to 1315 uncover 1316 its entire path to date in order to determine its current disposition. 1317 To discover a message's entire path, it will be necessary to query the 1318 Management Agent (MA) of each MTA and/or gateway encountered by the 1319 message, beginning with the originating MTA, to discover the status of 1320 the 1321 message from that MTA or gateway's perspective. 1322 Dispositions include: Transferred-to another MTA or gateway, In-queue 1323 within an MTA or gateway, Delivered, Non-delivered, Redirected, or 1324 Dlist- 1325 expanded. If a message was relayed to another MTA or gateway, then the 1326 MA 1327 of that MTA or gateway must be queried in turn. This must be repeated 1328 until 1329 the MTA or gateway which currently has responsibility for the message 1330 is 1331 reached. 1333 To discover a message's current disposition, it might in fact be 1334 necessary to track 1335 the message's entire path, since typically the current status can only 1336 be 1337 discovered by a forward traversal through the message path. 1338 Alternatively, to 1339 minimize expense, the MA of any MTA/gateway which is estimated to be in 1340 the 1341 message path can be queried; if the message is shown to have reached 1342 this 1343 estimated point, then previous points in the path are irrelevant. Best 1344 estimate 1345 may therefore be the MA of the destination MTA, if known. Other 1346 estimates 1347 are made based on arbitrary intelligence which may be available. 1349 For a message with multiple recipients, a different path/ disposition 1350 may be 1351 relevant for each recipient. Thus, message tracking queries must be 1352 made to 1353 discover the path/disposition of each recipient of the message, or for 1354 each 1355 recipient explicitly identified in the tracking request. For cases in 1356 which multiple 1357 recipient message copies are transferred-to the same MTA or gateway, 1358 these 1359 queries may be combined into a single query, for convenience. 1361 Identifying Messages to Track 1363 In some cases, the user may have retained some sort of a unique 1364 identifier for 1365 the message of interest. This will be true, for example, because an 1366 explicit 1367 trackability service was requested for the message, or because the 1368 user logs all 1369 outgoing messages. In such cases, a message query can be made simply 1370 on the 1371 basis of providing this unique identifier to the message tracking 1372 system. 1374 Optionally, this query can be bounded by: 1376 o specific recipient(s) of interest; 1377 o time range of interest; 1378 o or other bounding information. 1380 In other cases, the user may only know some general descriptive 1381 information 1382 about the message. For example, the user may know who originated it, 1383 to 1384 whom it was sent, and roughly what time of day it was submitted. In 1385 such 1386 cases, it will be necessary to provide descriptive information to the 1387 message 1388 tracking system and allow it to respond with a list of matching 1389 messages which 1390 it knows about, along with their unique identifiers. 1392 In either case, the query can specify or imply a list of information 1393 which it 1394 wishes the query response to return to the requester. 1396 Query Responses 1398 The query response must then return the requested information, or 1399 return an 1400 indication as to why it cannot return the requested information. If the 1401 returned 1402 information includes an indication that the message has been further 1403 relayed, 1404 then a subsequent query must made to the transferred-to MTA or gateway. 1405 Specific response information must be provided/implied in order to 1406 allow for 1407 the creation of subsequent queries. For example: 1409 o the name of the transferred-to MTA or gateway 1410 o the name of the MA of the transferred-to MTA or gateway 1411 o the names/addresses of the recipient(s) of interest which have taken 1412 this relay 1413 path. Note that this may be a "redirected" recipient. 1414 o If this response comes from a gateway, the translated versions of key 1415 identification fields. 1417 This subsequent query can optionally be formulated automatically. 1418 See next section on "Automating Follow-up Queries" for details on 1419 follow-up 1420 query creation. 1422 Automating Follow-up Queries 1424 In order to support a fully automated path search, it is convenient and 1425 powerful 1426 for a management agent to be able to automatically make all of the 1427 queries 1428 required to discover the full path of an individual message. The MC can 1429 accomplish this by creating an initial query, and then creating a 1430 follow-on query 1431 utilizing information returned by the initial query, and repeating this 1432 process 1433 until the current disposition of the message is discovered. 1435 Follow-on queries will need to be generated on a per-recipient basis. 1436 For cases 1437 in which multiple recipient message copies were transferred-to the same 1438 MTA 1439 or gateway, these queries may be combined into a single query, for 1440 efficiency. 1442 In general, a follow-on query will need to: 1444 o Be directed at the MA which corresponds to the MTA or gateway to 1445 which 1446 the message (copy) was relayed. 1447 o Include the names/addresses of the recipient(s) which have taken this 1448 relay 1449 path. Note that this may be a "redirected" recipient. 1450 o Include the same bounding criteria as did the initial query, with the 1451 addition of the unique message identification if that information was 1452 not 1453 previously available. 1454 o If the just-completed query was to a gateway, then the new translated 1455 formats for the following will need to be used, if applicable: 1456 - Message ID 1457 - Recipient address 1458 - Originator address 1459 - Priority value 1460 - Size. 1462 Tracking Aggregates of Messages 1464 It is sometimes desirable for messaging operations to be able to 1465 determine 1466 information about the history/status of all messages which match a 1467 given set 1468 of characteristics that have passed through their systems. 1470 Identifying Messages to Track 1472 In some cases, messaging operations may have retained some sort of a 1473 unique 1474 identifier for the messages of interest. More probably, messaging 1475 operations is 1476 simply interested in the set of messages which: 1478 o went through its systems within a given time range, or 1479 o were sent through its systems by a given originator, or 1480 o were sent through its systems to a given recipient, or 1481 o were sent through its systems with a given size or priority 1483 In such cases, it will be necessary to provide descriptive information 1484 to the 1485 message tracking system and allow it to respond with information on all 1486 of the 1487 matching messages which it knows about. The query can specify or imply 1488 a list 1489 of information which it wishes the query response to return to the 1490 requester. 1492 Query Responses 1494 The query response must then return the requested information, or 1495 return an 1496 indication as to why it cannot return the requested information. 1498 4.1 Security 1500 [TBD] 1502 5. Future Considerations 1504 A version of this information is also available in the Management 1505 Information 1506 Format (MIF) defined by the Desktop Management Task Force (DMTF). 1508 As SNMP continues to evolve (e.g. SNMPv3), 1509 the mechanisms in this document will leverage those new technologies. 1511 6. Acknowledgements 1513 This draft also incorporates the intellectual contributions of 1515 Bruce Greenblatt 1516 Niraj Jain 1517 Sue Lebeck 1518 Roger Mizumori 1519 Edward Owens 1521 7. References 1523 [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1524 of Management Information for version 2 of the Simple Network 1525 Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., 1526 Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1527 University, September 1996. 1529 [2] McCloghrie, K., and M. Rose, Editors, "Management Information 1530 Base for Network Management of TCP/IP-based internets: MIB-II", 1531 STD 17, RFC 1213, Hughes LAN Systems, Performance Systems 1532 International, March 1991. 1534 [3] Case, J., McCloghrie, K., Rose, M., and S, Waldbusser, "Protocol 1535 Operations for version 2 of the Simple Network Management 1536 Protocol (SNMPv2)", RFC 1905, SNMP Research,Inc., Hughes LAN 1537 Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1538 University, September 1996. 1540 [MODEL] Case, J., McCloghrie, K., Rose, M., and S, Waldbusser, 1541 "Protocol 1542 Operations for version 2 of the Simple Network Management 1544 Authors' Addresses 1546 Bruce Ernst 1547 Lotus Development Corporation 1549 Phone: +1 610 251 3404 1550 E-Mail: bruce_ernst@lotus.com 1552 Gordon Jones 1553 MITRE Corporation 1554 1820 Dolley Madison Blvd. 1555 McLean, VA 22102-3481 1557 Phone: +1 703 883 7670 1558 E-Mail: gbjones@mitre.org 1560 Jonathan Weintraub 1561 Electronic Data Systems, Inc. 1563 +1 301 619 3101