Priority on white/black lists
maf at eurotux.com
Fri Feb 10 17:19:59 CET 2012
Just to correct myself:
(...) preceded with +(*BLACKLISTING*) or - (*WHITELISTING*)
And not the other way around, sorry.
On 12/20/2011 04:54 PM, Miguel Fernandes wrote:
> Hi Mark!
> Replacing the wblist.wb with numeric values preceded with
> +(whitelisting) or - (blacklisting), will work for me :)
> On 12/16/2011 07:53 PM, Mark Martinec wrote:
>>> I need to have some sort of priority in black/white lists, but
>>> this field is in the mailaddr table...,
>>> so I can't have different priorities per recipient right?
>> I'm not sure I understand the problem. A wblist entry corresponds
>> to a sender& recipient pair. Why would you want to have both
>> a 'W' and a 'B' entry for the same exact pair?
>> Note that both the sender and the recipient can be either an exact
>> match, or any generalization on a domain and subdomain.
>> These are sorted by priority, so a more specific match should override
>> a more general match. In this sense you can have even now
>> multiple wblist entries matching a sender and a recipient, at different
>> levels of loose matching - the most specific match wins, assuming
>> the priority field is used as suggested in the examples.
>> SQL lookups (e.g. for user+foo at example.com) are performed in order
>> which is usually specified by 'ORDER BY...DESC' in the SELECT statement;
>> otherwise the order is unspecified, which is only useful if just
>> entries exist in a database (e.g. full address always, not domain
>> part only
>> or mailbox parts only).
>> The following order (implemented by sorting on the 'priority' field
>> in DESCending order, zero is low priority) is recommended, to follow
>> the same specific-to-general principle as in other lookup tables;
>> the first column is a suggested priority (the exact value does not
>> as long as the order is maintained):
>> 9 - lookup for user+foo at sub.example.com
>> 8 - lookup for user at sub.example.com (only if $recipient_delimiter is
>> 7 - lookup for user+foo (only if domain part is local)
>> 6 - lookup for user (only local; only if $recipient_delimiter is
>> 5 - lookup for @sub.example.com
>> 3 - lookup for @.sub.example.com
>> 2 - lookup for @.example.com
>> 1 - lookup for @.com
>> 0 - lookup for @. (catchall)
>>> I'm thinking on creating a priority field in the table wblist, to
>>> have a
>>> priority per wblist entry, mainly to prioritize white lists.
>>> Can this this be achieved by some other way?
>> Sure, if you want. Adjust the $sql_select_white_black_list accordingly.
>> I just don't see a point in doing so.
>>> How does a domain w/b list affect that domain's recipients?
>> wblist entries are per-recipient (i.e. keyed by a sender& recipient
>>> How can we know the priority order in the case we have both
>>> domain w/b lists and recipient's w/b lists?
>> They are sorted by mailaddr.priority, the most specific address
>> should have the highest priority.
>> Michael Scheidell writes:
>>> actually, the entry in the wb field doesn't need to be a 'w' or a 'b'
>>> (if I remember correctly)
>>> you can set it as a -100 for whitelist, and, say, +50 in b.
>> Correct. Hard w/b-listing is turned into a soft-wblisting this way.
>>> I've been digging a litle more and:
>>> on /usr/sbin/amavisd
>>> $sql_select_white_black_list =
>>> 'SELECT wb FROM wblist JOIN mailaddr ON wblist.sid=mailaddr.id'.
>>> ' WHERE wblist.rid=? AND mailaddr.email IN (%k)'.
>>> ' ORDER BY mailaddr.priority DESC';
>>> In only uses mailaddr.priority for sorting, so I think there wblist.wb
>>> is not expecting a numeric value...
>> amavisd-new-20040701 / amavisd-new-2.0 release notes :
>> - extended semantics of SQL field wblist.wb, which can hold a score
>> boost, which is interpreted as soft black/white-listing (the same
>> as the value in @score_sender_maps);
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the amavis-users