How could I alter tagged_above and required values for spam? I'm having some trouble with amavis and spamassassin. I receive emails tagged as spam with the following headers (as an example): X-Spam-Flag: YES X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: Yes, score=1.505 tagged_above=0 required=0 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.625] autolearn=no autolearn_force=no In the example above spam score is 1.505. I've intentionally made an ALL CAPS subject to get a higher score, but emails get tagged and discarded no matter what with scores as low as 0.135. I've altered the "normal" policy in spamassassin via ispconfig control panel to "spam lover = yes" wich lets emails pass to the recipients, but tagged_above and required always show 0. Values don't seem to change with changes in Ispconfig control panel. For a little more info, System on Debian Jessie 8.7, postfix-dovecot-amavis-spamassassin, dkim enabled. I did a sa-learn --clean and wiped out the database, it contains one ham and 0 spam emails right now. Amavis was off in the server for a short time before because it didn't work fine, but with an apt-get dist-upgrade and ispconfig 3.1 it's working again, just with this strange behaviour. I hope someone can help me with this!!! Am I missing something??
dude, currently got the same problem! Im running ubuntu 17.04 with ISPconfig 3.1.3... I searching my ass off here why its not getting the required numbers. Also wiped the database clean. I am unable to distupgrade as im already on the latest version :/ X-Spam-Flag: YES X-Spam-Score: 1.079 X-Spam-Level: * X-Spam-Status: Yes, score=1.079 tagged_above=0 required=0 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=1.187, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001]
you can add $DO_SYSLOG = 0; $LOGFILE = "/var/log/amavis.log"; # (defaults to empty, no log) $log_level = 3; # (defaults to 0) to /etc/amavis/conf.d/50-user create the log and set permissions: touch /var/log/amavis.log chown amavis /var/log/amavis.log and restart amavis. you'll much more data in the log (i would start with log_level 5) check "config files read" in the log after the restart
Jun 18 10:37:08 MAIL***.*** /usr/sbin/amavisd-new[1896]: config files read: /usr/share/amavis/conf.d/10-debian_scripts, /usr/share/amavis/conf.d/20-package, /etc/amavis/conf.d/01-debian, /etc/amavis/conf.d/05-domain_id, /etc/amavis/conf.d/05-node_id, /etc/amavis/conf.d/15-av_scanners, /etc/amavis/conf.d/15-content_filter_mode, /etc/amavis/conf.d/20-debian_defaults, /etc/amavis/conf.d/21-ubuntu_defaults, /etc/amavis/conf.d/25-amavis_helpers, /etc/amavis/conf.d/30-template_localization, /etc/amavis/conf.d/40-policy_banks, /etc/amavis/conf.d/50-user, /etc/amavis/conf.d/60-dkim is this to many?
it still seems that the correct values are not extracted from the table is dbisconfig. the values stay 0 and so always SPAM... or am i not correct?! PS below are some lines that are between the last PASSED and where the spam headers are added to the mail. Jun 18 10:37:32 MAIL***.***.NL /usr/sbin/amavisd-new[1903]: (01903-01) lookup_sql_field(spam_tag2_level) rec=0, "danny@***.nl" result: "0" Jun 18 10:37:32 MAIL***.***.NL /usr/sbin/amavisd-new[1903]: (01903-01) lookup [spam_tag2_level] => false, "danny@***.nl" matches, result="0", matching_key="/cached/" Jun 18 10:37:32 MAIL***.***.NL /usr/sbin/amavisd-new[1903]: (01903-01) lookup_sql_field(spam_subject_tag2) rec=0, "danny@***.nl" result: "[SPAM]" Jun 18 10:37:32 MAIL***.***.NL /usr/sbin/amavisd-new[1903]: (01903-01) lookup [spam_subject_tag2] => true, "danny@***.nl" matches, result="[SPAM]", matching_key="/cached/" Jun 18 10:37:32 MAIL***.***.NL /usr/sbin/amavisd-new[1903]: (01903-01) headers CLUSTERING: NEW CLUSTER <danny@***.nl>: score=1.068, tag=1, tag2=1, local=1, bl=, s=[SPAM], mangle=
The problem was caused by a change in Perl or Amavis which seems to have a problem with some database column types in MySQL. Ensure that you have updated your ISPConfig to 3.1.6.
Thanks Till, I was going through the changelog and spotted the fix on 3.1.4, I've upgraded now and will wait for some SPAM, thanks for getting back to me