idnits 2.17.1 draft-ietf-madman-mail-monitor-mib-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-25) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 1995) is 10389 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) ** Obsolete normative reference: RFC 1442 (ref. '1') (Obsoleted by RFC 1902) ** Downref: Normative reference to an Historic RFC: RFC 1445 (ref. '3') ** Obsolete normative reference: RFC 1448 (ref. '4') (Obsoleted by RFC 1905) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Steve Kille, WG Chair 2 Internet Draft Ned Freed, Editor 3 draft-ietf-madman-mail-monitor-mib-00.txt 5 Mail Monitoring MIB 7 November 1995 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months. 17 Internet-Drafts may be updated, replaced, or obsoleted by other 18 documents at any time. It is not appropriate to use Internet-Drafts as 19 reference material or to cite them other than as a ``working draft'' or 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 25 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 1. Introduction 29 This memo defines a portion of the Management Information Base (MIB) for 30 use with network management protocols in the Internet community. In 31 particular, this memo extends the basic Network Services Monitoring MIB 32 [5] to allow monitoring of Message Transfer Agents (MTAs). It may also 33 be used to monitor MTA components within gateways. 35 2. Table of Contents 37 1 Introduction .................................................... 1 38 2 Table of Contents ............................................... 2 39 3 The SNMPv2 Network Management Framework ......................... 2 40 3.1 Object Definitions ............................................ 2 41 4 Message Flow Model .............................................. 3 42 5 MTA Objects ..................................................... 3 43 6 Definitions ..................................................... 5 44 7 Changes made since RFC1565 ...................................... 22 45 8 Acknowledgements ................................................ 23 46 9 References ...................................................... 23 47 10 Security Considerations ........................................ 23 48 11 Authors' Addresses ............................................. 24 50 3. The SNMPv2 Network Management Framework 52 The SNMPv2 Network Management Framework consists of four major 53 components. They are: 55 o RFC 1442 [1] which defines the SMI, the mechanisms used for 56 describing and naming objects for the purpose of management. 58 o RFC 1213 [2] defines MIB-II, the core set of managed objects for 59 the Internet suite of protocols. 61 o RFC 1445 [3] which defines the administrative and other 62 architectural aspects of the framework. 64 o RFC 1448 [4] which defines the protocol used for network access to 65 managed objects. 67 The Framework permits new objects to be defined for the purpose of 68 experimentation and evaluation. 70 3.1. Object Definitions 72 Managed objects are accessed via a virtual information store, termed the 73 Management Information Base or MIB. Objects in the MIB are defined using 74 the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. 75 In particular, each object type is named by an OBJECT IDENTIFIER, an 76 administratively assigned name. The object type together with an object 77 instance serves to uniquely identify a specific instantiation of the 78 object. For human convenience, we often use a textual string, termed 79 the descriptor, to refer to the object type. 81 4. Message Flow Model 83 A general model of message flow inside an MTA has to be presented before 84 a MIB can be described. Generally speaking, message flow occurs in four 85 steps: 87 (1) Messages are received by the MTA from User Agents, Message 88 Stores, other MTAs, and gateways. 90 (2) The "next hop" for the each message is determined. This is simply 91 the destination the message is to be transmitted to; it may or 92 may not be the final destination of the message. Multiple "next 93 hops" may exist for a single message (as a result of either 94 having multiple recipients or distribution list expansion); this 95 may make it necessary to duplicate messages. 97 (3) Messages are converted into the format that's appropriate for the 98 next hop. 100 (4) Messages are transmitted to the appropriate destination, which 101 may be a User Agent, Message Store, another MTA, or gateway. 103 Storage of messages in the MTA occurs at some point during this process. 104 However, it is important to note that storage may occur at different and 105 possibly even multiple points during this process. For example, some 106 MTAs expand messages into multiple copies as they are received. In this 107 case (1), (2), and (3) may all occur prior to storage. Other MTAs store 108 messages precisely as they are received and perform all expansions and 109 conversions during retransmission processing. So here only (1) occurs 110 prior to storage. This leads to situations where, in general, a 111 measurement of messages received may not equal a measurement of messages 112 in store, or a measurement of messages stored may not equal a 113 measurement of messages retransmitted, or both. 115 5. MTA Objects 117 If there are one or more MTAs on the host, the following mta group may 118 be used to monitor them. Any number of the MTAs on a host may be 119 monitored. Each MTA is dealt with as a separate application and has its 120 own applTable entry in the Network Services Monitoring MIB. 122 The MIB described in this document covers only the portion which is 123 specific to the monitoring of MTAs. The network service related part of 124 the MIB is covered in a separate document [5]. 126 6. Definitions 128 MTA-MIB DEFINITIONS ::= BEGIN 130 IMPORTS 131 OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY 132 FROM SNMPv2-SMI 133 DisplayString, TimeInterval 134 FROM SNMPv2-TC 135 MODULE-COMPLIANCE, OBJECT-GROUP 136 FROM SNMPv2-CONF 137 mib-2 138 FROM RFC1213-MIB 139 applIndex 140 FROM APPLICATION-MIB; 142 mta MODULE-IDENTITY 143 LAST-UPDATED "9511170000Z" 144 ORGANIZATION "IETF Mail and Directory Management Working Group" 145 CONTACT-INFO 146 " Ned Freed 148 Postal: Innosoft International, Inc. 149 1050 East Garvey Avenue South 150 West Covina, CA 91790 151 US 153 Tel: +1 818 919 3600 154 Fax: +1 818 919 3614 156 E-Mail: ned@innosoft.com" 157 DESCRIPTION 158 "The MIB module describing Message Transfer Agents (MTAs)" 159 ::= {mib-2 28} 161 mtaTable OBJECT-TYPE 162 SYNTAX SEQUENCE OF MtaEntry 163 MAX-ACCESS not-accessible 164 STATUS current 165 DESCRIPTION 166 "The table holding information specific to an MTA." 167 ::= {mta 1} 169 mtaEntry OBJECT-TYPE 170 SYNTAX MtaEntry 171 MAX-ACCESS not-accessible 172 STATUS current 173 DESCRIPTION 174 "The entry associated with each MTA." 175 INDEX {applIndex} 176 ::= {mtaTable 1} 178 MtaEntry ::= SEQUENCE { 179 mtaReceivedMessages 180 Counter32, 181 mtaStoredMessages 182 Gauge32, 183 mtaTransmittedMessages 184 Counter32, 185 mtaReceivedVolume 186 Counter32, 187 mtaStoredVolume 188 Gauge32, 189 mtaTransmittedVolume 190 Counter32, 191 mtaReceivedRecipients 192 Counter32, 193 mtaStoredRecipients 194 Gauge32, 195 mtaTransmittedRecipients 196 Counter32 197 } 199 mtaReceivedMessages OBJECT-TYPE 200 SYNTAX Counter32 201 MAX-ACCESS read-only 202 STATUS current 203 DESCRIPTION 204 "The number of messages received since MTA initialization. 205 This includes messages transmitted to this MTA from other 206 MTAs as well as messages that have been submitted to the 207 MTA directly by end-users or applications." 208 ::= {mtaEntry 1} 210 mtaStoredMessages OBJECT-TYPE 211 SYNTAX Gauge32 212 MAX-ACCESS read-only 213 STATUS current 214 DESCRIPTION 215 "The total number of messages currently stored in the MTA. 216 This includes messages that are awaiting transmission to 217 some other MTA or are waiting for delivery to an end-user 218 or application." 219 ::= {mtaEntry 2} 221 mtaTransmittedMessages OBJECT-TYPE 222 SYNTAX Counter32 223 MAX-ACCESS read-only 224 STATUS current 225 DESCRIPTION 226 "The number of messages transmitted since MTA initialization. 227 This includes messages that were transmitted to some other 228 MTA or are waiting for delivery to an end-user or 229 application." 230 ::= {mtaEntry 3} 232 mtaReceivedVolume OBJECT-TYPE 233 SYNTAX Counter32 234 UNITS "K-octets" 235 MAX-ACCESS read-only 236 STATUS current 237 DESCRIPTION 238 "The total volume of messages received since MTA 239 initialization, measured in kilo-octets. This volume should 240 include all transferred data that is logically above the mail 241 transport protocol level. For example, an SMTP-based MTA 242 should use the number of kilo-octets in the message header 243 and body, while an X.400-based MTA should use the number of 244 kilo-octets of P2 data. This includes messages transmitted 245 to this MTA from other MTAs as well as messages that have 246 been submitted to the MTA directly by end-users or 247 applications." 248 ::= {mtaEntry 4} 250 mtaStoredVolume OBJECT-TYPE 251 SYNTAX Gauge32 252 UNITS "K-octets" 253 MAX-ACCESS read-only 254 STATUS current 255 DESCRIPTION 256 "The total volume of messages currently stored in the MTA, 257 measured in kilo-octets. This volume should include all 258 stored data that is logically above the mail transport 259 protocol level. For example, an SMTP-based MTA should 260 use the number of kilo-octets in the message header and 261 body, while an X.400-based MTA would use the number of 262 kilo-octets of P2 data. This includes messages that are 263 awaiting transmission to some other MTA or are waiting 264 for delivery to an end-user or application." 265 ::= {mtaEntry 5} 267 mtaTransmittedVolume OBJECT-TYPE 268 SYNTAX Counter32 269 UNITS "K-octets" 270 MAX-ACCESS read-only 271 STATUS current 272 DESCRIPTION 273 "The total volume of messages transmitted since MTA 274 initialization, measured in kilo-octets. This volume should 275 include all transferred data that is logically above the mail 276 transport protocol level. For example, an SMTP-based MTA 277 should use the number of kilo-octets in the message header 278 and body, while an X.400-based MTA should use the number of 279 kilo-octets of P2 data. This includes messages that were 280 transmitted to some other MTA or are waiting for delivery 281 to an end-user or application." 282 ::= {mtaEntry 6} 284 mtaReceivedRecipients OBJECT-TYPE 285 SYNTAX Counter32 286 MAX-ACCESS read-only 287 STATUS current 288 DESCRIPTION 289 "The total number of recipients specified in all messages 290 received since MTA initialization. Recipients this MTA 291 has no responsibility for, i.e. inactive envelope 292 recipients or ones referred to in message headers, 293 should not be counted even if information about such 294 recipients is available. This includes messages 295 transmitted to this MTA from other MTAs as well as 296 messages that have been submitted to the MTA directly 297 by end-users or applications." 298 ::= {mtaEntry 7} 300 mtaStoredRecipients OBJECT-TYPE 301 SYNTAX Gauge32 302 MAX-ACCESS read-only 303 STATUS current 304 DESCRIPTION 305 "The total number of recipients specified in all messages 306 currently stored in the MTA. Recipients this MTA has no 307 responsibility for, i.e. inactive envelope recipients or 308 ones referred to in message headers, should not be 309 counted. This includes messages that are awaiting 310 transmission to some other MTA or are waiting for 311 delivery to an end-user or application." 312 ::= {mtaEntry 8} 314 mtaTransmittedRecipients OBJECT-TYPE 315 SYNTAX Counter32 316 MAX-ACCESS read-only 317 STATUS current 318 DESCRIPTION 319 "The total number of recipients specified in all messages 320 transmitted since MTA initialization. Recipients this 321 MTA had no responsibility for, i.e. inactive envelope 322 recipients or ones referred to in message headers, 323 should not be counted. This includes messages that were 324 transmitted to some other MTA or are waiting for 325 delivery to an end-user or application." 326 ::= {mtaEntry 9} 328 -- MTAs typically group inbound reception, queue storage, and 329 -- outbound transmission in some way. In the most extreme case 330 -- information will be maintained for each different entity that 331 -- receives messages and for each entity the MTA stores messages for 332 -- and delivers messages to. Other MTAs may elect to treat all 333 -- reception equally, all queue storage equally, all deliveries 334 -- equally, or some combination of this. 336 -- In any case, a grouping abstraction is an extremely useful for 337 -- breaking down the activities of an MTA. For purposes of labelling 338 -- this will be called a "group" in this MIB. 340 -- Each group contains all the variables needed to monitor all aspects 341 -- of an MTA's operation. However, the fact that all groups contain 342 -- all possible variables does not imply that all groups must use all 343 -- possible variables. For example, a single group might be used to 344 -- monitor only one kind of event (inbound processing, outbound 345 -- processing, or storage). In this sort of configuration all unused 346 -- counters would be inaccessible; e.g., returning either a 347 -- noSuchName error (for an SNMPv1 get), or a noSuchInstance 348 -- exception (for an SNMPv2 get). 350 -- Groups are not necessarily mutually exclusive. A given event may 351 -- be recorded by more than one group, a message may be seen as 352 -- stored by more than one group, and so on. Groups should be all 353 -- inclusive, however: if groups are implemented all aspects of an 354 -- MTA's operation should be registered in at least one group. This 355 -- freedom lets implementors use different sets of groups to 356 -- provide differents "views" of an MTA. 358 -- The possibility of overlap between groups means that summing 359 -- variables across groups may not produce values equal to those in 360 -- the mtaTable. mtaTable should always provide accurate information 361 -- about the MTA as a whole. 363 -- The term "channel" is often used in MTA implementations; channels 364 -- are usually, but not always, equivalent to a group. However, 365 -- this MIB does not use the term "channel" because there is no 366 -- requirement that an MTA supporting this MIB has to map its 367 -- "channel" abstraction one-to-one onto the MIB's group abstration. 369 mtaGroupTable OBJECT-TYPE 370 SYNTAX SEQUENCE OF MtaGroupEntry 371 MAX-ACCESS not-accessible 372 STATUS current 373 DESCRIPTION 374 "The table holding information specific to each MTA group." 375 ::= {mta 2} 377 mtaGroupEntry OBJECT-TYPE 378 SYNTAX MtaGroupEntry 379 MAX-ACCESS not-accessible 380 STATUS current 381 DESCRIPTION 382 "The entry associated with each MTA group." 383 INDEX {applIndex, mtaGroupIndex} 384 ::= {mtaGroupTable 1} 386 MtaGroupEntry ::= SEQUENCE { 387 mtaGroupIndex 388 INTEGER, 389 mtaGroupReceivedMessages 390 Counter32, 391 mtaGroupRejectedMessages 392 Counter32, 393 mtaGroupStoredMessages 394 Gauge32, 395 mtaGroupTransmittedMessages 396 Counter32, 397 mtaGroupReceivedVolume 398 Counter32, 399 mtaGroupStoredVolume 400 Gauge32, 401 mtaGroupTransmittedVolume 402 Counter32, 403 mtaGroupReceivedRecipients 404 Counter32, 405 mtaGroupStoredRecipients 406 Gauge32, 407 mtaGroupTransmittedRecipients 408 Counter32, 409 mtaGroupOldestMessageStored 410 TimeInterval, 411 mtaGroupInboundAssociations 412 Gauge32, 413 mtaGroupOutboundAssociations 414 Gauge32, 415 mtaGroupAccumulatedInboundAssociations 416 Counter32, 417 mtaGroupAccumulatedOutboundAssociations 418 Counter32, 419 mtaGroupLastInboundActivity 420 TimeInterval, 421 mtaGroupLastOutboundActivity 422 TimeInterval, 423 mtaGroupRejectedInboundAssociations 424 Counter32, 425 mtaGroupFailedOutboundAssociations 426 Counter32, 427 mtaGroupInboundRejectionReason 428 DisplayString, 429 mtaGroupOutboundConnectFailureReason 430 DisplayString, 432 mtaGroupScheduledRetry 433 TimeInterval, 434 mtaGroupMailProtocol 435 OBJECT IDENTIFIER, 436 mtaGroupName 437 DisplayString 438 } 440 mtaGroupIndex OBJECT-TYPE 441 SYNTAX INTEGER (1..2147483647) 442 MAX-ACCESS not-accessible 443 STATUS current 444 DESCRIPTION 445 "The index associated with a group for a given MTA." 446 ::= {mtaGroupEntry 1} 448 mtaGroupReceivedMessages OBJECT-TYPE 449 SYNTAX Counter32 450 MAX-ACCESS read-only 451 STATUS current 452 DESCRIPTION 453 "The number of messages received to this group since MTA 454 initialization." 455 ::= {mtaGroupEntry 2} 457 mtaGroupRejectedMessages OBJECT-TYPE 458 SYNTAX Counter32 459 MAX-ACCESS read-only 460 STATUS current 461 DESCRIPTION 462 "The number of messages rejected by this group since MTA 463 initialization." 464 ::= {mtaGroupEntry 3} 466 mtaGroupStoredMessages OBJECT-TYPE 467 SYNTAX Gauge32 468 MAX-ACCESS read-only 469 STATUS current 470 DESCRIPTION 471 "The total number of messages currently stored in this 472 group's queue." 473 ::= {mtaGroupEntry 4} 475 mtaGroupTransmittedMessages OBJECT-TYPE 476 SYNTAX Counter32 477 MAX-ACCESS read-only 478 STATUS current 479 DESCRIPTION 480 "The number of messages transmitted by this group since MTA 481 initialization." 482 ::= {mtaGroupEntry 5} 484 mtaGroupReceivedVolume OBJECT-TYPE 485 SYNTAX Counter32 486 UNITS "K-octets" 487 MAX-ACCESS read-only 488 STATUS current 489 DESCRIPTION 490 "The total volume of messages received to this group since 491 MTA initialization, measured in kilo-octets. This volume 492 should include all transferred data that is logically above 493 the mail transport protocol level. For example, an 494 SMTP-based MTA should use the number of kilo-octets in the 495 message header and body, while an X.400-based MTA should use 496 the number of kilo-octets of P2 data." 497 ::= {mtaGroupEntry 6} 499 mtaGroupStoredVolume OBJECT-TYPE 500 SYNTAX Gauge32 501 UNITS "K-octets" 502 MAX-ACCESS read-only 503 STATUS current 504 DESCRIPTION 505 "The total volume of messages currently stored in this 506 group's queue, measured in kilo-octets. This volume should 507 include all stored data that is logically above the mail 508 transport protocol level. For example, an SMTP-based 509 MTA should use the number of kilo-octets in the message 510 header and body, while an X.400-based MTA would use the 511 number of kilo-octets of P2 data." 512 ::= {mtaGroupEntry 7} 514 mtaGroupTransmittedVolume OBJECT-TYPE 515 SYNTAX Counter32 516 UNITS "K-octets" 517 MAX-ACCESS read-only 518 STATUS current 519 DESCRIPTION 520 "The total volume of messages transmitted by this group 521 since MTA initialization, measured in kilo-octets. This 522 volume should include all transferred data that is logically 523 above the mail transport protocol level. For example, an 524 SMTP-based MTA should use the number of kilo-octets in the 525 message header and body, while an X.400-based MTA should use 526 the number of kilo-octets of P2 data." 527 ::= {mtaGroupEntry 8} 529 mtaGroupReceivedRecipients OBJECT-TYPE 530 SYNTAX Counter32 531 MAX-ACCESS read-only 532 STATUS current 533 DESCRIPTION 534 "The total number of recipients specified in all messages 535 received to this group since MTA initialization. 536 Recipients this MTA has no responsibility for should not 537 be counted." 538 ::= {mtaGroupEntry 9} 540 mtaGroupStoredRecipients OBJECT-TYPE 541 SYNTAX Gauge32 542 MAX-ACCESS read-only 543 STATUS current 544 DESCRIPTION 545 "The total number of recipients specified in all messages 546 currently stored in this group's queue. Recipients this 547 MTA has no responsibility for should not be counted." 548 ::= {mtaGroupEntry 10} 550 mtaGroupTransmittedRecipients OBJECT-TYPE 551 SYNTAX Counter32 552 MAX-ACCESS read-only 553 STATUS current 554 DESCRIPTION 555 "The total number of recipients specified in all messages 556 transmitted by this group since MTA initialization. 557 Recipients this MTA had no responsibility for should not 558 be counted." 560 ::= {mtaGroupEntry 11} 562 mtaGroupOldestMessageStored OBJECT-TYPE 563 SYNTAX TimeInterval 564 MAX-ACCESS read-only 565 STATUS current 566 DESCRIPTION 567 "Time since the oldest message in this group's queue was 568 placed in the queue." 569 ::= {mtaGroupEntry 12} 571 mtaGroupInboundAssociations OBJECT-TYPE 572 SYNTAX Gauge32 573 MAX-ACCESS read-only 574 STATUS current 575 DESCRIPTION 576 "The number of current associations to the group, where the 577 group is the responder." 578 ::= {mtaGroupEntry 13} 580 mtaGroupOutboundAssociations OBJECT-TYPE 581 SYNTAX Gauge32 582 MAX-ACCESS read-only 583 STATUS current 584 DESCRIPTION 585 "The number of current associations to the group, where the 586 group is the initiator." 587 ::= {mtaGroupEntry 14} 589 mtaGroupAccumulatedInboundAssociations OBJECT-TYPE 590 SYNTAX Counter32 591 MAX-ACCESS read-only 592 STATUS current 593 DESCRIPTION 594 "The total number of associations to the group since MTA 595 initialization, where the group is the responder." 596 ::= {mtaGroupEntry 15} 598 mtaGroupAccumulatedOutboundAssociations OBJECT-TYPE 599 SYNTAX Counter32 600 MAX-ACCESS read-only 601 STATUS current 602 DESCRIPTION 603 "The total number of associations from the group since MTA 604 initialization, where the group was the initiator." 605 ::= {mtaGroupEntry 16} 607 mtaGroupLastInboundActivity OBJECT-TYPE 608 SYNTAX TimeInterval 609 MAX-ACCESS read-only 610 STATUS current 611 DESCRIPTION 612 "Time since the last time that this group had an active 613 inbound association for purposes of message reception." 614 ::= {mtaGroupEntry 17} 616 mtaGroupLastOutboundActivity OBJECT-TYPE 617 SYNTAX TimeInterval 618 MAX-ACCESS read-only 619 STATUS current 620 DESCRIPTION 621 "Time since the last time that this group had an 622 outbound association for purposes of message delivery." 623 ::= {mtaGroupEntry 18} 625 mtaGroupRejectedInboundAssociations OBJECT-TYPE 626 SYNTAX Counter32 627 MAX-ACCESS read-only 628 STATUS current 629 DESCRIPTION 630 "The total number of inbound associations the group has 631 rejected, since MTA initialization. Rejected 632 associations are not counted in the accumulated 633 association totals." 634 ::= {mtaGroupEntry 19} 636 mtaGroupFailedOutboundAssociations OBJECT-TYPE 637 SYNTAX Counter32 638 MAX-ACCESS read-only 639 STATUS current 640 DESCRIPTION 641 "The total number associations where the group was the 642 initiator and association establishment has failed, 643 since MTA initialization. Failed associations are 644 not counted in the accumulated association totals." 645 ::= {mtaGroupEntry 20} 647 mtaGroupInboundRejectionReason OBJECT-TYPE 648 SYNTAX DisplayString 649 MAX-ACCESS read-only 650 STATUS current 651 DESCRIPTION 652 "The failure reason, if any, for the last association this 653 group refused to respond to. An empty string indicates that 654 the last attempt was successful. If no association attempt 655 has been made since the MTA was initialized the value 656 should be 'never'." 657 ::= {mtaGroupEntry 21} 659 mtaGroupOutboundConnectFailureReason OBJECT-TYPE 660 SYNTAX DisplayString 661 MAX-ACCESS read-only 662 STATUS current 663 DESCRIPTION 664 "The failure reason, if any, for the last association attempt 665 this group initiated. An empty string indicates that the last 666 attempt was successful. If no association attempt has been 667 made since the MTA was initialized the value should be 668 'never'." 669 ::= {mtaGroupEntry 22} 671 mtaGroupScheduledRetry OBJECT-TYPE 672 SYNTAX TimeInterval 673 MAX-ACCESS read-only 674 STATUS current 675 DESCRIPTION 676 "The time when this group is scheduled to next attempt to 677 make an association." 678 ::= {mtaGroupEntry 23} 680 mtaGroupMailProtocol OBJECT-TYPE 681 SYNTAX OBJECT IDENTIFIER 682 MAX-ACCESS read-only 683 STATUS current 684 DESCRIPTION 685 "An identification of the protocol being used by this group. 686 For an group employing OSI protocols, this will be the 687 Application Context. For Internet applications, the IANA 688 maintains a registry of the OIDs which correspond to well-known 689 message transfer protocols. If the application protocol is 690 not listed in the registry, an OID value of the form 691 {applTCPProtoID port} or {applUDProtoID port} are used for 692 TCP-based and UDP-based protocols, respectively. In either 693 case 'port' corresponds to the primary port number being 694 used by the group. applTCPProtoID and applUDPProtoID are 695 defined in [5]." 696 ::= {mtaGroupEntry 24} 698 mtaGroupName OBJECT-TYPE 699 SYNTAX DisplayString 700 MAX-ACCESS read-only 701 STATUS current 702 DESCRIPTION 703 "A descriptive name for the group. If this group connects to 704 a single remote MTA this should be the name of that MTA. If 705 this in turn is an Internet MTA this should be the domain name. 706 For an OSI MTA it should be the string encoded distinguished 707 name of the managed object using the format defined in RFC-1485. 708 For X.400(1984) MTAs which do not have a Distinguished Name, 709 the RFC-1327 syntax 'mta in globalid' should be used." 710 ::= {mtaGroupEntry 25} 712 mtaGroupAssociationTable OBJECT-TYPE 713 SYNTAX SEQUENCE OF MtaGroupAssociationEntry 714 MAX-ACCESS not-accessible 715 STATUS current 716 DESCRIPTION 717 "The table holding information regarding the associations 718 for each MTA group." 719 ::= {mta 3} 721 mtaGroupAssociationEntry OBJECT-TYPE 722 SYNTAX MtaGroupAssociationEntry 723 MAX-ACCESS not-accessible 724 STATUS current 725 DESCRIPTION 726 "The entry holding information regarding the associations 727 for each MTA group." 728 INDEX {applIndex, mtaGroupIndex, mtaGroupAssociationIndex} 729 ::= {mtaGroupAssociationTable 1} 731 MtaGroupAssociationEntry ::= SEQUENCE { 732 mtaGroupAssociationIndex 733 INTEGER 734 } 736 mtaGroupAssociationIndex OBJECT-TYPE 737 SYNTAX INTEGER (1..2147483647) 738 MAX-ACCESS read-only 739 STATUS current 740 DESCRIPTION 741 "Reference into association table to allow correlation of 742 this group's active associations with the association table." 743 ::= {mtaGroupAssociationEntry 1} 745 -- Conformance information 747 mtaConformance OBJECT IDENTIFIER ::= {mta 4} 749 mtaGroups OBJECT IDENTIFIER ::= {mtaConformance 1} 750 mtaCompliances OBJECT IDENTIFIER ::= {mtaConformance 2} 752 -- Compliance statements 754 mtaCompliance MODULE-COMPLIANCE 755 STATUS current 756 DESCRIPTION 757 "The compliance statement for SNMPv2 entities which 758 implement the Mail Monitoring MIB for basic 759 monitoring of MTAs." 760 MODULE -- this module 761 MANDATORY-GROUPS {mtaGroup} 762 ::= {mtaCompliances 1} 764 mtaAssocCompliance MODULE-COMPLIANCE 765 STATUS current 766 DESCRIPTION 767 "The compliance statement for SNMPv2 entities which 768 implement the Mail Monitoring MIB for monitoring of 769 MTAs and their associations." 770 MODULE -- this module 771 MANDATORY-GROUPS {mtaGroup, mtaAssocGroup} 772 ::= {mtaCompliances 2} 774 -- Units of conformance 776 mtaGroup OBJECT-GROUP 777 OBJECTS { 778 mtaReceivedMessages, mtaStoredMessages, 779 mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume, 780 mtaTransmittedVolume, mtaReceivedRecipients, 781 mtaStoredRecipients, mtaTransmittedRecipients, 782 mtaGroupReceivedMessages, mtaGroupRejectedMessages, 783 mtaGroupStoredMessages, mtaGroupTransmittedMessages, 784 mtaGroupReceivedVolume, mtaGroupStoredVolume, 785 mtaGroupTransmittedVolume, mtaGroupReceivedRecipients, 786 mtaGroupStoredRecipients, mtaGroupTransmittedRecipients, 787 mtaGroupOldestMessageStored, mtaGroupInboundAssociations, 788 mtaGroupOutboundAssociations, 789 mtaGroupAccumulatedInboundAssociations, 790 mtaGroupAccumulatedOutboundAssociations, 791 mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity, 792 mtaGroupRejectedInboundAssociations, 793 mtaGroupFailedOutboundAssociations, 794 mtaGroupInboundRejectionReason, 795 mtaGroupOutboundConnectFailureReason, 796 mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName} 797 STATUS current 798 DESCRIPTION 799 "A collection of objects providing basic monitoring of MTAs." 800 ::= {mtaGroups 1} 802 mtaAssocGroup OBJECT-GROUP 803 OBJECTS { 804 mtaGroupAssociationIndex} 805 STATUS current 806 DESCRIPTION 807 "A collection of objects providing monitoring of MTA 808 associations." 809 ::= {mtaGroups 2} 811 END 812 7. Changes made since RFC1565 814 The only changes made to this document since it was issued as RFC1566 815 are the following: 817 (1) A number of DESCRIPTION fields have been reworded, hopefully 818 making them clearer. 820 8. Acknowledgements 822 This document is a product of the Mail and Directory Management (MADMAN) 823 Working Group. It is based on an earlier MIB designed by S. Kille, T. 824 Lenggenhager, D. Partain, and W. Yeong. 826 9. References 828 [1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure 829 of Management Information for version 2 of the Simple Network 830 Management Protocol (SNMPv2)", RFC1442, SNMP Research, Inc., Hughes 831 LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon 832 University, April 1993. 834 [2] McCloghrie, K., and Rose, M., Editors, "Management Information Base 835 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 836 RFC 1213, Hughes LAN Systems, Performance Systems International, 837 March 1991. 839 [3] Galvin, J., McCloghrie, K., " Administrative Model for version 2 of 840 the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted 841 Information Systems, Hughes LAN Systems, April 1993. 843 [4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol 844 Operations for version 2 of the Simple Network Management Protocol 845 (SNMPv2)", RFC1448, SNMP Research, Inc., Hughes LAN Systems, Dover 846 Beach Consulting, Inc., Carnegie Mellon University, April 1993. 848 [5] Freed, N., Kille, S., "The Network Services Monitoring MIB", 849 Internet Draft, November, 1995. 851 10. Security Considerations 853 Security issues are not discussed in this memo. 855 11. Authors' Addresses 857 Ned Freed, Editor 858 Innosoft International, Inc. 859 1050 East Garvey Avenue South 860 West Covina, CA 91790 861 USA 862 tel: +1 818 919 3600 863 fax: +1 818 919 3614 864 email: ned@innosoft.com 866 Steve Kille, WG Chair 867 ISODE Consortium 868 The Dome, The Square 869 Richmond TW9 1DT 870 UK 871 tel: +44 81 332 9091 872 email: S.Kille@isode.com