draft-ietf-madman-email-mib-01.txt   draft-ietf-madman-email-mib-02.txt 
Network Working Group Ned Freed, Innosoft Network Working Group Ned Freed, Innosoft
Internet Draft Steve Kille, ISODE Consortium Internet Draft Steve Kille, ISODE Consortium
Obsoletes: 1566, 2249 <draft-ietf-madman-email-mib-01.txt> Obsoletes: 1566, 2249 <draft-ietf-madman-email-mib-02.txt>
Mail Monitoring MIB Mail Monitoring MIB
February 1999
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line ? skipping to change at page 2, line ?
use with network management protocols in the Internet community. use with network management protocols in the Internet community.
Specifically, this memo extends the basic Network Services Monitoring Specifically, this memo extends the basic Network Services Monitoring
MIB defined in RFC XXXX [16] to allow monitoring of Message Transfer MIB defined in RFC XXXX [16] to allow monitoring of Message Transfer
Agents (MTAs). It may also be used to monitor MTA components within Agents (MTAs). It may also be used to monitor MTA components within
gateways. gateways.
2. Table of Contents 2. Table of Contents
1 Introduction .................................................... 1 1 Introduction .................................................... 1
2 Table of Contents ............................................... 2 2 Table of Contents ............................................... 2
3 The SNMP Network Management Framework ........................... 2 3 The SNMPv2 Network Management Framework ......................... 2
3.1 Object Definitions ............................................ 3
4 Message Flow Model .............................................. 3 4 Message Flow Model .............................................. 3
5 MTA Objects ..................................................... 4 5 MTA Objects ..................................................... 4
6 Definitions ..................................................... 5 6 Definitions ..................................................... 4
7 Changes made since RFC 2249 ..................................... 34 7 Changes made since RFC 2249 ..................................... 33
8 Acknowledgements ................................................ 34 8 Acknowledgements ................................................ 34
9 References ...................................................... 34 9 References ...................................................... 34
10 Security Considerations ........................................ 37 10 Security Considerations ........................................ 36
11 Author and Chair Addresses ..................................... 37 11 Author and Chair Addresses ..................................... 37
12 Full Copyright Statement ....................................... 38 12 Full Copyright Statement ....................................... 37
3. The SNMP Network Management Framework 3. The SNMPv2 Network Management Framework
The SNMP Management Framework presently consists of five major The SNMP Management Framework presently consists of five major
components: components:
o An overall architecture, described in RFC 2271 [1]. o An overall architecture, described in RFC 2571 [1].
o Mechanisms for describing and naming objects and events for the o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in Management Information (SMI) is called SMIv1 and described in
RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version,
called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC called SMIv2, is described in RFC 2578 [5], RFC 2579 [6] and RFC
1904 [7]. 2580 [7].
o Message protocols for transferring management information. The o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and first version of the SNMP message protocol is called SNMPv1 and
described in RFC 1157 [8]. A second version of the SNMP message described in RFC 1157 [8]. A second version of the SNMP message
protocol, which is not an Internet standards track protocol, is protocol, which is not an Internet standards track protocol, is
called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10].
The third version of the message protocol is called SNMPv3 and The third version of the message protocol is called SNMPv3 and
described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12].
o Protocol operations for accessing management information. The o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is first set of protocol operations and associated PDU formats is
described in RFC 1157 [8]. A second set of protocol operations described in RFC 1157 [8]. A second set of protocol operations
and associated PDU formats is described in RFC 1905 [13]. and associated PDU formats is described in RFC 1905 [13].
o A set of fundamental applications described in RFC 2273 [14] and o A set of fundamental applications described in RFC 2573 [14] and
the view-based access control mechanism described in RFC 2275 the view-based access control mechanism described in RFC 2575
[15]. [15].
Managed objects are accessed via a virtual information store, termed the Managed objects are accessed via a virtual information store, termed the
Management Information Base or MIB. Objects in the MIB are defined Management Information Base or MIB. Objects in the MIB are defined
using the mechanisms defined in the SMI. using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A MIB This memo specifies a MIB module that is compliant to the SMIv2. A MIB
conforming to the SMIv1 can be produced through the appropriate conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the readable information is not considered to change the semantics of the
MIB. MIB.
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 4. Message Flow Model
A general model of message flow inside an MTA has to be presented before 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 a MIB can be described. Generally speaking, message flow is modelled as
occuring in four steps: occurring in four steps:
(1) Messages are received by the MTA from User Agents, Message (1) Messages are received by the MTA from User Agents, Message
Stores, other MTAs, and gateways. Stores, other MTAs, and gateways.
(2) The "next hop" for the each message is determined. This is simply (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 the destination the message is to be transmitted to; it may or
may not be the final destination of the message. Multiple "next may not be the final destination of the message. Multiple "next
hops" may exist for a single message (as a result of either hops" may exist for a single message (as a result of either
having multiple recipients or distribution list expansion); this having multiple recipients or distribution list expansion); this
may make it necessary to duplicate messages. may make it necessary to duplicate messages.
skipping to change at page 5, line 20 skipping to change at page 5, line 6
OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY, mib-2 OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY, mib-2
FROM SNMPv2-SMI FROM SNMPv2-SMI
DisplayString, TimeInterval DisplayString, TimeInterval
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
applIndex, URLString applIndex, URLString
FROM NETWORK-SERVICES-MIB; FROM NETWORK-SERVICES-MIB;
mta MODULE-IDENTITY mta MODULE-IDENTITY
LAST-UPDATED "9811130000Z" LAST-UPDATED "9905120000Z"
ORGANIZATION "IETF Mail and Directory Management Working Group" ORGANIZATION "IETF Mail and Directory Management Working Group"
CONTACT-INFO CONTACT-INFO
" Ned Freed " Ned Freed
Postal: Innosoft International, Inc. Postal: Innosoft International, Inc.
1050 Lakes Drive 1050 Lakes Drive
West Covina, CA 91790 West Covina, CA 91790
US US
Tel: +1 626 919 3600 Tel: +1 626 919 3600
Fax: +1 626 919 3614 Fax: +1 626 919 3614
E-Mail: ned.freed@innosoft.com" E-Mail: ned.freed@innosoft.com"
DESCRIPTION DESCRIPTION
"The MIB module describing Message Transfer Agents (MTAs)" "The MIB module describing Message Transfer Agents (MTAs)"
REVISION "9811130000Z" REVISION "9905120000Z"
DESCRIPTION DESCRIPTION
"This revision, published in RFC YYYY, fixes a number of "This revision, published in RFC YYYY, fixes a number of
technical problems found in previous versions. No changes technical problems found in previous versions: The
have been made to the objects this MIB defines." 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."
REVISION "9708170000Z" REVISION "9708170000Z"
DESCRIPTION DESCRIPTION
"This revision, published in RFC 2249, adds the "This revision, published in RFC 2249, adds the
mtaGroupDescription and mtaGroupURL fields, conversion mtaGroupDescription and mtaGroupURL fields, conversion
operation counters, a group hierarchy description mechanism, operation counters, a group hierarchy description mechanism,
counters for specific errors, oldest message IDs, per-MTA counters for specific errors, oldest message IDs, per-MTA
and per-group loop counters, and a new table for tracking and per-group loop counters, and a new table for tracking
any errors an MTA encounters." any errors an MTA encounters."
REVISION "9311280000Z" REVISION "9311280000Z"
DESCRIPTION DESCRIPTION
skipping to change at page 12, line 27 skipping to change at page 12, line 27
-- In any case, a grouping abstraction is an extremely useful for -- In any case, a grouping abstraction is an extremely useful for
-- breaking down the activities of an MTA. For purposes of -- breaking down the activities of an MTA. For purposes of
-- labelling this will be called a "group" in this MIB. -- labelling this will be called a "group" in this MIB.
-- Each group contains all the variables needed to monitor all -- Each group contains all the variables needed to monitor all
-- aspects of an MTA's operation. However, the fact that all -- aspects of an MTA's operation. However, the fact that all
-- groups contain all possible variables does not imply that all -- groups contain all possible variables does not imply that all
-- groups must use all possible variables. For example, a single -- groups must use all possible variables. For example, a single
-- group might be used to monitor only one kind of event (inbound -- group might be used to monitor only one kind of event (inbound
-- processing, outbound processing, or storage). In this sort of -- processing, outbound processing, or storage). In this sort of
-- configuration any counters that are unused as a result of a
-- given MTA's use of the group construct must 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 -- Groups can be created at any time after MTA initialization. Once
-- a group is created it should not be deleted or its mtaGroupIndex -- a group is created it should not be deleted or its mtaGroupIndex
-- changed unless the MTA is reinitialized. -- changed unless the MTA is reinitialized.
-- Groups are not necessarily mutually exclusive. A given event may -- Groups are not necessarily mutually exclusive. A given event may
-- be recorded by more than one group, a message may be seen as -- 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 -- stored by more than one group, and so on. Groups should be all
-- inclusive, however: if groups are implemented all aspects of an -- inclusive, however: if groups are implemented all aspects of an
-- MTA's operation should be registered in at least one group. -- MTA's operation should be registered in at least one group.
-- This freedom lets implementors use different sets of groups to -- This freedom lets implementors use different sets of groups to
-- provide different "views" of an MTA.
-- The possibility of overlap between groups means that summing -- The possibility of overlap between groups means that summing
-- variables across groups may not produce values equal to those in -- variables across groups may not produce values equal to those in
-- the mtaTable. mtaTable should always provide accurate information -- the mtaTable. mtaTable should always provide accurate information
-- about the MTA as a whole. -- about the MTA as a whole.
-- The term "channel" is often used in MTA implementations; channels -- The term "channel" is often used in MTA implementations; channels
-- are usually, but not always, equivalent to a group. However, -- are usually, but not always, equivalent to a group. However,
-- this MIB does not use the term "channel" because there is no -- this MIB does not use the term "channel" because there is no
-- requirement that an MTA supporting this MIB has to map its -- requirement that an MTA supporting this MIB has to map its
-- "channel" abstraction one-to-one onto the MIB's group abstraction.
-- An MTA may create a group or group of groups at any time. Once -- 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 -- created, however, an MTA cannot delete an entry for a group from
-- the group table. Deletion is only allowed when the MTA is
-- reinitialized, and is not required even then. This restriction -- reinitialized, and is not required even then. This restriction
-- is imposed so that monitoring agents can rely on group -- is imposed so that monitoring agents can rely on group
-- assignments being consistent across multiple query operations. -- assignments being consistent across multiple query operations.
-- Groups may be laid out so as to form a hierarchical arrangement, -- Groups may be laid out so as to form a hierarchical arrangement,
-- with some groups acting as subgroups for other groups. -- with some groups acting as subgroups for other groups.
-- Alternately, disjoint groups of groups may be used to provide -- Alternately, disjoint groups of groups may be used to provide
-- different sorts of "snapshots" of MTA operation. The -- different sorts of "snapshots" of MTA operation. The
-- mtaGroupHierarchy variable provides an indication of how each -- mtaGroupHierarchy variable provides an indication of how each
-- group fits into the overall arrangement being used. -- group fits into the overall arrangement being used.
-- Note that SNMP also defines and uses term "group". MTA groups are
-- NOT the same as SNMP groups.
mtaGroupTable OBJECT-TYPE mtaGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF MtaGroupEntry SYNTAX SEQUENCE OF MtaGroupEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The table holding information specific to each MTA group." "The table holding information specific to each MTA group."
::= {mta 2} ::= {mta 2}
mtaGroupEntry OBJECT-TYPE mtaGroupEntry OBJECT-TYPE
SYNTAX MtaGroupEntry SYNTAX MtaGroupEntry
skipping to change at page 20, line 42 skipping to change at page 20, line 42
since group creation. Failed associations are since group creation. Failed associations are
not counted in the accumulated association totals." not counted in the accumulated association totals."
::= {mtaGroupEntry 20} ::= {mtaGroupEntry 20}
mtaGroupInboundRejectionReason OBJECT-TYPE mtaGroupInboundRejectionReason OBJECT-TYPE
SYNTAX DisplayString SYNTAX DisplayString
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The failure reason, if any, for the last association this "The failure reason, if any, for the last association this
group refused to respond to. An empty string indicates that group refused to respond to. If no association attempt
the last attempt was successful. If no association attempt
has been made since the MTA was initialized the value has been made since the MTA was initialized the value
should be 'never'." should be 'never'."
::= {mtaGroupEntry 21} ::= {mtaGroupEntry 21}
mtaGroupOutboundConnectFailureReason OBJECT-TYPE mtaGroupOutboundConnectFailureReason OBJECT-TYPE
SYNTAX DisplayString SYNTAX DisplayString
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The failure reason, if any, for the last association attempt "The failure reason, if any, for the last association attempt
this group initiated. An empty string indicates that the last this group initiated. If no association attempt has been
attempt was successful. If no association attempt has been
made since the MTA was initialized the value should be made since the MTA was initialized the value should be
'never'." 'never'."
::= {mtaGroupEntry 22} ::= {mtaGroupEntry 22}
mtaGroupScheduledRetry OBJECT-TYPE mtaGroupScheduledRetry OBJECT-TYPE
SYNTAX TimeInterval SYNTAX TimeInterval
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The time when this group is scheduled to next attempt to "The amount of time until this group is next scheduled to
make an association." attempt to make an association."
::= {mtaGroupEntry 23} ::= {mtaGroupEntry 23}
mtaGroupMailProtocol OBJECT-TYPE mtaGroupMailProtocol OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An identification of the protocol being used by this group. "An identification of the protocol being used by this group.
For an group employing OSI protocols, this will be the For an group employing OSI protocols, this will be the
Application Context. For Internet applications, the IANA Application Context. For Internet applications, the IANA
skipping to change at page 26, line 25 skipping to change at page 26, line 25
SYNTAX MtaGroupErrorEntry SYNTAX MtaGroupErrorEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The entry holding information regarding accumulated "The entry holding information regarding accumulated
errors for each MTA group." errors for each MTA group."
INDEX {applIndex, mtaGroupIndex, mtaStatusCode} INDEX {applIndex, mtaGroupIndex, mtaStatusCode}
::= {mtaGroupErrorTable 1} ::= {mtaGroupErrorTable 1}
MtaGroupErrorEntry ::= SEQUENCE { MtaGroupErrorEntry ::= SEQUENCE {
mtaStatusCode
INTEGER (4000000..5999999),
mtaGroupInboundErrorCount mtaGroupInboundErrorCount
Counter32, Counter32,
mtaGroupInternalErrorCount mtaGroupInternalErrorCount
Counter32, Counter32,
mtaGroupOutboundErrorCount mtaGroupOutboundErrorCount
Counter32 Counter32
} }
mtaGroupInboundErrorCount OBJECT-TYPE mtaGroupInboundErrorCount OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Count of the number of errors of a given type that have "Count of the number of errors of a given type that have
been accumulated in assocation with a particular group been accumulated in association with a particular group
while processing incoming messages. In the case of SMTP while processing incoming messages. In the case of SMTP
these will typically be errors reporting by an SMTP these will typically be errors reporting by an SMTP
server to the remote client; in the case of X.400 server to the remote client; in the case of X.400
these will typically be errors encountered while these will typically be errors encountered while
processing an incoming message." processing an incoming message."
::= {mtaGroupErrorEntry 1} ::= {mtaGroupErrorEntry 1}
mtaGroupInternalErrorCount OBJECT-TYPE mtaGroupInternalErrorCount OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Count of the number of errors of a given type that have "Count of the number of errors of a given type that have
been accumulated in assocation with a particular group been accumulated in association with a particular group
during internal MTA processing." during internal MTA processing."
::= {mtaGroupErrorEntry 2} ::= {mtaGroupErrorEntry 2}
mtaGroupOutboundErrorCount OBJECT-TYPE mtaGroupOutboundErrorCount OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Count of the number of errors of a given type that have "Count of the number of errors of a given type that have
been accumulated in assocation with a particular group's been accumulated in association with a particular group's
outbound connection activities. In the case of an SMTP outbound connection activities. In the case of an SMTP
client these will typically be errors reported while client these will typically be errors reported while
attempting to contact or while communicating with the attempting to contact or while communicating with the
remote SMTP server. In the case of X.400 these will remote SMTP server. In the case of X.400 these will
typically be errors encountered while constructing typically be errors encountered while constructing
or attempting to deliver an outgoing message." or attempting to deliver an outgoing message."
::= {mtaGroupErrorEntry 3} ::= {mtaGroupErrorEntry 3}
-- Conformance information -- Conformance information
skipping to change at page 27, line 46 skipping to change at page 27, line 46
-- Compliance statements -- Compliance statements
mtaCompliance MODULE-COMPLIANCE mtaCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The compliance statement for RFC 1566 implementations "The compliance statement for RFC 1566 implementations
which support the Mail Monitoring MIB for basic which support the Mail Monitoring MIB for basic
monitoring of MTAs." monitoring of MTAs."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS {mtaGroup} MANDATORY-GROUPS {mtaRFC1566Group}
::= {mtaCompliances 1} ::= {mtaCompliances 1}
mtaAssocCompliance MODULE-COMPLIANCE mtaAssocCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The compliance statement for RFC 1566 implementations "The compliance statement for RFC 1566 implementations
which support the Mail Monitoring MIB for monitoring which support the Mail Monitoring MIB for monitoring
of MTAs and their associations." of MTAs and their associations."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS {mtaGroup, mtaAssocGroup} MANDATORY-GROUPS {mtaRFC1566Group, mtaRFC1566AssocGroup}
::= {mtaCompliances 2} ::= {mtaCompliances 2}
mtaRFC2249Compliance MODULE-COMPLIANCE mtaRFC2249Compliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The compliance statement for RFC 2249 implementations "The compliance statement for RFC 2249 implementations
which support the Mail Monitoring MIB for basic which support the Mail Monitoring MIB for basic
monitoring of MTAs." monitoring of MTAs."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS {mtaRFC2249Group} MANDATORY-GROUPS {mtaRFC2249Group}
skipping to change at page 30, line 18 skipping to change at page 30, line 18
"The compliance statement for RFC YYYY implementations "The compliance statement for RFC YYYY implementations
which support the full Mail Monitoring MIB for which support the full Mail Monitoring MIB for
monitoring of MTAs, associations, and detailed errors." monitoring of MTAs, associations, and detailed errors."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS {mtaRFCYYYYGroup, mtaRFCYYYYAssocGroup, MANDATORY-GROUPS {mtaRFCYYYYGroup, mtaRFCYYYYAssocGroup,
mtaRFCYYYYErrorGroup} mtaRFCYYYYErrorGroup}
::= {mtaCompliances 12} ::= {mtaCompliances 12}
-- Units of conformance -- Units of conformance
mtaGroup OBJECT-GROUP mtaRFC1566Group OBJECT-GROUP
OBJECTS { OBJECTS {
mtaReceivedMessages, mtaStoredMessages, mtaReceivedMessages, mtaStoredMessages,
mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume, mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume,
mtaTransmittedVolume, mtaReceivedRecipients, mtaTransmittedVolume, mtaReceivedRecipients,
mtaStoredRecipients, mtaTransmittedRecipients, mtaStoredRecipients, mtaTransmittedRecipients,
mtaGroupReceivedMessages, mtaGroupRejectedMessages, mtaGroupReceivedMessages, mtaGroupRejectedMessages,
mtaGroupStoredMessages, mtaGroupTransmittedMessages, mtaGroupStoredMessages, mtaGroupTransmittedMessages,
mtaGroupReceivedVolume, mtaGroupStoredVolume, mtaGroupReceivedVolume, mtaGroupStoredVolume,
mtaGroupTransmittedVolume, mtaGroupReceivedRecipients, mtaGroupTransmittedVolume, mtaGroupReceivedRecipients,
mtaGroupStoredRecipients, mtaGroupTransmittedRecipients, mtaGroupStoredRecipients, mtaGroupTransmittedRecipients,
skipping to change at page 30, line 44 skipping to change at page 30, line 44
mtaGroupRejectedInboundAssociations, mtaGroupRejectedInboundAssociations,
mtaGroupFailedOutboundAssociations, mtaGroupFailedOutboundAssociations,
mtaGroupInboundRejectionReason, mtaGroupInboundRejectionReason,
mtaGroupOutboundConnectFailureReason, mtaGroupOutboundConnectFailureReason,
mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName} mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName}
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of objects providing basic monitoring of MTAs. "A collection of objects providing basic monitoring of MTAs.
This is the original set of such objects defined in RFC This is the original set of such objects defined in RFC
1566." 1566."
::= {mtaGroups 1} ::= {mtaGroups 10}
mtaAssocGroup OBJECT-GROUP mtaRFC1566AssocGroup OBJECT-GROUP
OBJECTS { OBJECTS {
mtaGroupAssociationIndex} mtaGroupAssociationIndex}
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of objects providing monitoring of MTA "A collection of objects providing monitoring of MTA
associations. This is the original set of such objects associations. This is the original set of such objects
defined in RFC 1566." defined in RFC 1566."
::= {mtaGroups 2} ::= {mtaGroups 11}
mtaErrorGroup OBJECT-GROUP
OBJECTS {
mtaGroupInboundErrorCount, mtaGroupInternalErrorCount,
mtaGroupOutboundErrorCount}
STATUS current
DESCRIPTION
"A collection of objects providing monitoring of
detailed MTA errors."
::= {mtaGroups 3}
mtaRFC2249Group OBJECT-GROUP mtaRFC2249Group OBJECT-GROUP
OBJECTS { OBJECTS {
mtaReceivedMessages, mtaStoredMessages, mtaReceivedMessages, mtaStoredMessages,
mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume, mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume,
mtaTransmittedVolume, mtaReceivedRecipients, mtaTransmittedVolume, mtaReceivedRecipients,
mtaStoredRecipients, mtaTransmittedRecipients, mtaStoredRecipients, mtaTransmittedRecipients,
mtaSuccessfulConvertedMessages, mtaFailedConvertedMessages, mtaSuccessfulConvertedMessages, mtaFailedConvertedMessages,
mtaGroupReceivedMessages, mtaGroupRejectedMessages, mtaGroupReceivedMessages, mtaGroupRejectedMessages,
mtaGroupStoredMessages, mtaGroupTransmittedMessages, mtaGroupStoredMessages, mtaGroupTransmittedMessages,
skipping to change at page 34, line 21 skipping to change at page 33, line 39
"A collection of objects providing monitoring of "A collection of objects providing monitoring of
detailed MTA errors. This is the appropriate group detailed MTA errors. This is the appropriate group
for RFC YYYY error monitoring." for RFC YYYY error monitoring."
::= {mtaGroups 9} ::= {mtaGroups 9}
END END
7. Changes made since RFC 2249 7. Changes made since RFC 2249
This revision corrects a number of minor technical errors in the This revision corrects a number of minor technical errors in the
construction of the mail monitoring MIB in RFC 2249 [18]. There are no construction of the mail monitoring MIB in RFC 2249 [18]:
substantive changes to any of the objects the MIB defines.
(1) The conformance groups for different versions of this MIB have
been corrected,
(2) the required mtaStatusCode entry has been added to
MtaGroupErrorEntry, and
(3) 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.
8. Acknowledgements 8. Acknowledgements
This document is a work product of the Mail and Directory Management 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 (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 designed by S. Kille, T. Lenggenhager, D. Partain, and W. Yeong. The
Electronic Mail Association's TSC committee was instrumental in Electronic Mail Association's TSC committee was instrumental in
providing feedback on and suggesting enhancements to RFC 1566 [19] that providing feedback on and suggesting enhancements to RFC 1566 [19] that
have led to the present document. have led to the present document.
9. References 9. References
[1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for [1] Harrington, D., Presuhn, R., and Wijnen, B., "An Architecture for
Describing SNMP Management Frameworks", RFC 2271, Cabletron Describing SNMP Management Frameworks", RFC 2571, April 1999.
Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research,
January 1998.
[2] Rose, M., and K. McCloghrie, "Structure and Identification of [2] Rose, M. and McCloghrie, K., "Structure and Identification of
Management Information for TCP/IP-based Internets", RFC 1155, Management Information for TCP/IP-based Internets", RFC 1155, May
Performance Systems International, Hughes LAN Systems, May 1990. 1990.
[3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, [3] Rose, M. and McCloghrie, K., "Concise MIB Definitions", RFC 1212,
Performance Systems International, Hughes LAN Systems, March 1991. March 1991.
[4] M. Rose, "A Convention for Defining Traps for use with the SNMP", [4] Rose, M., "A Convention for Defining Traps for use with the SNMP",
RFC 1215, Performance Systems International, March 1991. RFC 1215, March 1991.
[5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure [5] McCloghrie, K., Perkins, D., and Schoenwaelder, J., "Structure of
of Management Information for Version 2 of the Simple Network Management Information Version 2 (SMIv2)", RFC 2578, April 1999.
Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco
Systems, Inc., Dover Beach Consulting, Inc., International Network
Services, January 1996.
[6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual [6] McCloghrie, K., Perkins, D., and Schoenwaelder, J., "Textual
Conventions for Version 2 of the Simple Network Management Protocol Conventions for SMIv2", RFC 2579, April 1999.
(SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc.,
Dover Beach Consulting, Inc., International Network Services,
January 1996.
[7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance [7] McCloghrie, K., Perkins, D., and Schoenwaelder, J., "Conformance
Statements for Version 2 of the Simple Network Management Protocol Statements for SMIv2", RFC 2580, April 1999.
(SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc.,
Dover Beach Consulting, Inc., International Network Services,
January 1996.
[8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network [8] Case, J., Fedor, M., Schoffstall, M., and Davin, J., "Simple
Management Protocol", RFC 1157, SNMP Research, Performance Systems Network Management Protocol", RFC 1157, May 1990.
International, Performance Systems International, MIT Laboratory
for Computer Science, May 1990.
[9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, [9] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport [10] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport
Mappings for Version 2 of the Simple Network Management Protocol Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., (SNMPv2)", RFC 1906, January 1996.
Dover Beach Consulting, Inc., International Network Services,
January 1996.
[11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message [11] Case, J., Harrington D., Presuhn R., and Wijnen, B., "Message
Processing and Dispatching for the Simple Network Management Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Protocol (SNMP)", RFC 2572, April 1999.
Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998.
[12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for [12] Blumenthal, U., and Wijnen, B., "User-based Security Model (USM)
version 3 of the Simple Network Management Protocol (SNMPv3)", RFC for version 3 of the Simple Network Management Protocol (SNMPv3)",
2274, IBM T. J. Watson Research, January 1998. RFC 2574, April 1999.
[13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol [13] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol
Operations for Version 2 of the Simple Network Management Protocol Operations for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., (SNMPv2)", RFC 1905, January 1996.
Dover Beach Consulting, Inc., International Network Services,
January 1996.
[14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC [14] Levi, D., Meyer, P., and Stewart, B., "SNMPv3 Applications", RFC
2273, SNMP Research, Inc., Secure Computing Corporation, Cisco 2573, April 1999.
Systems, January 1998.
[15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access [15] Wijnen, B., Presuhn, R., and McCloghrie, K., "View-based Access
Control Model (VACM) for the Simple Network Management Protocol Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., (SNMP)", RFC 2575, April 1999.
Cisco Systems, Inc., January 1998.
[16] Freed, N., Kille, S., "The Network Services Monitoring MIB", [16] Freed, N. and Kille, S., "The Network Services Monitoring MIB",
Internet Draft, November 1998. Internet Draft, May 1999.
[17] Kille, S., "A String Representation of Distinguished Names", RFC [17] Kille, S., "A String Representation of Distinguished Names", RFC
1779, March 1995. 1779, March 1995.
[18] Freed, N., Kille, S., "Mail Monitoring MIB", RFC 2249, January [18] Freed, N. and Kille, S., "Mail Monitoring MIB", RFC 2249, January
1998. 1998.
[19] Freed, N., Kille, S., "Mail Monitoring MIB", RFC 1566, January [19] Freed, N. and Kille, S., "Mail Monitoring MIB", RFC 1566, January
1994. 1994.
[20] Kille, S., "Mapping between X.400(1988) and RFC 822/MIME", RFC [20] Kille, S., "Mapping between X.400(1988) and RFC 822/MIME", RFC
2156, January 1998. 2156, January 1998.
[21] Crocker, D., "Standard for the Format of ARPA Internet Text [21] Crocker, D., "Standard for the Format of ARPA Internet Text
Message", STD 11, RFC 822, August 1982. Message", STD 11, RFC 822, August 1982.
[22] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, [22] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
January 1996. January 1996.
10. Security Considerations 10. Security Considerations
This MIB does not offer write access, and as such cannot be used to There are no management objects defined in this MIB that have a MAX-
actively attack a system. However, this MIB does provide passive ACCESS clause of read-write and/or read-create. So, if this MIB is
information about the existance, type, and configuration of applications implemented correctly, then there is no risk that an intruder can alter
on a given host that could potentially indicate some sort of or create any management objects of this MIB via direct SNMP SET
vulnerability. Finally, the information MIB provides about network usage operations.
could be used to analyze network traffic patterns.
However, this MIB does provide passive information about the existence,
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.
SNMPv1 by itself is not a secure environment. Even if the network SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no itself is secure (for example by using IPSec), even then, there is no
control as to who on the secure network is allowed to access and GET/SET control as to who on the secure network is allowed to access and GET/SET
(read/change/create/delete) the objects in this MIB. (read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security features It is recommended that the implementers consider the security features
as provided by the SNMPv3 framework. Specifically, the use of the as provided by the SNMPv3 framework. Specifically, the use of the
User-based Security Model RFC 2274 [12] and the View-based Access User-based Security Model RFC 2574 [12] and the View-based Access
Control Model RFC 2275 [15] is recommended. Control Model RFC 2575 [15] is recommended.
It is then a customer/user responsibility to ensure that the SNMP entity It is then a customer/user responsibility to ensure that the SNMP entity
giving access to an instance of this MIB, is properly configured to give giving access to an instance of this MIB, is properly configured to give
access to the objects only to those principals (users) that have access to the objects only to those principals (users) that have
legitimate rights to indeed GET or SET (change/create/delete) them. legitimate rights to indeed GET or SET (change/create/delete) them.
11. Author and Chair Addresses 11. Author and Chair Addresses
Ned Freed Ned Freed
Innosoft International, Inc. Innosoft International, Inc.
skipping to change at page 38, line 20 skipping to change at page 37, line 32
email: S.Kille@isode.com email: S.Kille@isode.com
12. Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are included
included on all such copies and derivative works. However, this on all such copies and derivative works. However, this document itself
document itself may not be modified in any way, such as by removing the may not be modified in any way, such as by removing the copyright notice
copyright notice or references to the Internet Society or other or references to the Internet Society or other Internet organizations,
Internet organizations, except as needed for the purpose of developing except as needed for the purpose of developing Internet standards in
Internet standards in which case the procedures for copyrights defined which case the procedures for copyrights defined in the Internet
in the Internet Standards process must be followed, or as required to Standards process must be followed, or as required to translate it into
translate it into languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an "AS
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 62 change blocks. 
140 lines changed or deleted 124 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/