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