black/whitelisting per-sender-recipient

[Jeroen Koekkoek]

Hi,

I finished the patch: http://www.intuxicated.org/amavis-wblist.patch.gz

For this to work, the database schema for the wblist table has to be modified. I added the columns:
cidr varchar(64) NOT NULL DEFAULT ''
wb_banned char(1)
wb_header char(1)
wb_virus char(1)

And altered the primary key to cover (rid, sid, cidr).

To enable the extra white/black listing features the user must add the following to the configuration file:
$banned_white_black_list = 1
$header_white_black_list = 1
$virus_white_black_list = 1

Note that apart from adding white/black list functionality for banned, header and virus categories it also adds the possibility to white/black list spam on a combination of cidr and sender. The patch should be backwards compatible with existing database schema's. Also, if the extra configuration variables aren't set, amavis behaves as if the patch wasn't applied.

It's a patch for version 2.8.0-pre4. Please have a look and let me know what you think.

Best regards,
Jeroen Koekkoek


> -----Original Message-----
> From: amavis-users-bounces+j.koekkoek=perrit.nl at amavis.org
> [mailto:amavis-users-bounces+j.koekkoek=perrit.nl at amavis.org] On Behalf
> Of Jeroen Koekkoek
> Sent: Thursday, March 08, 2012 10:56 AM
> To: amavis-users at amavis.org
> Subject: RE: black/whitelisting per-sender-recipient
> 
> Hi,
> 
> I think the best way to implement this is to do lookup by triplets, for
> example allow the user to create "SELECT * FROM <table> WHERE sender =
> <key> AND client_address = <key> AND recipient = <key>" queries. It does
> mean that multiple queries might be required. I was planning on
> implementing something that can be used for all content classes.
> 
> I want to use it primarily for bad content myself. E.g. allow .exe files
> from sender a, but not from sender b. By using modifiable queries, the
> user himself can choose to query for whatever he thinks is appropriate,
> of course the documents should state that not using triplets is very
> unwise.
> 
> Another idea I had is to have the black/whitelist for bad content
> contain policy names, e.g. ALLOW_EXE, ALLOW_VBS, etc. That way the
> administrator can define sensible classes in the amavis configuration
> and allow the user to only choose between a combination of these
> classes.
> 
> I think this would make a good addition. Would a patch like this match
> your quality criteria?
> 
> Best regards,
> Jeroen Koekkoek
> 
> 
> > -----Original Message-----
> > From: amavis-users-bounces+j.koekkoek=perrit.nl at amavis.org
> > [mailto:amavis-users-bounces+j.koekkoek=perrit.nl at amavis.org] On
> Behalf
> > Of Mark Martinec
> > Sent: Wednesday, March 07, 2012 7:02 PM
> > To: amavis-users at amavis.org
> > Subject: Re: black/whitelisting per-sender-recipient
> >
> > 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