> >> 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
> > XXX domain.it <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
> );
All works fine!
Thanks,
rocsca
------------------------------------------------------------
-------------
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://sourcefor
ge.net/powerbar/db2/
_______________________________________________
AMaViS-user mailing list
AMaViS-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amav
is.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/ho
wto/
|
