summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2789.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2789.txt')
-rw-r--r--doc/rfc/rfc2789.txt1851
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc2789.txt b/doc/rfc/rfc2789.txt
new file mode 100644
index 0000000..b495b96
--- /dev/null
+++ b/doc/rfc/rfc2789.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Network Working Group N. Freed
+Request for Comments: 2789 Innosoft
+Obsoletes: 2249, 1566 S. Kille
+Category: Standards Track MessagingDirect Ltd.
+ March 2000
+
+
+ Mail Monitoring MIB
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Introduction
+
+ This memo defines a portion of the Management Information Base (MIB)
+ for use with network management protocols in the Internet community.
+ Specifically, this memo extends the basic Network Services Monitoring
+ MIB defined in RFC 2788 [16] to allow monitoring of Message Transfer
+ Agents (MTAs). It may also be used to monitor MTA components within
+ gateways.
+
+Table of Contents
+
+ 1 The SNMP Network Management Framework ....................... 2
+ 2 Message Flow Model .......................................... 3
+ 3 MTA Objects ................................................. 3
+ 4 Definitions ................................................. 4
+ 5 Changes made since RFC 2249 ................................. 29
+ 6 Acknowledgements ............................................ 30
+ 7 References .................................................. 30
+ 8 Security Considerations ..................................... 31
+ 9 Author and Chair Addresses .................................. 32
+ 10 Full Copyright Statement .................................... 33
+
+
+
+
+
+
+
+
+
+Freed & Kille Standards Track [Page 1]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+1. The SNMP Network Management Framework
+
+ The SNMP Management Framework presently consists of five major
+ components:
+
+ o An overall architecture, described in RFC 2571 [1].
+
+ o Mechanisms for describing and naming objects and events for the
+ purpose of management. The first version of this Structure of
+ Management Information (SMI) is called SMIv1 and described in STD
+ 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The
+ second version, called SMIv2, is described in STD 58, RFC 2578
+ [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7].
+
+ o Message protocols for transferring management information. The
+ first version of the SNMP message protocol is called SNMPv1 and
+ described in STD 15, RFC 1157 [8]. A second version of the SNMP
+ message protocol, which is not an Internet standards track
+ protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC
+ 1906 [10]. The third version of the message protocol is called
+ SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574
+ [12].
+
+ o Protocol operations for accessing management information. The
+ first set of protocol operations and associated PDU formats is
+ described in STD 15, RFC 1157 [8]. A second set of protocol
+ operations and associated PDU formats is described in RFC 1905
+ [13].
+
+ o A set of fundamental applications described in RFC 2573 [14] and
+ the view-based access control mechanism described in RFC 2575
+ [15].
+
+ Managed objects are accessed via a virtual information store, termed
+ the Management Information Base or MIB. Objects in the MIB are
+ defined using the mechanisms defined in the SMI.
+
+ This memo specifies a MIB module that is compliant to the SMIv2. A
+ MIB conforming to the SMIv1 can be produced through the appropriate
+ translations. The resulting translated MIB must be semantically
+ equivalent, except where objects or events are omitted because no
+ translation is possible (use of Counter64). Some machine readable
+ information in SMIv2 will be converted into textual descriptions in
+ SMIv1 during the translation process. However, this loss of machine
+ readable information is not considered to change the semantics of the
+ MIB.
+
+
+
+
+
+Freed & Kille Standards Track [Page 2]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+2. Message Flow Model
+
+ A general model of message flow inside an MTA has to be presented
+ before a MIB can be described. Generally speaking, message flow is
+ modelled as occurring in four steps:
+
+ (1) Messages are received by the MTA from User Agents, Message
+ Stores, other MTAs, and gateways.
+
+ (2) The "next hop" for the each message is determined. This is simply
+ the destination the message is to be transmitted to; it may or
+ may not be the final destination of the message. Multiple "next
+ hops" may exist for a single message (as a result of either
+ having multiple recipients or distribution list expansion); this
+ may make it necessary to duplicate messages.
+
+ (3) If necessary messages are converted into the format that's
+ appropriate for the next hop. Conversion operations may be
+ successful or unsuccessful.
+
+ (4) Messages are transmitted to the appropriate destination, which
+ may be a User Agent, Message Store, another MTA, or gateway.
+
+ Storage of messages in the MTA occurs at some point during this
+ process. However, it is important to note that storage may occur at
+ different and possibly even multiple points during this process. For
+ example, some MTAs expand messages into multiple copies as they are
+ received. In this case (1), (2), and (3) may all occur prior to
+ storage. Other MTAs store messages precisely as they are received and
+ perform all expansions and conversions during retransmission
+ processing. So here only (1) occurs prior to storage. This leads to
+ situations where, in general, a measurement of messages received may
+ not equal a measurement of messages in store, or a measurement of
+ messages stored may not equal a measurement of messages
+ retransmitted, or both.
+
+3. MTA Objects
+
+ If there are one or more MTAs on the host, the following MIB may be
+ used to monitor them. Any number of the MTAs on a single host or
+ group of hosts may be monitored. Each MTA is dealt with as a separate
+ network service and has its own applTable entry in the Network
+ Services Monitoring MIB.
+
+ The MIB described in this document covers only the portion which is
+ specific to the monitoring of MTAs. The network service related part
+ of the MIB is covered in RFC 2788 [16].
+
+
+
+
+Freed & Kille Standards Track [Page 3]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ This MIB defines four tables. The first of these contains per-MTA
+ information that isn't specific to any particular part of MTA. The
+ second breaks each MTA down into a collection of separate components
+ called groups. Groups are described in detail in the comments
+ embedded in the MIB below. The third table provides a means of
+ correlating associations tracked by the network services MIB with
+ specific groups within different MTAs. Finally, the fourth table
+ provides a means of tracking any errors encountered during the
+ operation of the MTA. The first two tables must be implemented to
+ conform with this MIB; the last two are optional.
+
+4. Definitions
+
+ MTA-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY, mib-2
+ FROM SNMPv2-SMI
+ TimeInterval
+ FROM SNMPv2-TC
+ MODULE-COMPLIANCE, OBJECT-GROUP
+ FROM SNMPv2-CONF
+ SnmpAdminString
+ FROM SNMP-FRAMEWORK-MIB
+ applIndex, URLString
+ FROM NETWORK-SERVICES-MIB;
+
+ mta MODULE-IDENTITY
+ LAST-UPDATED "200003030000Z"
+ ORGANIZATION "IETF Mail and Directory Management Working Group"
+ CONTACT-INFO
+ " Ned Freed
+
+ Postal: Innosoft International, Inc.
+ 1050 Lakes Drive
+ West Covina, CA 91790
+ US
+
+ Tel: +1 626 919 3600
+ Fax: +1 626 919 3614
+
+ E-Mail: ned.freed@innosoft.com"
+ DESCRIPTION
+ "The MIB module describing Message Transfer Agents (MTAs)"
+ REVISION "200003030000Z"
+ DESCRIPTION
+ "This revision, published in RFC 2789, changes a number of
+ DisplayStrings to SnmpAdminStrings. Note that this change
+
+
+
+Freed & Kille Standards Track [Page 4]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ is not strictly supported by SMIv2. However, the alternative
+ of deprecating the old objects and defining new objects
+ would have a more adverse impact on backward compatibility
+ and interoperability, given the particular semantics of
+ these objects. The defining reference for distinguished
+ names has also been updated from RFC 1779 to RFC 2253."
+ REVISION "199905120000Z"
+ DESCRIPTION
+ "This revision fixes a number of technical problems found in
+ previous versions: The conformance groups for different
+ versions of this MIB have been corrected, the recommendation
+ that an empty string be returned if the last operation was
+ successful has been removed from
+ mtaGroupInboundRejectionReason and
+ mtaGroupOutboundConnectFailureReason as it conflicts
+ with the stated purpose of these variables, and the
+ required mtaStatusCode entry has been added to
+ MtaGroupErrorEntry. It should be noted that this last
+ change in no way affects the bits on the wire."
+ REVISION "199708170000Z"
+ DESCRIPTION
+ "This revision, published in RFC 2249, adds the
+ mtaGroupDescription and mtaGroupURL fields, conversion
+ operation counters, a group hierarchy description mechanism,
+ counters for specific errors, oldest message IDs, per-MTA
+ and per-group loop counters, and a new table for tracking
+ any errors an MTA encounters."
+ REVISION "199311280000Z"
+ DESCRIPTION
+ "The original version of this MIB was published in RFC 1566"
+ ::= {mib-2 28}
+
+ mtaTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF MtaEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The table holding information specific to an MTA."
+ ::= {mta 1}
+
+ mtaEntry OBJECT-TYPE
+ SYNTAX MtaEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The entry associated with each MTA."
+ INDEX {applIndex}
+ ::= {mtaTable 1}
+
+
+
+Freed & Kille Standards Track [Page 5]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ MtaEntry ::= SEQUENCE {
+ mtaReceivedMessages
+ Counter32,
+ mtaStoredMessages
+ Gauge32,
+ mtaTransmittedMessages
+ Counter32,
+ mtaReceivedVolume
+ Counter32,
+ mtaStoredVolume
+ Gauge32,
+ mtaTransmittedVolume
+ Counter32,
+ mtaReceivedRecipients
+ Counter32,
+ mtaStoredRecipients
+ Gauge32,
+ mtaTransmittedRecipients
+ Counter32,
+ mtaSuccessfulConvertedMessages
+ Counter32,
+ mtaFailedConvertedMessages
+ Counter32,
+ mtaLoopsDetected
+ Counter32
+ }
+
+ mtaReceivedMessages OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of messages received since MTA initialization.
+ This includes messages transmitted to this MTA from other
+ MTAs as well as messages that have been submitted to the
+ MTA directly by end-users or applications."
+ ::= {mtaEntry 1}
+
+ mtaStoredMessages OBJECT-TYPE
+ SYNTAX Gauge32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of messages currently stored in the MTA.
+ This includes messages that are awaiting transmission to
+ some other MTA or are waiting for delivery to an end-user
+ or application."
+ ::= {mtaEntry 2}
+
+
+
+Freed & Kille Standards Track [Page 6]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ mtaTransmittedMessages OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of messages transmitted since MTA initialization.
+ This includes messages that were transmitted to some other
+ MTA or are waiting for delivery to an end-user or
+ application."
+ ::= {mtaEntry 3}
+
+ mtaReceivedVolume OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "K-octets"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total volume of messages received since MTA
+ initialization, measured in kilo-octets. This volume should
+ include all transferred data that is logically above the mail
+ transport protocol level. For example, an SMTP-based MTA
+ should use the number of kilo-octets in the message header
+ and body, while an X.400-based MTA should use the number of
+ kilo-octets of P2 data. This includes messages transmitted
+ to this MTA from other MTAs as well as messages that have
+ been submitted to the MTA directly by end-users or
+ applications."
+ ::= {mtaEntry 4}
+
+ mtaStoredVolume OBJECT-TYPE
+ SYNTAX Gauge32
+ UNITS "K-octets"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total volume of messages currently stored in the MTA,
+ measured in kilo-octets. This volume should include all
+ stored data that is logically above the mail transport
+ protocol level. For example, an SMTP-based MTA should
+ use the number of kilo-octets in the message header and
+ body, while an X.400-based MTA would use the number of
+ kilo-octets of P2 data. This includes messages that are
+ awaiting transmission to some other MTA or are waiting
+ for delivery to an end-user or application."
+ ::= {mtaEntry 5}
+
+ mtaTransmittedVolume OBJECT-TYPE
+ SYNTAX Counter32
+
+
+
+Freed & Kille Standards Track [Page 7]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ UNITS "K-octets"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total volume of messages transmitted since MTA
+ initialization, measured in kilo-octets. This volume should
+ include all transferred data that is logically above the mail
+ transport protocol level. For example, an SMTP-based MTA
+ should use the number of kilo-octets in the message header
+ and body, while an X.400-based MTA should use the number of
+ kilo-octets of P2 data. This includes messages that were
+ transmitted to some other MTA or are waiting for delivery
+ to an end-user or application."
+ ::= {mtaEntry 6}
+
+ mtaReceivedRecipients OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of recipients specified in all messages
+ received since MTA initialization. Recipients this MTA
+ has no responsibility for, i.e. inactive envelope
+ recipients or ones referred to in message headers,
+ should not be counted even if information about such
+ recipients is available. This includes messages
+ transmitted to this MTA from other MTAs as well as
+ messages that have been submitted to the MTA directly
+ by end-users or applications."
+ ::= {mtaEntry 7}
+
+ mtaStoredRecipients OBJECT-TYPE
+ SYNTAX Gauge32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of recipients specified in all messages
+ currently stored in the MTA. Recipients this MTA has no
+ responsibility for, i.e. inactive envelope recipients or
+ ones referred to in message headers, should not be
+ counted. This includes messages that are awaiting
+ transmission to some other MTA or are waiting for
+ delivery to an end-user or application."
+ ::= {mtaEntry 8}
+
+ mtaTransmittedRecipients OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+
+
+
+Freed & Kille Standards Track [Page 8]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ STATUS current
+ DESCRIPTION
+ "The total number of recipients specified in all messages
+ transmitted since MTA initialization. Recipients this
+ MTA had no responsibility for, i.e. inactive envelope
+ recipients or ones referred to in message headers,
+ should not be counted. This includes messages that were
+ transmitted to some other MTA or are waiting for
+ delivery to an end-user or application."
+ ::= {mtaEntry 9}
+
+ mtaSuccessfulConvertedMessages OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of messages that have been successfully
+ converted from one form to another since MTA
+ initialization."
+ ::= {mtaEntry 10}
+
+ mtaFailedConvertedMessages OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of messages for which an unsuccessful
+ attempt was made to convert them from one form to
+ another since MTA initialization."
+ ::= {mtaEntry 11}
+
+ mtaLoopsDetected OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A message loop is defined as a situation where the MTA
+ decides that a given message will never be delivered to
+ one or more recipients and instead will continue to
+ loop endlessly through one or more MTAs. This variable
+ counts the number of times the MTA has detected such a
+ situation since MTA initialization. Note that the
+ mechanism MTAs use to detect loops (e.g., trace field
+ counting, count of references to this MTA in a trace
+ field, examination of DNS or other directory information,
+ etc.), the level at which loops are detected (e.g., per
+ message, per recipient, per directory entry, etc.), and
+ the handling of a loop once it is detected (e.g., looping
+
+
+
+Freed & Kille Standards Track [Page 9]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ messages are held, looping messages are bounced or sent
+ to the postmaster, messages that the MTA knows will loop
+ won't be accepted, etc.) vary widely from one MTA to the
+ next and cannot be inferred from this variable."
+ ::= {mtaEntry 12}
+
+ -- MTAs typically group inbound reception, queue storage, and
+ -- outbound transmission in some way, rather than accounting for
+ -- such operations only across the MTA as a whole. In the most
+ -- extreme case separate information will be maintained for each
+ -- different entity that receives messages and for each entity
+ -- the MTA stores messages for and delivers messages to. Other
+ -- MTAs may elect to treat all reception equally, all queue
+ -- storage equally, all deliveries equally, or some combination
+ -- of this. Overlapped groupings are also possible, where an MTA
+ -- decomposes its traffic in different ways for different
+ -- purposes.
+
+ -- In any case, a grouping abstraction is an extremely useful for
+ -- breaking down the activities of an MTA. For purposes of
+ -- labelling this will be called a "group" in this MIB.
+
+ -- Each group contains all the variables needed to monitor all
+ -- aspects of an MTA's operation. However, the fact that all
+ -- groups contain all possible variables does not imply that all
+ -- groups must use all possible variables. For example, a single
+ -- group might be used to monitor only one kind of event (inbound
+ -- processing, outbound processing, or storage). In this sort of
+ -- configuration any counters that are unused as a result of a
+ -- given MTA's use of the group construct must be inaccessible;
+ -- e.g., returning either a noSuchName error (for an SNMPv1 get),
+ -- or a noSuchInstance exception (for an SNMPv2 get).
+
+ -- Groups can be created at any time after MTA initialization. Once
+ -- a group is created it should not be deleted or its mtaGroupIndex
+ -- changed unless the MTA is reinitialized.
+
+ -- Groups are not necessarily mutually exclusive. A given event may
+ -- be recorded by more than one group, a message may be seen as
+ -- stored by more than one group, and so on. Groups should be all
+ -- inclusive, however: if groups are implemented all aspects of an
+ -- MTA's operation should be registered in at least one group.
+ -- This freedom lets implementors use different sets of groups to
+ -- provide different "views" of an MTA.
+
+ -- The possibility of overlap between groups means that summing
+ -- variables across groups may not produce values equal to those in
+ -- the mtaTable. mtaTable should always provide accurate information
+
+
+
+Freed & Kille Standards Track [Page 10]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ -- about the MTA as a whole.
+
+ -- The term "channel" is often used in MTA implementations; channels
+ -- are usually, but not always, equivalent to a group. However,
+ -- this MIB does not use the term "channel" because there is no
+ -- requirement that an MTA supporting this MIB has to map its
+ -- "channel" abstraction one-to-one onto the MIB's group abstraction.
+
+ -- An MTA may create a group or group of groups at any time. Once
+ -- created, however, an MTA cannot delete an entry for a group from
+ -- the group table. Deletion is only allowed when the MTA is
+ -- reinitialized, and is not required even then. This restriction
+ -- is imposed so that monitoring agents can rely on group
+ -- assignments being consistent across multiple query operations.
+
+ -- Groups may be laid out so as to form a hierarchical arrangement,
+ -- with some groups acting as subgroups for other groups.
+ -- Alternately, disjoint groups of groups may be used to provide
+ -- different sorts of "snapshots" of MTA operation. The
+ -- mtaGroupHierarchy variable provides an indication of how each
+ -- group fits into the overall arrangement being used.
+
+ -- Note that SNMP also defines and uses term "group". MTA groups are
+ -- NOT the same as SNMP groups.
+
+ mtaGroupTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF MtaGroupEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The table holding information specific to each MTA group."
+ ::= {mta 2}
+
+ mtaGroupEntry OBJECT-TYPE
+ SYNTAX MtaGroupEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The entry associated with each MTA group."
+ INDEX {applIndex, mtaGroupIndex}
+ ::= {mtaGroupTable 1}
+
+ MtaGroupEntry ::= SEQUENCE {
+ mtaGroupIndex
+ INTEGER,
+ mtaGroupReceivedMessages
+ Counter32,
+ mtaGroupRejectedMessages
+
+
+
+Freed & Kille Standards Track [Page 11]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ Counter32,
+ mtaGroupStoredMessages
+ Gauge32,
+ mtaGroupTransmittedMessages
+ Counter32,
+ mtaGroupReceivedVolume
+ Counter32,
+ mtaGroupStoredVolume
+ Gauge32,
+ mtaGroupTransmittedVolume
+ Counter32,
+ mtaGroupReceivedRecipients
+ Counter32,
+ mtaGroupStoredRecipients
+ Gauge32,
+ mtaGroupTransmittedRecipients
+ Counter32,
+ mtaGroupOldestMessageStored
+ TimeInterval,
+ mtaGroupInboundAssociations
+ Gauge32,
+ mtaGroupOutboundAssociations
+ Gauge32,
+ mtaGroupAccumulatedInboundAssociations
+ Counter32,
+ mtaGroupAccumulatedOutboundAssociations
+ Counter32,
+ mtaGroupLastInboundActivity
+ TimeInterval,
+ mtaGroupLastOutboundActivity
+ TimeInterval,
+ mtaGroupLastOutboundAssociationAttempt
+ TimeInterval,
+ mtaGroupRejectedInboundAssociations
+ Counter32,
+ mtaGroupFailedOutboundAssociations
+ Counter32,
+ mtaGroupInboundRejectionReason
+ SnmpAdminString,
+ mtaGroupOutboundConnectFailureReason
+ SnmpAdminString,
+ mtaGroupScheduledRetry
+ TimeInterval,
+ mtaGroupMailProtocol
+ OBJECT IDENTIFIER,
+ mtaGroupName
+ SnmpAdminString,
+ mtaGroupSuccessfulConvertedMessages
+
+
+
+Freed & Kille Standards Track [Page 12]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ Counter32,
+ mtaGroupFailedConvertedMessages
+ Counter32,
+ mtaGroupDescription
+ SnmpAdminString,
+ mtaGroupURL
+ URLString,
+ mtaGroupCreationTime
+ TimeInterval,
+ mtaGroupHierarchy
+ INTEGER,
+ mtaGroupOldestMessageId
+ SnmpAdminString,
+ mtaGroupLoopsDetected
+ Counter32
+ }
+
+ mtaGroupIndex OBJECT-TYPE
+ SYNTAX INTEGER (1..2147483647)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The index associated with a group for a given MTA."
+ ::= {mtaGroupEntry 1}
+
+ mtaGroupReceivedMessages OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of messages received to this group since
+ group creation."
+ ::= {mtaGroupEntry 2}
+
+ mtaGroupRejectedMessages OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of messages rejected by this group since
+ group creation."
+ ::= {mtaGroupEntry 3}
+
+ mtaGroupStoredMessages OBJECT-TYPE
+ SYNTAX Gauge32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+
+
+
+Freed & Kille Standards Track [Page 13]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ "The total number of messages currently stored in this
+ group's queue."
+ ::= {mtaGroupEntry 4}
+
+ mtaGroupTransmittedMessages OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of messages transmitted by this group since
+ group creation."
+ ::= {mtaGroupEntry 5}
+
+ mtaGroupReceivedVolume OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "K-octets"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total volume of messages received to this group since
+ group creation, measured in kilo-octets. This volume
+ should include all transferred data that is logically above
+ the mail transport protocol level. For example, an
+ SMTP-based MTA should use the number of kilo-octets in the
+ message header and body, while an X.400-based MTA should use
+ the number of kilo-octets of P2 data."
+ ::= {mtaGroupEntry 6}
+
+ mtaGroupStoredVolume OBJECT-TYPE
+ SYNTAX Gauge32
+ UNITS "K-octets"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total volume of messages currently stored in this
+ group's queue, measured in kilo-octets. This volume should
+ include all stored data that is logically above the mail
+ transport protocol level. For example, an SMTP-based
+ MTA should use the number of kilo-octets in the message
+ header and body, while an X.400-based MTA would use the
+ number of kilo-octets of P2 data."
+ ::= {mtaGroupEntry 7}
+
+ mtaGroupTransmittedVolume OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "K-octets"
+ MAX-ACCESS read-only
+ STATUS current
+
+
+
+Freed & Kille Standards Track [Page 14]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ DESCRIPTION
+ "The total volume of messages transmitted by this group
+ since group creation, measured in kilo-octets. This
+ volume should include all transferred data that is logically
+ above the mail transport protocol level. For example, an
+ SMTP-based MTA should use the number of kilo-octets in the
+ message header and body, while an X.400-based MTA should use
+ the number of kilo-octets of P2 data."
+ ::= {mtaGroupEntry 8}
+
+ mtaGroupReceivedRecipients OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of recipients specified in all messages
+ received to this group since group creation.
+ Recipients this MTA has no responsibility for should not
+ be counted."
+ ::= {mtaGroupEntry 9}
+
+ mtaGroupStoredRecipients OBJECT-TYPE
+ SYNTAX Gauge32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of recipients specified in all messages
+ currently stored in this group's queue. Recipients this
+ MTA has no responsibility for should not be counted."
+ ::= {mtaGroupEntry 10}
+
+ mtaGroupTransmittedRecipients OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of recipients specified in all messages
+ transmitted by this group since group creation.
+ Recipients this MTA had no responsibility for should not
+ be counted."
+ ::= {mtaGroupEntry 11}
+
+ mtaGroupOldestMessageStored OBJECT-TYPE
+ SYNTAX TimeInterval
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Time since the oldest message in this group's queue was
+
+
+
+Freed & Kille Standards Track [Page 15]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ placed in the queue."
+ ::= {mtaGroupEntry 12}
+
+ mtaGroupInboundAssociations OBJECT-TYPE
+ SYNTAX Gauge32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of current associations to the group, where the
+ group is the responder."
+ ::= {mtaGroupEntry 13}
+
+ mtaGroupOutboundAssociations OBJECT-TYPE
+ SYNTAX Gauge32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of current associations to the group, where the
+ group is the initiator."
+ ::= {mtaGroupEntry 14}
+
+ mtaGroupAccumulatedInboundAssociations OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of associations to the group since
+ group creation, where the MTA was the responder."
+ ::= {mtaGroupEntry 15}
+
+ mtaGroupAccumulatedOutboundAssociations OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of associations from the group since
+ group creation, where the MTA was the initiator."
+ ::= {mtaGroupEntry 16}
+
+ mtaGroupLastInboundActivity OBJECT-TYPE
+ SYNTAX TimeInterval
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Time since the last time that this group had an active
+ inbound association for purposes of message reception."
+ ::= {mtaGroupEntry 17}
+
+
+
+
+Freed & Kille Standards Track [Page 16]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ mtaGroupLastOutboundActivity OBJECT-TYPE
+ SYNTAX TimeInterval
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Time since the last time that this group had a
+ successful outbound association for purposes of
+ message delivery."
+ ::= {mtaGroupEntry 18}
+
+ mtaGroupLastOutboundAssociationAttempt OBJECT-TYPE
+ SYNTAX TimeInterval
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Time since the last time that this group attempted
+ to make an outbound association for purposes of
+ message delivery."
+ ::= {mtaGroupEntry 34}
+
+ mtaGroupRejectedInboundAssociations OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of inbound associations the group has
+ rejected, since group creation. Rejected associations
+ are not counted in the accumulated association totals."
+ ::= {mtaGroupEntry 19}
+
+ mtaGroupFailedOutboundAssociations OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number associations where the group was the
+ initiator and association establishment has failed,
+ since group creation. Failed associations are
+ not counted in the accumulated association totals."
+ ::= {mtaGroupEntry 20}
+
+ mtaGroupInboundRejectionReason OBJECT-TYPE
+ SYNTAX SnmpAdminString
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The failure reason, if any, for the last association this
+ group refused to respond to. If no association attempt
+
+
+
+Freed & Kille Standards Track [Page 17]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ has been made since the MTA was initialized the value
+ should be 'never'."
+ ::= {mtaGroupEntry 21}
+
+ mtaGroupOutboundConnectFailureReason OBJECT-TYPE
+ SYNTAX SnmpAdminString
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The failure reason, if any, for the last association attempt
+ this group initiated. If no association attempt has been
+ made since the MTA was initialized the value should be
+ 'never'."
+ ::= {mtaGroupEntry 22}
+
+ mtaGroupScheduledRetry OBJECT-TYPE
+ SYNTAX TimeInterval
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The amount of time until this group is next scheduled to
+ attempt to make an association."
+ ::= {mtaGroupEntry 23}
+
+ mtaGroupMailProtocol OBJECT-TYPE
+ SYNTAX OBJECT IDENTIFIER
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "An identification of the protocol being used by this group.
+ For an group employing OSI protocols, this will be the
+ Application Context. For Internet applications, OID
+ values of the form {applTCPProtoID port} or {applUDPProtoID
+ port} are used for TCP-based and UDP-based protocols,
+ respectively. In either case 'port' corresponds to the
+ primary port number being used by the protocol. The
+ usual IANA procedures may be used to register ports for
+ new protocols. applTCPProtoID and applUDPProtoID are
+ defined in the NETWORK-SERVICES-MIB, RFC 2788."
+ ::= {mtaGroupEntry 24}
+
+ mtaGroupName OBJECT-TYPE
+ SYNTAX SnmpAdminString
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A descriptive name for the group. If this group connects to
+ a single remote MTA this should be the name of that MTA. If
+
+
+
+Freed & Kille Standards Track [Page 18]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ this in turn is an Internet MTA this should be the domain
+ name. For an OSI MTA it should be the string encoded
+ distinguished name of the managed object using the format
+ defined in RFC 2253. For X.400(1984) MTAs which do not
+ have a Distinguished Name, the RFC 2156 syntax
+ 'mta in globalid' used in X400-Received: fields can be
+ used."
+ ::= {mtaGroupEntry 25}
+
+ mtaGroupSuccessfulConvertedMessages OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of messages that have been successfully
+ converted from one form to another in this group
+ since group creation."
+ ::= {mtaGroupEntry 26}
+
+ mtaGroupFailedConvertedMessages OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of messages for which an unsuccessful
+ attempt was made to convert them from one form to
+ another in this group since group creation."
+ ::= {mtaGroupEntry 27}
+
+ mtaGroupDescription OBJECT-TYPE
+ SYNTAX SnmpAdminString
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A description of the group's purpose. This information is
+ intended to identify the group in a status display."
+ ::= {mtaGroupEntry 28}
+
+ mtaGroupURL OBJECT-TYPE
+ SYNTAX URLString
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A URL pointing to a description of the group. This
+ information is intended to identify and briefly describe
+ the group in a status display."
+ ::= {mtaGroupEntry 29}
+
+
+
+
+Freed & Kille Standards Track [Page 19]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ mtaGroupCreationTime OBJECT-TYPE
+ SYNTAX TimeInterval
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Time since this group was first created."
+ ::= {mtaGroupEntry 30}
+
+ mtaGroupHierarchy OBJECT-TYPE
+ SYNTAX INTEGER (-2147483648..2147483647)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Describes how this group fits into the hierarchy. A
+ positive value is interpreted as an mtaGroupIndex
+ value for some other group whose variables include
+ those of this group (and usually others). A negative
+ value is interpreted as a group collection code: Groups
+ with common negative hierarchy values comprise one
+ particular breakdown of MTA activity as a whole. A
+ zero value means that this MIB implementation doesn't
+ implement hierarchy indicators and thus the overall
+ group hierarchy cannot be determined."
+ ::= {mtaGroupEntry 31}
+
+ mtaGroupOldestMessageId OBJECT-TYPE
+ SYNTAX SnmpAdminString
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Message ID of the oldest message in the group's queue.
+ Whenever possible this should be in the form of an
+ RFC 822 msg-id; X.400 may convert X.400 message
+ identifiers to this form by following the rules laid
+ out in RFC2156."
+ ::= {mtaGroupEntry 32}
+
+ mtaGroupLoopsDetected OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A message loop is defined as a situation where the MTA
+ decides that a given message will never be delivered to
+ one or more recipients and instead will continue to
+ loop endlessly through one or more MTAs. This variable
+ counts the number of times the MTA has detected such a
+ situation in conjunction with something associated with
+
+
+
+Freed & Kille Standards Track [Page 20]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ this group since group creation. Note that the
+ mechanism MTAs use to detect loops (e.g., trace field
+ counting, count of references to this MTA in a trace
+ field, examination of DNS or other directory information,
+ etc.), the level at which loops are detected (e.g., per
+ message, per recipient, per directory entry, etc.), and
+ the handling of a loop once it is detected (e.g., looping
+ messages are held, looping messages are bounced or sent
+ to the postmaster, messages that the MTA knows will loop
+ won't be accepted, etc.) vary widely from one MTA to the
+ next and cannot be inferred from this variable."
+ ::= {mtaGroupEntry 33}
+
+ -- The mtaGroupAssociationTable provides a means of correlating
+ -- entries in the network services association table with the
+ -- MTA group responsible for the association.
+
+ mtaGroupAssociationTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF MtaGroupAssociationEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The table holding information regarding the associations
+ for each MTA group."
+ ::= {mta 3}
+
+ mtaGroupAssociationEntry OBJECT-TYPE
+ SYNTAX MtaGroupAssociationEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The entry holding information regarding the associations
+ for each MTA group."
+ INDEX {applIndex, mtaGroupIndex, mtaGroupAssociationIndex}
+ ::= {mtaGroupAssociationTable 1}
+
+ MtaGroupAssociationEntry ::= SEQUENCE {
+ mtaGroupAssociationIndex
+ INTEGER
+ }
+
+ mtaGroupAssociationIndex OBJECT-TYPE
+ SYNTAX INTEGER (1..2147483647)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Reference into association table to allow correlation of
+ this group's active associations with the association table."
+
+
+
+Freed & Kille Standards Track [Page 21]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ ::= {mtaGroupAssociationEntry 1}
+
+ -- The mtaGroupErrorTable gives each group a way of tallying
+ -- the specific errors it has encountered. The mechanism
+ -- defined here uses RFC 1893 status codes to identify
+ -- various specific errors. There are also classes for generic
+ -- errors of various sorts, and the entire mechanism is also
+ -- extensible, in that new error codes can be defined at any
+ -- time.
+
+ mtaGroupErrorTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF MtaGroupErrorEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The table holding information regarding accumulated errors
+ for each MTA group."
+ ::= {mta 5}
+
+ mtaGroupErrorEntry OBJECT-TYPE
+ SYNTAX MtaGroupErrorEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The entry holding information regarding accumulated
+ errors for each MTA group."
+ INDEX {applIndex, mtaGroupIndex, mtaStatusCode}
+ ::= {mtaGroupErrorTable 1}
+
+ MtaGroupErrorEntry ::= SEQUENCE {
+ mtaStatusCode
+ INTEGER (4000000..5999999),
+ mtaGroupInboundErrorCount
+ Counter32,
+ mtaGroupInternalErrorCount
+ Counter32,
+ mtaGroupOutboundErrorCount
+ Counter32
+ }
+
+ mtaGroupInboundErrorCount OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Count of the number of errors of a given type that have
+ been accumulated in association with a particular group
+ while processing incoming messages. In the case of SMTP
+
+
+
+Freed & Kille Standards Track [Page 22]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ these will typically be errors reporting by an SMTP
+ server to the remote client; in the case of X.400
+ these will typically be errors encountered while
+ processing an incoming message."
+ ::= {mtaGroupErrorEntry 1}
+
+ mtaGroupInternalErrorCount OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Count of the number of errors of a given type that have
+ been accumulated in association with a particular group
+ during internal MTA processing."
+ ::= {mtaGroupErrorEntry 2}
+
+ mtaGroupOutboundErrorCount OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Count of the number of errors of a given type that have
+ been accumulated in association with a particular group's
+ outbound connection activities. In the case of an SMTP
+ client these will typically be errors reported while
+ attempting to contact or while communicating with the
+ remote SMTP server. In the case of X.400 these will
+ typically be errors encountered while constructing
+ or attempting to deliver an outgoing message."
+ ::= {mtaGroupErrorEntry 3}
+
+ mtaStatusCode OBJECT-TYPE
+ SYNTAX INTEGER (4000000..5999999)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "An index capable of representing an Enhanced Mail System
+ Status Code. Enhanced Mail System Status Codes are
+ defined in RFC 1893. These codes have the form
+
+ class.subject.detail
+
+ Here 'class' is either 2, 4, or 5 and both 'subject' and
+ 'detail' are integers in the range 0..999. Given a status
+ code the corresponding index value is defined to be
+ ((class * 1000) + subject) * 1000 + detail. Both SMTP
+ error response codes and X.400 reason and diagnostic codes
+ can be mapped into these codes, resulting in a namespace
+
+
+
+Freed & Kille Standards Track [Page 23]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ capable of describing most error conditions a mail system
+ encounters in a generic yet detailed way."
+ ::= {mtaGroupErrorEntry 4}
+
+ -- Conformance information
+
+ mtaConformance OBJECT IDENTIFIER ::= {mta 4}
+
+ mtaGroups OBJECT IDENTIFIER ::= {mtaConformance 1}
+ mtaCompliances OBJECT IDENTIFIER ::= {mtaConformance 2}
+
+
+ -- Compliance statements
+
+ mtaCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for RFC 1566 implementations
+ which support the Mail Monitoring MIB for basic
+ monitoring of MTAs."
+ MODULE -- this module
+ MANDATORY-GROUPS {mtaRFC1566Group}
+ ::= {mtaCompliances 1}
+
+ mtaAssocCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for RFC 1566 implementations
+ which support the Mail Monitoring MIB for monitoring
+ of MTAs and their associations."
+ MODULE -- this module
+ MANDATORY-GROUPS {mtaRFC1566Group, mtaRFC1566AssocGroup}
+ ::= {mtaCompliances 2}
+
+ mtaRFC2249Compliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for RFC 2249 implementations
+ which support the Mail Monitoring MIB for basic
+ monitoring of MTAs."
+ MODULE -- this module
+ MANDATORY-GROUPS {mtaRFC2249Group}
+ ::= {mtaCompliances 5}
+
+ mtaRFC2249AssocCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for RFC 2249 implementations
+
+
+
+Freed & Kille Standards Track [Page 24]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ which support the Mail Monitoring MIB for monitoring of
+ MTAs and their associations."
+ MODULE -- this module
+ MANDATORY-GROUPS {mtaRFC2249Group, mtaRFC2249AssocGroup}
+ ::= {mtaCompliances 6}
+
+ mtaRFC2249ErrorCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for RFC 2249 implementations
+ which support the Mail Monitoring MIB for monitoring of
+ MTAs and detailed errors."
+ MODULE -- this module
+ MANDATORY-GROUPS {mtaRFC2249Group, mtaRFC2249ErrorGroup}
+ ::= {mtaCompliances 7}
+
+ mtaRFC2249FullCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for RFC 2249 implementations
+ which support the full Mail Monitoring MIB for
+ monitoring of MTAs, associations, and detailed errors."
+ MODULE -- this module
+ MANDATORY-GROUPS {mtaRFC2249Group, mtaRFC2249AssocGroup,
+ mtaRFC2249ErrorGroup}
+ ::= {mtaCompliances 8}
+
+ mtaRFC2789Compliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for RFC 2789 implementations
+ which support the Mail Monitoring MIB for basic
+ monitoring of MTAs."
+ MODULE -- this module
+ MANDATORY-GROUPS {mtaRFC2789Group}
+ ::= {mtaCompliances 9}
+
+ mtaRFC2789AssocCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for RFC 2789 implementations
+ which support the Mail Monitoring MIB for monitoring of
+ MTAs and their associations."
+ MODULE -- this module
+ MANDATORY-GROUPS {mtaRFC2789Group, mtaRFC2789AssocGroup}
+ ::= {mtaCompliances 10}
+
+ mtaRFC2789ErrorCompliance MODULE-COMPLIANCE
+
+
+
+Freed & Kille Standards Track [Page 25]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for RFC 2789 implementations
+ which support the Mail Monitoring MIB for monitoring of
+ MTAs and detailed errors."
+ MODULE -- this module
+ MANDATORY-GROUPS {mtaRFC2789Group, mtaRFC2789ErrorGroup}
+ ::= {mtaCompliances 11}
+
+ mtaRFC2789FullCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for RFC 2789 implementations
+ which support the full Mail Monitoring MIB for
+ monitoring of MTAs, associations, and detailed errors."
+ MODULE -- this module
+ MANDATORY-GROUPS {mtaRFC2789Group, mtaRFC2789AssocGroup,
+ mtaRFC2789ErrorGroup}
+ ::= {mtaCompliances 12}
+
+ -- Units of conformance
+
+ mtaRFC1566Group OBJECT-GROUP
+ OBJECTS {
+ mtaReceivedMessages, mtaStoredMessages,
+ mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume,
+ mtaTransmittedVolume, mtaReceivedRecipients,
+ mtaStoredRecipients, mtaTransmittedRecipients,
+ mtaGroupReceivedMessages, mtaGroupRejectedMessages,
+ mtaGroupStoredMessages, mtaGroupTransmittedMessages,
+ mtaGroupReceivedVolume, mtaGroupStoredVolume,
+ mtaGroupTransmittedVolume, mtaGroupReceivedRecipients,
+ mtaGroupStoredRecipients, mtaGroupTransmittedRecipients,
+ mtaGroupOldestMessageStored, mtaGroupInboundAssociations,
+ mtaGroupOutboundAssociations,
+ mtaGroupAccumulatedInboundAssociations,
+ mtaGroupAccumulatedOutboundAssociations,
+ mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity,
+ mtaGroupRejectedInboundAssociations,
+ mtaGroupFailedOutboundAssociations,
+ mtaGroupInboundRejectionReason,
+ mtaGroupOutboundConnectFailureReason,
+ mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName}
+ STATUS current
+ DESCRIPTION
+ "A collection of objects providing basic monitoring of MTAs.
+ This is the original set of such objects defined in RFC
+ 1566."
+
+
+
+Freed & Kille Standards Track [Page 26]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ ::= {mtaGroups 10}
+
+ mtaRFC1566AssocGroup OBJECT-GROUP
+ OBJECTS {
+ mtaGroupAssociationIndex}
+ STATUS current
+ DESCRIPTION
+ "A collection of objects providing monitoring of MTA
+ associations. This is the original set of such objects
+ defined in RFC 1566."
+ ::= {mtaGroups 11}
+
+ mtaRFC2249Group OBJECT-GROUP
+ OBJECTS {
+ mtaReceivedMessages, mtaStoredMessages,
+ mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume,
+ mtaTransmittedVolume, mtaReceivedRecipients,
+ mtaStoredRecipients, mtaTransmittedRecipients,
+ mtaSuccessfulConvertedMessages, mtaFailedConvertedMessages,
+ mtaGroupReceivedMessages, mtaGroupRejectedMessages,
+ mtaGroupStoredMessages, mtaGroupTransmittedMessages,
+ mtaGroupReceivedVolume, mtaGroupStoredVolume,
+ mtaGroupTransmittedVolume, mtaGroupReceivedRecipients,
+ mtaGroupStoredRecipients, mtaGroupTransmittedRecipients,
+ mtaGroupOldestMessageStored, mtaGroupInboundAssociations,
+ mtaGroupOutboundAssociations, mtaLoopsDetected,
+ mtaGroupAccumulatedInboundAssociations,
+ mtaGroupAccumulatedOutboundAssociations,
+ mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity,
+ mtaGroupLastOutboundAssociationAttempt,
+ mtaGroupRejectedInboundAssociations,
+ mtaGroupFailedOutboundAssociations,
+ mtaGroupInboundRejectionReason,
+ mtaGroupOutboundConnectFailureReason,
+ mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName,
+ mtaGroupSuccessfulConvertedMessages,
+ mtaGroupFailedConvertedMessages, mtaGroupDescription,
+ mtaGroupURL, mtaGroupCreationTime, mtaGroupHierarchy,
+ mtaGroupOldestMessageId, mtaGroupLoopsDetected}
+ STATUS current
+ DESCRIPTION
+ "A collection of objects providing basic monitoring of MTAs.
+ This group was originally defined in RFC 2249."
+ ::= {mtaGroups 4}
+
+ mtaRFC2249AssocGroup OBJECT-GROUP
+ OBJECTS {
+ mtaGroupAssociationIndex}
+
+
+
+Freed & Kille Standards Track [Page 27]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ STATUS current
+ DESCRIPTION
+ "A collection of objects providing monitoring of MTA
+ associations. This group was originally defined in RFC
+ 2249."
+ ::= {mtaGroups 5}
+
+ mtaRFC2249ErrorGroup OBJECT-GROUP
+ OBJECTS {
+ mtaGroupInboundErrorCount, mtaGroupInternalErrorCount,
+ mtaGroupOutboundErrorCount}
+ STATUS current
+ DESCRIPTION
+ "A collection of objects providing monitoring of
+ detailed MTA errors. This group was originally defined
+ in RFC 2249."
+ ::= {mtaGroups 6}
+
+ mtaRFC2789Group OBJECT-GROUP
+ OBJECTS {
+ mtaReceivedMessages, mtaStoredMessages,
+ mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume,
+ mtaTransmittedVolume, mtaReceivedRecipients,
+ mtaStoredRecipients, mtaTransmittedRecipients,
+ mtaSuccessfulConvertedMessages, mtaFailedConvertedMessages,
+ mtaGroupReceivedMessages, mtaGroupRejectedMessages,
+ mtaGroupStoredMessages, mtaGroupTransmittedMessages,
+ mtaGroupReceivedVolume, mtaGroupStoredVolume,
+ mtaGroupTransmittedVolume, mtaGroupReceivedRecipients,
+ mtaGroupStoredRecipients, mtaGroupTransmittedRecipients,
+ mtaGroupOldestMessageStored, mtaGroupInboundAssociations,
+ mtaGroupOutboundAssociations, mtaLoopsDetected,
+ mtaGroupAccumulatedInboundAssociations,
+ mtaGroupAccumulatedOutboundAssociations,
+ mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity,
+ mtaGroupLastOutboundAssociationAttempt,
+ mtaGroupRejectedInboundAssociations,
+ mtaGroupFailedOutboundAssociations,
+ mtaGroupInboundRejectionReason,
+ mtaGroupOutboundConnectFailureReason,
+ mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName,
+ mtaGroupSuccessfulConvertedMessages,
+ mtaGroupFailedConvertedMessages, mtaGroupDescription,
+ mtaGroupURL, mtaGroupCreationTime, mtaGroupHierarchy,
+ mtaGroupOldestMessageId, mtaGroupLoopsDetected}
+ STATUS current
+ DESCRIPTION
+ "A collection of objects providing basic monitoring of MTAs.
+
+
+
+Freed & Kille Standards Track [Page 28]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ This is the appropriate group for RFC 2789."
+ ::= {mtaGroups 7}
+
+ mtaRFC2789AssocGroup OBJECT-GROUP
+ OBJECTS {
+ mtaGroupAssociationIndex}
+ STATUS current
+ DESCRIPTION
+ "A collection of objects providing monitoring of MTA
+ associations. This is the appropriate group for RFC
+ 2789 association monitoring."
+ ::= {mtaGroups 8}
+
+ mtaRFC2789ErrorGroup OBJECT-GROUP
+ OBJECTS {
+ mtaGroupInboundErrorCount, mtaGroupInternalErrorCount,
+ mtaGroupOutboundErrorCount}
+ STATUS current
+ DESCRIPTION
+ "A collection of objects providing monitoring of
+ detailed MTA errors. This is the appropriate group
+ for RFC 2789 error monitoring."
+ ::= {mtaGroups 9}
+
+ END
+
+5. Changes made since RFC 2249
+
+ This revision corrects a number of minor technical errors in the
+ construction of the mail monitoring MIB in RFC 2249 [18]:
+
+ (1) All DisplayStrings have been changed to SnmpAdminStrings,
+
+ (2) the conformance groups for different versions of this MIB have
+ been corrected,
+
+ (3) the required mtaStatusCode entry has been added to
+ MtaGroupErrorEntry (which does not affect the bits on the wire in
+ any way), and
+
+ (4) the recommendation that an empty string be returned if the last
+ operation was successful has been removed from
+ mtaGroupInboundRejectionReason and
+ mtaGroupOutboundConnectFailureReason as it conflicts with the
+ stated purpose of these variables.
+
+
+
+
+
+
+Freed & Kille Standards Track [Page 29]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+6. Acknowledgements
+
+ This document is a work product of the Mail and Directory Management
+ (MADMAN) Working Group of the IETF. It is based on an earlier MIB
+ designed by S. Kille, T. Lenggenhager, D. Partain, and W. Yeong. The
+ Electronic Mail Association's TSC committee was instrumental in
+ providing feedback on and suggesting enhancements to RFC 1566 [19]
+ that have led to the present document.
+
+7. References
+
+ [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
+ Describing SNMP Management Frameworks", RFC 2571, April 1999.
+
+ [2] Rose, M. and K. McCloghrie, "Structure and Identification of
+ Management Information for TCP/IP-based Internets", STD 16, RFC
+ 1155, May 1990.
+
+ [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
+ RFC 1212, March 1991.
+
+ [4] Rose, M., "A Convention for Defining Traps for use with the
+ SNMP", RFC 1215, March 1991.
+
+ [5] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of
+ Management Information Version 2 (SMIv2)", STD 58, RFC 2578,
+ April 1999.
+
+ [6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
+ Conventions for SMIv2", STD 58, RFC 2579, April 1999.
+
+ [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance
+ Statements for SMIv2", STD 58, RFC 2580, April 1999.
+
+ [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
+ Network Management Protocol", STD 15, RFC 1157, May 1990.
+
+ [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+ "Introduction to Community-based SNMPv2", RFC 1901, January
+ 1996.
+
+ [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
+ Mappings for Version 2 of the Simple Network Management Protocol
+ (SNMPv2)", RFC 1906, January 1996.
+
+ [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
+ Processing and Dispatching for the Simple Network Management
+ Protocol (SNMP)", RFC 2572, April 1999.
+
+
+
+Freed & Kille Standards Track [Page 30]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
+ for version 3 of the Simple Network Management Protocol
+ (SNMPv3)", RFC 2574, April 1999.
+
+ [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
+ Operations for Version 2 of the Simple Network Management
+ Protocol (SNMPv2)", RFC 1905, January 1996.
+
+ [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC
+ 2573, April 1999.
+
+ [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
+ Control Model (VACM) for the Simple Network Management Protocol
+ (SNMP)", RFC 2575, April 1999.
+
+ [16] Freed, N. and S. Kille, "Network Services Monitoring MIB", RFC
+ 2788, March 2000.
+
+ [17] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished
+ Names", RFC 2253, December 1997.
+
+ [18] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 2249, January
+ 1998.
+
+ [19] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 1566, January
+ 1994.
+
+ [20] Kille, S., "Mapping between X.400(1988) and RFC 822/MIME", RFC
+ 2156, January 1998.
+
+ [21] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Message", STD 11, RFC 822, August 1982.
+
+ [22] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
+ January 1996.
+
+8. Security Considerations
+
+ There are no management objects defined in this MIB that have a MAX-
+ ACCESS clause of read-write and/or read-create. So, if this MIB is
+ implemented correctly, then there is no risk that an intruder can
+ alter or create any management objects of this MIB via direct SNMP
+ SET operations.
+
+
+
+
+
+
+
+Freed & Kille Standards Track [Page 31]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+ However, this MIB does provide passive information about the
+ existence, type, and configuration of applications on a given host
+ that could potentially indicate some sort of vulnerability. Finally,
+ the information MIB provides about network usage could be used to
+ analyze network traffic patterns.
+
+ SNMPv1 by itself is not a secure environment. Even if the network
+ itself is secure (for example by using IPSec), even then, there is no
+ control as to who on the secure network is allowed to access and
+ GET/SET (read/change/create/delete) the objects in this MIB.
+
+ It is recommended that the implementers consider the security
+ features as provided by the SNMPv3 framework. Specifically, the use
+ of the User-based Security Model RFC 2574 [12] and the View-based
+ Access Control Model RFC 2575 [15] is recommended.
+
+ It is then a customer/user responsibility to ensure that the SNMP
+ entity giving access to an instance of this MIB, is properly
+ configured to give access to the objects only to those principals
+ (users) that have legitimate rights to indeed GET or SET
+ (change/create/delete) them.
+
+9. Author and Chair Addresses
+
+ Ned Freed
+ Innosoft International, Inc.
+ 1050 Lakes Drive
+ West Covina, CA 91790
+ USA
+
+ Phone: +1 626 919 3600
+ Fax: +1 626 919 3614
+ EMail: ned.freed@innosoft.com
+
+
+ Steve Kille, MADMAN WG Chair
+ MessagingDirect Ltd.
+ The Dome, The Square
+ Richmond TW9 1DT
+ UK
+
+ Phone: +44 20 8332 9091
+ EMail: Steve.Kille@MessagingDirect.com
+
+
+
+
+
+
+
+
+Freed & Kille Standards Track [Page 32]
+
+RFC 2789 Mail Monitoring MIB March 2000
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed & Kille Standards Track [Page 33]
+