Mail Monitoring MIB
Extracted elements (26)
Message flow inside an MTA is modeled in four steps: (1) receive from UA/MTA/gateway, (2) determine next hop, (3) convert format if needed, (4) transmit. Storage may occur at different points in this pipeline, which is why received, stored, and transmitted counts can differ.
mtaTable always provides authoritative whole-MTA figures; summing group-level variables across groups may not equal mtaTable values because groups can overlap and are not required to be mutually exclusive.
RFC 2789 changed all DisplayStrings to SnmpAdminStrings rather than deprecating old objects and defining new ones; the authors note this change is not strictly supported by SMIv2 but was preferred to minimize adverse impact on backward compatibility and interoperability.
The error table uses RFC 1893 Enhanced Mail System Status Codes as an index rather than protocol-specific codes, enabling both SMTP error responses and X.400 reason/diagnostic codes to be mapped into a single extensible namespace that describes most mail system errors generically.
The MIB uses the term 'group' rather than 'channel' deliberately: MTAs are not required to map their internal channel abstraction one-to-one onto MIB groups, allowing implementors to create overlapping or hierarchical 'views' of MTA operation.
The recommendation to return an empty string from mtaGroupInboundRejectionReason and mtaGroupOutboundConnectFailureReason on success was removed in RFC 2249 because it conflicted with the stated purpose of those variables (to record the failure reason, not success state).
A MIB conforming to SMIv1 can be produced by translating this SMIv2 MIB, but Counter64 objects and machine-readable information in SMIv2 will be lost or converted to textual descriptions; the resulting MIB must be semantically equivalent within those constraints.
mtaGroupName for Internet MTAs should be the domain name; for OSI MTAs it should be the RFC 2253 string-encoded Distinguished Name; for X.400(1984) MTAs lacking a DN, the RFC 2156 'mta in globalid' syntax used in X400-Received fields may be used.
RFC 2789 defines compliance levels for three MIB generations (RFC 1566, RFC 2249, RFC 2789), each with basic, association-monitoring, error-monitoring, and full variants, yielding compliance OIDs mtaCompliances 1–2 (1566), 5–8 (2249), and 9–12 (2789).
Counters within a group that are unused for a given MTA's deployment of the group construct MUST be inaccessible, returning noSuchName (SNMPv1) or noSuchInstance (SNMPv2) rather than zero.
If groups are implemented, all aspects of an MTA's operation SHOULD be registered in at least one group (groups should be all-inclusive), though groups are not required to be mutually exclusive.
Implementations MUST implement mtaTable and mtaGroupTable to conform with this MIB; mtaGroupAssociationTable and mtaGroupErrorTable are optional.
Once a group entry is created it SHOULD NOT be deleted or have its mtaGroupIndex changed unless the MTA is reinitialized, so monitoring agents can rely on consistent group assignments across queries.
Recipient counters SHOULD NOT count recipients for which the MTA has no responsibility (inactive envelope recipients or header-only references); only active envelope recipients under the MTA's responsibility are counted.
Volume counters (mtaReceivedVolume, mtaStoredVolume, mtaTransmittedVolume) SHOULD include all transferred/stored data logically above the mail transport protocol level; e.g., SMTP MTAs count header+body kilo-octets, X.400 MTAs count P2 data kilo-octets.
mtaGroupAssociationTable (optional) correlates active network-service associations (from RFC 2788 assocTable) with the MTA group responsible; indexed by applIndex, mtaGroupIndex, and mtaGroupAssociationIndex.
mtaGroupErrorTable (optional) tallies per-group errors by RFC 1893 Enhanced Mail System Status Code, providing separate counters for inbound (mtaGroupInboundErrorCount), internal (mtaGroupInternalErrorCount), and outbound (mtaGroupOutboundErrorCount) errors.
mtaGroupHierarchy is a signed INTEGER: a positive value names the parent group's mtaGroupIndex; a negative value is a collection code grouping disjoint views of MTA activity; zero means hierarchy is not implemented.
mtaGroupInboundRejectionReason and mtaGroupOutboundConnectFailureReason are SnmpAdminStrings holding the failure reason for the last rejected inbound or failed outbound association; the value should be 'never' if no attempt has been made since MTA initialization.
mtaGroupMailProtocol identifies the protocol used by a group as an OID; for Internet protocols the OID has the form {applTCPProtoID port} or {applUDPProtoID port} using the primary port number.
mtaGroupOldestMessageId holds the RFC 822 msg-id (SnmpAdminString) of the oldest message in a group's queue; X.400 MTAs should convert X.400 identifiers using RFC 2156 rules.
mtaGroupTable breaks each MTA into named 'groups' (indexed by applIndex + mtaGroupIndex) carrying per-group counters for messages, volume, recipients, associations, conversion results, oldest message age and ID, loop detection, and hierarchy placement.
mtaStatusCode is an INTEGER index in the range 4000000..5999999 encoding an RFC 1893 Enhanced Mail System Status Code via the formula ((class * 1000) + subject) * 1000 + detail, where class is 4 or 5 and subject/detail are 0..999.
mtaTable holds one row per MTA (indexed by applIndex from the Network Services MIB) and provides whole-MTA counters for received, stored, and transmitted messages, volume (K-octets), recipients, conversion successes/failures, and loop detections.
All objects in this MIB are read-only (MAX-ACCESS read-only or not-accessible); there are no read-write or read-create objects, so an intruder cannot alter or create management objects via SNMP SET operations.
This MIB exposes passive information about the existence, type, and configuration of mail applications on a host (potential vulnerability indicators) and network usage patterns that could be used to analyze traffic; SNMPv3 with the User-based Security Model (RFC 2574) and View-based Access Control Model (RFC 2575) is recommended to restrict access.