rfc2789.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 1,781 行 · 第 1/5 页
TXT
1,781 行
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: +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 "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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?