Patrick,

> I need to split rejected messages by destination, but I don't know how.
> What I see is origins and destinations:
> 
> AMAVIS-MIB::inMsgsInbound.0 = Counter32: 1
> AMAVIS-MIB::inMsgsOutbound.0 = Counter32: 10
> AMAVIS-MIB::inMsgsInternal.0 = Counter32: 0
> AMAVIS-MIB::inMsgsOriginating.0 = Counter32: 10
> AMAVIS-MIB::inMsgsOpenRelay.0 = Counter32: 0
> 
> And I see all kinds of message status:
> 
> AMAVIS-MIB::inMsgsStatusAccepted.0 = Counter32: 0
> AMAVIS-MIB::inMsgsStatusRelayed.0 = Counter32: 1
> AMAVIS-MIB::inMsgsStatusDiscarded.0 = Counter32: 10
> AMAVIS-MIB::inMsgsStatusNoBounce.0 = Counter32: 0
> AMAVIS-MIB::inMsgsStatusBounced.0 = Counter32: 0
> AMAVIS-MIB::inMsgsStatusRejected.0 = Counter32: 0
> AMAVIS-MIB::inMsgsStatusTempFailed.0 = Counter32: 0
> 
> Any idea how I could get what I want?

This information is not currently available in the SNMP Berkeley DB or
in the final MIB. Partly because it is not clear what 'by destination' means,
and because to be able to provide this information through MIB,
the SNMP variables need to be enumerated somehow, and the
number of 'destinations' is potentially unbound. So what would
be needed is perhaps a SNMP table structure, containing 'destination'
names along with their counters (note that enumeration could change
between restarts). So far we don't provide any 'table's in the MIB.

Regarding the 'by destination', it could mean: a recipient domain,
or a forwarder IP address from a perspective of amavisd, or
transport next hop IP address from a perspective of an MTA.
A multi-recipient message can be split into multiple deliveries
by amavisd or later by the back-end MTA. So which counts
would you like to collect?

One can call the routine Amavis::Util::snmp_count or
snmp_count64 from a custom hook. The name of a counter is
in principle arbitrary so you can come up with any names
(like some prefix, appended by a domain name), and they
will end up in a Berkeley DB (typically /var/amavis/db/snmp.db),
from which a utility amavisd-agent and a amavisd-snmp-subagent
collect their information.

The amavisd-agent will show *all* entries in this database,
but the amavisd-snmp-subagent will only pick the names
which it knows how to map into a MIB, and ignore the rest.

So, if accessing the snmp.db suffices for your purpose, you can
get away with a custom hook which traverses recipients and
increments suitable counter names (similar to how virus names
end up in this database). These counters can be read either
by invoking 'amavisd-agent -c 1' and parsing its output,
or better, by your own program (use amavisd-agent or
amavisd-snmp-subagent as a template for accessing a bdb).

If you need also to map it into a MIB, the MIB would need to
be enhanced and the amavisd-snmp-subagent educated on
how to map entries from a snmp.db into OIDs.

  Mark

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/amavis-user 
 Please visit http://www.ijs.si/software/amavisd/ regularly
 For administrativa requests please send email to rainer at openantivirus dot 
org

Reply via email to