black/whitelisting per-sender-recipient

[Jeroen Koekkoek]

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