amavis-user March 2012 archive
Main Archive Page > Month Archives  > amavis-user archives
amavis-user: Re: black/whitelisting per-sender-recipient

Re: black/whitelisting per-sender-recipient

From: Mark Martinec <Mark.Martinec+amavis_at_nospam>
Date: Wed Mar 07 2012 - 18:01:31 GMT
To: amavis-users@amavis.org

Jeroen,

> I'm configuring new spam/virus gateways. As far as I know it's currently
> not possible with amavis to black/whitelist for example bad headers and
> viruses on a per sender-recipient basis.

Currently it is only possible to do so using @author_to_policy_bank_maps,
provided the mail has a valid DKIM signature. This is similiar
to SpamAssassin's setting whitelist_from_dkim, but more flexible.

Whitelisting only applies to spam checks. It would be too risky to
skip virus or banning checks based on an unproven sender identity.

There is no such concern against *blacklisting* the virus or banning checks
based on a sender identity (proven or not), although it is probably
not very useful.

It would possibly make sense to add some other authentication mechanism
besides the DKIM signature, perhaps based on a sender's mailer IP address
or based on SPF, similar to SpamAssassin's whitelist_from_spf and
whitelist_from_rcvd. But I don't find it acceptable to just naively
believe the From or a sender envelope address for these purposes.

I wouldn't mind extending the whitelisting to bad header checks though,
as failing these is mostly harmless. But I guess there is not much
demand, as mail with bad headers is by default and commonly
just passed to a recipient, with a warning added.

> I'd like to implement this functionality. If I come up with a good patch
> will you consider including it in amavis?

If it comes combined with some sender address verification then parhaps,
otherwise unlikely.

> Does anybody have good pointers as to where I should begin. My initial
> thought was to add extra columns to the wblist table and move the
> invocation of "white_black_list" upwards.

Alternatively, just dual-purpose the existing whitelist SQL field,
perhaps by giving semantics to additional values in wblist.wb,
which currently can hold a 'W', a 'B', or a numerical spam score
(soft wblisting).

If not widely deployed, consider implementing most if not all
of such functionality by a custom hook - which is able to clear
detected contents type flags (CC_VIRUS, CC_BANNED, ...).

  Mark