draft-ietf-madman-mail-monitor-mib-05.txt   rfc2249.txt 
Network Working Group Ned Freed, Innosoft Network Working Group N. Freed
Internet Draft Steve Kille, ISODE Consortium Request for Comments: 2249 Innosoft
Obsoletes: 1566 <draft-ietf-madman-mail-monitor-mib-05.txt> Obsoletes: 1566 S. Kille
Category: Standards Track ISODE Consortium
January 1998
Mail Monitoring MIB Mail Monitoring MIB
August 1997 Status of this Memo
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its areas, and Internet community, and requests discussion and suggestions for
its working groups. Note that other groups may also distribute working improvements. Please refer to the current edition of the "Internet
documents as Internet-Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months. Copyright Notice
Internet-Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a ``working draft'' or
``work in progress.''
To learn the current status of any Internet-Draft, please check the Copyright (C) The Internet Society (1998). All Rights Reserved.
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
1. Introduction 1. Introduction
This memo defines a portion of the Management Information Base (MIB) for This memo defines a portion of the Management Information Base (MIB)
use with network management protocols in the Internet community. for 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 [8] to allow monitoring of Message Transfer Agents (MTAs). It may MIB [8] to allow monitoring of Message Transfer Agents (MTAs). It may
also be used to monitor MTA components within gateways. also be used to monitor MTA components within gateways.
2. Table of Contents 2. Table of Contents
1 Introduction .................................................... 1 1 Introduction ............................................. 1
2 Table of Contents ............................................... 2 2 Table of Contents ........................................ 1
3 The SNMPv2 Network Management Framework ......................... 2 3 The SNMPv2 Network Management Framework .................. 2
3.1 Object Definitions ............................................ 2 3.1 Object Definitions ..................................... 2
4 Message Flow Model .............................................. 3 4 Message Flow Model ....................................... 2
5 MTA Objects ..................................................... 4 5 MTA Objects .............................................. 3
6 Definitions ..................................................... 4 6 Definitions .............................................. 4
7 Changes made since RFC 1566 ..................................... 30 7 Changes made since RFC 1566 .............................. 25
8 Acknowledgements ................................................ 31 8 Acknowledgements ......................................... 26
9 References ...................................................... 31 9 References ............................................... 26
10 Security Considerations ........................................ 32 10 Security Considerations ................................. 27
11 Author and Chair Addresses ..................................... 32 11 Author and Chair Addresses .............................. 27
12 Full Copyright Statement ................................ 28
3. The SNMPv2 Network Management Framework 3. The SNMPv2 Network Management Framework
The SNMPv2 Network Management Framework consists of seven major The SNMPv2 Network Management Framework consists of seven major
components. They are: components. They are:
o RFC 1902 [1] which defines the SMI, the mechanisms used for o RFC 1902 [1] which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management. describing and naming objects for the purpose of management.
o RFC 1903 [2] defines textual conventions for SNMPv2. o RFC 1903 [2] defines textual conventions for SNMPv2.
o RFC 1904 [3] defines conformance statements for SNMPv2. o RFC 1904 [3] defines conformance statements for SNMPv2.
o RFC 1905 [4] defines transport mappings for SNMPv2. o RFC 1905 [4] defines transport mappings for SNMPv2.
o RFC 1906 [5] defines the protocol operations used for network o RFC 1906 [5] defines the protocol operations used for network
access to managed objects. access to managed objects.
o RFC 1907 [6] defines the Management Information Base for SNMPv2. o RFC 1907 [6] defines the Management Information Base for SNMPv2.
o RFC 1908 [7] specifies coexistance between SNMP and SNMPv2. o RFC 1908 [7] specifies coexistance between SNMP and SNMPv2.
The Framework permits new objects to be defined for the purpose of The Framework permits new objects to be defined for the purpose of
experimentation and evaluation. experimentation and evaluation.
3.1. Object Definitions 3.1. Object Definitions
Managed objects are accessed via a virtual information store, termed the Managed objects are accessed via a virtual information store, termed
Management Information Base or MIB. Objects in the MIB are defined using the Management Information Base or MIB. Objects in the MIB are
the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. defined using the subset of Abstract Syntax Notation One (ASN.1)
In particular, each object type is named by an OBJECT IDENTIFIER, an defined in the SMI. In particular, each object type is named by an
administratively assigned name. The object type together with an object OBJECT IDENTIFIER, an administratively assigned name. The object type
instance serves to uniquely identify a specific instantiation of the together with an object instance serves to uniquely identify a
object. For human convenience, we often use a textual string, termed specific instantiation of the object. For human convenience, we
the descriptor, to refer to the object type. 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
a MIB can be described. Generally speaking, message flow is modelled as before a MIB can be described. Generally speaking, message flow is
occuring in four steps: modelled as occuring 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
the destination the message is to be transmitted to; it may or simply the destination the message is to be transmitted to; it
may not be the final destination of the message. Multiple "next may or may not be the final destination of the message.
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 Multiple "next hops" may exist for a single message (as a
appropriate for the next hop. Conversion operations may be result of either having multiple recipients or distribution
successful or unsuccessful. list expansion); this may make it necessary to duplicate
messages.
(4) Messages are transmitted to the appropriate destination, which (3) If necessary messages are converted into the format that's
may be a User Agent, Message Store, another MTA, or gateway. appropriate for the next hop. Conversion operations may be
successful or unsuccessful.
Storage of messages in the MTA occurs at some point during this process. (4) Messages are transmitted to the appropriate destination, which
However, it is important to note that storage may occur at different and may be a User Agent, Message Store, another MTA, or gateway.
possibly even multiple points during this process. For example, some
MTAs expand messages into multiple copies as they are received. In this Storage of messages in the MTA occurs at some point during this
case (1), (2), and (3) may all occur prior to storage. Other MTAs store process. However, it is important to note that storage may occur at
messages precisely as they are received and perform all expansions and different and possibly even multiple points during this process. For
conversions during retransmission processing. So here only (1) occurs example, some MTAs expand messages into multiple copies as they are
prior to storage. This leads to situations where, in general, a received. In this case (1), (2), and (3) may all occur prior to
measurement of messages received may not equal a measurement of messages storage. Other MTAs store messages precisely as they are received and
in store, or a measurement of messages stored may not equal a perform all expansions and conversions during retransmission
measurement of messages retransmitted, or both. 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 5. MTA Objects
If there are one or more MTAs on the host, the following MIB may be used If there are one or more MTAs on the host, the following MIB may be
to monitor them. Any number of the MTAs on a single host or group of used to monitor them. Any number of the MTAs on a single host or
hosts may be monitored. Each MTA is dealt with as a separate network group of hosts may be monitored. Each MTA is dealt with as a separate
service and has its own applTable entry in the Network Services network service and has its own applTable entry in the Network
Monitoring MIB. Services Monitoring MIB.
The MIB described in this document covers only the portion which is The MIB described in this document covers only the portion which is
specific to the monitoring of MTAs. The network service related part of specific to the monitoring of MTAs. The network service related part
the MIB is covered in a separate document [8]. of the MIB is covered in a separate document [8].
This MIB defines four tables. The first of these contains per-MTA This MIB defines four tables. The first of these contains per-MTA
information that isn't specific to any particular part of MTA. The information that isn't specific to any particular part of MTA. The
second breaks each MTA down into a collection of separate components second breaks each MTA down into a collection of separate components
called groups. Groups are described in detail in the comments embedded called groups. Groups are described in detail in the comments
in the MIB below. The third table provides a means of correlating embedded in the MIB below. The third table provides a means of
associations tracked by the network services MIB with specific groups correlating associations tracked by the network services MIB with
within different MTAs. Finally, the fourth table provides a means of specific groups within different MTAs. Finally, the fourth table
tracking any errors encountered during the operation of the MTA. The provides a means of tracking any errors encountered during the
first two tables must be implemented to conform with this MIB; the last operation of the MTA. The first two tables must be implemented to
two are optional. conform with this MIB; the last two are optional.
6. Definitions 6. Definitions
MTA-MIB DEFINITIONS ::= BEGIN MTA-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
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
skipping to change at page 30, line 19 skipping to change at page 25, line 21
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of objects providing monitoring of "A collection of objects providing monitoring of
detailed MTA errors." detailed MTA errors."
::= {mtaGroups 3} ::= {mtaGroups 3}
END END
7. Changes made since RFC 1566 7. Changes made since RFC 1566
The only changes made to this document since it was issued as RFC 1566 The only changes made to this document since it was issued as RFC
[11] are the following: 1566 [11] are the following:
(1) A number of DESCRIPTION fields have been reworded, hopefully (1) A number of DESCRIPTION fields have been reworded, hopefully
making them clearer. making them clearer.
(2) mtaGroupDescription and mtaGroupURL fields have been added. (2) mtaGroupDescription and mtaGroupURL fields have been added.
These fields are intended to identify and describe the MTA and These fields are intended to identify and describe the MTA and
the various MTA groups. the various MTA groups.
(3) The time since the last outbound association attempt is now (3) The time since the last outbound association attempt is now
distinct from the time since the last successfuol outbound distinct from the time since the last successfuol outbound
association attempt. association attempt.
(4) Conversion operation counters have been added. (4) Conversion operation counters have been added.
(5) A mechanism to explicitly describe group hierarchies has been (5) A mechanism to explicitly describe group hierarchies has been
added. added.
(6) A mechanism to count specific sorts of errors 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 (7) A field for the ID of the oldest message in a group's queue
been added. has been added.
(8) Per-MTA and per-group message loop counters have 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 (9) A new table has been added to keep track of any errors an MTA
encounters. encounters.
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 [11] that providing feedback on and suggesting enhancements to RFC 1566 [11]
have led to the present document. that have led to the present document.
9. References 9. References
[1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
of Management Information for Version 2 of the Simple Network S. Waldbusser, "Structure of Management Information for Version
Management Protocol (SNMPv2)", RFC 1902, January 1996. 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[2] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Textual [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
Conventions for Version 2 of the Simple Network Management Protocol S. Waldbusser, "Textual Conventions for Version 2 of the Simple
(SNMPv2)", RFC 1903, January 1996. Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[3] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Conformance [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
Statements for Version 2 of the Simple Network Management Protocol S. Waldbusser, "Conformance Statements for Version 2 of the
(SNMPv2)", RFC 1904, January 1996. Simple Network Management Protocol (SNMPv2)", RFC 1904, January
1996.
[4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol [4] SNMPv2 Working Grou, Case, J., McCloghrie, K., Rose, M., and
Operations for Version 2 of the Simple Network Management Protocol S. Waldbusser, "Protocol Operations for Version 2 of the Simple
(SNMPv2)", RFC 1905, January 1996. Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
Mappings for Version 2 of the Simple Network Management Protocol S. Waldbusser, "Transport Mappings for Version 2 of the Simple
(SNMPv2)", RFC 1906, January 1996. Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
Information Base for Version 2 of the Simple Network Management S. Waldbusser, "Management Information Base for Version 2 of the
Protocol (SNMPv2)", RFC 1907, January 1996. Simple Network Management Protocol (SNMPv2)", RFC 1907, January
1996.
[7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
"Coexistence between Version 1 and Version 2 of the Internet- S. Waldbusser, "Coexistence between Version 1 and Version 2 of
standard Network Management Framework", RFC 1908, January 1996. the Internet-standard Network Management Framework", RFC 1908,
January 1996.
[8] Freed, N., Kille, S., "The Network Services Monitoring MIB", [8] Freed, N., and S. Kille, "The Network Services Monitoring MIB",
Internet Draft, March 1997. RFC 2248, January 1998.
[9] Kille, S., "A String Representation of Distinguished Names", RFC [9] Kille, S., "A String Representation of Distinguished Names", RFC
1779, March 1995. 1779, March 1995.
[10] Berners-Lee, T., Masinter, L., McCahill, M., iform Resource [10] Berners-Lee, T., Masinter, L. and M. McCahill, Uniform Resource
Locators (URL)", RFC 1738, December 1994. Locators (URL)", RFC 1738, December 1994.
[11] Freed, N., Kille, S., "Mail Monitoring MIB", RFC 1566, January [11] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 1566, January
1994. 1994.
[12] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", [12] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC
RFC 1327, May 1992. 822", RFC 1327, May 1992.
[13] Crocker, D., "Standard for the Format of ARPA Internet Text [13] Crocker, D., "Standard for the Format of ARPA Internet Text
Message", RFC 822, August 1982. Message", RFC 822, August 1982.
[14] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, Octel [14] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
Network Services, January 1996. January 1996.
10. Security Considerations 10. Security Considerations
This MIB does not offer write access, and as such cannot be used to This MIB does not offer write access, and as such cannot be used to
actively attack a system. However, this MIB does provide passive actively attack a system. However, this MIB does provide passive
information about the existance, type, and configuration of applications information about the existance, type, and configuration of
on a given host that could potentially indicate some sort of applications on a given host that could potentially indicate some
vulnerability. Finally, the information MIB provides about network usage sort of vulnerability. Finally, the information MIB provides about
could be used to analyze network traffic patterns. network usage could be used to analyze network traffic patterns.
11. Author and Chair Addresses 11. Author and Chair Addresses
Ned Freed Ned Freed
Innosoft International, Inc. Innosoft International, Inc.
1050 Lakes Drive 1050 Lakes Drive
West Covina, CA 91790 West Covina, CA 91790
USA USA
tel: +1 626 919 3600
fax: +1 626 919 3614
email: ned.freed@innosoft.com
Steve Kille, MADMAN WG Chair Phone: +1 626 919 3600
ISODE Consortium Fax: +1 626 919 3614
The Dome, The Square EMail: ned.freed@innosoft.com
Richmond TW9 1DT
UK Steve Kille, MADMAN WG Chair
tel: +44 181 332 9091 ISODE Consortium
email: S.Kille@isode.com The Dome, The Square
Richmond TW9 1DT
UK
Phone: +44 181 332 9091
EMail: S.Kille@isode.com
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
 End of changes. 54 change blocks. 
176 lines changed or deleted 176 lines changed or added

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