rfc2249.txt

RFC 的详细文档！

Freed & Kille               Standards Track                     [Page 7]

RFC 2249                  Mail Monitoring MIB               January 1998


       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}




Freed & Kille               Standards Track                     [Page 8]

RFC 2249                  Mail Monitoring MIB               January 1998


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.



Freed & Kille               Standards Track                     [Page 9]

RFC 2249                  Mail Monitoring MIB               January 1998


-- 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 all unused counters would 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 differents "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 abstration.

-- 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.  Deletation 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.

mtaGroupTable OBJECT-TYPE



Freed & Kille               Standards Track                    [Page 10]

RFC 2249                  Mail Monitoring MIB               January 1998


    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



Freed & Kille               Standards Track                    [Page 11]

RFC 2249                  Mail Monitoring MIB               January 1998


        Counter32,
    mtaGroupLastInboundActivity
        TimeInterval,
    mtaGroupLastOutboundActivity
        TimeInterval,
    mtaGroupLastOutboundAssociationAttempt
        TimeInterval,
    mtaGroupRejectedInboundAssociations
        Counter32,
    mtaGroupFailedOutboundAssociations
        Counter32,
    mtaGroupInboundRejectionReason
        DisplayString,
    mtaGroupOutboundConnectFailureReason
        DisplayString,
    mtaGroupScheduledRetry
        TimeInterval,
    mtaGroupMailProtocol
        OBJECT IDENTIFIER,
    mtaGroupName
        DisplayString,
    mtaGroupSuccessfulConvertedMessages
        Counter32,
    mtaGroupFailedConvertedMessages
        Counter32,
    mtaGroupDescription
        DisplayString,
    mtaGroupURL
        URLString,
    mtaGroupCreationTime
        TimeInterval,
    mtaGroupHierarchy
        INTEGER,
    mtaGroupOldestMessageId
        DisplayString,
    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



Freed & Kille               Standards Track                    [Page 12]

RFC 2249                  Mail Monitoring MIB               January 1998


    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
      "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."



Freed & Kille               Standards Track                    [Page 13]

RFC 2249                  Mail Monitoring MIB               January 1998


    ::= {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
    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



Freed & Kille               Standards Track                    [Page 14]