As per Relevance of the word association, we have this rfc below:
Network Working Group S. Kille, WG
Request for Comments: 1566 ISODE
Category: Standards Track N. Freed,
January 1994
Mail Monitoring
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Table of
1. Introduction ................................................. 2
2. The SNMPv2 Network Management Framework ...................... 2
2.1 Object Definitions .......................................... 2
3. Message Flow Model ........................................... 3
4. MTA Objects .................................................. 3
5. Definitions .................................................. 4
6. Acknowledgements .............................................19
7. References ...................................................19
8. Security Considerations ......................................19
9. Authors' Addresses ...........................................20
Kille & Freed [Page 1]
RFC 1566 Mail Monitoring MIB January 1994
1.
This memo defines a portion of the Management Information Base (MIB
for use with network management protocols in the Internet community
In particular, this memo extends the basic Network
Monitoring MIB [5] to allow monitoring of Message Transfer
(MTAs). It may also be used to monitor MTA components
gateways
2. The SNMPv2 Network Management
The SNMPv2 Network Management Framework consists of four
components. They are
o RFC 1442 [1] which defines the SMI, the mechanisms used
describing and naming objects for the purpose of management
o STD 17, RFC 1213 [2] defines MIB-II, the core set of
objects for the Internet suite of protocols
o RFC 1445 [3] which defines the administrative and
architectural aspects of the framework
o RFC 1448 [4] which defines the protocol used for
access to managed objects
The Framework permits new objects to be defined for the purpose
experimentation and evaluation
2.1 Object
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the subset of Abstract Syntax Notation One (ASN.1)
defined in the SMI. In particular, each object type is named by
OBJECT IDENTIFIER, an administratively assigned name. The
type together with an object instance serves to uniquely identify
specific instantiation of the object. For human convenience,
often use a textual string, termed the descriptor, to refer to
object type
Kille & Freed [Page 2]
RFC 1566 Mail Monitoring MIB January 1994
3. Message Flow
A general model of message flow inside an MTA has to be
before a MIB can be described. Generally speaking, message
occurs in four steps
(1) Messages are received by the MTA from User Agents,
Stores, other MTAs, and gateways
(2) The "next hop" for the each message is determined. This
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
result of either having multiple recipients or
list expansion); this may make it necessary to
messages
(3) Messages are converted into the format that's
for the next hop
(4) Messages are transmitted to the appropriate destination
which may be a User Agent, Message Store, another MTA,
gateway
Storage of messages in the MTA occurs at some point during
process. However, it is important to note that storage may occur
different and possibly even multiple points during this process.
example, some MTAs expand messages into multiple copies as they
received. In this case (1), (2), and (3) may all occur prior
storage. Other MTAs store messages precisely as they are
and perform all expansions and conversions during
processing. So here only (1) occurs prior to storage. This leads
situations where, in general, a measurement of messages received
not equal a measurement of messages in store, or a measurement
messages stored may not equal a measurement of
retransmitted, or both
4. MTA
If there are one or more MTAs on the host, the following mta
may be used to monitor them. Any number of the MTAs on a host may
monitored. Each MTA is dealt with as a separate application and
its own applTable entry in the Network Services Monitoring MIB
The MIB described in this document covers only the portion which
specific to the monitoring of MTAs. The network service related
of the MIB is covered in a separate document [5].
Kille & Freed [Page 3]
RFC 1566 Mail Monitoring MIB January 1994
5.
MTA-MIB DEFINITIONS ::=
OBJECT-TYPE, Counter32, Gauge32
FROM SNMPv2-
DisplayString,
FROM SNMPv2-
mib-2
FROM RFC1213-
FROM APPLICATION-MIB
mta MODULE-
LAST-UPDATED "9311280000Z
ORGANIZATION "IETF Mail and Directory Management Working Group
CONTACT-
" Ned
Postal: Innosoft International, Inc
250 West First Street, Suite 240
Claremont, CA 91711
Tel: +1 909 624 7907
Fax: +1 909 621 5319
E-Mail: ned@innosoft.com
"The MIB module describing Message Transfer Agents (MTAs)"
::= { mib-2 28 }
mtaTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"The table holding information specific to an MTA."
::= {mta 1}
mtaEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"The entry associated with each MTA."
INDEX {applIndex
Kille & Freed [Page 4]
RFC 1566 Mail Monitoring MIB January 1994
::= {mtaTable 1}
MtaEntry ::= SEQUENCE {
Counter32,
Gauge32,
Counter32,
Counter32,
Gauge32,
Counter32,
Counter32,
Gauge32,
Counter32
}
mtaReceivedMessages OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of messages received since MTA initialization."
::= {mtaEntry 1}
mtaStoredMessages OBJECT-
SYNTAX Gauge32
MAX-ACCESS read-
STATUS
"The total number of messages currently stored in the MTA."
::= {mtaEntry 2}
mtaTransmittedMessages OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of messages transmitted since MTA initialization."
::= {mtaEntry 3}
Kille & Freed [Page 5]
RFC 1566 Mail Monitoring MIB January 1994
mtaReceivedVolume OBJECT-
SYNTAX Counter32
UNITS "K-octets
MAX-ACCESS read-
STATUS
"The total volume of messages received since
initialization, measured in kilo-octets. This volume
include all transferred data that is logically above the
transport protocol level. For example, an SMTP-based
should use the number of kilo-octets in the message
and body, while an X.400-based MTA should use the number
kilo-octets of P2 data."
::= {mtaEntry 4}
mtaStoredVolume OBJECT-
SYNTAX Gauge32
UNITS "K-octets
MAX-ACCESS read-
STATUS
"The total volume of messages currently stored in the MTA
measured in kilo-octets. This volume should include
stored data that is logically above the mail
protocol level. For example, an SMTP-based MTA
use the number of kilo-octets in the message header
body, while an X.400-based MTA would use the number
kilo-octets of P2 data."
::= {mtaEntry 5}
mtaTransmittedVolume OBJECT-
SYNTAX Counter32
UNITS "K-octets
MAX-ACCESS read-
STATUS
"The total volume of messages transmitted since
initialization, measured in kilo-octets. This volume
include all transferred data that is logically above the
transport protocol level. For example, an SMTP-based
should use the number of kilo-octets in the message
and body, while an X.400-based MTA should use the number
kilo-octets of P2 data."
::= {mtaEntry 6}
Kille & Freed [Page 6]
RFC 1566 Mail Monitoring MIB January 1994
mtaReceivedRecipients OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of recipients specified in all
received since MTA initialization. Recipients this
had no responsibility for should not be counted even
information about such recipients is available."
::= {mtaEntry 7}
mtaStoredRecipients OBJECT-
SYNTAX Gauge32
MAX-ACCESS read-
STATUS
"The total number of recipients specified in all
currently stored in the MTA. Recipients this MTA had
responsibility for should not be counted."
::= {mtaEntry 8}
mtaTransmittedRecipients OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of recipients specified in all
transmitted since MTA initialization. Recipients this
had no responsibility for should not be counted."
::= {mtaEntry 9}
-- MTAs typically group inbound reception, queue storage,
-- outbound transmission in some way. In the most extreme
-- information will be maintained for each different entity
-- receives messages and for each entity the MTA stores messages
-- and delivers messages to. Other MTAs may elect to treat
-- reception equally, all queue storage equally, all
-- equally, or some combination of this
-- In any case, a grouping abstraction is an extremely useful
-- breaking down the activities of an MTA. For purposes of
-- this will be called a "group" in this MIB
Kille & Freed [Page 7]
RFC 1566 Mail Monitoring MIB January 1994
-- Each group contains all the variables needed to monitor all
-- of an MTA's operation. However, the fact that all groups
-- all possible variables does not imply that all groups must use
-- possible variables. For example, a single group might be used
-- monitor only one kind of event (inbound processing,
-- processing, or storage). In this sort of configuration all
-- counters would be inaccessible; e.g., returning either
-- noSuchName error (for an SNMPv1 get), or a
-- exception (for an SNMPv2 get).
-- Groups are not necessarily mutually exclusive. A given event
-- be recorded by more than one group, a message may be seen
-- stored by more than one group, and so on. Groups should be
-- inclusive, however: if groups are implemented all aspects of
-- MTA's operation should be registered in at least one group.
-- freedom lets implementors use different sets of groups
-- provide differents "views" of an MTA
-- The possibility of overlap between groups means that
-- variables across groups may not produce values equal to those
-- the mtaTable. mtaTable should always provide accurate
-- about the MTA as a whole
-- The term "channel" is often used in MTA implementations;
-- are usually, but not always, equivalent to a group. However
-- this MIB does not use the term "channel" because there is
-- requirement that an MTA supporting this MIB has to map
-- "channel" abstraction one-to-one onto the MIB's group abstration
mtaGroupTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"The table holding information specific to each MTA group."
::= {mta 2}
mtaGroupEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"The entry associated with each MTA group."
INDEX {applIndex, mtaGroupIndex
::= {mtaGroupTable 1}
Kille & Freed [Page 8]
RFC 1566 Mail Monitoring MIB January 1994
MtaGroupEntry ::= SEQUENCE {
INTEGER
Counter32,
Counter32,
Gauge32,
Counter32,
Counter32,
Gauge32,
Counter32,
Counter32,
Gauge32,
Counter32,
TimeInterval
Gauge32,
Gauge32,
Counter32,
Counter32,
TimeInterval
TimeInterval
Counter32,
Counter32,
DisplayString
DisplayString
TimeInterval
Kille & Freed [Page 9]
RFC 1566 Mail Monitoring MIB January 1994
OBJECT IDENTIFIER
}
mtaGroupIndex OBJECT-
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS not-
STATUS
"The index associated with a group for a given MTA."
::= {mtaGroupEntry 1}
mtaGroupReceivedMessages OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of messages received to this group since
initialization."
::= {mtaGroupEntry 2}
mtaGroupRejectedMessages OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of messages rejected by this group since
initialization."
::= {mtaGroupEntry 3}
mtaGroupStoredMessages OBJECT-
SYNTAX Gauge32
MAX-ACCESS read-
STATUS
"The total number of messages currently stored in
group's queue."
::= {mtaGroupEntry 4}
mtaGroupTransmittedMessages OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of messages transmitted by this group since
initialization."
::= {mtaGroupEntry 5}
Kille & Freed [Page 10]
RFC 1566 Mail Monitoring MIB January 1994
mtaGroupReceivedVolume OBJECT-
SYNTAX Counter32
UNITS "K-octets
MAX-ACCESS read-
STATUS
"The total volume of messages received to this group
MTA initialization, measured in kilo-octets. This
should include all transferred data that is logically
the mail transport protocol level. For example,
SMTP-based MTA should use the number of kilo-octets in
message header and body, while an X.400-based MTA should
the number of kilo-octets of P2 data."
::= {mtaGroupEntry 6}
mtaGroupStoredVolume OBJECT-
SYNTAX Gauge32
UNITS "K-octets
MAX-ACCESS read-
STATUS
"The total volume of messages currently stored in
group's queue, measured in kilo-octets. This volume
include all stored data that is logically above the
transport protocol level. For example, an SMTP-
MTA should use the number of kilo-octets in the
header and body, while an X.400-based MTA would use
number of kilo-octets of P2 data."
::= {mtaGroupEntry 7}
mtaGroupTransmittedVolume OBJECT-
SYNTAX Counter32
UNITS "K-octets
MAX-ACCESS read-
STATUS
"The total volume of messages transmitted by this
since MTA initialization, measured in kilo-octets.
volume should include all transferred data that is
above the mail transport protocol level. For example,
SMTP-based MTA should use the number of kilo-octets in
message header and body, while an X.400-based MTA should
the number of kilo-octets of P2 data."
::= {mtaGroupEntry 8}
Kille & Freed [Page 11]
RFC 1566 Mail Monitoring MIB January 1994
mtaGroupReceivedRecipients OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of recipients specified in all
received to this group since MTA initialization
Recipients this MTA had no responsibility for should
be counted."
::= {mtaGroupEntry 9}
mtaGroupStoredRecipients OBJECT-
SYNTAX Gauge32
MAX-ACCESS read-
STATUS
"The total number of recipients specified in all
currently stored in this group's queue. Recipients
MTA had no responsibility for should not be counted."
::= {mtaGroupEntry 10}
mtaGroupTransmittedRecipients OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of recipients specified in all
transmitted by this group since MTA initialization
Recipients this MTA had no responsibility for should
be counted."
::= {mtaGroupEntry 11}
mtaGroupOldestMessageStored OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"Time since the oldest message in this group's queue
placed in the queue."
::= {mtaGroupEntry 12}
Kille & Freed [Page 12]
RFC 1566 Mail Monitoring MIB January 1994
mtaGroupInboundAssociations OBJECT-
SYNTAX Gauge32
MAX-ACCESS read-
STATUS
"The number of current associations to the group, where
group is the responder."
::= {mtaGroupEntry 13}
mtaGroupOutboundAssociations OBJECT-
SYNTAX Gauge32
MAX-ACCESS read-
STATUS
"The number of current associations to the group, where
group is the initiator."
::= {mtaGroupEntry 14}
mtaGroupAccumulatedInboundAssociations OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of associations to the group since
initialization, where the group is the responder."
::= {mtaGroupEntry 15}
mtaGroupAccumulatedOutboundAssociations OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of associations from the group since
initialization, where the group was the initiator."
::= {mtaGroupEntry 16}
mtaGroupLastInboundActivity OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"Time since the last time that this group had an
inbound association for purposes of message reception."
::= {mtaGroupEntry 17}
Kille & Freed [Page 13]
RFC 1566 Mail Monitoring MIB January 1994
mtaGroupLastOutboundActivity OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"Time since the last time that this group had
outbound association for purposes of message delivery."
::= {mtaGroupEntry 18}
mtaGroupRejectedInboundAssociations OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of inbound associations the group
rejected, since MTA initialization."
::= {mtaGroupEntry 19}
mtaGroupFailedOutboundAssociations OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number associations where the group was
initiator and association establishment has failed
since MTA initialization."
::= {mtaGroupEntry 20}
mtaGroupInboundRejectionReason OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The failure reason, if any, for the last association
group refused to respond to. An empty string indicates
the last attempt was successful. If no association
has been made since the MTA was initializaed the
should be 'never'."
::= {mtaGroupEntry 21}
Kille & Freed [Page 14]
RFC 1566 Mail Monitoring MIB January 1994
mtaGroupOutboundConnectFailureReason OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The failure reason, if any, for the last association
this group initiated. An empty string indicates that the
attempt was successful. If no association attempt has
made since the MTA was initialized the value should
'never'."
::= {mtaGroupEntry 22}
mtaGroupScheduledRetry OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The time when this group is scheduled to next attempt
make an association."
::= {mtaGroupEntry 23}
mtaGroupMailProtocol OBJECT-
SYNTAX OBJECT
MAX-ACCESS read-
STATUS
"An identification of the protocol being used by this group
For an group employing OSI protocols, this will be
Application Context. For Internet applications, the
maintains a registry of the OIDs which correspond to well-
message transfer protocols. If the application protocol
not listed in the registry, an OID value of the
{applTCPProtoID port} or {applUDProtoID port} are used
TCP-based and UDP-based protocols, respectively. In
case 'port' corresponds to the primary port number
used by the group. applTCPProtoID and applUDPProtoID
defined in [5]."
::= {mtaGroupEntry 24}
Kille & Freed [Page 15]
RFC 1566 Mail Monitoring MIB January 1994
mtaGroupName OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"A descriptive name for the group. If this group connects
a single remote MTA this should be the name of that MTA.
this in turn is an Internet MTA this should be the domain name
For an OSI MTA it should be the string encoded
name of the managed object using the format defined in RFC-1485.
For X.400(1984) MTAs which do not have a Distinguished Name
the RFC-1327 syntax 'mta in globalid' should be used."
::= {mtaGroupEntry 25}
mtaGroupAssociationTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"The table holding information regarding the
for each MTA group."
::= {mta 3}
mtaGroupAssociationEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"The entry holding information regarding the
for each MTA group."
INDEX {applIndex, mtaGroupIndex, mtaGroupAssociationIndex
::= {mtaGroupAssociationTable 1}
MtaGroupAssociationEntry ::= SEQUENCE {
}
mtaGroupAssociationIndex OBJECT-
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-
STATUS
"Reference into association table to allow correlation
this group's active associations with the association table."
::= {mtaGroupAssociationEntry 1}
Kille & Freed [Page 16]
RFC 1566 Mail Monitoring MIB January 1994
-- Conformance
mtaConformance OBJECT IDENTIFIER ::= {mta 4}
mtaGroups OBJECT IDENTIFIER ::= {mtaConformance 1}
mtaCompliances OBJECT IDENTIFIER ::= {mtaConformance 2}
-- Compliance
mtaCompliance MODULE-
STATUS
"The compliance statement for SNMPv2 entities
implement the Mail Monitoring MIB for
monitoring of MTAs."
MODULE -- this
MANDATORY-GROUPS {mtaGroup
::= {mtaCompliances 1}
mtaAssocCompliance MODULE-
STATUS
"The compliance statement for SNMPv2 entities
implement the Mail Monitoring MIB for monitoring
MTAs and their associations."
MODULE -- this
MANDATORY-GROUPS {mtaGroup, mtaAssocGroup
::= {mtaCompliances 2}
Kille & Freed [Page 17]
RFC 1566 Mail Monitoring MIB January 1994
-- Units of
mtaGroup OBJECT-
OBJECTS {
mtaReceivedMessages, mtaStoredMessages
mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume
mtaTransmittedVolume, mtaReceivedRecipients
mtaStoredRecipients, mtaTransmittedRecipients
mtaGroupReceivedMessages, mtaGroupRejectedMessages
mtaGroupStoredMessages, mtaGroupTransmittedMessages
mtaGroupReceivedVolume, mtaGroupStoredVolume
mtaGroupTransmittedVolume, mtaGroupReceivedRecipients
mtaGroupStoredRecipients, mtaGroupTransmittedRecipients
mtaGroupOldestMessageStored, mtaGroupInboundAssociations
mtaGroupOutboundAssociations
mtaGroupAccumulatedInboundAssociations
mtaGroupAccumulatedOutboundAssociations
mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity
mtaGroupRejectedInboundAssociations
mtaGroupFailedOutboundAssociations
mtaGroupInboundRejectionReason
mtaGroupOutboundConnectFailureReason
mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName
STATUS
"A collection of objects providing basic monitoring of MTAs."
::= {mtaGroups 1}
mtaAssocGroup OBJECT-
OBJECTS {
mtaGroupAssociationIndex
STATUS
"A collection of objects providing monitoring of
associations."
::= {mtaGroups 2}
Kille & Freed [Page 18]
RFC 1566 Mail Monitoring MIB January 1994
6.
This document is a product of the Mail and Directory
(MADMAN) Working Group. It is based on an earlier MIB designed by S
Kille, T. Lenggenhager, D. Partain, and W. Yeong
7.
[1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "
of Management Information for version 2 of the Simple
Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie
University, April 1993.
[2] McCloghrie, K., and M. Rose, Editors, "Management
Base for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, Hughes LAN Systems, Performance
International, March 1991.
[3] Galvin, J., and K. McCloghrie, K., "Administrative Model
version 2 of the Simple Network Management Protocol (SNMPv2)",
RFC 1445, Trusted Information Systems, Hughes LAN Systems,
1993.
[4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "
Operations for version 2 of the Simple Network
Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes
Systems, Dover Beach Consulting, Inc., Carnegie
University, April 1993.
[5] Kille, S., WG Chair, and N. Freed, Editor, "The Network
Monitoring MIB", RFC 1565, ISODE Consortium, Innosoft,
1994.
8. Security
Security issues are not discussed in this memo
Kille & Freed [Page 19]
RFC 1566 Mail Monitoring MIB January 1994
9. Authors'
Steve Kille, WG
ISODE
The Dome, The
Richmond TW9 1
Phone: +44 81 332 9091
EMail: S.Kille@isode.
Ned Freed,
Innosoft International, Inc
250 West First Street, Suite 240
Claremont, CA 91711
Phone: +1 909 624 7907
Fax: +1 909 621 5319
EMail: ned@innosoft.
Kille & Freed [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
