Rocco wrote:

>> OOPS, I blundered. You cannot bypass spam checks and still 
>> get spam tags. You should ONLY use spam_lover if you want 
>> mail spam tagged.

> I tried to sent a spam to an address of the spam lover domain:

> /usr/local/src/amavisd-new-2.4.4/test-messages # sendmail -i
> [EMAIL PROTECTED] <sample-spam.txt

Sending from the local machine is not a good way to test. Send from an
external client.

> The message has delivered the the postoffice server in the correct
> mailbox, but in fact it has no any spam tag (I aspect the 'X-Spam-Flag'
> tag).

Did it have a X-Virus-Scanned: header? If not then you may have
content_filter disabled for the 'pickup' service in master.cf. This is
why it's better to test from an external client.

> Why? maybe the domain 'domain.it' is not considered local for
> amavisd-new? And when a domain is considered local for amavisd-new?

Let me ask you first: in your users table, do you have a 'local'
field? If not, then every user (except @.) in the database is local.
If you do have a local field then you would want to set it to 'Y'. For
recipients that are not in SQL, or for recipients that have a 'local'
field set to NULL, add the domain to @local_domains_maps (you should
anyway).

>From README.lookups:

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

> Thanks,
> rocsca

BTW, looking at this:

INSERT INTO policy (id, policy_name, spam_lover, spam_kill_level) VALUES (88, 
'Pass spam', 'Y', '9999');

one realizes that while it's probably a good idea
to set spam_lover, if you set spam_kill_level high enough (like 9999)
then the mail will get delivered anyway, so it should not be strictly
required to also set spam_lover.

The static equivalent would be:

@spam_kill_level_maps = (
  { '.example.com' => 9999 },
  \$sa_kill_level_deflt,   # catchall default
);


Gary V



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/

Reply via email to