<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>