doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc2249.txt b/doc/rfc/rfc2249.txt
new file mode 100644
index 0000000..ccaf930
--- /dev/null
+++ b/doc/rfc/rfc2249.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+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: +1 626 919 3600
+       Fax: +1 626 919 3614
+
+       E-Mail: ned.freed@innosoft.com"
+    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
+
+
+
+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]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+      "The total number of recipients specified in all messages
+       currently stored in this group's queue.  Recipients this
+       MTA has no responsibility for should not be counted."
+    ::= {mtaGroupEntry 10}
+
+mtaGroupTransmittedRecipients OBJECT-TYPE
+    SYNTAX Counter32
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "The total number of recipients specified in all messages
+       transmitted by this group since group creation.
+       Recipients this MTA had no responsibility for should not
+       be counted."
+    ::= {mtaGroupEntry 11}
+
+mtaGroupOldestMessageStored OBJECT-TYPE
+    SYNTAX TimeInterval
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "Time since the oldest message in this group's queue was
+       placed in the queue."
+    ::= {mtaGroupEntry 12}
+
+mtaGroupInboundAssociations OBJECT-TYPE
+    SYNTAX Gauge32
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "The number of current associations to the group, where the
+       group is the responder."
+    ::= {mtaGroupEntry 13}
+
+mtaGroupOutboundAssociations OBJECT-TYPE
+    SYNTAX Gauge32
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "The number of current associations to the group, where the
+      group is the initiator."
+    ::= {mtaGroupEntry 14}
+
+mtaGroupAccumulatedInboundAssociations OBJECT-TYPE
+    SYNTAX Counter32
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+
+
+
+Freed & Kille               Standards Track                    [Page 15]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+      "The total number of associations to the group since
+      group creation, where the MTA was the responder."
+    ::= {mtaGroupEntry 15}
+
+mtaGroupAccumulatedOutboundAssociations OBJECT-TYPE
+    SYNTAX Counter32
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "The total number of associations from the group since
+       group creation, where the MTA was the initiator."
+    ::= {mtaGroupEntry 16}
+
+mtaGroupLastInboundActivity OBJECT-TYPE
+    SYNTAX TimeInterval
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "Time since the last time that this group had an active
+      inbound association for purposes of message reception."
+    ::= {mtaGroupEntry 17}
+
+mtaGroupLastOutboundActivity OBJECT-TYPE
+    SYNTAX TimeInterval
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "Time since the last time that this group had a
+       successful outbound association for purposes of
+       message delivery."
+    ::= {mtaGroupEntry 18}
+
+mtaGroupLastOutboundAssociationAttempt OBJECT-TYPE
+    SYNTAX TimeInterval
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "Time since the last time that this group attempted
+       to make an outbound association for purposes of
+       message delivery."
+    ::= {mtaGroupEntry 34}
+
+mtaGroupRejectedInboundAssociations OBJECT-TYPE
+    SYNTAX Counter32
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "The total number of inbound associations the group has
+
+
+
+Freed & Kille               Standards Track                    [Page 16]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+      rejected, since group creation.  Rejected associations
+      are not counted in the accumulated association totals."
+    ::= {mtaGroupEntry 19}
+
+mtaGroupFailedOutboundAssociations OBJECT-TYPE
+    SYNTAX Counter32
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "The total number associations where the group was the
+      initiator and association establishment has failed,
+      since group creation.  Failed associations are
+      not counted in the accumulated association totals."
+    ::= {mtaGroupEntry 20}
+
+mtaGroupInboundRejectionReason OBJECT-TYPE
+    SYNTAX DisplayString
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "The failure reason, if any, for the last association this
+      group refused to respond to. An empty string indicates that
+      the last attempt was successful.  If no association attempt
+      has been made since the MTA was initialized the value
+      should be 'never'."
+    ::= {mtaGroupEntry 21}
+
+mtaGroupOutboundConnectFailureReason OBJECT-TYPE
+    SYNTAX DisplayString
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "The failure reason, if any, for the last association attempt
+      this group initiated. An empty string indicates that the last
+      attempt was successful.  If no association attempt has been
+      made since the MTA was initialized the value should be
+      'never'."
+    ::= {mtaGroupEntry 22}
+
+mtaGroupScheduledRetry OBJECT-TYPE
+    SYNTAX TimeInterval
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "The time when this group is scheduled to next attempt to
+       make an association."
+    ::= {mtaGroupEntry 23}
+
+
+
+
+Freed & Kille               Standards Track                    [Page 17]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+mtaGroupMailProtocol OBJECT-TYPE
+    SYNTAX OBJECT IDENTIFIER
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "An identification of the protocol being used by this group.
+      For an group employing OSI protocols, this will be the
+      Application Context.  For Internet applications, the IANA
+      maintains a registry of the OIDs which correspond to well-known
+      message transfer protocols.  If the application protocol is
+      not listed in the registry, an OID value of the form
+      {applTCPProtoID port} or {applUDProtoID port} are used for
+      TCP-based and UDP-based protocols, respectively.  In either
+      case 'port' corresponds to the primary port number being
+      used by the group.  applTCPProtoID and applUDPProtoID are
+      defined in [8]."
+    ::= {mtaGroupEntry 24}
+
+mtaGroupName OBJECT-TYPE
+    SYNTAX DisplayString
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "A descriptive name for the group. If this group connects to
+       a single remote MTA this should be the name of that MTA. If
+       this in turn is an Internet MTA this should be the domain
+       name.  For an OSI MTA it should be the string encoded
+       distinguished name of the managed object using the format
+       defined in RFC 1779 [9]. For X.400(1984) MTAs which do not
+       have a Distinguished Name, the RFC 1327 [12] syntax
+       'mta in globalid' should be used."
+    ::= {mtaGroupEntry 25}
+
+mtaGroupSuccessfulConvertedMessages 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 in this group
+       since group creation."
+    ::= {mtaGroupEntry 26}
+
+mtaGroupFailedConvertedMessages OBJECT-TYPE
+    SYNTAX Counter32
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+
+
+
+Freed & Kille               Standards Track                    [Page 18]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+      "The number of messages for which an unsuccessful
+       attempt was made to convert them from one form to
+       another in this group since group creation."
+    ::= {mtaGroupEntry 27}
+
+mtaGroupDescription OBJECT-TYPE
+    SYNTAX DisplayString
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "A description of the group's purpose.  This information is
+       intended to identify the group in a status display."
+    ::= {mtaGroupEntry 28}
+
+mtaGroupURL OBJECT-TYPE
+    SYNTAX URLString
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "A URL pointing to a description of the group.  This
+       information is intended to identify and briefly describe
+       the group in a status display."
+    ::= {mtaGroupEntry 29}
+
+mtaGroupCreationTime OBJECT-TYPE
+    SYNTAX TimeInterval
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "Time since this group was first created."
+    ::= {mtaGroupEntry 30}
+
+mtaGroupHierarchy OBJECT-TYPE
+    SYNTAX INTEGER (-2147483648..2147483647)
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "Describes how this group fits into the hierarchy. A
+       positive value is interpreted as an mtaGroupIndex
+       value for some other group whose variables include
+       those of this group (and usually others). A negative
+       value is interpreted as a group collection code: Groups
+       with common negative hierarchy values comprise one
+       particular breakdown of MTA activity as a whole. A
+       zero value means that this MIB implementation doesn't
+       implement hierarchy indicators and thus the overall
+       group hierarchy cannot be determined."
+    ::= {mtaGroupEntry 31}
+
+
+
+Freed & Kille               Standards Track                    [Page 19]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+mtaGroupOldestMessageId OBJECT-TYPE
+    SYNTAX DisplayString
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "Message ID of the oldest message in the group's queue.
+       Whenever possible this should be in the form of an
+       RFC 822 [13] msg-id; X.400 may convert X.400 message
+       identifiers to this form by following the rules laid
+       out in RFC1327 [12]."
+    ::= {mtaGroupEntry 32}
+
+mtaGroupLoopsDetected 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 in conjunction with something associated with
+       this group since group creation.  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."
+    ::= {mtaGroupEntry 33}
+
+-- The mtaGroupAssociationTable provides a means of correlating
+-- entries in the network services association table with the
+-- MTA group responsible for the association.
+
+
+mtaGroupAssociationTable OBJECT-TYPE
+    SYNTAX SEQUENCE OF MtaGroupAssociationEntry
+    MAX-ACCESS not-accessible
+    STATUS current
+    DESCRIPTION
+      "The table holding information regarding the associations
+       for each MTA group."
+
+
+
+Freed & Kille               Standards Track                    [Page 20]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+    ::= {mta 3}
+
+mtaGroupAssociationEntry OBJECT-TYPE
+    SYNTAX MtaGroupAssociationEntry
+    MAX-ACCESS not-accessible
+    STATUS current
+    DESCRIPTION
+      "The entry holding information regarding the associations
+       for each MTA group."
+    INDEX {applIndex, mtaGroupIndex, mtaGroupAssociationIndex}
+    ::= {mtaGroupAssociationTable 1}
+
+MtaGroupAssociationEntry ::= SEQUENCE {
+    mtaGroupAssociationIndex
+        INTEGER
+}
+
+mtaGroupAssociationIndex OBJECT-TYPE
+    SYNTAX INTEGER (1..2147483647)
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "Reference into association table to allow correlation of
+       this group's active associations with the association table."
+    ::= {mtaGroupAssociationEntry 1}
+
+-- The mtaGroupErrorTable gives each group a way of tallying
+-- the specific errors it has encountered.  The mechanism
+-- defined here uses RFC 1893 [14] status codes to identify
+-- various specific errors. There are also classes for generic
+-- errors of various sorts, and the entire mechanism is also
+-- extensible, in that new error codes can be defined at any
+-- time.
+
+mtaGroupErrorTable OBJECT-TYPE
+    SYNTAX SEQUENCE OF MtaGroupErrorEntry
+    MAX-ACCESS not-accessible
+    STATUS current
+    DESCRIPTION
+      "The table holding information regarding accumulated errors
+       for each MTA group."
+    ::= {mta 5}
+
+mtaGroupErrorEntry OBJECT-TYPE
+    SYNTAX MtaGroupErrorEntry
+    MAX-ACCESS not-accessible
+    STATUS current
+    DESCRIPTION
+
+
+
+Freed & Kille               Standards Track                    [Page 21]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+      "The entry holding information regarding accumulated
+       errors for each MTA group."
+    INDEX {applIndex, mtaGroupIndex, mtaStatusCode}
+    ::= {mtaGroupErrorTable 1}
+
+MtaGroupErrorEntry ::= SEQUENCE {
+    mtaGroupInboundErrorCount
+        Counter32,
+    mtaGroupInternalErrorCount
+        Counter32,
+    mtaGroupOutboundErrorCount
+        Counter32
+}
+
+mtaGroupInboundErrorCount OBJECT-TYPE
+    SYNTAX Counter32
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "Count of the number of errors of a given type that have
+       been accumulated in assocation with a particular group
+       while processing incoming messages. In the case of SMTP
+       these will typically be errors reporting by an SMTP
+       server to the remote client; in the case of X.400
+       these will typically be errors encountered while
+       processing an incoming message."
+    ::= {mtaGroupErrorEntry 1}
+
+
+mtaGroupInternalErrorCount OBJECT-TYPE
+    SYNTAX Counter32
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "Count of the number of errors of a given type that have
+       been accumulated in assocation with a particular group
+       during internal MTA processing."
+    ::= {mtaGroupErrorEntry 2}
+
+mtaGroupOutboundErrorCount OBJECT-TYPE
+    SYNTAX Counter32
+    MAX-ACCESS read-only
+    STATUS current
+    DESCRIPTION
+      "Count of the number of errors of a given type that have
+       been accumulated in assocation with a particular group's
+       outbound connection activities. In the case of an SMTP
+       client these will typically be errors reported while
+
+
+
+Freed & Kille               Standards Track                    [Page 22]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+       attempting to contact or while communicating with the
+       remote SMTP server. In the case of X.400 these will
+       typically be errors encountered while constructing
+       or attempting to deliver an outgoing message."
+    ::= {mtaGroupErrorEntry 3}
+
+-- Conformance information
+
+mtaConformance OBJECT IDENTIFIER ::= {mta 4}
+
+mtaGroups      OBJECT IDENTIFIER ::= {mtaConformance 1}
+mtaCompliances OBJECT IDENTIFIER ::= {mtaConformance 2}
+
+-- Compliance statements
+
+mtaCompliance MODULE-COMPLIANCE
+    STATUS current
+    DESCRIPTION
+      "The compliance statement for SNMPv2 entities which
+       implement the Mail Monitoring MIB for basic
+       monitoring of MTAs."
+    MODULE  -- this module
+      MANDATORY-GROUPS {mtaGroup}
+    ::= {mtaCompliances 1}
+
+mtaAssocCompliance MODULE-COMPLIANCE
+    STATUS current
+    DESCRIPTION
+      "The compliance statement for SNMPv2 entities which
+       implement the Mail Monitoring MIB for monitoring of
+       MTAs and their associations."
+    MODULE  -- this module
+      MANDATORY-GROUPS {mtaGroup, mtaAssocGroup}
+    ::= {mtaCompliances 2}
+
+mtaErrorCompliance MODULE-COMPLIANCE
+    STATUS current
+    DESCRIPTION
+      "The compliance statement for SNMPv2 entities which
+       implement the Mail Monitoring MIB for monitoring of
+       MTAs and detailed errors."
+    MODULE  -- this module
+      MANDATORY-GROUPS {mtaGroup, mtaErrorGroup}
+    ::= {mtaCompliances 3}
+
+mtaFullCompliance MODULE-COMPLIANCE
+    STATUS current
+    DESCRIPTION
+
+
+
+Freed & Kille               Standards Track                    [Page 23]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+      "The compliance statement for SNMPv2 entities which
+       implement the full Mail Monitoring MIB for monitoring
+       of MTAs, associations, and detailed errors."
+    MODULE  -- this module
+      MANDATORY-GROUPS {mtaGroup, mtaAssocGroup, mtaErrorGroup}
+    ::= {mtaCompliances 4}
+
+-- Units of conformance
+
+mtaGroup OBJECT-GROUP
+    OBJECTS {
+      mtaReceivedMessages, mtaStoredMessages,
+      mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume,
+      mtaTransmittedVolume, mtaReceivedRecipients,
+      mtaStoredRecipients, mtaTransmittedRecipients,
+      mtaSuccessfulConvertedMessages, mtaFailedConvertedMessages,
+      mtaGroupReceivedMessages, mtaGroupRejectedMessages,
+      mtaGroupStoredMessages, mtaGroupTransmittedMessages,
+      mtaGroupReceivedVolume, mtaGroupStoredVolume,
+      mtaGroupTransmittedVolume, mtaGroupReceivedRecipients,
+      mtaGroupStoredRecipients, mtaGroupTransmittedRecipients,
+      mtaGroupOldestMessageStored, mtaGroupInboundAssociations,
+      mtaGroupOutboundAssociations, mtaLoopsDetected,
+      mtaGroupAccumulatedInboundAssociations,
+      mtaGroupAccumulatedOutboundAssociations,
+      mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity,
+      mtaGroupLastOutboundAssociationAttempt,
+      mtaGroupRejectedInboundAssociations,
+      mtaGroupFailedOutboundAssociations,
+      mtaGroupInboundRejectionReason,
+      mtaGroupOutboundConnectFailureReason,
+      mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName,
+      mtaGroupSuccessfulConvertedMessages,
+      mtaGroupFailedConvertedMessages, mtaGroupDescription,
+      mtaGroupURL, mtaGroupCreationTime, mtaGroupHierarchy,
+      mtaGroupOldestMessageId, mtaGroupLoopsDetected}
+    STATUS current
+    DESCRIPTION
+      "A collection of objects providing basic monitoring of MTAs."
+    ::= {mtaGroups 1}
+
+mtaAssocGroup OBJECT-GROUP
+    OBJECTS {
+      mtaGroupAssociationIndex}
+    STATUS current
+    DESCRIPTION
+      "A collection of objects providing monitoring of MTA
+       associations."
+
+
+
+Freed & Kille               Standards Track                    [Page 24]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+    ::= {mtaGroups 2}
+
+mtaErrorGroup OBJECT-GROUP
+    OBJECTS {
+      mtaGroupInboundErrorCount, mtaGroupInternalErrorCount,
+      mtaGroupOutboundErrorCount}
+    STATUS current
+    DESCRIPTION
+      "A collection of objects providing monitoring of
+       detailed MTA errors."
+    ::= {mtaGroups 3}
+
+END
+
+7.  Changes made since RFC 1566
+
+   The only changes made to this document since it was issued as RFC
+   1566 [11] are the following:
+
+    (1)   A number of DESCRIPTION fields have been reworded, hopefully
+          making them clearer.
+
+    (2)   mtaGroupDescription and mtaGroupURL fields have been added.
+          These fields are intended to identify and describe the MTA and
+          the various MTA groups.
+
+    (3)   The time since the last outbound association attempt is now
+          distinct from the time since the last successfuol outbound
+          association attempt.
+
+    (4)   Conversion operation counters have been added.
+
+    (5)   A mechanism to explicitly describe group hierarchies has been
+          added.
+
+    (6)   A mechanism to count specific sorts of errors has been added.
+
+    (7)   A field for the ID of the oldest message in a group's queue
+          has been added.
+
+    (8)   Per-MTA and per-group message loop counters have been added.
+
+    (9)   A new table has been added to keep track of any errors an MTA
+          encounters.
+
+
+
+
+
+
+
+Freed & Kille               Standards Track                    [Page 25]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+8.  Acknowledgements
+
+   This document is a work product of the Mail and Directory Management
+   (MADMAN) Working Group of the IETF. It is based on an earlier MIB
+   designed by S. Kille, T. Lenggenhager, D. Partain, and W. Yeong. The
+   Electronic Mail Association's TSC committee was instrumental in
+   providing feedback on and suggesting enhancements to RFC 1566 [11]
+   that have led to the present document.
+
+9.  References
+
+   [1]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+        S. Waldbusser, "Structure of Management Information for Version
+        2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
+        January 1996.
+
+   [2]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+        S. Waldbusser, "Textual Conventions for Version 2 of the Simple
+        Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
+
+   [3]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+        S. Waldbusser, "Conformance Statements for Version 2 of the
+        Simple Network Management Protocol (SNMPv2)", RFC 1904, January
+        1996.
+
+   [4]  SNMPv2 Working Grou, Case, J., McCloghrie, K., Rose, M., and
+        S. Waldbusser, "Protocol Operations for Version 2 of the Simple
+        Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
+
+   [5]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+        S. Waldbusser, "Transport Mappings for Version 2 of the Simple
+        Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
+
+   [6]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+        S. Waldbusser, "Management Information Base for Version 2 of the
+        Simple Network Management Protocol (SNMPv2)", RFC 1907, January
+        1996.
+
+   [7]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+        S. Waldbusser, "Coexistence between Version 1 and Version 2 of
+        the Internet-standard Network Management Framework", RFC 1908,
+        January 1996.
+
+   [8]  Freed, N., and S. Kille, "The Network Services Monitoring MIB",
+        RFC 2248, January 1998.
+
+   [9]  Kille, S., "A String Representation of Distinguished Names", RFC
+        1779, March 1995.
+
+
+
+Freed & Kille               Standards Track                    [Page 26]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+   [10] Berners-Lee, T., Masinter, L. and M. McCahill, Uniform Resource
+        Locators (URL)", RFC 1738, December 1994.
+
+   [11] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 1566, January
+        1994.
+
+   [12] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC
+        822", RFC 1327, May 1992.
+
+   [13] Crocker, D., "Standard for the Format of ARPA Internet Text
+        Message", RFC 822, August 1982.
+
+   [14] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
+        January 1996.
+
+10.  Security Considerations
+
+   This MIB does not offer write access, and as such cannot be used to
+   actively attack a system. However, this MIB does provide passive
+   information about the existance, type, and configuration of
+   applications on a given host that could potentially indicate some
+   sort of vulnerability. Finally, the information MIB provides about
+   network usage could be used to analyze network traffic patterns.
+
+11.  Author and Chair Addresses
+
+   Ned Freed
+   Innosoft International, Inc.
+   1050 Lakes Drive
+   West Covina, CA 91790
+   USA
+
+   Phone: +1 626 919 3600
+   Fax: +1 626 919 3614
+   EMail: ned.freed@innosoft.com
+
+
+   Steve Kille, MADMAN WG Chair
+   ISODE Consortium
+   The Dome, The Square
+   Richmond TW9 1DT
+   UK
+
+   Phone: +44 181 332 9091
+   EMail: S.Kille@isode.com
+
+
+
+
+
+
+Freed & Kille               Standards Track                    [Page 27]
+
+RFC 2249                  Mail Monitoring MIB               January 1998
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+   This document and translations of it may be copied and furnished  to
+   others, and derivative works that comment on or otherwise  explain it
+   or assist in its implementation may be prepared, copied,  published
+   and distributed, in whole or in part, without  restriction of any
+   kind, provided that the above copyright notice  and this paragraph
+   are included on all such copies and derivative  works.  However, this
+   document itself may not be modified in any  way, such as by removing
+   the copyright notice or references to the  Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the  procedures for
+   copyrights defined in the Internet Standards  process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on  an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET  ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR  IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF  THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+   RPO
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed & Kille               Standards Track                    [Page 28]
+