Mail Monitoring MIB
Extracted elements (23)
Each group contains all possible monitoring variables even if a given group only monitors one kind of event (e.g., inbound only). Unused counters are simply inaccessible (noSuchName in SNMPv1, noSuchInstance in SNMPv2), rather than defining separate partial group schemas.
Groups are intentionally allowed to overlap so that implementors can provide different 'views' of MTA operation. The mtaTable always provides accurate whole-MTA totals; summing group variables may therefore not equal mtaTable values. Groups should be all-inclusive if groups are implemented at all.
Message flow is modelled as four steps (receive, determine next hop, convert, transmit) with storage occurring at potentially different points. This explains why mtaReceivedMessages, mtaStoredMessages, and mtaTransmittedMessages may differ: some MTAs expand messages on receipt, others store first and expand on retransmission.
Once a group is created it must not be deleted or have its mtaGroupIndex changed unless the MTA is reinitialized, so that monitoring agents can rely on stable group assignments across multiple query operations. Deletion is not even required at reinitialization.
The term 'channel' (common in MTA implementations) is deliberately avoided in this MIB because there is no requirement that an MTA's channel abstraction maps one-to-one onto the MIB's group abstraction. The more general 'group' concept was chosen to accommodate diverse MTA architectures.
This MIB obsoletes RFC 1566. Changes include: reworded DESCRIPTION fields; new mtaGroupDescription and mtaGroupURL fields; separation of last outbound attempt from last successful outbound; conversion operation counters; explicit group hierarchy; per-group error table using RFC 1893 status codes; oldest-message-ID field; and per-MTA and per-group loop counters.
Recipient counts (mtaReceivedRecipients, mtaStoredRecipients, mtaTransmittedRecipients and group equivalents) must exclude recipients the MTA has no responsibility for — i.e., inactive envelope recipients or recipients referenced only in message headers.
The first two tables (mtaTable and mtaGroupTable) must be implemented to conform with this MIB; the mtaGroupAssociationTable and mtaGroupErrorTable are optional.
The mtaCompliance MODULE-COMPLIANCE requires implementation of mtaGroup (mtaTable plus mtaGroupTable objects) for basic MTA monitoring conformance. The mtaAssocGroup and mtaErrorGroup are additive compliance levels defined in mtaAssocCompliance, mtaErrorCompliance, and mtaFullCompliance.
mtaGroupAssociationTable (mta 3) is indexed by {applIndex, mtaGroupIndex, mtaGroupAssociationIndex} and contains a single object, mtaGroupAssociationIndex, which is a reference into the network services association table to correlate active associations with a specific MTA group.
mtaGroupErrorTable (mta 5) is indexed by {applIndex, mtaGroupIndex, mtaStatusCode} and holds three Counter32 objects per error code per group: mtaGroupInboundErrorCount, mtaGroupInternalErrorCount, and mtaGroupOutboundErrorCount, enabling fine-grained error accounting by RFC 1893 status code.
mtaGroupHierarchy is an INTEGER where a positive value names a parent group's mtaGroupIndex (this group's variables are a subset of that group), a negative value indicates a group-collection code (groups sharing a negative value form one breakdown of MTA activity), and zero means hierarchy is not implemented.
mtaGroupInboundRejectionReason and mtaGroupOutboundConnectFailureReason are DisplayString objects holding the failure reason for the most recent rejected inbound association or failed outbound attempt; an empty string indicates the last attempt succeeded; 'never' is used if no attempt has been made since MTA initialization.
mtaGroupLastOutboundActivity records time since the last successful outbound association, while mtaGroupLastOutboundAssociationAttempt (entry 34) records time since the last attempt regardless of success — these two fields are distinct, a change from RFC 1566.
mtaGroupMailProtocol is an OBJECT IDENTIFIER identifying the protocol used by a group. For Internet protocols the IANA registry of OIDs is used; for unlisted TCP/UDP protocols the form {applTCPProtoID port} or {applUDPProtoID port} is used.
mtaGroupName is a DisplayString naming the group. For Internet MTAs this should be the remote domain name; for OSI MTAs the RFC 1779 string-encoded distinguished name; for X.400(1984) MTAs without a DN, the RFC 1327 'mta in globalid' syntax.
mtaGroupTable (mta 2) is indexed by {applIndex, mtaGroupIndex} and contains 33 objects per group including message/volume/recipient counters, association gauges and accumulators, timing intervals, rejection reasons, scheduled retry time, mail protocol OID, group name, description, URL, creation time, hierarchy indicator, oldest message ID, and loop counter.
mtaLoopsDetected (per-MTA) and mtaGroupLoopsDetected (per-group) are Counter32 objects counting detected message loops since initialization or group creation. The MIB explicitly notes that loop detection mechanisms, granularity, and handling vary across MTA implementations and cannot be inferred from these counters.
mtaStatusCode encodes an RFC 1893 Enhanced Mail System Status Code as an INTEGER in the range 4000000..5999999 using the formula ((class * 1000) + subject) * 1000 + detail, mapping SMTP error responses and X.400 reason/diagnostic codes into a single unified namespace.
mtaTable (mta 1) holds one row per MTA indexed by applIndex, containing 12 whole-MTA counters: mtaReceivedMessages, mtaStoredMessages (Gauge32), mtaTransmittedMessages, three volume counters in K-octets, three recipient counters, mtaSuccessfulConvertedMessages, mtaFailedConvertedMessages, and mtaLoopsDetected.
Volume objects (mtaReceivedVolume, mtaStoredVolume, mtaTransmittedVolume and their group-level counterparts) are Counter32 or Gauge32 values measured in K-octets and cover data logically above the mail transport protocol level — message header plus body for SMTP, P2 data for X.400.
The MTA-MIB module is registered at OID {mib-2 28}, assigned under the SNMPv2 MIB-2 subtree. The module identity was last updated 1997-08-17 and originally published in RFC 1566.
This MIB offers only read-only access and therefore cannot be used to actively attack a system. However, the information it exposes about application existence, type, and configuration could indicate vulnerabilities, and traffic pattern data could be used to analyze network usage.