rfc2789.mib

wm PNE 3.3 source code, running at more than vxworks6.x version.

   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: [phone]
         Fax: [phone]

         E-Mail: [e-mail]"
      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
         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}

   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}

   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
      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
      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
         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
   -- 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
          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,