rfc2249.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                          N. Freed
Request for Comments: 2249                                     Innosoft
Obsoletes: 1566                                                S. Kille
Category: Standards Track                              ISODE Consortium
                                                           January 1998


                          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 (1998).  All Rights Reserved.

1.  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 [8] to allow monitoring of Message Transfer Agents (MTAs). It may
   also be used to monitor MTA components within gateways.

2.  Table of Contents

   1 Introduction .............................................    1
   2 Table of Contents ........................................    1
   3 The SNMPv2 Network Management Framework ..................    2
   3.1 Object Definitions .....................................    2
   4 Message Flow Model .......................................    2
   5 MTA Objects ..............................................    3
   6 Definitions ..............................................    4
   7 Changes made since RFC 1566 ..............................   25
   8 Acknowledgements .........................................   26
   9 References ...............................................   26
   10 Security Considerations .................................   27
   11 Author and Chair Addresses ..............................   27
   12 Full Copyright Statement ................................   28






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


3.  The SNMPv2 Network Management Framework

   The SNMPv2 Network Management Framework consists of seven major
   components. They are:

   o    RFC 1902 [1] which defines the SMI, the mechanisms used for
        describing and naming objects for the purpose of management.

   o    RFC 1903 [2] defines textual conventions for SNMPv2.

   o    RFC 1904 [3] defines conformance statements for SNMPv2.

   o    RFC 1905 [4] defines  transport mappings for SNMPv2.

   o    RFC 1906 [5] defines the protocol operations used for network
        access to managed objects.

   o    RFC 1907 [6] defines the Management Information Base for SNMPv2.

   o    RFC 1908 [7] specifies coexistance between SNMP and SNMPv2.

   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

3.1.  Object Definitions

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB. Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1)
   defined in the SMI.  In particular, each object type is named by an
   OBJECT IDENTIFIER, an administratively assigned name. The object type
   together with an object instance serves to uniquely identify a
   specific instantiation of the object.  For human convenience, we
   often use a textual string, termed the descriptor, to refer to the
   object type.

4.  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 occuring 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.



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


          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.

5.  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 a separate document [8].

   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.




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


6.  Definitions

MTA-MIB DEFINITIONS ::= BEGIN

IMPORTS
    OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY, mib-2
      FROM SNMPv2-SMI
    DisplayString, TimeInterval
      FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP
      FROM SNMPv2-CONF
    applIndex, URLString
      FROM NETWORK-SERVICES-MIB;

mta MODULE-IDENTITY
    LAST-UPDATED "9708170000Z"
    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 "9311280000Z"
    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}

mtaStatusCode OBJECT-TYPE
    SYNTAX INTEGER (4000000..5999999)
    MAX-ACCESS not-accessible
    STATUS current



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


    DESCRIPTION
      "An index capable of representing an Enhanced Mail System
       Status Code.  Enhanced Mail System Status Codes are
       defined in RFC 1893 [14].  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
       capable of describing most error conditions a mail system
       encounters in a generic yet detailed way."
    ::= {mta 6}

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



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


      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



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


       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