rfc2789.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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: [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



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