Philippe,
> can anybody tell me howto configure amavisd-new with virtual domains and
> users to use per-recipient black-/whitelisting?
> i´m using spamassissin with razor, pyzor and dcc for spam detection.
> at the moment i have the following config:
> $sql_select_policy = 'SELECT "Y" as local FROM domain WHERE
> CONCAT("@",domain_name) IN (%k)';
> $sql_select_white_black_list = 'SELECT wb FROM wblist,mailaddr'.
> ' WHERE (wblist.rid=?) AND (wblist.sid=mailaddr.id)'.
> ' AND (mailaddr.email IN (%k))'.
> ' ORDER BY mailaddr.priority DESC';
>
> what does the Y in the above select-statement mean?
It is normal SQL syntax, it supplies a field 'local' with a
constant value 'Y' for all returned records. I don't know
what your schema is and why do you need such a SELECT clause.
Seems its only purpose is to distinguish local from non-local
recipients based on some foreign SQL schema: the local recipients
get 'local=Y' and the rest do not match, i.e. do not belong to
local domains.
> when i replace sql_select_policy with this
> #$sql_select_policy = 'SELECT *,accountuser.id FROM accountuser,policy'.
> ' WHERE (accountuser.policy_id=policy.id) AND (accountuser.email IN
> (%k))'.
> ' ORDER BY accountuser.priority DESC';
>
> then the spam for my domains is no more marked as spam
> when i undo this the spam is marked
> again. i tested this with the gtube-sring.
Mail header markup is only done for local recipients.
Being local can be supplied by static lookup tables
(@local_domains_maps) or through SQL lookups, by
a field 'local' with a value 'Y', or by a mere presence
of a domain in $sql_select_policy. See README.lookups
about the default interpretation of a missing 'local' field:
Special handling of optional SQL field 'users.local'
A special shorthand is provided when SQL lookups are used: when a match
for recipient address (or domain) is found in SQL tables (regardless of
field values), the recipient is considered local, regardless of static
@local_comains_acl or %local_domains lookup tables. This simplifies
life when a large number of dynamically changing domains is hosted.
To overrule this behaviour, add an explicit boolean field 'local'
to table 'users' (missing field defaults to true, meaning record match
implies the recipient is local; a NULL field 'local' is not special,
it is interpreted as undef like other NULL fields, causing search
to continue into other lookup tables).
Since amavisd-new-20030616-p7:
changed the default value for local_domains_sql lookup for the catchall
key '@.' under conditions: when user record with key '@.' is present in
the database and a field 'local' is not present. Previously it surprisingly
defaulted to true, now it falls back to static lookup table defaults,
the same as if the record '@.' were not present in the table or as if
the field value 'local' was NULL.
> white/blacklisting doesn´t work too.
This one is independent on 'local' field. Your problem seems to
stem from a missing or wrong value of users.id, which does
not correspond with any entry in table wblist:
-- per-recipient whitelist and/or blacklist,
-- puts sender and recipient in relation wb (white or blacklisted sender)
CREATE TABLE wblist (
rid integer unsigned NOT NULL, -- recipient: users.id
sid integer unsigned NOT NULL, -- sender: mailaddr.id
wb varchar(10) NOT NULL,
-- W or Y / B or N / space=neutral / score
PRIMARY KEY (rid,sid)
);
Mark
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
