black/whitelisting per-sender-recipient

[Jeroen Koekkoek]

Hi Mark,

Did you, by any chance, had some time to look at the patch I created?
 
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: Monday, March 12, 2012 5:18 PM
> To: amavis-users at amavis.org
> Subject: RE: black/whitelisting per-sender-recipient
> 
> 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