Lucio,

> Our question now concerns how to manage whitelisting in case of false
> positives. We formerly managed those at level of sendmail access.db, which
> had the advantage of being an "hotplug" system : one inserted a rule in
> file "access", ran "make" and hopla' ... sendmail used it without restart.
>
> In practice we needed to manage false positives very rarely :
...
> We wonder what will be the best way to handle similar (hopefully rare)
> cases with amavis-milter + spamassassin (in a centralized configuration),
> ideally in an "hotplug way.

>  1) using whitelist_from in spamassassin local.cf ?
>     but is this hotplug, or requires restarting sendmail and amavisd-new
>     and milter ?

The whitelist_from in local.cf is certainly a possibility.
It requires restarting amavisd (not sendmail and not amavisd-milter).
SA whitelisting is based on addresses in mail header (see its docs).
Amavisd does supply envelope sender address to SA by inserting
Return-Path header field, and supplies envelope recipient addresses
to SA in X-Envelope-To header field. SA may chose to use the author's
address (From header) instead of an envelope address, see its docs.

>     Also will it whitelist the From address or the domain to which the
>     relay IP belongs ?

See Mail::SpamAssassin::Conf man page, I never used this feature.

>  2) using options in amavisd.conf (which are the best ?) ?
>     Is this hotplug ?  If not can one send a signal to amavis-milter to
>     reload (-HUP or alike ?)

In amavisd-new you can use static white/blacklisting, which requires
a restart or amavisd for changes to take effect. There is a support
for dynamic white/blacklisting through SQL lookups, changes there
take effect immediately, no restart is necessary.

Besides hard white/blacklisting, it is also possible to just
add a few score points (positive or negative) to the SA score,
based on sender address (score boost value is either global or is
configurable per-recipient). This is called soft-white(black)-listing.
It uses same/similar mechanism to hard w/b-listing, i.e. it has
its static and a SQL lookup mechanism.

Please see:
 http://www.ijs.si/software/amavisd/amavisd-new-docs.html#wblist
 http://www.ijs.si/software/amavisd/amavisd-new-docs.html#score_sender

For SQL configuration use table wblist, see README.sql

The hard-whitelisting is not recommended, it is better to just
add few negative score points to mail from friendly sender addresses,
so that a blatant spam which would happen to fake such sender
address would still have a chance of being blocked.

See example for @score_sender_maps setting in amavisd.conf-sample.
This is the mechanism I use for an occasional fixups of persistent
false positives and false negatives.

>  3) using either sa-learn (Bayes) or the spamassassin commands to append
>     the address to the AWL (which is best) to feed in a single false
>     positive. This seems to be hotplug, but I infer it's not as effective
>     as the other methods

Feeding an occasional toublesome false positive and false negative
to Bayes is certainy a good idea. Make sure to do it as user vscan,
e.g.  su vscan -c 'sa-learn --spam --mbox sample.msg'

AWL is probably not a good mechanism for this purpose.
One may want to remove an address from AWL once in a while (rarely)
if it turns out that AWL for this sender address gives wildly
inappropriate value, perhaps after it has been misused by some spam,
faking sender address. Other modifications to AWL are not needed.

> Do I infer correctly that methods 1 and/or 2 (or is there a better one)
> are the best to handle "emergencies" or "ex-officio" cases in a hard way,
> while method 3 is suited for user correspondent misconfigurations ?

Use static @score_sender_maps for emergencies and for persistent
troublesome cases, 'amavisd reload' is needed. If changes are frequent,
use SQL soft w/b listing.

If per-recipient dynamic settings are needed (through some web-based GUI),
SQL-based soft-wblisting may be used.

Feeding troublesome spam cases to sa-learn or to 'spamassassin --report'
can be useful, but is not often needed when SA has the whole range of
network and SARE tests at its disposal, bayes auto-learning works quite well.

  Mark


_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/

Reply via email to