[CentOS-docs] amavisd-new, spamassassin and clamav
ned at unixmail.co.uk
Tue Apr 29 10:45:59 UTC 2008
Ralph Angenendt wrote:
> Ned Slider wrote:
>> I've finished the main parts that I intended to cover now, just the
>> introduction to write plus a bit more on testing at the end, and apply a
>> bit of spit and polish:
> Okay, I changed two small bits about spamassassin (on a mail scanning
> gateway you really want to use rpmforge's spamassassin, as that is more
> current). The rest looks okay.
Thanks Ralph. I haven't been able to get any sort of a real world feel
for spamassassin on my mail server as my postfix restrictions (DNSBLs)
and greylisting takes out all spam before it ever reaches spamassassin.
I have access to an unused spammy domain for testing (~600-700 spam per
day) that's currently parked as a spamtrap for uceprotect. I used this
for about a month to test the rules in the postfix restrictions Wiki guide.
> What should be stressed (maybe I can get that in later today) is that
> you shouldn't "bounce" mails back if you think that they are spam. There
> are a few configuration variables in amavisd to control that.
I agree, if they *are* spam, sender addresses are almost certainly
forged and it only generates backscatter. Presumably that behaviour is
controlled with the following settings:
# $final_virus_destiny = D_DISCARD;
# $final_banned_destiny = D_BOUNCE; #change to D_DISCARD
# $final_spam_destiny = D_BOUNCE; #change to D_DISCARD
# $final_bad_header_destiny = D_PASS;
# $bad_header_quarantine_method = undef;
and is triggered by $sa_kill_level_deflt, ...and this doesn't affect
I'm also wondering about $sa_dsn_cutoff_level - so would one want to set
this to equal $sa_kill_level_deflt on the same basis, otherwise you're
no longer bouncing the message, but *are* still sending a DSN??
More information about the CentOS-docs