SpamAssassin no longer modifying subject line. (cPanel 6)

[mccmikey]

G'day

My parent hosting provider appears to have upgraded to cPanel 6. Since then SpamAssassin is not altering the subject line, but is doing everything else that it used to. I have tried disabling and re-enabling SA.

Has anyone else come across this problem?

Cheers, Mike.

http://www.auzzie.net/

 

[perlchild]

spamassassin

from reading the spamassasin mailing list, there MIGHT
be a configuration option to return to the old behaviour,
otherwise, I'd suggest you look at spamassassin.org
they might have the authoritative answer for you

 

[dgbaker]

Try this;

In /usr/share/spamassassin

edit 10_misc.cf

Look for the following lines

10_misc.cf: rewrite_subject 0
10_misc.cf: subject_tag *****SPAM*****

change the 0 to a 1

That should turn it back on.

 

[mccmikey]

G'day again

My parent hosts have tried your solution, and also tried rebooting the server, but the problem still remains.

Any other suggestions?

Cheers, Mike.

 

[JC]

Well Mike,

David is right.
I did some testing because it is also happening on my server.
It does work as he says if you add those options into each /home/user/.spamassassin/user_prefs

I just added the following at the end of each file:
rewrite_subject 1
# report_safe 1
subject_tag *****SPAM*****
# use_terse_report 0
# skip_rbl_checks 0
# check_mx_attempts 2
# check_mx_delay 5

Tested by sending a spam message and it works now. Why it doesn't work serverwide I cannot gues :-(

 

[trakwebster]

system-wide config for spamassassin

At spamassassin.org/doc.html there is a 'Top Level README File' which, among many many many other things, says:

Customising SpamAssassin
------------------------

These are the configuration files installed by SpamAssassin. The commands
that can be used therein are listed in the POD documentation for the
Mail::SpamAssassin::Conf class (run the following command to read it:
"perldoc Mail::SpamAssassin::Conf"). Note: The following directories are
the standard defaults that people use. There is an explanation of all the
default locations that SpamAssassin will look at the end.

- /usr/share/spamassassin/*.cf:

Distributed configuration files, with all defaults. Do not modify
these, as they are overwritten when you upgrade.

- /etc/mail/spamassassin/*.cf:

Site config files, for system admins to create, modify, and
add local rules and scores to. Modifications here will be
appended to the config loaded from the above directory.

- /usr/share/spamassassin/user_prefs.template:

Distributed default user preferences. Do not modify this, as it is
overwritten when you upgrade.

- /etc/mail/spamassassin/user_prefs.template:

Default user preferences, for system admins to create, modify, and
set defaults for users' preferences files. Takes precedence over
the above prefs file, if it exists.

Do not put system-wide settings in here; put them in the
/etc/mail/spamassassin directory. This file is just a template,
which will be copied to a user's home directory for them to
change.

[ snip -- it then goes on to the config available inside the user's home area ]


Now, I'm not very skillful at this, but it would appear that the one which would produce system-wide change would be the second one, here:


- /etc/mail/spamassassin/*.cf:

When I went there I found only one file called local.conf. Inside it says:

# this is the right place to customize your installation of SpamAssassin
# See 'perldoc Mail::SpamAssassin::Conf for details of what can be tweaked
#
#rewrite_subject 0
#report_header 1
#defang_mime 0

I tried uncommenting rewrite_subject and setting the value to 1.

However, it didn't seem to make any difference. I sent myself some spam, and although all the 'analysis' is printed inside the email when received, the header is not rewritten.

I might guess that the spam daemon may need to be restarted because if it's smart it only reads the config file once; but I do not know how to restart it, assuming that the spam daemon is in fact running.

I tried the suggestion about using the command perldoc blahblah, but my system complained that something called taint needed to be enabled.

I suppose I could rewrite all the user prefs, but it's meant to be configurable system wide, so there must be a way it can be done.

Anyone?

 

[dgbaker]

To use perldoc make sure you are NOT root.

 

[trakwebster]

Must be root ... must not be root!

David,

aha!

Ok, one devil down, 428 to go!

-- Arthur Cronos at Voltos

 

[jumpdomain]

Cpanel upgraded Spamassassin with the Cpanel 6 upgrade... So this behavior changed.

To put the *****SPAM***** back in the subject line by default, edit this file:
/etc/mail/spamassassin/local.cf

And put in this line:
rewrite_subject 1

Then restart spamd by restarting Exim:
service exim restart

This upgrade (finally) made it possible for users to use their own preferences again. So the user can turn this off if they want by editing the:
~/.spamassassin/user_pref file and putting in:
rewrite_subject 0

 

[trakwebster]

Found the problem!

Hi, jumpdomain,

What you say makes sense. This is exactly what the SpamAssassin document says should work.

All the same, I did just those things and restarted exim ... but it did not seem to work.

However, I've found where the problem lies. When, as root, I restart exim with

service exim restart

then it *does* stop and restart the spamd daemon along with exim.

However, apparently when I *restart* exim by using WHMgr, it does restart exim but it must not restart spamd, because if you do it that way, the emails's subjects do *NOT* show the change you've made to /etc/mail/spamassassin/local.cf

Saying it another way, in order to re-enable SpamAssassin to write *****SPAM***** in the subject line, after you edit the /etc/mail/spamassassin/local.cf file you must restart exim with the shell command, not with WHMgr.

Thanks for your help!

 

[SageBrian]

Re: Found the problem!

Originally posted by trakwebster

However, I've found where the problem lies. When, as root, I restart exim with

service exim restart

then it *does* stop and restart the spamd daemon along with exim.

However, apparently when I *restart* exim by using WHMgr, it does restart exim but it must not restart spamd, because if you do it that way, the emails's subjects do *NOT* show the change you've made to /etc/mail/spamassassin/local.cf

Saying it another way, in order to re-enable SpamAssassin to write *****SPAM***** in the subject line, after you edit the /etc/mail/spamassassin/local.cf file you must restart exim with the shell command, not with WHMgr.

Confirmed. Worked great. While there, I also made sure that my email address was put in on the WhiteList.

Let's hope that SpamAssassin and Exim don't change the system again.

And, maybe in the future, when we restart exim from WHM, it will behave like the command line? Or, better yet.... what if we had a way to issue a command line directly from WHM?