idnits 2.17.1 draft-ietf-madman-mail-monitor-mib-05.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-19) 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 an Authors' Addresses Section. ** 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. -- The draft header indicates that this document obsoletes RFC1566, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 62 has weird spacing: '...defines trans...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1997) is 9744 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) == Unused Reference: '10' is defined on line 1242, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1902 (ref. '1') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '2') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '3') (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1905 (ref. '4') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (ref. '5') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (ref. '6') (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (ref. '7') (Obsoleted by RFC 2576) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1779 (ref. '9') (Obsoleted by RFC 2253, RFC 3494) ** Obsolete normative reference: RFC 1738 (ref. '10') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1566 (ref. '11') (Obsoleted by RFC 2249, RFC 2789) ** Obsolete normative reference: RFC 1327 (ref. '12') (Obsoleted by RFC 2156) ** Obsolete normative reference: RFC 822 (ref. '13') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1893 (ref. '14') (Obsoleted by RFC 3463) Summary: 23 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ned Freed, Innosoft 2 Internet Draft Steve Kille, ISODE Consortium 3 Obsoletes: 1566 5 Mail Monitoring MIB 7 August 1997 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. 31 Specifically, this memo extends the basic Network Services Monitoring 32 MIB [8] to allow monitoring of Message Transfer Agents (MTAs). It may 33 also 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 ..................................................... 4 43 6 Definitions ..................................................... 4 44 7 Changes made since RFC 1566 ..................................... 30 45 8 Acknowledgements ................................................ 31 46 9 References ...................................................... 31 47 10 Security Considerations ........................................ 32 48 11 Author and Chair Addresses ..................................... 32 50 3. The SNMPv2 Network Management Framework 52 The SNMPv2 Network Management Framework consists of seven 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 1903 [2] defines textual conventions for SNMPv2. 60 o RFC 1904 [3] defines conformance statements for SNMPv2. 62 o RFC 1905 [4] defines transport mappings for SNMPv2. 64 o RFC 1906 [5] defines the protocol operations used for network 65 access to managed objects. 67 o RFC 1907 [6] defines the Management Information Base for SNMPv2. 69 o RFC 1908 [7] specifies coexistance between SNMP and SNMPv2. 71 The Framework permits new objects to be defined for the purpose of 72 experimentation and evaluation. 74 3.1. Object Definitions 76 Managed objects are accessed via a virtual information store, termed the 77 Management Information Base or MIB. Objects in the MIB are defined using 78 the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. 79 In particular, each object type is named by an OBJECT IDENTIFIER, an 80 administratively assigned name. The object type together with an object 81 instance serves to uniquely identify a specific instantiation of the 82 object. For human convenience, we often use a textual string, termed 83 the descriptor, to refer to the object type. 85 4. Message Flow Model 87 A general model of message flow inside an MTA has to be presented before 88 a MIB can be described. Generally speaking, message flow is modelled as 89 occuring in four steps: 91 (1) Messages are received by the MTA from User Agents, Message 92 Stores, other MTAs, and gateways. 94 (2) The "next hop" for the each message is determined. This is simply 95 the destination the message is to be transmitted to; it may or 96 may not be the final destination of the message. Multiple "next 97 hops" may exist for a single message (as a result of either 98 having multiple recipients or distribution list expansion); this 99 may make it necessary to duplicate messages. 101 (3) If necessary messages are converted into the format that's 102 appropriate for the next hop. Conversion operations may be 103 successful or unsuccessful. 105 (4) Messages are transmitted to the appropriate destination, which 106 may be a User Agent, Message Store, another MTA, or gateway. 108 Storage of messages in the MTA occurs at some point during this process. 109 However, it is important to note that storage may occur at different and 110 possibly even multiple points during this process. For example, some 111 MTAs expand messages into multiple copies as they are received. In this 112 case (1), (2), and (3) may all occur prior to storage. Other MTAs store 113 messages precisely as they are received and perform all expansions and 114 conversions during retransmission processing. So here only (1) occurs 115 prior to storage. This leads to situations where, in general, a 116 measurement of messages received may not equal a measurement of messages 117 in store, or a measurement of messages stored may not equal a 118 measurement of messages retransmitted, or both. 120 5. MTA Objects 122 If there are one or more MTAs on the host, the following MIB may be used 123 to monitor them. Any number of the MTAs on a single host or group of 124 hosts may be monitored. Each MTA is dealt with as a separate network 125 service and has its own applTable entry in the Network Services 126 Monitoring MIB. 128 The MIB described in this document covers only the portion which is 129 specific to the monitoring of MTAs. The network service related part of 130 the MIB is covered in a separate document [8]. 132 This MIB defines four tables. The first of these contains per-MTA 133 information that isn't specific to any particular part of MTA. The 134 second breaks each MTA down into a collection of separate components 135 called groups. Groups are described in detail in the comments embedded 136 in the MIB below. The third table provides a means of correlating 137 associations tracked by the network services MIB with specific groups 138 within different MTAs. Finally, the fourth table provides a means of 139 tracking any errors encountered during the operation of the MTA. The 140 first two tables must be implemented to conform with this MIB; the last 141 two are optional. 143 6. Definitions 145 MTA-MIB DEFINITIONS ::= BEGIN 147 IMPORTS 148 OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY, mib-2 149 FROM SNMPv2-SMI 150 DisplayString, TimeInterval 151 FROM SNMPv2-TC 152 MODULE-COMPLIANCE, OBJECT-GROUP 153 FROM SNMPv2-CONF 154 applIndex, URLString 155 FROM NETWORK-SERVICES-MIB; 157 mta MODULE-IDENTITY 158 LAST-UPDATED "9708170000Z" 159 ORGANIZATION "IETF Mail and Directory Management Working Group" 160 CONTACT-INFO 161 " Ned Freed 163 Postal: Innosoft International, Inc. 164 1050 Lakes Drive 165 West Covina, CA 91790 166 US 168 Tel: +1 626 919 3600 169 Fax: +1 626 919 3614 171 E-Mail: ned.freed@innosoft.com" 172 DESCRIPTION 173 "The MIB module describing Message Transfer Agents (MTAs)" 174 REVISION "9311280000Z" 175 DESCRIPTION 176 "The original version of this MIB was published in RFC 1566" 177 ::= {mib-2 28} 179 mtaTable OBJECT-TYPE 180 SYNTAX SEQUENCE OF MtaEntry 181 MAX-ACCESS not-accessible 182 STATUS current 183 DESCRIPTION 184 "The table holding information specific to an MTA." 185 ::= {mta 1} 187 mtaStatusCode OBJECT-TYPE 188 SYNTAX INTEGER (4000000..5999999) 189 MAX-ACCESS not-accessible 190 STATUS current 191 DESCRIPTION 192 "An index capable of representing an Enhanced Mail System 193 Status Code. Enhanced Mail System Status Codes are 194 defined in RFC 1893 [14]. These codes have the form 196 class.subject.detail 198 Here 'class' is either 2, 4, or 5 and both 'subject' and 199 'detail' are integers in the range 0..999. Given a status 200 code the corresponding index value is defined to be 201 ((class * 1000) + subject) * 1000 + detail. Both SMTP 202 error response codes and X.400 reason and diagnostic codes 203 can be mapped into these codes, resulting in a namespace 204 capable of describing most error conditions a mail system 205 encounters in a generic yet detailed way." 206 ::= {mta 6} 208 mtaEntry OBJECT-TYPE 209 SYNTAX MtaEntry 210 MAX-ACCESS not-accessible 211 STATUS current 212 DESCRIPTION 213 "The entry associated with each MTA." 214 INDEX {applIndex} 215 ::= {mtaTable 1} 217 MtaEntry ::= SEQUENCE { 218 mtaReceivedMessages 219 Counter32, 220 mtaStoredMessages 221 Gauge32, 222 mtaTransmittedMessages 223 Counter32, 224 mtaReceivedVolume 225 Counter32, 226 mtaStoredVolume 227 Gauge32, 228 mtaTransmittedVolume 229 Counter32, 230 mtaReceivedRecipients 231 Counter32, 232 mtaStoredRecipients 233 Gauge32, 234 mtaTransmittedRecipients 235 Counter32, 236 mtaSuccessfulConvertedMessages 237 Counter32, 238 mtaFailedConvertedMessages 239 Counter32, 240 mtaLoopsDetected 241 Counter32 242 } 243 mtaReceivedMessages OBJECT-TYPE 244 SYNTAX Counter32 245 MAX-ACCESS read-only 246 STATUS current 247 DESCRIPTION 248 "The number of messages received since MTA initialization. 249 This includes messages transmitted to this MTA from other 250 MTAs as well as messages that have been submitted to the 251 MTA directly by end-users or applications." 252 ::= {mtaEntry 1} 254 mtaStoredMessages OBJECT-TYPE 255 SYNTAX Gauge32 256 MAX-ACCESS read-only 257 STATUS current 258 DESCRIPTION 259 "The total number of messages currently stored in the MTA. 260 This includes messages that are awaiting transmission to 261 some other MTA or are waiting for delivery to an end-user 262 or application." 263 ::= {mtaEntry 2} 265 mtaTransmittedMessages OBJECT-TYPE 266 SYNTAX Counter32 267 MAX-ACCESS read-only 268 STATUS current 269 DESCRIPTION 270 "The number of messages transmitted since MTA initialization. 271 This includes messages that were transmitted to some other 272 MTA or are waiting for delivery to an end-user or 273 application." 274 ::= {mtaEntry 3} 276 mtaReceivedVolume OBJECT-TYPE 277 SYNTAX Counter32 278 UNITS "K-octets" 279 MAX-ACCESS read-only 280 STATUS current 281 DESCRIPTION 282 "The total volume of messages received since MTA 283 initialization, measured in kilo-octets. This volume should 284 include all transferred data that is logically above the mail 285 transport protocol level. For example, an SMTP-based MTA 286 should use the number of kilo-octets in the message header 287 and body, while an X.400-based MTA should use the number of 288 kilo-octets of P2 data. This includes messages transmitted 289 to this MTA from other MTAs as well as messages that have 290 been submitted to the MTA directly by end-users or 291 applications." 292 ::= {mtaEntry 4} 294 mtaStoredVolume OBJECT-TYPE 295 SYNTAX Gauge32 296 UNITS "K-octets" 297 MAX-ACCESS read-only 298 STATUS current 299 DESCRIPTION 300 "The total volume of messages currently stored in the MTA, 301 measured in kilo-octets. This volume should include all 302 stored data that is logically above the mail transport 303 protocol level. For example, an SMTP-based MTA should 304 use the number of kilo-octets in the message header and 305 body, while an X.400-based MTA would use the number of 306 kilo-octets of P2 data. This includes messages that are 307 awaiting transmission to some other MTA or are waiting 308 for delivery to an end-user or application." 309 ::= {mtaEntry 5} 311 mtaTransmittedVolume OBJECT-TYPE 312 SYNTAX Counter32 313 UNITS "K-octets" 314 MAX-ACCESS read-only 315 STATUS current 316 DESCRIPTION 317 "The total volume of messages transmitted since MTA 318 initialization, measured in kilo-octets. This volume should 319 include all transferred data that is logically above the mail 320 transport protocol level. For example, an SMTP-based MTA 321 should use the number of kilo-octets in the message header 322 and body, while an X.400-based MTA should use the number of 323 kilo-octets of P2 data. This includes messages that were 324 transmitted to some other MTA or are waiting for delivery 325 to an end-user or application." 326 ::= {mtaEntry 6} 328 mtaReceivedRecipients OBJECT-TYPE 329 SYNTAX Counter32 330 MAX-ACCESS read-only 331 STATUS current 332 DESCRIPTION 333 "The total number of recipients specified in all messages 334 received since MTA initialization. Recipients this MTA 335 has no responsibility for, i.e. inactive envelope 336 recipients or ones referred to in message headers, 337 should not be counted even if information about such 338 recipients is available. This includes messages 339 transmitted to this MTA from other MTAs as well as 340 messages that have been submitted to the MTA directly 341 by end-users or applications." 342 ::= {mtaEntry 7} 344 mtaStoredRecipients OBJECT-TYPE 345 SYNTAX Gauge32 346 MAX-ACCESS read-only 347 STATUS current 348 DESCRIPTION 349 "The total number of recipients specified in all messages 350 currently stored in the MTA. Recipients this MTA has no 351 responsibility for, i.e. inactive envelope recipients or 352 ones referred to in message headers, should not be 353 counted. This includes messages that are awaiting 354 transmission to some other MTA or are waiting for 355 delivery to an end-user or application." 356 ::= {mtaEntry 8} 358 mtaTransmittedRecipients OBJECT-TYPE 359 SYNTAX Counter32 360 MAX-ACCESS read-only 361 STATUS current 362 DESCRIPTION 363 "The total number of recipients specified in all messages 364 transmitted since MTA initialization. Recipients this 365 MTA had no responsibility for, i.e. inactive envelope 366 recipients or ones referred to in message headers, 367 should not be counted. This includes messages that were 368 transmitted to some other MTA or are waiting for 369 delivery to an end-user or application." 370 ::= {mtaEntry 9} 372 mtaSuccessfulConvertedMessages OBJECT-TYPE 373 SYNTAX Counter32 374 MAX-ACCESS read-only 375 STATUS current 376 DESCRIPTION 377 "The number of messages that have been successfully 378 converted from one form to another since MTA 379 initialization." 380 ::= {mtaEntry 10} 382 mtaFailedConvertedMessages OBJECT-TYPE 383 SYNTAX Counter32 384 MAX-ACCESS read-only 385 STATUS current 386 DESCRIPTION 387 "The number of messages for which an unsuccessful 388 attempt was made to convert them from one form to 389 another since MTA initialization." 390 ::= {mtaEntry 11} 392 mtaLoopsDetected OBJECT-TYPE 393 SYNTAX Counter32 394 MAX-ACCESS read-only 395 STATUS current 396 DESCRIPTION 397 "A message loop is defined as a situation where the MTA 398 decides that a given message will never be delivered to 399 one or more recipients and instead will continue to 400 loop endlessly through one or more MTAs. This variable 401 counts the number of times the MTA has detected such a 402 situation since MTA initialization. Note that the 403 mechanism MTAs use to detect loops (e.g. trace field 404 counting, count of references to this MTA in a trace 405 field, examination of DNS or other directory information, 406 etc.), the level at which loops are detected (e.g. per 407 message, per recipient, per directory entry, etc.), and 408 the handling of a loop once it is detected (e.g. looping 409 messages are held, looping messages are bounced or sent 410 to the postmaster, messages that the MTA knows will loop 411 won't be accepted, etc.) vary widely from one MTA to the 412 next and cannot be inferred from this variable." 413 ::= {mtaEntry 12} 415 -- MTAs typically group inbound reception, queue storage, and 416 -- outbound transmission in some way, rather than accounting for 417 -- such operations only across the MTA as a whole. In the most 418 -- extreme case separate information will be maintained for each 419 -- different entity that receives messages and for each entity 420 -- the MTA stores messages for and delivers messages to. Other 421 -- MTAs may elect to treat all reception equally, all queue 422 -- storage equally, all deliveries equally, or some combination 423 -- of this. Overlapped groupings are also possible, where an MTA 424 -- decomposes its traffic in different ways for different 425 -- purposes. 427 -- In any case, a grouping abstraction is an extremely useful for 428 -- breaking down the activities of an MTA. For purposes of 429 -- labelling this will be called a "group" in this MIB. 431 -- Each group contains all the variables needed to monitor all 432 -- aspects of an MTA's operation. However, the fact that all 433 -- groups contain all possible variables does not imply that all 434 -- groups must use all possible variables. For example, a single 435 -- group might be used to monitor only one kind of event (inbound 436 -- processing, outbound processing, or storage). In this sort of 437 -- configuration all unused counters would be inaccessible; e.g., 438 -- returning either a noSuchName error (for an SNMPv1 get), or a 439 -- noSuchInstance exception (for an SNMPv2 get). 441 -- Groups can be created at any time after MTA initialization. Once 442 -- a group is created it should not be deleted or its mtaGroupIndex 443 -- changed unless the MTA is reinitialized. 445 -- Groups are not necessarily mutually exclusive. A given event may 446 -- be recorded by more than one group, a message may be seen as 447 -- stored by more than one group, and so on. Groups should be all 448 -- inclusive, however: if groups are implemented all aspects of an 449 -- MTA's operation should be registered in at least one group. This 450 -- freedom lets implementors use different sets of groups to 451 -- provide differents "views" of an MTA. 453 -- The possibility of overlap between groups means that summing 454 -- variables across groups may not produce values equal to those in 455 -- the mtaTable. mtaTable should always provide accurate information 456 -- about the MTA as a whole. 458 -- The term "channel" is often used in MTA implementations; channels 459 -- are usually, but not always, equivalent to a group. However, 460 -- this MIB does not use the term "channel" because there is no 461 -- requirement that an MTA supporting this MIB has to map its 462 -- "channel" abstraction one-to-one onto the MIB's group abstration. 464 -- An MTA may create a group or group of groups at any time. Once 465 -- created, however, an MTA cannot delete an entry for a group from 466 -- the group table. Deletation is only allowed when the MTA is 467 -- reinitialized, and is not required even then. This restriction 468 -- is imposed so that monitoring agents can rely on group 469 -- assignments being consistent across multiple query operations. 471 -- Groups may be laid out so as to form a hierarchical arrangement, 472 -- with some groups acting as subgroups for other groups. 473 -- Alternately, disjoint groups of groups may be used to provide 474 -- different sorts of "snapshots" of MTA operation. The 475 -- mtaGroupHierarchy variable provides an indication of how each 476 -- group fits into the overall arrangement being used. 478 mtaGroupTable OBJECT-TYPE 479 SYNTAX SEQUENCE OF MtaGroupEntry 480 MAX-ACCESS not-accessible 481 STATUS current 482 DESCRIPTION 483 "The table holding information specific to each MTA group." 484 ::= {mta 2} 486 mtaGroupEntry OBJECT-TYPE 487 SYNTAX MtaGroupEntry 488 MAX-ACCESS not-accessible 489 STATUS current 490 DESCRIPTION 491 "The entry associated with each MTA group." 492 INDEX {applIndex, mtaGroupIndex} 493 ::= {mtaGroupTable 1} 495 MtaGroupEntry ::= SEQUENCE { 496 mtaGroupIndex 497 INTEGER, 498 mtaGroupReceivedMessages 499 Counter32, 500 mtaGroupRejectedMessages 501 Counter32, 502 mtaGroupStoredMessages 503 Gauge32, 504 mtaGroupTransmittedMessages 505 Counter32, 506 mtaGroupReceivedVolume 507 Counter32, 508 mtaGroupStoredVolume 509 Gauge32, 510 mtaGroupTransmittedVolume 511 Counter32, 512 mtaGroupReceivedRecipients 513 Counter32, 514 mtaGroupStoredRecipients 515 Gauge32, 517 mtaGroupTransmittedRecipients 518 Counter32, 519 mtaGroupOldestMessageStored 520 TimeInterval, 521 mtaGroupInboundAssociations 522 Gauge32, 523 mtaGroupOutboundAssociations 524 Gauge32, 525 mtaGroupAccumulatedInboundAssociations 526 Counter32, 527 mtaGroupAccumulatedOutboundAssociations 528 Counter32, 529 mtaGroupLastInboundActivity 530 TimeInterval, 531 mtaGroupLastOutboundActivity 532 TimeInterval, 533 mtaGroupLastOutboundAssociationAttempt 534 TimeInterval, 535 mtaGroupRejectedInboundAssociations 536 Counter32, 537 mtaGroupFailedOutboundAssociations 538 Counter32, 539 mtaGroupInboundRejectionReason 540 DisplayString, 541 mtaGroupOutboundConnectFailureReason 542 DisplayString, 543 mtaGroupScheduledRetry 544 TimeInterval, 545 mtaGroupMailProtocol 546 OBJECT IDENTIFIER, 547 mtaGroupName 548 DisplayString, 549 mtaGroupSuccessfulConvertedMessages 550 Counter32, 551 mtaGroupFailedConvertedMessages 552 Counter32, 554 mtaGroupDescription 555 DisplayString, 556 mtaGroupURL 557 URLString, 558 mtaGroupCreationTime 559 TimeInterval, 560 mtaGroupHierarchy 561 INTEGER, 562 mtaGroupOldestMessageId 563 DisplayString, 564 mtaGroupLoopsDetected 565 Counter32 566 } 568 mtaGroupIndex OBJECT-TYPE 569 SYNTAX INTEGER (1..2147483647) 570 MAX-ACCESS not-accessible 571 STATUS current 572 DESCRIPTION 573 "The index associated with a group for a given MTA." 574 ::= {mtaGroupEntry 1} 576 mtaGroupReceivedMessages OBJECT-TYPE 577 SYNTAX Counter32 578 MAX-ACCESS read-only 579 STATUS current 580 DESCRIPTION 581 "The number of messages received to this group since 582 group creation." 583 ::= {mtaGroupEntry 2} 585 mtaGroupRejectedMessages OBJECT-TYPE 586 SYNTAX Counter32 587 MAX-ACCESS read-only 588 STATUS current 589 DESCRIPTION 590 "The number of messages rejected by this group since 591 group creation." 592 ::= {mtaGroupEntry 3} 594 mtaGroupStoredMessages OBJECT-TYPE 595 SYNTAX Gauge32 596 MAX-ACCESS read-only 597 STATUS current 598 DESCRIPTION 599 "The total number of messages currently stored in this 600 group's queue." 601 ::= {mtaGroupEntry 4} 603 mtaGroupTransmittedMessages OBJECT-TYPE 604 SYNTAX Counter32 605 MAX-ACCESS read-only 606 STATUS current 607 DESCRIPTION 608 "The number of messages transmitted by this group since 609 group creation." 610 ::= {mtaGroupEntry 5} 612 mtaGroupReceivedVolume OBJECT-TYPE 613 SYNTAX Counter32 614 UNITS "K-octets" 615 MAX-ACCESS read-only 616 STATUS current 617 DESCRIPTION 618 "The total volume of messages received to this group since 619 group creation, measured in kilo-octets. This volume 620 should include all transferred data that is logically above 621 the mail transport protocol level. For example, an 622 SMTP-based MTA should use the number of kilo-octets in the 623 message header and body, while an X.400-based MTA should use 624 the number of kilo-octets of P2 data." 625 ::= {mtaGroupEntry 6} 627 mtaGroupStoredVolume OBJECT-TYPE 628 SYNTAX Gauge32 629 UNITS "K-octets" 630 MAX-ACCESS read-only 631 STATUS current 632 DESCRIPTION 633 "The total volume of messages currently stored in this 634 group's queue, measured in kilo-octets. This volume should 635 include all stored data that is logically above the mail 636 transport protocol level. For example, an SMTP-based 637 MTA should use the number of kilo-octets in the message 638 header and body, while an X.400-based MTA would use the 639 number of kilo-octets of P2 data." 640 ::= {mtaGroupEntry 7} 642 mtaGroupTransmittedVolume OBJECT-TYPE 643 SYNTAX Counter32 644 UNITS "K-octets" 645 MAX-ACCESS read-only 646 STATUS current 647 DESCRIPTION 648 "The total volume of messages transmitted by this group 649 since group creation, measured in kilo-octets. This 650 volume should include all transferred data that is logically 651 above the mail transport protocol level. For example, an 652 SMTP-based MTA should use the number of kilo-octets in the 653 message header and body, while an X.400-based MTA should use 654 the number of kilo-octets of P2 data." 655 ::= {mtaGroupEntry 8} 657 mtaGroupReceivedRecipients OBJECT-TYPE 658 SYNTAX Counter32 659 MAX-ACCESS read-only 660 STATUS current 661 DESCRIPTION 662 "The total number of recipients specified in all messages 663 received to this group since group creation. 664 Recipients this MTA has no responsibility for should not 665 be counted." 666 ::= {mtaGroupEntry 9} 668 mtaGroupStoredRecipients OBJECT-TYPE 669 SYNTAX Gauge32 670 MAX-ACCESS read-only 671 STATUS current 672 DESCRIPTION 673 "The total number of recipients specified in all messages 674 currently stored in this group's queue. Recipients this 675 MTA has no responsibility for should not be counted." 676 ::= {mtaGroupEntry 10} 678 mtaGroupTransmittedRecipients OBJECT-TYPE 679 SYNTAX Counter32 680 MAX-ACCESS read-only 681 STATUS current 682 DESCRIPTION 683 "The total number of recipients specified in all messages 684 transmitted by this group since group creation. 685 Recipients this MTA had no responsibility for should not 686 be counted." 687 ::= {mtaGroupEntry 11} 689 mtaGroupOldestMessageStored OBJECT-TYPE 690 SYNTAX TimeInterval 691 MAX-ACCESS read-only 692 STATUS current 693 DESCRIPTION 694 "Time since the oldest message in this group's queue was 695 placed in the queue." 696 ::= {mtaGroupEntry 12} 698 mtaGroupInboundAssociations OBJECT-TYPE 699 SYNTAX Gauge32 700 MAX-ACCESS read-only 701 STATUS current 702 DESCRIPTION 703 "The number of current associations to the group, where the 704 group is the responder." 705 ::= {mtaGroupEntry 13} 707 mtaGroupOutboundAssociations 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 initiator." 714 ::= {mtaGroupEntry 14} 716 mtaGroupAccumulatedInboundAssociations OBJECT-TYPE 717 SYNTAX Counter32 718 MAX-ACCESS read-only 719 STATUS current 720 DESCRIPTION 721 "The total number of associations to the group since 722 group creation, where the MTA was the responder." 723 ::= {mtaGroupEntry 15} 725 mtaGroupAccumulatedOutboundAssociations OBJECT-TYPE 726 SYNTAX Counter32 727 MAX-ACCESS read-only 728 STATUS current 729 DESCRIPTION 730 "The total number of associations from the group since 731 group creation, where the MTA was the initiator." 732 ::= {mtaGroupEntry 16} 734 mtaGroupLastInboundActivity OBJECT-TYPE 735 SYNTAX TimeInterval 736 MAX-ACCESS read-only 737 STATUS current 738 DESCRIPTION 739 "Time since the last time that this group had an active 740 inbound association for purposes of message reception." 741 ::= {mtaGroupEntry 17} 743 mtaGroupLastOutboundActivity 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 a 749 successful outbound association for purposes of 750 message delivery." 751 ::= {mtaGroupEntry 18} 753 mtaGroupLastOutboundAssociationAttempt OBJECT-TYPE 754 SYNTAX TimeInterval 755 MAX-ACCESS read-only 756 STATUS current 757 DESCRIPTION 758 "Time since the last time that this group attempted 759 to make an outbound association for purposes of 760 message delivery." 761 ::= {mtaGroupEntry 34} 763 mtaGroupRejectedInboundAssociations OBJECT-TYPE 764 SYNTAX Counter32 765 MAX-ACCESS read-only 766 STATUS current 767 DESCRIPTION 768 "The total number of inbound associations the group has 769 rejected, since group creation. Rejected associations 770 are not counted in the accumulated association totals." 771 ::= {mtaGroupEntry 19} 773 mtaGroupFailedOutboundAssociations OBJECT-TYPE 774 SYNTAX Counter32 775 MAX-ACCESS read-only 776 STATUS current 777 DESCRIPTION 778 "The total number associations where the group was the 779 initiator and association establishment has failed, 780 since group creation. Failed associations are 781 not counted in the accumulated association totals." 782 ::= {mtaGroupEntry 20} 784 mtaGroupInboundRejectionReason OBJECT-TYPE 785 SYNTAX DisplayString 786 MAX-ACCESS read-only 787 STATUS current 788 DESCRIPTION 789 "The failure reason, if any, for the last association this 790 group refused to respond to. An empty string indicates that 791 the last attempt was successful. If no association attempt 792 has been made since the MTA was initialized the value 793 should be 'never'." 794 ::= {mtaGroupEntry 21} 796 mtaGroupOutboundConnectFailureReason OBJECT-TYPE 797 SYNTAX DisplayString 798 MAX-ACCESS read-only 799 STATUS current 800 DESCRIPTION 801 "The failure reason, if any, for the last association attempt 802 this group initiated. An empty string indicates that the last 803 attempt was successful. If no association attempt has been 804 made since the MTA was initialized the value should be 805 'never'." 806 ::= {mtaGroupEntry 22} 808 mtaGroupScheduledRetry OBJECT-TYPE 809 SYNTAX TimeInterval 810 MAX-ACCESS read-only 811 STATUS current 812 DESCRIPTION 813 "The time when this group is scheduled to next attempt to 814 make an association." 815 ::= {mtaGroupEntry 23} 817 mtaGroupMailProtocol OBJECT-TYPE 818 SYNTAX OBJECT IDENTIFIER 819 MAX-ACCESS read-only 820 STATUS current 821 DESCRIPTION 822 "An identification of the protocol being used by this group. 823 For an group employing OSI protocols, this will be the 824 Application Context. For Internet applications, the IANA 825 maintains a registry of the OIDs which correspond to well-known 826 message transfer protocols. If the application protocol is 827 not listed in the registry, an OID value of the form 828 {applTCPProtoID port} or {applUDProtoID port} are used for 829 TCP-based and UDP-based protocols, respectively. In either 830 case 'port' corresponds to the primary port number being 831 used by the group. applTCPProtoID and applUDPProtoID are 832 defined in [8]." 833 ::= {mtaGroupEntry 24} 835 mtaGroupName OBJECT-TYPE 836 SYNTAX DisplayString 837 MAX-ACCESS read-only 838 STATUS current 839 DESCRIPTION 840 "A descriptive name for the group. If this group connects to 841 a single remote MTA this should be the name of that MTA. If 842 this in turn is an Internet MTA this should be the domain 843 name. For an OSI MTA it should be the string encoded 844 distinguished name of the managed object using the format 845 defined in RFC 1779 [9]. For X.400(1984) MTAs which do not 846 have a Distinguished Name, the RFC 1327 [12] syntax 847 'mta in globalid' should be used." 848 ::= {mtaGroupEntry 25} 850 mtaGroupSuccessfulConvertedMessages OBJECT-TYPE 851 SYNTAX Counter32 852 MAX-ACCESS read-only 853 STATUS current 854 DESCRIPTION 855 "The number of messages that have been successfully 856 converted from one form to another in this group 857 since group creation." 858 ::= {mtaGroupEntry 26} 860 mtaGroupFailedConvertedMessages OBJECT-TYPE 861 SYNTAX Counter32 862 MAX-ACCESS read-only 863 STATUS current 864 DESCRIPTION 865 "The number of messages for which an unsuccessful 866 attempt was made to convert them from one form to 867 another in this group since group creation." 868 ::= {mtaGroupEntry 27} 870 mtaGroupDescription OBJECT-TYPE 871 SYNTAX DisplayString 872 MAX-ACCESS read-only 873 STATUS current 874 DESCRIPTION 875 "A description of the group's purpose. This information is 876 intended to identify the group in a status display." 877 ::= {mtaGroupEntry 28} 879 mtaGroupURL OBJECT-TYPE 880 SYNTAX URLString 881 MAX-ACCESS read-only 882 STATUS current 883 DESCRIPTION 884 "A URL pointing to a description of the group. This 885 information is intended to identify and briefly describe 886 the group in a status display." 887 ::= {mtaGroupEntry 29} 889 mtaGroupCreationTime OBJECT-TYPE 890 SYNTAX TimeInterval 891 MAX-ACCESS read-only 892 STATUS current 893 DESCRIPTION 894 "Time since this group was first created." 895 ::= {mtaGroupEntry 30} 897 mtaGroupHierarchy OBJECT-TYPE 898 SYNTAX INTEGER (-2147483648..2147483647) 899 MAX-ACCESS read-only 900 STATUS current 901 DESCRIPTION 902 "Describes how this group fits into the hierarchy. A 903 positive value is interpreted as an mtaGroupIndex 904 value for some other group whose variables include 905 those of this group (and usually others). A negative 906 value is interpreted as a group collection code: Groups 907 with common negative hierarchy values comprise one 908 particular breakdown of MTA activity as a whole. A 909 zero value means that this MIB implementation doesn't 910 implement hierarchy indicators and thus the overall 911 group hierarchy cannot be determined." 912 ::= {mtaGroupEntry 31} 914 mtaGroupOldestMessageId OBJECT-TYPE 915 SYNTAX DisplayString 916 MAX-ACCESS read-only 917 STATUS current 918 DESCRIPTION 919 "Message ID of the oldest message in the group's queue. 920 Whenever possible this should be in the form of an 921 RFC 822 [13] msg-id; X.400 may convert X.400 message 922 identifiers to this form by following the rules laid 923 out in RFC1327 [12]." 924 ::= {mtaGroupEntry 32} 926 mtaGroupLoopsDetected OBJECT-TYPE 927 SYNTAX Counter32 928 MAX-ACCESS read-only 929 STATUS current 930 DESCRIPTION 931 "A message loop is defined as a situation where the MTA 932 decides that a given message will never be delivered to 933 one or more recipients and instead will continue to 934 loop endlessly through one or more MTAs. This variable 935 counts the number of times the MTA has detected such a 936 situation in conjunction with something associated with 937 this group since group creation. Note that the 938 mechanism MTAs use to detect loops (e.g. trace field 939 counting, count of references to this MTA in a trace 940 field, examination of DNS or other directory information, 941 etc.), the level at which loops are detected (e.g. per 942 message, per recipient, per directory entry, etc.), and 943 the handling of a loop once it is detected (e.g. looping 944 messages are held, looping messages are bounced or sent 945 to the postmaster, messages that the MTA knows will loop 946 won't be accepted, etc.) vary widely from one MTA to the 947 next and cannot be inferred from this variable." 948 ::= {mtaGroupEntry 33} 950 -- The mtaGroupAssociationTable provides a means of correlating 951 -- entries in the network services association table with the 952 -- MTA group responsible for the association. 954 mtaGroupAssociationTable OBJECT-TYPE 955 SYNTAX SEQUENCE OF MtaGroupAssociationEntry 956 MAX-ACCESS not-accessible 957 STATUS current 958 DESCRIPTION 959 "The table holding information regarding the associations 960 for each MTA group." 961 ::= {mta 3} 963 mtaGroupAssociationEntry OBJECT-TYPE 964 SYNTAX MtaGroupAssociationEntry 965 MAX-ACCESS not-accessible 966 STATUS current 967 DESCRIPTION 968 "The entry holding information regarding the associations 969 for each MTA group." 970 INDEX {applIndex, mtaGroupIndex, mtaGroupAssociationIndex} 971 ::= {mtaGroupAssociationTable 1} 973 MtaGroupAssociationEntry ::= SEQUENCE { 974 mtaGroupAssociationIndex 975 INTEGER 976 } 978 mtaGroupAssociationIndex OBJECT-TYPE 979 SYNTAX INTEGER (1..2147483647) 980 MAX-ACCESS read-only 981 STATUS current 982 DESCRIPTION 983 "Reference into association table to allow correlation of 984 this group's active associations with the association table." 985 ::= {mtaGroupAssociationEntry 1} 987 -- The mtaGroupErrorTable gives each group a way of tallying 988 -- the specific errors it has encountered. The mechanism 989 -- defined here uses RFC 1893 [14] status codes to identify 990 -- various specific errors. There are also classes for generic 991 -- errors of various sorts, and the entire mechanism is also 992 -- extensible, in that new error codes can be defined at any 993 -- time. 995 mtaGroupErrorTable OBJECT-TYPE 996 SYNTAX SEQUENCE OF MtaGroupErrorEntry 997 MAX-ACCESS not-accessible 998 STATUS current 999 DESCRIPTION 1000 "The table holding information regarding accumulated errors 1001 for each MTA group." 1002 ::= {mta 5} 1004 mtaGroupErrorEntry OBJECT-TYPE 1005 SYNTAX MtaGroupErrorEntry 1006 MAX-ACCESS not-accessible 1007 STATUS current 1008 DESCRIPTION 1009 "The entry holding information regarding accumulated 1010 errors for each MTA group." 1011 INDEX {applIndex, mtaGroupIndex, mtaStatusCode} 1012 ::= {mtaGroupErrorTable 1} 1014 MtaGroupErrorEntry ::= SEQUENCE { 1015 mtaGroupInboundErrorCount 1016 Counter32, 1017 mtaGroupInternalErrorCount 1018 Counter32, 1019 mtaGroupOutboundErrorCount 1020 Counter32 1021 } 1023 mtaGroupInboundErrorCount OBJECT-TYPE 1024 SYNTAX Counter32 1025 MAX-ACCESS read-only 1026 STATUS current 1027 DESCRIPTION 1028 "Count of the number of errors of a given type that have 1029 been accumulated in assocation with a particular group 1030 while processing incoming messages. In the case of SMTP 1031 these will typically be errors reporting by an SMTP 1032 server to the remote client; in the case of X.400 1033 these will typically be errors encountered while 1034 processing an incoming message." 1035 ::= {mtaGroupErrorEntry 1} 1037 mtaGroupInternalErrorCount OBJECT-TYPE 1038 SYNTAX Counter32 1039 MAX-ACCESS read-only 1040 STATUS current 1041 DESCRIPTION 1042 "Count of the number of errors of a given type that have 1043 been accumulated in assocation with a particular group 1044 during internal MTA processing." 1045 ::= {mtaGroupErrorEntry 2} 1047 mtaGroupOutboundErrorCount OBJECT-TYPE 1048 SYNTAX Counter32 1049 MAX-ACCESS read-only 1050 STATUS current 1051 DESCRIPTION 1052 "Count of the number of errors of a given type that have 1053 been accumulated in assocation with a particular group's 1054 outbound connection activities. In the case of an SMTP 1055 client these will typically be errors reported while 1056 attempting to contact or while communicating with the 1057 remote SMTP server. In the case of X.400 these will 1058 typically be errors encountered while constructing 1059 or attempting to deliver an outgoing message." 1060 ::= {mtaGroupErrorEntry 3} 1062 -- Conformance information 1064 mtaConformance OBJECT IDENTIFIER ::= {mta 4} 1066 mtaGroups OBJECT IDENTIFIER ::= {mtaConformance 1} 1067 mtaCompliances OBJECT IDENTIFIER ::= {mtaConformance 2} 1069 -- Compliance statements 1071 mtaCompliance MODULE-COMPLIANCE 1072 STATUS current 1073 DESCRIPTION 1074 "The compliance statement for SNMPv2 entities which 1075 implement the Mail Monitoring MIB for basic 1076 monitoring of MTAs." 1077 MODULE -- this module 1078 MANDATORY-GROUPS {mtaGroup} 1079 ::= {mtaCompliances 1} 1081 mtaAssocCompliance MODULE-COMPLIANCE 1082 STATUS current 1083 DESCRIPTION 1084 "The compliance statement for SNMPv2 entities which 1085 implement the Mail Monitoring MIB for monitoring of 1086 MTAs and their associations." 1087 MODULE -- this module 1088 MANDATORY-GROUPS {mtaGroup, mtaAssocGroup} 1089 ::= {mtaCompliances 2} 1091 mtaErrorCompliance MODULE-COMPLIANCE 1092 STATUS current 1093 DESCRIPTION 1094 "The compliance statement for SNMPv2 entities which 1095 implement the Mail Monitoring MIB for monitoring of 1096 MTAs and detailed errors." 1097 MODULE -- this module 1098 MANDATORY-GROUPS {mtaGroup, mtaErrorGroup} 1099 ::= {mtaCompliances 3} 1101 mtaFullCompliance MODULE-COMPLIANCE 1102 STATUS current 1103 DESCRIPTION 1104 "The compliance statement for SNMPv2 entities which 1105 implement the full Mail Monitoring MIB for monitoring 1106 of MTAs, associations, and detailed errors." 1107 MODULE -- this module 1108 MANDATORY-GROUPS {mtaGroup, mtaAssocGroup, mtaErrorGroup} 1109 ::= {mtaCompliances 4} 1111 -- Units of conformance 1113 mtaGroup OBJECT-GROUP 1114 OBJECTS { 1115 mtaReceivedMessages, mtaStoredMessages, 1116 mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume, 1117 mtaTransmittedVolume, mtaReceivedRecipients, 1118 mtaStoredRecipients, mtaTransmittedRecipients, 1119 mtaSuccessfulConvertedMessages, mtaFailedConvertedMessages, 1120 mtaGroupReceivedMessages, mtaGroupRejectedMessages, 1121 mtaGroupStoredMessages, mtaGroupTransmittedMessages, 1122 mtaGroupReceivedVolume, mtaGroupStoredVolume, 1123 mtaGroupTransmittedVolume, mtaGroupReceivedRecipients, 1124 mtaGroupStoredRecipients, mtaGroupTransmittedRecipients, 1125 mtaGroupOldestMessageStored, mtaGroupInboundAssociations, 1126 mtaGroupOutboundAssociations, mtaLoopsDetected, 1127 mtaGroupAccumulatedInboundAssociations, 1128 mtaGroupAccumulatedOutboundAssociations, 1129 mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity, 1130 mtaGroupLastOutboundAssociationAttempt, 1131 mtaGroupRejectedInboundAssociations, 1132 mtaGroupFailedOutboundAssociations, 1133 mtaGroupInboundRejectionReason, 1134 mtaGroupOutboundConnectFailureReason, 1135 mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName, 1136 mtaGroupSuccessfulConvertedMessages, 1137 mtaGroupFailedConvertedMessages, mtaGroupDescription, 1138 mtaGroupURL, mtaGroupCreationTime, mtaGroupHierarchy, 1139 mtaGroupOldestMessageId, mtaGroupLoopsDetected} 1140 STATUS current 1141 DESCRIPTION 1142 "A collection of objects providing basic monitoring of MTAs." 1143 ::= {mtaGroups 1} 1145 mtaAssocGroup OBJECT-GROUP 1146 OBJECTS { 1147 mtaGroupAssociationIndex} 1148 STATUS current 1149 DESCRIPTION 1150 "A collection of objects providing monitoring of MTA 1151 associations." 1152 ::= {mtaGroups 2} 1154 mtaErrorGroup OBJECT-GROUP 1155 OBJECTS { 1156 mtaGroupInboundErrorCount, mtaGroupInternalErrorCount, 1157 mtaGroupOutboundErrorCount} 1158 STATUS current 1159 DESCRIPTION 1160 "A collection of objects providing monitoring of 1161 detailed MTA errors." 1162 ::= {mtaGroups 3} 1164 END 1166 7. Changes made since RFC 1566 1168 The only changes made to this document since it was issued as RFC 1566 1169 [11] are the following: 1171 (1) A number of DESCRIPTION fields have been reworded, hopefully 1172 making them clearer. 1174 (2) mtaGroupDescription and mtaGroupURL fields have been added. 1175 These fields are intended to identify and describe the MTA and 1176 the various MTA groups. 1178 (3) The time since the last outbound association attempt is now 1179 distinct from the time since the last successfuol outbound 1180 association attempt. 1182 (4) Conversion operation counters have been added. 1184 (5) A mechanism to explicitly describe group hierarchies has been 1185 added. 1187 (6) A mechanism to count specific sorts of errors has been added. 1189 (7) A field for the ID of the oldest message in a group's queue has 1190 been added. 1192 (8) Per-MTA and per-group message loop counters have been added. 1194 (9) A new table has been added to keep track of any errors an MTA 1195 encounters. 1197 8. Acknowledgements 1199 This document is a work product of the Mail and Directory Management 1200 (MADMAN) Working Group of the IETF. It is based on an earlier MIB 1201 designed by S. Kille, T. Lenggenhager, D. Partain, and W. Yeong. The 1202 Electronic Mail Association's TSC committee was instrumental in 1203 providing feedback on and suggesting enhancements to RFC 1566 [11] that 1204 have led to the present document. 1206 9. References 1208 [1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure 1209 of Management Information for Version 2 of the Simple Network 1210 Management Protocol (SNMPv2)", RFC 1902, January 1996. 1212 [2] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Textual 1213 Conventions for Version 2 of the Simple Network Management Protocol 1214 (SNMPv2)", RFC 1903, January 1996. 1216 [3] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Conformance 1217 Statements for Version 2 of the Simple Network Management Protocol 1218 (SNMPv2)", RFC 1904, January 1996. 1220 [4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol 1221 Operations for Version 2 of the Simple Network Management Protocol 1222 (SNMPv2)", RFC 1905, January 1996. 1224 [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport 1225 Mappings for Version 2 of the Simple Network Management Protocol 1226 (SNMPv2)", RFC 1906, January 1996. 1228 [6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management 1229 Information Base for Version 2 of the Simple Network Management 1230 Protocol (SNMPv2)", RFC 1907, January 1996. 1232 [7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., 1233 "Coexistence between Version 1 and Version 2 of the Internet- 1234 standard Network Management Framework", RFC 1908, January 1996. 1236 [8] Freed, N., Kille, S., "The Network Services Monitoring MIB", 1237 Internet Draft, March 1997. 1239 [9] Kille, S., "A String Representation of Distinguished Names", RFC 1240 1779, March 1995. 1242 [10] Berners-Lee, T., Masinter, L., McCahill, M., iform Resource 1243 Locators (URL)", RFC 1738, December 1994. 1245 [11] Freed, N., Kille, S., "Mail Monitoring MIB", RFC 1566, January 1246 1994. 1248 [12] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", 1249 RFC 1327, May 1992. 1251 [13] Crocker, D., "Standard for the Format of ARPA Internet Text 1252 Message", RFC 822, August 1982. 1254 [14] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, Octel 1255 Network Services, January 1996. 1257 10. Security Considerations 1259 This MIB does not offer write access, and as such cannot be used to 1260 actively attack a system. However, this MIB does provide passive 1261 information about the existance, type, and configuration of applications 1262 on a given host that could potentially indicate some sort of 1263 vulnerability. Finally, the information MIB provides about network usage 1264 could be used to analyze network traffic patterns. 1266 11. Author and Chair Addresses 1268 Ned Freed 1269 Innosoft International, Inc. 1270 1050 Lakes Drive 1271 West Covina, CA 91790 1272 USA 1273 tel: +1 626 919 3600 1274 fax: +1 626 919 3614 1275 email: ned.freed@innosoft.com 1277 Steve Kille, MADMAN WG Chair 1278 ISODE Consortium 1279 The Dome, The Square 1280 Richmond TW9 1DT 1281 UK 1282 tel: +44 181 332 9091 1283 email: S.Kille@isode.com