Hi Mark, Did you, by any chance, had some time to look at the patch I created? Best regards, Jeroen Koekkoek
> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf > Of Jeroen Koekkoek > Sent: Monday, March 12, 2012 5:18 PM > To: [email protected] > 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: [email protected] > > [mailto:[email protected]] On > Behalf > > Of Jeroen Koekkoek > > Sent: Thursday, March 08, 2012 10:56 AM > > To: [email protected] > > 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: [email protected] > > > [mailto:[email protected]] On > > Behalf > > > Of Mark Martinec > > > Sent: Wednesday, March 07, 2012 7:02 PM > > > To: [email protected] > > > 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
