HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (
-   Installation/Configuration (
-   -   SPAM over assigned policy's kill level not deleted automatically (

cbj4074 9th January 2012 20:11

SPAM over assigned policy's kill level not deleted automatically
5 Attachment(s)
I created a new "Spamfilter Policy" under Email -> Policy, but it seems as though the policy is not being applied to incoming mail.

My understanding is that if the "SPAM kill level" is set to 15, then messages with a SPAM score >= 15 will be discarded.

There seems to be conflicting information regarding the following directive in /etc/amavis/conf.d/50-user:


$final_spam_destiny = D_DISCARD;
Some say that this directive must be enabled in this specific configuration file for automatic SPAM deletion to occur, while others (e.g., Till) say that this directive is irrelevant, as ISPConfig overrides this value on a per-policy-assignment basis.


Originally Posted by till (Post 177549)
The spam kill level is set in ISPConfig for every policy individually and not in this file. the setting in the rc2 was wrong as it caused nmail to be deleted even if spam scanning was deactivated for an account or domain.


Originally Posted by till (Post 218322)
Anyway, the configuration that you do in ispconfig when you select a policy overrides these, so they do not matter for all emails domains or mailboxes that you assigned a policy.


Originally Posted by prisfeo (Post 218331)
thanks Falko.. :)
check also this strange behaviour i posted here:
(about the "double" amavisd.conf files)

since it can lead not to use correctly amavis...
i think it can be related to some installation issue.

thanks Till..yes i confirm since i have changed & made some
tests in that direction.. too thought that, but from the test i made, have to say that it does not ovveride..
let me explain:

in the amavis conf file i have deleted the two statements groups above
and wrote one group with the following settings:

$final_virus_destiny = D_DISCARD;
$final_spam_destiny = D_DISCARD;
$final_banned_destiny = D_BOUNCE;
$final_bad_header_destiny = D_PASS;

now if i change
$final_spam_destiny = D_DISCARD;
$final_spam_destiny = D_PASS;

and i send a spam gtube test email to account inside ispconfig,
(see above ispconfig tab settings), are not killed (deleted), but
tagged as "SPAM: subject"
even if "SPAM kill level: 6.9"
only putting $final_spam_destiny = D_DISCARD;
i obtain that email with spam hits > 6.9 are killed(deleted)..

so, do you think it's not normal or there's something wrong
into my ispconfig/amavis integration ?

Anyway, the line in question is un-commented in my amavis configuration.

However, messages with an X-Spam-Score header well over the kill level are not deleted automatically. Here are the headers from one such email message:


X-Virus-Scanned: Debian amavisd-new at
X-Spam-Flag: YES
X-Spam-Score: 27.428
X-Spam-Level: ***************************
X-Spam-Status: Yes, score=27.428 tagged_above=1 required=4.5
tests=[BAYES_99=3.5, DATE_IN_FUTURE_24_48=2.048,
URIBL_SBL=1.623, URIBL_WS_SURBL=1.608] autolearn=spam

Screen captures of the Spampolicy Filter settings, and of the individual mailbox's Spamfilter setting are attached.

The Spamfilter setting for the domain is set to "Normal", but my understanding is that the Spamfilter setting for the specific mailbox should override the domain-level setting.

Am I missing something?

till 9th January 2012 20:34

As you can see in the mail header, a policy where spam tag2 Level = 4.5 is applied to this email:


The policy you posted has score 5.0, so this is not the policy that got applied. Please check your policys to find the one with tag level 4.5.

Beside that, please go To spamfilter > User/Domain and post the priority of the domain rule and the mailbox rule.

cbj4074 9th January 2012 21:25

Ah, thank you for pointing-out that the filter being applied has 4.5 for the tag2 level. It is the "Normal" filter that is being applied.

In Email -> Spamfilter -> User / Domain, the "Normal" filter has a priority of 5, and the "Auto-Delete Really Spammy Spam" filter has a priority of 10.

So, this all makes sense. The part I was missing is the Priority.

I have lowered the priority for the "Auto-Delete Really Spammy Spam" filter to 1 and expect that this will correct the issue.

My only question: is there any means by which to avoid having to double-check (and potentially change) the Priority value for every user to whom a new policy is applied?

To be clear, I would prefer that user-level policies always take precedence over domain-level policies.

till 9th January 2012 21:35

The last time I tested it on my servers, amavis picked up the highest priority first and not the lowest as on your system now, so the way ispconfig assigned the priorities worked here. I will test that again, maybe its a config option or this has been changed in a amavis release.

Which amavis version dp you have installed.

cbj4074 9th January 2012 22:32

I'm using amavisd-new-2.6.4.

till 10th January 2012 11:54

Checked it on my servers here and amavis selects the correct policy (mailbox has precedence before domain rule). I verified this also in the amavis config file where the order is set correctly in the sql querys:


$sql_select_policy =
  'SELECT *,'.
  ' FROM spamfilter_users LEFT JOIN spamfilter_policy ON'.
  ' WHERE IN (%k) ORDER BY spamfilter_users.priority DESC';

$sql_select_white_black_list = 'SELECT wb FROM spamfilter_wblist'.
    ' WHERE (spamfilter_wblist.rid=?) AND ( IN (%k))' .
    ' ORDER BY spamfilter_wblist.priority DESC';

Maybe you use a modified amavis configuration file on your system and not the one that is delivered with ISPconfig?

cbj4074 10th January 2012 18:04

I have not modified the amavis configuration; the MySQL queries in my file look just like yours.

I'll do some additional testing and report back when I figure out exactly what's going on. Thanks for pointing me in the right direction!

All times are GMT +2. The time now is 10:15.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.