idnits 2.17.1 draft-ietf-madman-mail-monitor-mib-03.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-23) 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. 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 (March 1997) is 9901 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 1241, 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 (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ned Freed 3 Internet Draft 5 Mail Monitoring MIB 7 March 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 149 FROM SNMPv2-SMI 150 DisplayString, TimeInterval 151 FROM SNMPv2-TC 152 MODULE-COMPLIANCE, OBJECT-GROUP 153 FROM SNMPv2-CONF 154 mib-2 155 FROM RFC1213-MIB 156 applIndex, URLString 157 FROM NETWORK-SERVICES-MIB 159 -- Textual conventions 160 mta MODULE-IDENTITY 161 LAST-UPDATED "9703020000Z" 162 ORGANIZATION "IETF Mail and Directory Management Working Group" 163 CONTACT-INFO 164 " Ned Freed 166 Postal: Innosoft International, Inc. 167 1050 East Garvey Avenue South 168 West Covina, CA 91790 169 US 171 Tel: +1 818 919 3600 172 Fax: +1 818 919 3614 174 E-Mail: ned@innosoft.com" 175 DESCRIPTION 176 "The MIB module describing Message Transfer Agents (MTAs)" 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." 207 mtaEntry OBJECT-TYPE 208 SYNTAX MtaEntry 209 MAX-ACCESS not-accessible 210 STATUS current 211 DESCRIPTION 212 "The entry associated with each MTA." 213 INDEX {applIndex} 214 ::= {mtaTable 1} 216 MtaEntry ::= SEQUENCE { 217 mtaReceivedMessages 218 Counter32, 219 mtaStoredMessages 220 Gauge32, 221 mtaTransmittedMessages 222 Counter32, 223 mtaReceivedVolume 224 Counter32, 225 mtaStoredVolume 226 Gauge32, 227 mtaTransmittedVolume 228 Counter32, 229 mtaReceivedRecipients 230 Counter32, 231 mtaStoredRecipients 232 Gauge32, 233 mtaTransmittedRecipients 234 Counter32, 235 mtaSuccessfulConvertedMessages 236 Counter32, 237 mtaFailedConvertedMessages 238 Counter32, 239 mtaLoopsDetected 240 Counter32, 241 } 242 mtaReceivedMessages OBJECT-TYPE 243 SYNTAX Counter32 244 MAX-ACCESS read-only 245 STATUS current 246 DESCRIPTION 247 "The number of messages received since MTA initialization. 248 This includes messages transmitted to this MTA from other 249 MTAs as well as messages that have been submitted to the 250 MTA directly by end-users or applications." 251 ::= {mtaEntry 1} 253 mtaStoredMessages OBJECT-TYPE 254 SYNTAX Gauge32 255 MAX-ACCESS read-only 256 STATUS current 257 DESCRIPTION 258 "The total number of messages currently stored in the MTA. 259 This includes messages that are awaiting transmission to 260 some other MTA or are waiting for delivery to an end-user 261 or application." 262 ::= {mtaEntry 2} 264 mtaTransmittedMessages OBJECT-TYPE 265 SYNTAX Counter32 266 MAX-ACCESS read-only 267 STATUS current 268 DESCRIPTION 269 "The number of messages transmitted since MTA initialization. 270 This includes messages that were transmitted to some other 271 MTA or are waiting for delivery to an end-user or 272 application." 273 ::= {mtaEntry 3} 275 mtaReceivedVolume OBJECT-TYPE 276 SYNTAX Counter32 277 UNITS "K-octets" 278 MAX-ACCESS read-only 279 STATUS current 280 DESCRIPTION 281 "The total volume of messages received since MTA 282 initialization, measured in kilo-octets. This volume should 283 include all transferred data that is logically above the mail 284 transport protocol level. For example, an SMTP-based MTA 285 should use the number of kilo-octets in the message header 286 and body, while an X.400-based MTA should use the number of 287 kilo-octets of P2 data. This includes messages transmitted 288 to this MTA from other MTAs as well as messages that have 289 been submitted to the MTA directly by end-users or 290 applications." 291 ::= {mtaEntry 4} 293 mtaStoredVolume OBJECT-TYPE 294 SYNTAX Gauge32 295 UNITS "K-octets" 296 MAX-ACCESS read-only 297 STATUS current 298 DESCRIPTION 299 "The total volume of messages currently stored in the MTA, 300 measured in kilo-octets. This volume should include all 301 stored data that is logically above the mail transport 302 protocol level. For example, an SMTP-based MTA should 303 use the number of kilo-octets in the message header and 304 body, while an X.400-based MTA would use the number of 305 kilo-octets of P2 data. This includes messages that are 306 awaiting transmission to some other MTA or are waiting 307 for delivery to an end-user or application." 308 ::= {mtaEntry 5} 310 mtaTransmittedVolume OBJECT-TYPE 311 SYNTAX Counter32 312 UNITS "K-octets" 313 MAX-ACCESS read-only 314 STATUS current 315 DESCRIPTION 316 "The total volume of messages transmitted since MTA 317 initialization, measured in kilo-octets. This volume should 318 include all transferred data that is logically above the mail 319 transport protocol level. For example, an SMTP-based MTA 320 should use the number of kilo-octets in the message header 321 and body, while an X.400-based MTA should use the number of 322 kilo-octets of P2 data. This includes messages that were 323 transmitted to some other MTA or are waiting for delivery 324 to an end-user or application." 325 ::= {mtaEntry 6} 327 mtaReceivedRecipients OBJECT-TYPE 328 SYNTAX Counter32 329 MAX-ACCESS read-only 330 STATUS current 331 DESCRIPTION 332 "The total number of recipients specified in all messages 333 received since MTA initialization. Recipients this MTA 334 has no responsibility for, i.e. inactive envelope 335 recipients or ones referred to in message headers, 336 should not be counted even if information about such 337 recipients is available. This includes messages 338 transmitted to this MTA from other MTAs as well as 339 messages that have been submitted to the MTA directly 340 by end-users or applications." 341 ::= {mtaEntry 7} 343 mtaStoredRecipients OBJECT-TYPE 344 SYNTAX Gauge32 345 MAX-ACCESS read-only 346 STATUS current 347 DESCRIPTION 348 "The total number of recipients specified in all messages 349 currently stored in the MTA. Recipients this MTA has no 350 responsibility for, i.e. inactive envelope recipients or 351 ones referred to in message headers, should not be 352 counted. This includes messages that are awaiting 353 transmission to some other MTA or are waiting for 354 delivery to an end-user or application." 355 ::= {mtaEntry 8} 357 mtaTransmittedRecipients OBJECT-TYPE 358 SYNTAX Counter32 359 MAX-ACCESS read-only 360 STATUS current 361 DESCRIPTION 362 "The total number of recipients specified in all messages 363 transmitted since MTA initialization. Recipients this 364 MTA had no responsibility for, i.e. inactive envelope 365 recipients or ones referred to in message headers, 366 should not be counted. This includes messages that were 367 transmitted to some other MTA or are waiting for 368 delivery to an end-user or application." 369 ::= {mtaEntry 9} 371 mtaSuccessfulConvertedMessages OBJECT-TYPE 372 SYNTAX Counter32 373 MAX-ACCESS read-only 374 STATUS current 375 DESCRIPTION 376 "The number of messages that have been successfully 377 converted from one form to another since MTA 378 initialization." 379 ::= {mtaEntry 10} 381 mtaFailedConvertedMessages OBJECT-TYPE 382 SYNTAX Counter32 383 MAX-ACCESS read-only 384 STATUS current 385 DESCRIPTION 386 "The number of messages for which an unsuccessful 387 attempt was made to convert them from one form to 388 another since MTA initialization." 389 ::= {mtaEntry 11} 391 mtaLoopsDetected OBJECT-TYPE 392 SYNTAX Counter32 393 MAX-ACCESS read-only 394 STATUS current 395 DESCRIPTION 396 "A message loop is defined as a situation where the MTA 397 decides that a given message will never be delivered to 398 one or more recipients and instead will continue to 399 loop endlessly through one or more MTAs. This variable 400 counts the number of times the MTA has detected such a 401 situation since MTA initialization. Note that the 402 mechanism MTAs use to detect loops (e.g. trace field 403 counting, count of references to this MTA in a trace 404 field, examination of DNS or other directory information, 405 etc.), the level at which loops are detected (e.g. per 406 message, per recipient, per directory entry, etc.), and 407 the handling of a loop once it is detected (e.g. looping 408 messages are held, looping messages are bounced or sent 409 to the postmaster, messages that the MTA knows will loop 410 won't be accepted, etc.) vary widely from one MTA to the 411 next and cannot be inferred from this variable." 412 ::= {mtaEntry 12} 414 -- MTAs typically group inbound reception, queue storage, and 415 -- outbound transmission in some way, rather than accounting for 416 -- such operations only across the MTA as a whole. In the most 417 -- extreme case separate information will be maintained for each 418 -- different entity that receives messages and for each entity 419 -- the MTA stores messages for and delivers messages to. Other 420 -- MTAs may elect to treat all reception equally, all queue 421 -- storage equally, all deliveries equally, or some combination 422 -- of this. Overlapped groupings are also possible, where an MTA 423 -- decomposes its traffic in different ways for different 424 -- purposes. 426 -- In any case, a grouping abstraction is an extremely useful for 427 -- breaking down the activities of an MTA. For purposes of 428 -- labelling this will be called a "group" in this MIB. 430 -- Each group contains all the variables needed to monitor all 431 -- aspects of an MTA's operation. However, the fact that all 432 -- groups contain all possible variables does not imply that all 433 -- groups must use all possible variables. For example, a single 434 -- group might be used to monitor only one kind of event (inbound 435 -- processing, outbound processing, or storage). In this sort of 436 -- configuration all unused counters would be inaccessible; e.g., 437 -- returning either a noSuchName error (for an SNMPv1 get), or a 438 -- noSuchInstance exception (for an SNMPv2 get). 440 -- Groups can be created at any time after MTA initialization. Once 441 -- a group is created it should not be deleted or its mtaGroupIndex 442 -- changed unless the MTA is reinitialized. 444 -- Groups are not necessarily mutually exclusive. A given event may 445 -- be recorded by more than one group, a message may be seen as 446 -- stored by more than one group, and so on. Groups should be all 447 -- inclusive, however: if groups are implemented all aspects of an 448 -- MTA's operation should be registered in at least one group. This 449 -- freedom lets implementors use different sets of groups to 450 -- provide differents "views" of an MTA. 452 -- The possibility of overlap between groups means that summing 453 -- variables across groups may not produce values equal to those in 454 -- the mtaTable. mtaTable should always provide accurate information 455 -- about the MTA as a whole. 457 -- The term "channel" is often used in MTA implementations; channels 458 -- are usually, but not always, equivalent to a group. However, 459 -- this MIB does not use the term "channel" because there is no 460 -- requirement that an MTA supporting this MIB has to map its 461 -- "channel" abstraction one-to-one onto the MIB's group abstration. 463 -- An MTA may create a group or group of groups at any time. Once 464 -- created, however, an MTA cannot delete an entry for a group from 465 -- the group table. Deletation is only allowed when the MTA is 466 -- reinitialized, and is not required even then. This restriction 467 -- is imposed so that monitoring agents can rely on group 468 -- assignments being consistent across multiple query operations. 470 -- Groups may be laid out so as to form a hierarchical arrangement, 471 -- with some groups acting as subgroups for other groups. 472 -- Alternately, disjoint groups of groups may be used to provide 473 -- different sorts of "snapshots" of MTA operation. The 474 -- mtaGroupHierarchy variable provides an indication of how each 475 -- group fits into the overall arrangement being used. 477 mtaGroupTable OBJECT-TYPE 478 SYNTAX SEQUENCE OF MtaGroupEntry 479 MAX-ACCESS not-accessible 480 STATUS current 481 DESCRIPTION 482 "The table holding information specific to each MTA group." 483 ::= {mta 2} 485 mtaGroupEntry OBJECT-TYPE 486 SYNTAX MtaGroupEntry 487 MAX-ACCESS not-accessible 488 STATUS current 489 DESCRIPTION 490 "The entry associated with each MTA group." 491 INDEX {applIndex, mtaGroupIndex} 492 ::= {mtaGroupTable 1} 494 MtaGroupEntry ::= SEQUENCE { 495 mtaGroupIndex 496 INTEGER, 497 mtaGroupReceivedMessages 498 Counter32, 499 mtaGroupRejectedMessages 500 Counter32, 501 mtaGroupStoredMessages 502 Gauge32, 503 mtaGroupTransmittedMessages 504 Counter32, 505 mtaGroupReceivedVolume 506 Counter32, 507 mtaGroupStoredVolume 508 Gauge32, 509 mtaGroupTransmittedVolume 510 Counter32, 511 mtaGroupReceivedRecipients 512 Counter32, 513 mtaGroupStoredRecipients 514 Gauge32, 516 mtaGroupTransmittedRecipients 517 Counter32, 518 mtaGroupOldestMessageStored 519 TimeInterval, 520 mtaGroupInboundAssociations 521 Gauge32, 522 mtaGroupOutboundAssociations 523 Gauge32, 524 mtaGroupAccumulatedInboundAssociations 525 Counter32, 526 mtaGroupAccumulatedOutboundAssociations 527 Counter32, 528 mtaGroupLastInboundActivity 529 TimeInterval, 530 mtaGroupLastOutboundActivity 531 TimeInterval, 532 mtaGroupLastOutboundAssociationAttempt 533 TimeInterval, 534 mtaGroupRejectedInboundAssociations 535 Counter32, 536 mtaGroupFailedOutboundAssociations 537 Counter32, 538 mtaGroupInboundRejectionReason 539 DisplayString, 540 mtaGroupOutboundConnectFailureReason 541 DisplayString, 542 mtaGroupScheduledRetry 543 TimeInterval, 544 mtaGroupMailProtocol 545 OBJECT IDENTIFIER, 546 mtaGroupName 547 DisplayString, 548 mtaGroupSuccessfulConvertedMessages 549 Counter32, 550 mtaGroupFailedConvertedMessages 551 Counter32, 553 mtaGroupDescription 554 DisplayString, 555 mtaGroupURL 556 URLString, 557 mtaGroupCreationTime 558 TimeInterval, 559 mtaGroupHierarchy 560 INTEGER, 561 mtaGroupOldestMessageId 562 DisplayString, 563 mtaGroupLoopsDetected 564 Counter32 565 } 567 mtaGroupIndex OBJECT-TYPE 568 SYNTAX INTEGER (1..2147483647) 569 MAX-ACCESS not-accessible 570 STATUS current 571 DESCRIPTION 572 "The index associated with a group for a given MTA." 573 ::= {mtaGroupEntry 1} 575 mtaGroupReceivedMessages OBJECT-TYPE 576 SYNTAX Counter32 577 MAX-ACCESS read-only 578 STATUS current 579 DESCRIPTION 580 "The number of messages received to this group since 581 group creation." 582 ::= {mtaGroupEntry 2} 584 mtaGroupRejectedMessages OBJECT-TYPE 585 SYNTAX Counter32 586 MAX-ACCESS read-only 587 STATUS current 588 DESCRIPTION 589 "The number of messages rejected by this group since 590 group creation." 591 ::= {mtaGroupEntry 3} 593 mtaGroupStoredMessages OBJECT-TYPE 594 SYNTAX Gauge32 595 MAX-ACCESS read-only 596 STATUS current 597 DESCRIPTION 598 "The total number of messages currently stored in this 599 group's queue." 600 ::= {mtaGroupEntry 4} 602 mtaGroupTransmittedMessages OBJECT-TYPE 603 SYNTAX Counter32 604 MAX-ACCESS read-only 605 STATUS current 606 DESCRIPTION 607 "The number of messages transmitted by this group since 608 group creation." 609 ::= {mtaGroupEntry 5} 611 mtaGroupReceivedVolume OBJECT-TYPE 612 SYNTAX Counter32 613 UNITS "K-octets" 614 MAX-ACCESS read-only 615 STATUS current 616 DESCRIPTION 617 "The total volume of messages received to this group since 618 group creation, measured in kilo-octets. This volume 619 should include all transferred data that is logically above 620 the mail transport protocol level. For example, an 621 SMTP-based MTA should use the number of kilo-octets in the 622 message header and body, while an X.400-based MTA should use 623 the number of kilo-octets of P2 data." 624 ::= {mtaGroupEntry 6} 626 mtaGroupStoredVolume OBJECT-TYPE 627 SYNTAX Gauge32 628 UNITS "K-octets" 629 MAX-ACCESS read-only 630 STATUS current 631 DESCRIPTION 632 "The total volume of messages currently stored in this 633 group's queue, measured in kilo-octets. This volume should 634 include all stored data that is logically above the mail 635 transport protocol level. For example, an SMTP-based 636 MTA should use the number of kilo-octets in the message 637 header and body, while an X.400-based MTA would use the 638 number of kilo-octets of P2 data." 639 ::= {mtaGroupEntry 7} 641 mtaGroupTransmittedVolume OBJECT-TYPE 642 SYNTAX Counter32 643 UNITS "K-octets" 644 MAX-ACCESS read-only 645 STATUS current 646 DESCRIPTION 647 "The total volume of messages transmitted by this group 648 since group creation, measured in kilo-octets. This 649 volume should include all transferred data that is logically 650 above the mail transport protocol level. For example, an 651 SMTP-based MTA should use the number of kilo-octets in the 652 message header and body, while an X.400-based MTA should use 653 the number of kilo-octets of P2 data." 654 ::= {mtaGroupEntry 8} 656 mtaGroupReceivedRecipients OBJECT-TYPE 657 SYNTAX Counter32 658 MAX-ACCESS read-only 659 STATUS current 660 DESCRIPTION 661 "The total number of recipients specified in all messages 662 received to this group since group creation. 663 Recipients this MTA has no responsibility for should not 664 be counted." 665 ::= {mtaGroupEntry 9} 667 mtaGroupStoredRecipients OBJECT-TYPE 668 SYNTAX Gauge32 669 MAX-ACCESS read-only 670 STATUS current 671 DESCRIPTION 672 "The total number of recipients specified in all messages 673 currently stored in this group's queue. Recipients this 674 MTA has no responsibility for should not be counted." 675 ::= {mtaGroupEntry 10} 677 mtaGroupTransmittedRecipients OBJECT-TYPE 678 SYNTAX Counter32 679 MAX-ACCESS read-only 680 STATUS current 681 DESCRIPTION 682 "The total number of recipients specified in all messages 683 transmitted by this group since group creation. 684 Recipients this MTA had no responsibility for should not 685 be counted." 686 ::= {mtaGroupEntry 11} 688 mtaGroupOldestMessageStored OBJECT-TYPE 689 SYNTAX TimeInterval 690 MAX-ACCESS read-only 691 STATUS current 692 DESCRIPTION 693 "Time since the oldest message in this group's queue was 694 placed in the queue." 695 ::= {mtaGroupEntry 12} 697 mtaGroupInboundAssociations OBJECT-TYPE 698 SYNTAX Gauge32 699 MAX-ACCESS read-only 700 STATUS current 701 DESCRIPTION 702 "The number of current associations to the group, where the 703 group is the responder." 704 ::= {mtaGroupEntry 13} 706 mtaGroupOutboundAssociations OBJECT-TYPE 707 SYNTAX Gauge32 708 MAX-ACCESS read-only 709 STATUS current 710 DESCRIPTION 711 "The number of current associations to the group, where the 712 group is the initiator." 713 ::= {mtaGroupEntry 14} 715 mtaGroupAccumulatedInboundAssociations OBJECT-TYPE 716 SYNTAX Counter32 717 MAX-ACCESS read-only 718 STATUS current 719 DESCRIPTION 720 "The total number of associations to the group since 721 group creation, where the MTA was the responder." 722 ::= {mtaGroupEntry 15} 724 mtaGroupAccumulatedOutboundAssociations OBJECT-TYPE 725 SYNTAX Counter32 726 MAX-ACCESS read-only 727 STATUS current 728 DESCRIPTION 729 "The total number of associations from the group since 730 group creation, where the MTA was the initiator." 731 ::= {mtaGroupEntry 16} 733 mtaGroupLastInboundActivity OBJECT-TYPE 734 SYNTAX TimeInterval 735 MAX-ACCESS read-only 736 STATUS current 737 DESCRIPTION 738 "Time since the last time that this group had an active 739 inbound association for purposes of message reception." 740 ::= {mtaGroupEntry 17} 742 mtaGroupLastOutboundActivity OBJECT-TYPE 743 SYNTAX TimeInterval 744 MAX-ACCESS read-only 745 STATUS current 746 DESCRIPTION 747 "Time since the last time that this group had a 748 successful outbound association for purposes of 749 message delivery." 750 ::= {mtaGroupEntry 18} 752 mtaGroupLastOutboundAssociationAttempt OBJECT-TYPE 753 SYNTAX TimeInterval 754 MAX-ACCESS read-only 755 STATUS current 756 DESCRIPTION 757 "Time since the last time that this group attempted 758 to make an outbound association for purposes of 759 message delivery." 760 ::= {mtaGroupEntry 34} 762 mtaGroupRejectedInboundAssociations OBJECT-TYPE 763 SYNTAX Counter32 764 MAX-ACCESS read-only 765 STATUS current 766 DESCRIPTION 767 "The total number of inbound associations the group has 768 rejected, since group creation. Rejected associations 769 are not counted in the accumulated association totals." 770 ::= {mtaGroupEntry 19} 772 mtaGroupFailedOutboundAssociations OBJECT-TYPE 773 SYNTAX Counter32 774 MAX-ACCESS read-only 775 STATUS current 776 DESCRIPTION 777 "The total number associations where the group was the 778 initiator and association establishment has failed, 779 since group creation. Failed associations are 780 not counted in the accumulated association totals." 781 ::= {mtaGroupEntry 20} 783 mtaGroupInboundRejectionReason OBJECT-TYPE 784 SYNTAX DisplayString 785 MAX-ACCESS read-only 786 STATUS current 787 DESCRIPTION 788 "The failure reason, if any, for the last association this 789 group refused to respond to. An empty string indicates that 790 the last attempt was successful. If no association attempt 791 has been made since the MTA was initialized the value 792 should be 'never'." 793 ::= {mtaGroupEntry 21} 795 mtaGroupOutboundConnectFailureReason OBJECT-TYPE 796 SYNTAX DisplayString 797 MAX-ACCESS read-only 798 STATUS current 799 DESCRIPTION 800 "The failure reason, if any, for the last association attempt 801 this group initiated. An empty string indicates that the last 802 attempt was successful. If no association attempt has been 803 made since the MTA was initialized the value should be 804 'never'." 805 ::= {mtaGroupEntry 22} 807 mtaGroupScheduledRetry OBJECT-TYPE 808 SYNTAX TimeInterval 809 MAX-ACCESS read-only 810 STATUS current 811 DESCRIPTION 812 "The time when this group is scheduled to next attempt to 813 make an association." 814 ::= {mtaGroupEntry 23} 816 mtaGroupMailProtocol OBJECT-TYPE 817 SYNTAX OBJECT IDENTIFIER 818 MAX-ACCESS read-only 819 STATUS current 820 DESCRIPTION 821 "An identification of the protocol being used by this group. 822 For an group employing OSI protocols, this will be the 823 Application Context. For Internet applications, the IANA 824 maintains a registry of the OIDs which correspond to well-known 825 message transfer protocols. If the application protocol is 826 not listed in the registry, an OID value of the form 827 {applTCPProtoID port} or {applUDProtoID port} are used for 828 TCP-based and UDP-based protocols, respectively. In either 829 case 'port' corresponds to the primary port number being 830 used by the group. applTCPProtoID and applUDPProtoID are 831 defined in [8]." 832 ::= {mtaGroupEntry 24} 834 mtaGroupName OBJECT-TYPE 835 SYNTAX DisplayString 836 MAX-ACCESS read-only 837 STATUS current 838 DESCRIPTION 839 "A descriptive name for the group. If this group connects to 840 a single remote MTA this should be the name of that MTA. If 841 this in turn is an Internet MTA this should be the domain 842 name. For an OSI MTA it should be the string encoded 843 distinguished name of the managed object using the format 844 defined in RFC 1779 [9]. For X.400(1984) MTAs which do not 845 have a Distinguished Name, the RFC 1327 [12] syntax 846 'mta in globalid' should be used." 847 ::= {mtaGroupEntry 25} 849 mtaGroupSuccessfulConvertedMessages OBJECT-TYPE 850 SYNTAX Counter32 851 MAX-ACCESS read-only 852 STATUS current 853 DESCRIPTION 854 "The number of messages that have been successfully 855 converted from one form to another in this group 856 since group creation." 857 ::= {mtaGroupEntry 26} 859 mtaGroupFailedConvertedMessages OBJECT-TYPE 860 SYNTAX Counter32 861 MAX-ACCESS read-only 862 STATUS current 863 DESCRIPTION 864 "The number of messages for which an unsuccessful 865 attempt was made to convert them from one form to 866 another in this group since group creation." 867 ::= {mtaGroupEntry 27} 869 mtaGroupDescription OBJECT-TYPE 870 SYNTAX DisplayString 871 MAX-ACCESS read-only 872 STATUS current 873 DESCRIPTION 874 "A description of the group's purpose. This information is 875 intended to identify the group in a status display." 876 ::= {mtaGroupEntry 28} 878 mtaGroupURL OBJECT-TYPE 879 SYNTAX URLString 880 MAX-ACCESS read-only 881 STATUS current 882 DESCRIPTION 883 "A URL pointing to a description of the group. This 884 information is intended to identify and briefly describe 885 the group in a status display." 886 ::= {mtaEntry 29} 888 mtaGroupCreationTime OBJECT-TYPE 889 SYNTAX TimeInterval 890 MAX-ACCESS read-only 891 STATUS current 892 DESCRIPTION 893 "Time since this group was first created." 894 ::= {mtaGroupEntry 30} 896 mtaGroupHierarchy OBJECT-TYPE 897 SYNTAX INTEGER (-2147483648..2147483647) 898 MAX-ACCESS not-accessible 899 STATUS current 900 DESCRIPTION 901 "Describes how this group fits into the hierarchy. A 902 positive value is interpreted as an mtaGroupIndex 903 value for some other group whose variables include 904 those of this group (and usually others). A negative 905 value is interpreted as a group collection code: Groups 906 with common negative hierarchy values comprise one 907 particular breakdown of MTA activity as a whole. A 908 zero value means that this MIB implementation doesn't 909 implement hierarchy indicators and thus the overall 910 group hierarchy cannot be determined." 911 ::= {mtaGroupEntry 31} 913 mtaGroupOldestMessageId OBJECT-TYPE 914 SYNTAX DisplayString 915 MAX-ACCESS read-only 916 STATUS current 917 DESCRIPTION 918 "Message ID of the oldest message in the group's queue. 919 Whenever possible this should be in the form of an 920 RFC 822 [13] msg-id; X.400 may convert X.400 message 921 identifiers to this form by following the rules laid 922 out in RFC1327 [12]." 923 ::= {mtaGroupEntry 32} 925 mtaGroupLoopsDetected OBJECT-TYPE 926 SYNTAX Counter32 927 MAX-ACCESS read-only 928 STATUS current 929 DESCRIPTION 930 "A message loop is defined as a situation where the MTA 931 decides that a given message will never be delivered to 932 one or more recipients and instead will continue to 933 loop endlessly through one or more MTAs. This variable 934 counts the number of times the MTA has detected such a 935 situation in conjunction with something associated with 936 this group since group creation. Note that the 937 mechanism MTAs use to detect loops (e.g. trace field 938 counting, count of references to this MTA in a trace 939 field, examination of DNS or other directory information, 940 etc.), the level at which loops are detected (e.g. per 941 message, per recipient, per directory entry, etc.), and 942 the handling of a loop once it is detected (e.g. looping 943 messages are held, looping messages are bounced or sent 944 to the postmaster, messages that the MTA knows will loop 945 won't be accepted, etc.) vary widely from one MTA to the 946 next and cannot be inferred from this variable." 947 ::= {mtaGroupEntry 33} 949 -- The mtaGroupAssociationTable provides a means of correlating 950 -- entries in the network services association table with the 951 -- MTA group responsible for the association. 953 mtaGroupAssociationTable OBJECT-TYPE 954 SYNTAX SEQUENCE OF MtaGroupAssociationEntry 955 MAX-ACCESS not-accessible 956 STATUS current 957 DESCRIPTION 958 "The table holding information regarding the associations 959 for each MTA group." 960 ::= {mta 3} 962 mtaGroupAssociationEntry OBJECT-TYPE 963 SYNTAX MtaGroupAssociationEntry 964 MAX-ACCESS not-accessible 965 STATUS current 966 DESCRIPTION 967 "The entry holding information regarding the associations 968 for each MTA group." 969 INDEX {applIndex, mtaGroupIndex, mtaGroupAssociationIndex} 970 ::= {mtaGroupAssociationTable 1} 972 MtaGroupAssociationEntry ::= SEQUENCE { 973 mtaGroupAssociationIndex 974 INTEGER 975 } 977 mtaGroupAssociationIndex OBJECT-TYPE 978 SYNTAX INTEGER (1..2147483647) 979 MAX-ACCESS read-only 980 STATUS current 981 DESCRIPTION 982 "Reference into association table to allow correlation of 983 this group's active associations with the association table." 984 ::= {mtaGroupAssociationEntry 1} 986 -- The mtaGroupErrorTable gives each group a way of tallying 987 -- the specific errors it has encountered. The mechanism 988 -- defined here uses RFC 1893 [14] status codes to identify 989 -- various specific errors. There are also classes for generic 990 -- errors of various sorts, and the entire mechanism is also 991 -- extensible, in that new error codes can be defined at any 992 -- time. 994 mtaGroupErrorTable OBJECT-TYPE 995 SYNTAX SEQUENCE OF MtaGroupErrorEntry 996 MAX-ACCESS not-accessible 997 STATUS current 998 DESCRIPTION 999 "The table holding information regarding accumulated errors 1000 for each MTA group." 1001 ::= {mta 4} 1003 mtaGroupErrorEntry OBJECT-TYPE 1004 SYNTAX MtaGroupErrorEntry 1005 MAX-ACCESS not-accessible 1006 STATUS current 1007 DESCRIPTION 1008 "The entry holding information regarding accumulated 1009 errors for each MTA group." 1010 INDEX {applIndex, mtaGroupIndex, mtaStatusCode} 1011 ::= {mtaGroupErrorTable 1} 1013 MtaGroupErrorEntry ::= SEQUENCE { 1014 mtaGroupInboundErrorCount 1015 Counter32, 1016 mtaGroupInternalErrorCount 1017 Counter32, 1018 mtaGroupOutboundErrorCount 1019 Counter32 1020 } 1022 mtaGroupInboundErrorCount OBJECT-TYPE 1023 SYNTAX Counter32 1024 MAX-ACCESS read-only 1025 STATUS current 1026 DESCRIPTION 1027 "Count of the number of errors of a given type that have 1028 been accumulated in assocation with a particular group 1029 while processing incoming messages. In the case of SMTP 1030 these will typically be errors reporting by an SMTP 1031 server to the remote client; in the case of X.400 1032 these will typically be errors encountered while 1033 processing an incoming message." 1034 ::= {mtaGroupErrorEntry 1} 1036 mtaGroupInternalErrorCount OBJECT-TYPE 1037 SYNTAX Counter32 1038 MAX-ACCESS read-only 1039 STATUS current 1040 DESCRIPTION 1041 "Count of the number of errors of a given type that have 1042 been accumulated in assocation with a particular group 1043 during internal MTA processing." 1044 ::= {mtaGroupErrorEntry 2} 1046 mtaGroupOutboundErrorCount OBJECT-TYPE 1047 SYNTAX Counter32 1048 MAX-ACCESS read-only 1049 STATUS current 1050 DESCRIPTION 1051 "Count of the number of errors of a given type that have 1052 been accumulated in assocation with a particular group's 1053 outbound connection activities. In the case of an SMTP 1054 client these will typically be errors reported while 1055 attempting to contact or while communicating with the 1056 remote SMTP server. In the case of X.400 these will 1057 typically be errors encountered while constructing 1058 or attempting to deliver an outgoing message." 1059 ::= {mtaGroupErrorEntry 3} 1061 -- Conformance information 1063 mtaConformance OBJECT IDENTIFIER ::= {mta 4} 1065 mtaGroups OBJECT IDENTIFIER ::= {mtaConformance 1} 1066 mtaCompliances OBJECT IDENTIFIER ::= {mtaConformance 2} 1068 -- Compliance statements 1070 mtaCompliance MODULE-COMPLIANCE 1071 STATUS current 1072 DESCRIPTION 1073 "The compliance statement for SNMPv2 entities which 1074 implement the Mail Monitoring MIB for basic 1075 monitoring of MTAs." 1076 MODULE -- this module 1077 MANDATORY-GROUPS {mtaGroup} 1078 ::= {mtaCompliances 1} 1080 mtaAssocCompliance MODULE-COMPLIANCE 1081 STATUS current 1082 DESCRIPTION 1083 "The compliance statement for SNMPv2 entities which 1084 implement the Mail Monitoring MIB for monitoring of 1085 MTAs and their associations." 1086 MODULE -- this module 1087 MANDATORY-GROUPS {mtaGroup, mtaAssocGroup} 1088 ::= {mtaCompliances 2} 1090 mtaErrorCompliance MODULE-COMPLIANCE 1091 STATUS current 1092 DESCRIPTION 1093 "The compliance statement for SNMPv2 entities which 1094 implement the Mail Monitoring MIB for monitoring of 1095 MTAs and detailed errors." 1096 MODULE -- this module 1097 MANDATORY-GROUPS {mtaGroup, mtaErrorGroup} 1098 ::= {mtaCompliances 2} 1100 mtaFullCompliance MODULE-COMPLIANCE 1101 STATUS current 1102 DESCRIPTION 1103 "The compliance statement for SNMPv2 entities which 1104 implement the full Mail Monitoring MIB for monitoring 1105 of MTAs, associations, and detailed errors." 1106 MODULE -- this module 1107 MANDATORY-GROUPS {mtaGroup, mtaAssocGroup, mtaErrorGroup} 1108 ::= {mtaCompliances 2} 1110 -- Units of conformance 1112 mtaGroup OBJECT-GROUP 1113 OBJECTS { 1114 mtaReceivedMessages, mtaStoredMessages, 1115 mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume, 1116 mtaTransmittedVolume, mtaReceivedRecipients, 1117 mtaStoredRecipients, mtaTransmittedRecipients, 1118 mtaSuccessfulConvertedMessages, mtaFailedConvertedMessages, 1119 mtaGroupReceivedMessages, mtaGroupRejectedMessages, 1120 mtaGroupStoredMessages, mtaGroupTransmittedMessages, 1121 mtaGroupReceivedVolume, mtaGroupStoredVolume, 1122 mtaGroupTransmittedVolume, mtaGroupReceivedRecipients, 1123 mtaGroupStoredRecipients, mtaGroupTransmittedRecipients, 1124 mtaGroupOldestMessageStored, mtaGroupInboundAssociations, 1125 mtaGroupOutboundAssociations, mtaLoopsDetected, 1126 mtaGroupAccumulatedInboundAssociations, 1127 mtaGroupAccumulatedOutboundAssociations, 1128 mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity, 1129 mtaGroupLastOutboundAssociationAttempt, 1130 mtaGroupRejectedInboundAssociations, 1131 mtaGroupFailedOutboundAssociations, 1132 mtaGroupInboundRejectionReason, 1133 mtaGroupOutboundConnectFailureReason, 1134 mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName, 1135 mtaGroupSuccessfulConvertedMessages, 1136 mtaGroupFailedConvertedMessages, mtaGroupDescription, 1137 mtaGroupURL, mtaGroupCreationTime, mtaGroupHierarchy, 1138 mtaGroupOldestMessageId, mtaGroupLoopsDetected} 1139 STATUS current 1140 DESCRIPTION 1141 "A collection of objects providing basic monitoring of MTAs." 1142 ::= {mtaGroups 1} 1144 mtaAssocGroup OBJECT-GROUP 1145 OBJECTS { 1146 mtaGroupAssociationIndex} 1147 STATUS current 1148 DESCRIPTION 1149 "A collection of objects providing monitoring of MTA 1150 associations." 1151 ::= {mtaGroups 2} 1153 mtaErrorGroup OBJECT-GROUP 1154 OBJECTS { 1155 mtaGroupInboundErrorCount, mtaGroupInternalErrorCount, 1156 mtaGroupOutboundErrorCount} 1157 STATUS current 1158 DESCRIPTION 1159 "A collection of objects providing monitoring of 1160 detailed MTA errors." 1161 ::= {mtaGroups 3} 1163 END 1165 7. Changes made since RFC 1566 1167 The only changes made to this document since it was issued as RFC 1566 1168 [11] are the following: 1170 (1) A number of DESCRIPTION fields have been reworded, hopefully 1171 making them clearer. 1173 (2) mtaGroupDescription and mtaGroupURL fields have been added. 1174 These fields are intended to identify and describe the MTA and 1175 the various MTA groups. 1177 (3) The time since the last outbound association attempt is now 1178 distinct from the time since the last successfuol outbound 1179 association attempt. 1181 (4) Conversion operation counters have been added. 1183 (5) A mechanism to explicitly describe group hierarchies has been 1184 added. 1186 (6) A mechanism to count specific sorts of errors has been added. 1188 (7) A field for the ID of the oldest message in a group's queue has 1189 been added. 1191 (8) Per-MTA and per-group message loop counters have been added. 1193 (9) A new table has been added to keep track of any errors an MTA 1194 encounters. 1196 8. Acknowledgements 1198 This document is a work product of the Mail and Directory Management 1199 (MADMAN) Working Group of the IETF. It is based on an earlier MIB 1200 designed by S. Kille, T. Lenggenhager, D. Partain, and W. Yeong. The 1201 Electronic Mail Association's TSC committee was instrumental in 1202 providing feedback on and suggesting enhancements to RFC 1566 [11] that 1203 have led to the present document. 1205 9. References 1207 [1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure 1208 of Management Information for Version 2 of the Simple Network 1209 Management Protocol (SNMPv2)", RFC 1902, January 1996. 1211 [2] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Textual 1212 Conventions for Version 2 of the Simple Network Management Protocol 1213 (SNMPv2)", RFC 1903, January 1996. 1215 [3] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Conformance 1216 Statements for Version 2 of the Simple Network Management Protocol 1217 (SNMPv2)", RFC 1904, January 1996. 1219 [4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol 1220 Operations for Version 2 of the Simple Network Management Protocol 1221 (SNMPv2)", RFC 1905, January 1996. 1223 [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport 1224 Mappings for Version 2 of the Simple Network Management Protocol 1225 (SNMPv2)", RFC 1906, January 1996. 1227 [6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management 1228 Information Base for Version 2 of the Simple Network Management 1229 Protocol (SNMPv2)", RFC 1907, January 1996. 1231 [7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., 1232 "Coexistence between Version 1 and Version 2 of the Internet- 1233 standard Network Management Framework", RFC 1908, January 1996. 1235 [8] Freed, N., Kille, S., "The Network Services Monitoring MIB", 1236 Internet Draft, March 1997. 1238 [9] Kille, S., "A String Representation of Distinguished Names", RFC 1239 1779, March 1995. 1241 [10] Berners-Lee, T., Masinter, L., McCahill, M., iform Resource 1242 Locators (URL)", RFC 1738, December 1994. 1244 [11] Freed, N., Kille, S., "Mail Monitoring MIB", RFC 1566, January 1245 1994. 1247 [12] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", 1248 RFC 1327, May 1992. 1250 [13] Crocker, D., "Standard for the Format of ARPA Internet Text 1251 Message", RFC 822, August 1982. 1253 [14] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, Octel 1254 Network Services, January 1996. 1256 10. Security Considerations 1258 Security issues are not discussed in this memo. 1260 11. Author and Chair Addresses 1262 Ned Freed 1263 Innosoft International, Inc. 1264 1050 East Garvey Avenue South 1265 West Covina, CA 91790 1266 USA 1267 tel: +1 818 919 3600 1268 fax: +1 818 919 3614 1269 email: ned@innosoft.com 1271 Steve Kille, MADMAN WG Chair 1272 ISODE Consortium 1273 The Dome, The Square 1274 Richmond TW9 1DT 1275 UK 1276 tel: +44 181 332 9091 1277 email: S.Kille@isode.com