rfc2789.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,781 行 · 第 1/5 页

      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