idnits 2.17.1 draft-ietf-madman-mail-monitor-mib-02.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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1099 has weird spacing: '...ntal in provi...' -- 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 1996) is 10115 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 1902 (ref. '1') (Obsoleted by RFC 2578) ** Downref: Normative reference to an Historic RFC: RFC 1445 (ref. '3') ** Obsolete normative reference: RFC 1905 (ref. '4') (Obsoleted by RFC 3416) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1779 (ref. '6') (Obsoleted by RFC 2253, RFC 3494) ** Obsolete normative reference: RFC 1738 (ref. '7') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1566 (ref. '8') (Obsoleted by RFC 2249, RFC 2789) ** Obsolete normative reference: RFC 1327 (ref. '9') (Obsoleted by RFC 2156) -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 1893 (ref. '11') (Obsoleted by RFC 3463) Summary: 17 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 5 Mail Monitoring MIB 7 August 1996 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 ..................................................... 4 44 7 Changes made since RFC 1566 ..................................... 27 45 8 Acknowledgements ................................................ 28 46 9 References ...................................................... 28 47 10 Security Considerations ........................................ 29 48 11 Authors' Addresses ............................................. 29 50 3. The SNMPv2 Network Management Framework 52 The SNMPv2 Network Management Framework consists of four major 53 components. They are: 55 o RFC 1902 [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 1905 [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) If necessary messages are converted into the format that's 98 appropriate for the next hop. Conversion operations may be 99 successful or unsuccessful. 101 (4) Messages are transmitted to the appropriate destination, which 102 may be a User Agent, Message Store, another MTA, or gateway. 104 Storage of messages in the MTA occurs at some point during this process. 105 However, it is important to note that storage may occur at different and 106 possibly even multiple points during this process. For example, some 107 MTAs expand messages into multiple copies as they are received. In this 108 case (1), (2), and (3) may all occur prior to storage. Other MTAs store 109 messages precisely as they are received and perform all expansions and 110 conversions during retransmission processing. So here only (1) occurs 111 prior to storage. This leads to situations where, in general, a 112 measurement of messages received may not equal a measurement of messages 113 in store, or a measurement of messages stored may not equal a 114 measurement of messages retransmitted, or both. 116 5. MTA Objects 118 If there are one or more MTAs on the host, the following MIB may be used 119 to monitor them. Any number of the MTAs on a host may be monitored. Each 120 MTA is dealt with as a separate application and has its own applTable 121 entry in the Network Services Monitoring MIB. 123 The MIB described in this document covers only the portion which is 124 specific to the monitoring of MTAs. The network service related part of 125 the MIB is covered in a separate document [5]. 127 6. Definitions 129 MTA-MIB DEFINITIONS ::= BEGIN 131 IMPORTS 132 OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY 133 FROM SNMPv2-SMI 134 DisplayString, TimeInterval 135 FROM SNMPv2-TC 136 MODULE-COMPLIANCE, OBJECT-GROUP 137 FROM SNMPv2-CONF 138 mib-2 139 FROM RFC1213-MIB 140 applIndex 141 FROM APPLICATION-MIB; 143 -- Textual conventions 145 -- Uniform Resource Locators are stored in URLStrings. 147 URLString ::= TEXTUAL-CONVENTION 148 STATUS current 149 DESCRIPTION 150 "A Uniform Resource Locator represented in accordance 151 with RFC 1738 [7]." 152 SYNTAX DisplayString 154 mta MODULE-IDENTITY 155 LAST-UPDATED "9608270000Z" 156 ORGANIZATION "IETF Mail and Directory Management Working Group" 157 CONTACT-INFO 158 " Ned Freed 160 Postal: Innosoft International, Inc. 161 1050 East Garvey Avenue South 162 West Covina, CA 91790 163 US 165 Tel: +1 818 919 3600 166 Fax: +1 818 919 3614 168 E-Mail: ned@innosoft.com" 169 DESCRIPTION 170 "The MIB module describing Message Transfer Agents (MTAs)" 171 ::= {mib-2 28} 173 mtaTable OBJECT-TYPE 174 SYNTAX SEQUENCE OF MtaEntry 175 MAX-ACCESS not-accessible 176 STATUS current 177 DESCRIPTION 178 "The table holding information specific to an MTA." 179 ::= {mta 1} 181 mtaStatusCode OBJECT-TYPE 182 SYNTAX INTEGER (40000..59999) 183 MAX-ACCESS not-accessible 184 STATUS current 185 DESCRIPTION 186 "An index capable of representing an Enhanced Mail System 187 Status Code. Enhanced Mail System Status Codes are defined 188 in RFC 1893 [11]. Both SMTP error response codes and X.400 189 reason and diagnostic codes can be mapped into these codes. 190 Specifically, given a status code of the form 191 class.subject.detail, the corresponding index value is 192 defined to be ((class * 100) + subject) * 100 + detail." 194 mtaEntry OBJECT-TYPE 195 SYNTAX MtaEntry 196 MAX-ACCESS not-accessible 197 STATUS current 198 DESCRIPTION 199 "The entry associated with each MTA." 200 INDEX {applIndex} 201 ::= {mtaTable 1} 203 MtaEntry ::= SEQUENCE { 204 mtaReceivedMessages 205 Counter32, 206 mtaStoredMessages 207 Gauge32, 208 mtaTransmittedMessages 209 Counter32, 210 mtaReceivedVolume 211 Counter32, 212 mtaStoredVolume 213 Gauge32, 214 mtaTransmittedVolume 215 Counter32, 216 mtaReceivedRecipients 217 Counter32, 218 mtaStoredRecipients 219 Gauge32, 220 mtaTransmittedRecipients 221 Counter32, 222 mtaSuccessfulConvertedMessages 223 Counter32, 224 mtaFailedConvertedMessages 225 Counter32, 226 mtaLoopsDetected 227 Counter32, 228 mtaDescription 229 DisplayString, 230 mtaURL, 231 URLString 232 } 233 mtaReceivedMessages OBJECT-TYPE 234 SYNTAX Counter32 235 MAX-ACCESS read-only 236 STATUS current 237 DESCRIPTION 238 "The number of messages received since MTA initialization. 239 This includes messages transmitted to this MTA from other 240 MTAs as well as messages that have been submitted to the 241 MTA directly by end-users or applications." 242 ::= {mtaEntry 1} 244 mtaStoredMessages OBJECT-TYPE 245 SYNTAX Gauge32 246 MAX-ACCESS read-only 247 STATUS current 248 DESCRIPTION 249 "The total number of messages currently stored in the MTA. 250 This includes messages that are awaiting transmission to 251 some other MTA or are waiting for delivery to an end-user 252 or application." 253 ::= {mtaEntry 2} 255 mtaTransmittedMessages OBJECT-TYPE 256 SYNTAX Counter32 257 MAX-ACCESS read-only 258 STATUS current 259 DESCRIPTION 260 "The number of messages transmitted since MTA initialization. 261 This includes messages that were transmitted to some other 262 MTA or are waiting for delivery to an end-user or 263 application." 264 ::= {mtaEntry 3} 266 mtaReceivedVolume OBJECT-TYPE 267 SYNTAX Counter32 268 UNITS "K-octets" 269 MAX-ACCESS read-only 270 STATUS current 271 DESCRIPTION 272 "The total volume of messages received since MTA 273 initialization, measured in kilo-octets. This volume should 274 include all transferred data that is logically above the mail 275 transport protocol level. For example, an SMTP-based MTA 276 should use the number of kilo-octets in the message header 277 and body, while an X.400-based MTA should use the number of 278 kilo-octets of P2 data. This includes messages transmitted 279 to this MTA from other MTAs as well as messages that have 280 been submitted to the MTA directly by end-users or 281 applications." 282 ::= {mtaEntry 4} 284 mtaStoredVolume OBJECT-TYPE 285 SYNTAX Gauge32 286 UNITS "K-octets" 287 MAX-ACCESS read-only 288 STATUS current 289 DESCRIPTION 290 "The total volume of messages currently stored in the MTA, 291 measured in kilo-octets. This volume should include all 292 stored data that is logically above the mail transport 293 protocol level. For example, an SMTP-based MTA should 294 use the number of kilo-octets in the message header and 295 body, while an X.400-based MTA would use the number of 296 kilo-octets of P2 data. This includes messages that are 297 awaiting transmission to some other MTA or are waiting 298 for delivery to an end-user or application." 299 ::= {mtaEntry 5} 301 mtaTransmittedVolume OBJECT-TYPE 302 SYNTAX Counter32 303 UNITS "K-octets" 304 MAX-ACCESS read-only 305 STATUS current 306 DESCRIPTION 307 "The total volume of messages transmitted since MTA 308 initialization, measured in kilo-octets. This volume should 309 include all transferred data that is logically above the mail 310 transport protocol level. For example, an SMTP-based MTA 311 should use the number of kilo-octets in the message header 312 and body, while an X.400-based MTA should use the number of 313 kilo-octets of P2 data. This includes messages that were 314 transmitted to some other MTA or are waiting for delivery 315 to an end-user or application." 316 ::= {mtaEntry 6} 318 mtaReceivedRecipients OBJECT-TYPE 319 SYNTAX Counter32 320 MAX-ACCESS read-only 321 STATUS current 322 DESCRIPTION 323 "The total number of recipients specified in all messages 324 received since MTA initialization. Recipients this MTA 325 has no responsibility for, i.e. inactive envelope 326 recipients or ones referred to in message headers, 327 should not be counted even if information about such 328 recipients is available. This includes messages 329 transmitted to this MTA from other MTAs as well as 330 messages that have been submitted to the MTA directly 331 by end-users or applications." 332 ::= {mtaEntry 7} 334 mtaStoredRecipients OBJECT-TYPE 335 SYNTAX Gauge32 336 MAX-ACCESS read-only 337 STATUS current 338 DESCRIPTION 339 "The total number of recipients specified in all messages 340 currently stored in the MTA. Recipients this MTA has no 341 responsibility for, i.e. inactive envelope recipients or 342 ones referred to in message headers, should not be 343 counted. This includes messages that are awaiting 344 transmission to some other MTA or are waiting for 345 delivery to an end-user or application." 347 ::= {mtaEntry 8} 349 mtaTransmittedRecipients OBJECT-TYPE 350 SYNTAX Counter32 351 MAX-ACCESS read-only 352 STATUS current 353 DESCRIPTION 354 "The total number of recipients specified in all messages 355 transmitted since MTA initialization. Recipients this 356 MTA had no responsibility for, i.e. inactive envelope 357 recipients or ones referred to in message headers, 358 should not be counted. This includes messages that were 359 transmitted to some other MTA or are waiting for 360 delivery to an end-user or application." 361 ::= {mtaEntry 9} 363 mtaSuccessfulConvertedMessages OBJECT-TYPE 364 SYNTAX Counter32 365 MAX-ACCESS read-only 366 STATUS current 367 DESCRIPTION 368 "The number of messages that have been successfully 369 converted from one form to another since MTA 370 initialization." 371 ::= {mtaEntry 10} 373 mtaFailedConvertedMessages OBJECT-TYPE 374 SYNTAX Counter32 375 MAX-ACCESS read-only 376 STATUS current 377 DESCRIPTION 378 "The number of messages for which an unsuccessful 379 attempt was made to convert them from one form to 380 another since MTA initialization." 381 ::= {mtaEntry 11} 383 mtaLoopsDetected OBJECT-TYPE 384 SYNTAX Counter32 385 MAX-ACCESS read-only 386 STATUS current 387 DESCRIPTION 388 "A message loop is defined as a situation where the MTA 389 decides that a given message will never be delivered to 390 one or more recipients and instead will continue to 391 loop endlessly through one or more MTAs. This variable 392 counts the number of times the MTA has detected such a 393 situation since MTA initialization. Note that the 394 mechanism MTAs use to detect loops (e.g. trace field 395 counting, count of references to this MTA in a trace 396 field, examination of DNS or other directory information, 397 etc.), the level at which loops are detected (e.g. per 398 message, per recipient, per directory entry, etc.), and 399 the handling of a loop once it is detected (e.g. looping 400 messages are held, looping messages are bounced or sent 401 to the postmaster, messages that the MTA knows will loop 402 won't be accepted, etc.) vary widely from one MTA to the 403 next and cannot be inferred from this variable." 404 ::= {mtaEntry 12} 406 mtaDescription OBJECT-TYPE 407 SYNTAX DisplayString 408 MAX-ACCESS read-only 409 STATUS current 410 DESCRIPTION 411 "A description of the MTA. This information is 412 intended to identify the MTA in a status display." 413 ::= {mtaEntry 13} 415 mtaURL OBJECT-TYPE 416 SYNTAX URLString 417 MAX-ACCESS read-only 418 STATUS current 419 DESCRIPTION 420 "A URL pointing to a description of the MTA. This 421 information is intended to identify and describe the MTA 422 in a status display." 423 ::= {mtaEntry 14} 425 -- MTAs typically group inbound reception, queue storage, and 426 -- outbound transmission in some way, rather than accounting for 427 -- such operations only across the MTA as a whole. In the most 428 -- extreme case separate information will be maintained for each 429 -- different entity that receives messages and for each entity 430 -- the MTA stores messages for and delivers messages to. Other 431 -- MTAs may elect to treat all reception equally, all queue 432 -- storage equally, all deliveries equally, or some combination 433 -- of this. Overlapped groupings are also possible, where an MTA 434 -- decomposes its traffic in different ways for different 435 -- purposes. 437 -- In any case, a grouping abstraction is an extremely useful for 438 -- breaking down the activities of an MTA. For purposes of 439 -- labelling this will be called a "group" in this MIB. 441 -- Each group contains all the variables needed to monitor all 442 -- aspects of an MTA's operation. However, the fact that all 443 -- groups contain all possible variables does not imply that all 444 -- groups must use all possible variables. For example, a single 445 -- group might be used to monitor only one kind of event (inbound 446 -- processing, outbound processing, or storage). In this sort of 447 -- configuration all unused counters would be inaccessible; e.g., 448 -- returning either a noSuchName error (for an SNMPv1 get), or a 449 -- noSuchInstance exception (for an SNMPv2 get). 451 -- Groups can be created at any time after MTA initialization. Once 452 -- a group is created it should not be deleted or its mtaGroupIndex 453 -- changed unless the MTA is reinitialized. 455 -- Groups are not necessarily mutually exclusive. A given event may 456 -- be recorded by more than one group, a message may be seen as 457 -- stored by more than one group, and so on. Groups should be all 458 -- inclusive, however: if groups are implemented all aspects of an 459 -- MTA's operation should be registered in at least one group. This 460 -- freedom lets implementors use different sets of groups to 461 -- provide differents "views" of an MTA. 463 -- The possibility of overlap between groups means that summing 464 -- variables across groups may not produce values equal to those in 465 -- the mtaTable. mtaTable should always provide accurate information 466 -- about the MTA as a whole. 468 -- The term "channel" is often used in MTA implementations; channels 469 -- are usually, but not always, equivalent to a group. However, 470 -- this MIB does not use the term "channel" because there is no 471 -- requirement that an MTA supporting this MIB has to map its 472 -- "channel" abstraction one-to-one onto the MIB's group abstration. 474 -- An MTA may create a group or group of groups at any time. Once 475 -- created, however, an MTA cannot delete an entry for a group from 476 -- the group table. Deletation is only allowed when the MTA is 477 -- reinitialized, and is not required even then. This restriction 478 -- is imposed so that monitoring agents can rely on group 479 -- assignments being consistent across multiple query operations. 481 -- Groups may be laid out so as to form a hierarchical arrangement, 482 -- with some groups acting as subgroups for other groups. 483 -- Alternately, disjoint groups of groups may be used to provide 484 -- different sorts of "snapshots" of MTA operation. The 485 -- mtaGroupHierarchy variable provides an indication of how each 486 -- group fits into the overall arrangement being used. 488 mtaGroupTable OBJECT-TYPE 489 SYNTAX SEQUENCE OF MtaGroupEntry 490 MAX-ACCESS not-accessible 491 STATUS current 492 DESCRIPTION 493 "The table holding information specific to each MTA group." 494 ::= {mta 2} 496 mtaGroupEntry OBJECT-TYPE 497 SYNTAX MtaGroupEntry 498 MAX-ACCESS not-accessible 499 STATUS current 500 DESCRIPTION 501 "The entry associated with each MTA group." 502 INDEX {applIndex, mtaGroupIndex} 503 ::= {mtaGroupTable 1} 505 MtaGroupEntry ::= SEQUENCE { 506 mtaGroupIndex 507 INTEGER, 508 mtaGroupReceivedMessages 509 Counter32, 510 mtaGroupRejectedMessages 511 Counter32, 512 mtaGroupStoredMessages 513 Gauge32, 514 mtaGroupTransmittedMessages 515 Counter32, 516 mtaGroupReceivedVolume 517 Counter32, 518 mtaGroupStoredVolume 519 Gauge32, 520 mtaGroupTransmittedVolume 521 Counter32, 522 mtaGroupReceivedRecipients 523 Counter32, 524 mtaGroupStoredRecipients 525 Gauge32, 526 mtaGroupTransmittedRecipients 527 Counter32, 528 mtaGroupOldestMessageStored 529 TimeInterval, 530 mtaGroupInboundAssociations 531 Gauge32, 532 mtaGroupOutboundAssociations 533 Gauge32, 534 mtaGroupAccumulatedInboundAssociations 535 Counter32, 536 mtaGroupAccumulatedOutboundAssociations 537 Counter32, 538 mtaGroupLastInboundActivity 539 TimeInterval, 540 mtaGroupLastOutboundActivity 541 TimeInterval, 542 mtaGroupLastOutboundAssociationAttempt 543 TimeInterval, 544 mtaGroupRejectedInboundAssociations 545 Counter32, 546 mtaGroupFailedOutboundAssociations 547 Counter32, 548 mtaGroupInboundRejectionReason 549 DisplayString, 550 mtaGroupOutboundConnectFailureReason 551 DisplayString, 552 mtaGroupScheduledRetry 553 TimeInterval, 554 mtaGroupMailProtocol 555 OBJECT IDENTIFIER, 556 mtaGroupName 557 DisplayString, 559 mtaGroupSuccessfulConvertedMessages 560 Counter32, 561 mtaGroupFailedConvertedMessages 562 Counter32, 563 mtaGroupDescription 564 DisplayString, 565 mtaGroupURL 566 URLString, 567 mtaGroupCreationTime 568 TimeInterval, 569 mtaGroupHierarchy 570 INTEGER, 571 mtaGroupOldestMessageId 572 DisplayString, 573 mtaGroupLoopsDetected 574 Counter32 575 } 577 mtaGroupIndex OBJECT-TYPE 578 SYNTAX INTEGER (1..2147483647) 579 MAX-ACCESS not-accessible 580 STATUS current 581 DESCRIPTION 582 "The index associated with a group for a given MTA." 583 ::= {mtaGroupEntry 1} 585 mtaGroupReceivedMessages OBJECT-TYPE 586 SYNTAX Counter32 587 MAX-ACCESS read-only 588 STATUS current 589 DESCRIPTION 590 "The number of messages received to this group since 591 group creation." 592 ::= {mtaGroupEntry 2} 594 mtaGroupRejectedMessages OBJECT-TYPE 595 SYNTAX Counter32 596 MAX-ACCESS read-only 597 STATUS current 598 DESCRIPTION 599 "The number of messages rejected by this group since 600 group creation." 601 ::= {mtaGroupEntry 3} 603 mtaGroupStoredMessages OBJECT-TYPE 604 SYNTAX Gauge32 605 MAX-ACCESS read-only 606 STATUS current 607 DESCRIPTION 608 "The total number of messages currently stored in this 609 group's queue." 610 ::= {mtaGroupEntry 4} 612 mtaGroupTransmittedMessages OBJECT-TYPE 613 SYNTAX Counter32 614 MAX-ACCESS read-only 615 STATUS current 616 DESCRIPTION 617 "The number of messages transmitted by this group since 618 group creation." 619 ::= {mtaGroupEntry 5} 621 mtaGroupReceivedVolume OBJECT-TYPE 622 SYNTAX Counter32 623 UNITS "K-octets" 624 MAX-ACCESS read-only 625 STATUS current 626 DESCRIPTION 627 "The total volume of messages received to this group since 628 group creation, measured in kilo-octets. This volume 629 should include all transferred data that is logically above 630 the mail transport protocol level. For example, an 631 SMTP-based MTA should use the number of kilo-octets in the 632 message header and body, while an X.400-based MTA should use 633 the number of kilo-octets of P2 data." 634 ::= {mtaGroupEntry 6} 636 mtaGroupStoredVolume OBJECT-TYPE 637 SYNTAX Gauge32 638 UNITS "K-octets" 639 MAX-ACCESS read-only 640 STATUS current 641 DESCRIPTION 642 "The total volume of messages currently stored in this 643 group's queue, measured in kilo-octets. This volume should 644 include all stored data that is logically above the mail 645 transport protocol level. For example, an SMTP-based 646 MTA should use the number of kilo-octets in the message 647 header and body, while an X.400-based MTA would use the 648 number of kilo-octets of P2 data." 649 ::= {mtaGroupEntry 7} 651 mtaGroupTransmittedVolume OBJECT-TYPE 652 SYNTAX Counter32 653 UNITS "K-octets" 654 MAX-ACCESS read-only 655 STATUS current 656 DESCRIPTION 657 "The total volume of messages transmitted by this group 658 since group creation, measured in kilo-octets. This 659 volume should include all transferred data that is logically 660 above the mail transport protocol level. For example, an 661 SMTP-based MTA should use the number of kilo-octets in the 662 message header and body, while an X.400-based MTA should use 663 the number of kilo-octets of P2 data." 664 ::= {mtaGroupEntry 8} 666 mtaGroupReceivedRecipients OBJECT-TYPE 667 SYNTAX Counter32 668 MAX-ACCESS read-only 669 STATUS current 670 DESCRIPTION 671 "The total number of recipients specified in all messages 672 received to this group since group creation. 673 Recipients this MTA has no responsibility for should not 674 be counted." 675 ::= {mtaGroupEntry 9} 677 mtaGroupStoredRecipients OBJECT-TYPE 678 SYNTAX Gauge32 679 MAX-ACCESS read-only 680 STATUS current 681 DESCRIPTION 682 "The total number of recipients specified in all messages 683 currently stored in this group's queue. Recipients this 684 MTA has no responsibility for should not be counted." 685 ::= {mtaGroupEntry 10} 687 mtaGroupTransmittedRecipients OBJECT-TYPE 688 SYNTAX Counter32 689 MAX-ACCESS read-only 690 STATUS current 691 DESCRIPTION 692 "The total number of recipients specified in all messages 693 transmitted by this group since group creation. 694 Recipients this MTA had no responsibility for should not 695 be counted." 696 ::= {mtaGroupEntry 11} 698 mtaGroupOldestMessageStored OBJECT-TYPE 699 SYNTAX TimeInterval 700 MAX-ACCESS read-only 701 STATUS current 702 DESCRIPTION 703 "Time since the oldest message in this group's queue was 704 placed in the queue." 705 ::= {mtaGroupEntry 12} 707 mtaGroupInboundAssociations OBJECT-TYPE 708 SYNTAX Gauge32 709 MAX-ACCESS read-only 710 STATUS current 711 DESCRIPTION 712 "The number of current associations to the group, where the 713 group is the responder." 714 ::= {mtaGroupEntry 13} 716 mtaGroupOutboundAssociations OBJECT-TYPE 717 SYNTAX Gauge32 718 MAX-ACCESS read-only 719 STATUS current 720 DESCRIPTION 721 "The number of current associations to the group, where the 722 group is the initiator." 723 ::= {mtaGroupEntry 14} 725 mtaGroupAccumulatedInboundAssociations OBJECT-TYPE 726 SYNTAX Counter32 727 MAX-ACCESS read-only 728 STATUS current 729 DESCRIPTION 730 "The total number of associations to the group since 731 group creation, where the MTA was the responder." 732 ::= {mtaGroupEntry 15} 734 mtaGroupAccumulatedOutboundAssociations OBJECT-TYPE 735 SYNTAX Counter32 736 MAX-ACCESS read-only 737 STATUS current 738 DESCRIPTION 739 "The total number of associations from the group since 740 group creation, where the MTA was the initiator." 741 ::= {mtaGroupEntry 16} 743 mtaGroupLastInboundActivity OBJECT-TYPE 744 SYNTAX TimeInterval 745 MAX-ACCESS read-only 746 STATUS current 747 DESCRIPTION 748 "Time since the last time that this group had an active 749 inbound association for purposes of message reception." 750 ::= {mtaGroupEntry 17} 752 mtaGroupLastOutboundActivity OBJECT-TYPE 753 SYNTAX TimeInterval 754 MAX-ACCESS read-only 755 STATUS current 756 DESCRIPTION 757 "Time since the last time that this group had a 758 successful outbound association for purposes of 759 message delivery." 760 ::= {mtaGroupEntry 18} 762 mtaGroupLastOutboundAssociationAttempt OBJECT-TYPE 763 SYNTAX TimeInterval 764 MAX-ACCESS read-only 765 STATUS current 766 DESCRIPTION 767 "Time since the last time that this group attempted 768 to make an outbound association for purposes of 769 message delivery." 770 ::= {mtaGroupEntry 34} 772 mtaGroupRejectedInboundAssociations OBJECT-TYPE 773 SYNTAX Counter32 774 MAX-ACCESS read-only 775 STATUS current 776 DESCRIPTION 777 "The total number of inbound associations the group has 778 rejected, since group creation. Rejected 779 associations are not counted in the accumulated 780 association totals." 781 ::= {mtaGroupEntry 19} 783 mtaGroupFailedOutboundAssociations OBJECT-TYPE 784 SYNTAX Counter32 785 MAX-ACCESS read-only 786 STATUS current 787 DESCRIPTION 788 "The total number associations where the group was the 789 initiator and association establishment has failed, 790 since group creation. Failed associations are 791 not counted in the accumulated association totals." 792 ::= {mtaGroupEntry 20} 794 mtaGroupInboundRejectionReason OBJECT-TYPE 795 SYNTAX DisplayString 796 MAX-ACCESS read-only 797 STATUS current 798 DESCRIPTION 799 "The failure reason, if any, for the last association this 800 group refused to respond to. An empty string indicates that 801 the last attempt was successful. If no association attempt 802 has been made since the MTA was initialized the value 803 should be 'never'." 804 ::= {mtaGroupEntry 21} 806 mtaGroupOutboundConnectFailureReason OBJECT-TYPE 807 SYNTAX DisplayString 808 MAX-ACCESS read-only 809 STATUS current 810 DESCRIPTION 811 "The failure reason, if any, for the last association attempt 812 this group initiated. An empty string indicates that the last 813 attempt was successful. If no association attempt has been 814 made since the MTA was initialized the value should be 815 'never'." 816 ::= {mtaGroupEntry 22} 818 mtaGroupScheduledRetry OBJECT-TYPE 819 SYNTAX TimeInterval 820 MAX-ACCESS read-only 821 STATUS current 822 DESCRIPTION 823 "The time when this group is scheduled to next attempt to 824 make an association." 825 ::= {mtaGroupEntry 23} 827 mtaGroupMailProtocol OBJECT-TYPE 828 SYNTAX OBJECT IDENTIFIER 829 MAX-ACCESS read-only 830 STATUS current 831 DESCRIPTION 832 "An identification of the protocol being used by this group. 833 For an group employing OSI protocols, this will be the 834 Application Context. For Internet applications, the IANA 835 maintains a registry of the OIDs which correspond to well-known 836 message transfer protocols. If the application protocol is 837 not listed in the registry, an OID value of the form 838 {applTCPProtoID port} or {applUDProtoID port} are used for 839 TCP-based and UDP-based protocols, respectively. In either 840 case 'port' corresponds to the primary port number being 841 used by the group. applTCPProtoID and applUDPProtoID are 842 defined in [5]." 843 ::= {mtaGroupEntry 24} 845 mtaGroupName OBJECT-TYPE 846 SYNTAX DisplayString 847 MAX-ACCESS read-only 848 STATUS current 849 DESCRIPTION 850 "A descriptive name for the group. If this group connects to 851 a single remote MTA this should be the name of that MTA. If 852 this in turn is an Internet MTA this should be the domain 853 name. For an OSI MTA it should be the string encoded 854 distinguished name of the managed object using the format 855 defined in RFC 1779 [6]. For X.400(1984) MTAs which do not 856 have a Distinguished Name, the RFC 1327 [9] syntax 857 'mta in globalid' should be used." 858 ::= {mtaGroupEntry 25} 860 mtaGroupSuccessfulConvertedMessages OBJECT-TYPE 861 SYNTAX Counter32 862 MAX-ACCESS read-only 863 STATUS current 864 DESCRIPTION 865 "The number of messages that have been successfully 866 converted from one form to another in this group 867 since group creation." 868 ::= {mtaGroupEntry 26} 870 mtaGroupFailedConvertedMessages OBJECT-TYPE 871 SYNTAX Counter32 872 MAX-ACCESS read-only 873 STATUS current 874 DESCRIPTION 875 "The number of messages for which an unsuccessful 876 attempt was made to convert them from one form to 877 another in this group since group creation." 878 ::= {mtaGroupEntry 27} 880 mtaGroupDescription OBJECT-TYPE 881 SYNTAX DisplayString 882 MAX-ACCESS read-only 883 STATUS current 884 DESCRIPTION 885 "A description of the group's purpose. This information is 886 intended to identify the group in a status display." 887 ::= {mtaGroupEntry 28} 889 mtaGroupURL OBJECT-TYPE 890 SYNTAX URLString 891 MAX-ACCESS read-only 892 STATUS current 893 DESCRIPTION 894 "A URL pointing to a description of the group. This 895 information is intended to identify and describe the group 896 in a status display." 897 ::= {mtaEntry 29} 899 mtaGroupCreationTime OBJECT-TYPE 900 SYNTAX TimeInterval 901 MAX-ACCESS read-only 902 STATUS current 903 DESCRIPTION 904 "Time since this group was first created." 905 ::= {mtaGroupEntry 30} 907 mtaGroupHierarchy OBJECT-TYPE 908 SYNTAX INTEGER (-2147483648..2147483647) 909 MAX-ACCESS not-accessible 910 STATUS current 911 DESCRIPTION 912 "Describes how this group fits into the hierarchy. A 913 positive value is interpreted as an mtaGroupIndex 914 value for some other group whose variables include 915 those of this group (and usually others). A negative 916 value is interpreted as a group collection code: Groups 917 with common negative hierarchy values comprise one 918 particular breakdown of MTA activity as a whole. A 919 zero value means that this MIB implementation doesn't 920 implement hierarchy indicators and thus the overall 921 group hierarchy cannot be determined." 922 ::= {mtaGroupEntry 31} 924 mtaGroupOldestMessageId OBJECT-TYPE 925 SYNTAX DisplayString 926 MAX-ACCESS read-only 927 STATUS current 928 DESCRIPTION 929 "Message ID of the oldest message in the group's queue. 930 Whenever possible this should be in the form of an 931 RFC 822 [10] msg-id; X.400 may convert X.400 message 932 identifiers to this form by following the rules laid 933 out in RFC1327 [9]." 935 ::= {mtaGroupEntry 32} 937 mtaGroupLoopsDetected OBJECT-TYPE 938 SYNTAX Counter32 939 MAX-ACCESS read-only 940 STATUS current 941 DESCRIPTION 942 "A message loop is defined as a situation where the MTA 943 decides that a given message will never be delivered to 944 one or more recipients and instead will continue to 945 loop endlessly through one or more MTAs. This variable 946 counts the number of times the MTA has detected such a 947 situation in conjunction with something associated with 948 this group since group creation. Note that the 949 mechanism MTAs use to detect loops (e.g. trace field 950 counting, count of references to this MTA in a trace 951 field, examination of DNS or other directory information, 952 etc.), the level at which loops are detected (e.g. per 953 message, per recipient, per directory entry, etc.), and 954 the handling of a loop once it is detected (e.g. looping 955 messages are held, looping messages are bounced or sent 956 to the postmaster, messages that the MTA knows will loop 957 won't be accepted, etc.) vary widely from one MTA to the 958 next and cannot be inferred from this variable." 959 ::= {mtaGroupEntry 33} 961 mtaGroupAssociationTable OBJECT-TYPE 962 SYNTAX SEQUENCE OF MtaGroupAssociationEntry 963 MAX-ACCESS not-accessible 964 STATUS current 965 DESCRIPTION 966 "The table holding information regarding the associations 967 for each MTA group." 968 ::= {mta 3} 970 mtaGroupAssociationEntry OBJECT-TYPE 971 SYNTAX MtaGroupAssociationEntry 972 MAX-ACCESS not-accessible 973 STATUS current 974 DESCRIPTION 975 "The entry holding information regarding the associations 976 for each MTA group." 977 INDEX {applIndex, mtaGroupIndex, mtaGroupAssociationIndex} 978 ::= {mtaGroupAssociationTable 1} 980 MtaGroupAssociationEntry ::= SEQUENCE { 981 mtaGroupAssociationIndex 982 INTEGER 983 } 985 mtaGroupAssociationIndex OBJECT-TYPE 986 SYNTAX INTEGER (1..2147483647) 987 MAX-ACCESS read-only 988 STATUS current 989 DESCRIPTION 990 "Reference into association table to allow correlation of 991 this group's active associations with the association table." 992 ::= {mtaGroupAssociationEntry 1} 994 -- Conformance information 996 mtaConformance OBJECT IDENTIFIER ::= {mta 4} 998 mtaGroups OBJECT IDENTIFIER ::= {mtaConformance 1} 999 mtaCompliances OBJECT IDENTIFIER ::= {mtaConformance 2} 1001 -- Compliance statements 1003 mtaCompliance MODULE-COMPLIANCE 1004 STATUS current 1005 DESCRIPTION 1006 "The compliance statement for SNMPv2 entities which 1007 implement the Mail Monitoring MIB for basic 1008 monitoring of MTAs." 1009 MODULE -- this module 1010 MANDATORY-GROUPS {mtaGroup} 1011 ::= {mtaCompliances 1} 1013 mtaAssocCompliance MODULE-COMPLIANCE 1014 STATUS current 1015 DESCRIPTION 1016 "The compliance statement for SNMPv2 entities which 1017 implement the Mail Monitoring MIB for monitoring of 1018 MTAs and their associations." 1019 MODULE -- this module 1020 MANDATORY-GROUPS {mtaGroup, mtaAssocGroup} 1021 ::= {mtaCompliances 2} 1023 -- Units of conformance 1025 mtaGroup OBJECT-GROUP 1026 OBJECTS { 1027 mtaReceivedMessages, mtaStoredMessages, 1028 mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume, 1029 mtaTransmittedVolume, mtaReceivedRecipients, 1030 mtaStoredRecipients, mtaTransmittedRecipients, 1031 mtaSuccessfulConvertedMessages, mtaFailedConvertedMessages, 1032 mtaLoopsDetected, mtaDescription, mtaURL, 1033 mtaGroupReceivedMessages, mtaGroupRejectedMessages, 1034 mtaGroupStoredMessages, mtaGroupTransmittedMessages, 1035 mtaGroupReceivedVolume, mtaGroupStoredVolume, 1036 mtaGroupTransmittedVolume, mtaGroupReceivedRecipients, 1037 mtaGroupStoredRecipients, mtaGroupTransmittedRecipients, 1038 mtaGroupOldestMessageStored, mtaGroupInboundAssociations, 1039 mtaGroupOutboundAssociations, 1040 mtaGroupAccumulatedInboundAssociations, 1041 mtaGroupAccumulatedOutboundAssociations, 1042 mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity, 1043 mtaGroupLastOutboundAssociationAttempt, 1044 mtaGroupRejectedInboundAssociations, 1045 mtaGroupFailedOutboundAssociations, 1046 mtaGroupInboundRejectionReason, 1047 mtaGroupOutboundConnectFailureReason, 1048 mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName, 1049 mtaGroupSuccessfulConvertedMessages, 1050 mtaGroupFailedConvertedMessages, mtaGroupDescription, 1051 mtaGroupURL, mtaGroupCreationTime, mtaGroupHierarchy, 1052 mtaGroupOldestMessageId, mtaGroupLoopsDetected} 1053 STATUS current 1054 DESCRIPTION 1055 "A collection of objects providing basic monitoring of MTAs." 1056 ::= {mtaGroups 1} 1058 mtaAssocGroup OBJECT-GROUP 1059 OBJECTS { 1060 mtaGroupAssociationIndex} 1061 STATUS current 1062 DESCRIPTION 1063 "A collection of objects providing monitoring of MTA 1064 associations." 1065 ::= {mtaGroups 2} 1067 END 1068 7. Changes made since RFC 1566 1070 The only changes made to this document since it was issued as RFC 1566 1071 [8] are the following: 1073 (1) A number of DESCRIPTION fields have been reworded, hopefully 1074 making them clearer. 1076 (2) mtaDescription, mtaURL, mtaGroupDescription, mtaGroupURL fields 1077 have been added. These fields are intended to identify and 1078 describe the MTA and the various MTA groups. 1080 (3) The time since the last outbound association attempt is now 1081 distinct from the time since the last successfuol outbound 1082 association attempt. 1084 (4) Conversion operation counters have been added. 1086 (5) A mechanism to explicitly describe group hierarchies has been 1087 added. 1089 (6) A field for the ID of the oldest message in a group's queue has 1090 been added. 1092 (7) Per-MTA and per-group message loop counters have been added. 1094 8. Acknowledgements 1096 This document is a product of the Mail and Directory Management (MADMAN) 1097 Working Group. It is based on an earlier MIB designed by S. Kille, T. 1098 Lenggenhager, D. Partain, and W. Yeong. The Electronic Mail 1099 Association's TSC committee was instrumental in providing feedback on 1100 and suggesting enhancements to RFC 1566 [8] that have led to the present 1101 document. 1103 9. References 1105 [1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure 1106 of Management Information for Version 2 of the Simple Network 1107 Management Protocol (SNMPv2)", RFC 1902, January 1996. 1109 [2] McCloghrie, K., and Rose, M., Editors, "Management Information Base 1110 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 1111 RFC 1213, March 1991. 1113 [3] Galvin, J., McCloghrie, K., " Administrative Model for version 2 of 1114 the Simple Network Management Protocol (SNMPv2)", RFC 1445, April 1115 1993. 1117 [4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol 1118 Operations for Version 2 of the Simple Network Management Protocol 1119 (SNMPv2)", RFC 1905, January 1996. 1121 [5] Freed, N., Kille, S., "The Network Services Monitoring MIB", 1122 Internet Draft, March 1996. 1124 [6] Kille, S., "A String Representation of Distinguished Names", RFC 1125 1779, March 1995. 1127 [7] Berners-Lee, T., Masinter, L., McCahill, M., iform Resource 1128 Locators (URL)", RFC 1738, December 1994. 1130 [8] Freed, N., Kille, S., "Mail Monitoring MIB", RFC 1566, January 1131 1994. 1133 [9] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", 1134 RFC 1327, May 1992. 1136 [10] Crocker, D., "Standard for the Format of ARPA Internet Text 1137 Message", August 1982. 1139 [11] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, Octel 1140 Network Services, January 1996. 1142 10. Security Considerations 1144 Security issues are not discussed in this memo. 1146 11. Authors' Addresses 1148 Ned Freed, Editor 1149 Innosoft International, Inc. 1150 1050 East Garvey Avenue South 1151 West Covina, CA 91790 1152 USA 1153 tel: +1 818 919 3600 1154 fax: +1 818 919 3614 1155 email: ned@innosoft.com 1157 Steve Kille, WG Chair 1158 ISODE Consortium 1159 The Dome, The Square 1160 Richmond TW9 1DT 1161 UK 1162 tel: +44 181 332 9091 1163 email: S.Kille@isode.com