Mail Monitoring MIB
Extracted elements (19)
Groups are not required to be mutually exclusive; a given event may be recorded by more than one group. However, if groups are implemented all aspects of an MTA's operation should appear in at least one group, and mtaTable always provides authoritative aggregate totals.
Message flow inside an MTA occurs in four steps: receive from UA/store/MTA/gateway, determine next hop, convert format, and transmit. Storage may occur at different points in this pipeline, so measured counts of received, stored, and transmitted messages may legitimately differ from each other.
The MIB introduces a 'group' abstraction to break down MTA activity into inbound, storage, and outbound components. The term 'channel' is deliberately avoided because MTAs are not required to map their channel abstraction one-to-one onto MIB groups.
Volume counters measure data logically above the mail transport protocol level. For SMTP-based MTAs this means kilo-octets of message header and body; for X.400-based MTAs it means kilo-octets of P2 data. This ensures protocol-neutral comparability.
This MIB extends the Network Services Monitoring MIB (RFC 1565) and reuses applIndex from APPLICATION-MIB as its primary index, meaning each monitored MTA must have a corresponding applTable entry in the Network Services Monitoring MIB.
Unused counters in a group (e.g., a group monitoring only inbound activity) are inaccessible and return noSuchName (SNMPv1) or noSuchInstance (SNMPv2) rather than zero, allowing partial group implementations without misleading zero values.
If groups are implemented, all aspects of an MTA's operation should be registered in at least one group, ensuring complete coverage even though groups may overlap.
Recipient counters (mtaReceivedRecipients, mtaStoredRecipients, mtaTransmittedRecipients at both MTA and group level) MUST NOT count recipients for which the MTA had no responsibility, even if recipient information is available.
The compliance statement mtaAssocCompliance requires SNMPv2 entities that monitor MTA associations to support both mtaGroup and mtaAssocGroup (which contributes mtaGroupAssociationIndex).
The compliance statement mtaCompliance requires SNMPv2 entities implementing the Mail Monitoring MIB to support the mandatory OBJECT-GROUP mtaGroup, covering all MTA-level and group-level counters.
mtaGroupAssociationTable (OID mib-2.28.3) indexed by (applIndex, mtaGroupIndex, mtaGroupAssociationIndex) contains a single object, mtaGroupAssociationIndex, which provides a reference into the association table to correlate active associations with this group.
mtaGroupInboundRejectionReason and mtaGroupOutboundConnectFailureReason (entries 21 and 22) are DisplayStrings holding the failure reason for the last rejected or failed association. An empty string indicates the last attempt succeeded; the value 'never' indicates no attempt has been made since MTA initialization.
mtaGroupMailProtocol (mtaGroupEntry 24) is an OBJECT IDENTIFIER that identifies the protocol used by a group. For OSI it is the Application Context; for Internet protocols IANA maintains a registry; if unlisted, {applTCPProtoID port} or {applUDPProtoID port} forms are used.
mtaGroupName (mtaGroupEntry 25) is a DisplayString. For a group connected to a single remote Internet MTA it should be the domain name; for OSI MTAs the string-encoded Distinguished Name per RFC 1485; for X.400(1984) MTAs without a DN, the RFC 1327 syntax 'mta in globalid'.
mtaGroupOldestMessageStored (mtaGroupEntry 12, type TimeInterval) records the time elapsed since the oldest message currently in the group's queue was placed there, enabling detection of stuck or stalled queues.
mtaGroupTable (OID mib-2.28.2) provides per-group counters indexed by (applIndex, mtaGroupIndex) and extends the per-MTA counters with mtaGroupRejectedMessages, mtaGroupOldestMessageStored, inbound/outbound association gauges and accumulators, last-activity timestamps, rejection and failure reason strings, scheduled retry time, mail protocol OID, and group name.
mtaTable (OID mib-2.28.1) provides per-MTA aggregate counters indexed by applIndex: mtaReceivedMessages, mtaStoredMessages (Gauge32), mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume, mtaTransmittedVolume (all in K-octets), mtaReceivedRecipients, mtaStoredRecipients (Gauge32), and mtaTransmittedRecipients.
The MTA MIB module is assigned OID mib-2.28 (MODULE-IDENTITY). IANA maintains a registry mapping well-known message transfer protocol names to OIDs used by mtaGroupMailProtocol; unlisted protocols fall back to {applTCPProtoID port} or {applUDPProtoID port}.
The Security Considerations section explicitly states that security issues are not discussed in this memo, providing no guidance on access control, authentication, or protection of the monitoring data exposed by this MIB.