Priority on white/black lists

[Miguel Fernandes]

Hi!

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 :)
>
> Thanks.
>
>
>
> On 12/16/2011 07:53 PM, Mark Martinec wrote:
>> Miguel,
>>
>>> I need to have some sort of priority in black/white lists, but 
>>> currently
>>> 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.
>>
>>
>> README.lookups:
>>
>> 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 
>> specific
>> 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 
>> matter
>> 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 
>> pair)
>>
>>> 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 
>> value
>>    boost, which is interpreted as soft black/white-listing (the same 
>> semantics
>>    as the value in @score_sender_maps);
>>
>>
>> Mark
>
>


-- 
Cumprimentos,
Miguel Fernandes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.amavis.org/pipermail/amavis-users/attachments/20120210/763fb38d/attachment.html>