Spam Assassin subject Tagging

[gonecrazy]

I had a custom subject tag setup in my local.cf file in /etc/mail/spamassassin i changed that option for the new 3.0.x version of spamassassin upgraded to dsm 3, ran a spamassassin --lint and everything checks out fine, but now when spam gets taged its useing the default spamassassin subject tag, and not using the report_safe option either. Does dsm 3.0 specifiy a different local.cf config file for spamassasin then the default? The new 3.0 version seems not to be even reading any of my custom server rules setup in /etc/mail/spamassassin, which makes setting the trusted_networks option very hard to do so that spamassassin runs correctly. Where do I find the local.cf file that spamasssassin is using in the dsm 3.0 version?

Thank you
Andrew

[LeeJ]

Try placing your files within the directory below.
/usr/share/spamassassin

[gonecrazy]

After doing a lot more digging into this issue. it seems the dsm 3 upgrade overwrote all of the user_prefs files that were on the system This should not happen, all customer whitelists or preferences that users had are now gone. Also, this new user_prefs file that was created specifically creates a rewrite_header for the Subject tag and a report_safe to 0 in it, making it impossible to do a global server setting for those two options which we had setup in dsm 2. I would consider this a major flaw in 3.0. Now I can fix this by deleting all the user_prefs files on the system and spamassassin will recreate the prefs file as the user gets mail, but if any new customers are created they will have the same problem until those two options are removed from their user_prefs file. Since there is no way to change those two options in the graphical interface, I don't believe that dsm should create them in the user_prefs file that it creates. Even if there was a option to set them it shouldn't set them explicitly unless the user wants that, other wise the local.cf file for global server settings has no way of over riding it.

[gonecrazy]

It seems it only destroyed about half of the user_prefs files, and left some of them untouched, i would think the upgrade script has a slight issue. It seems to be the same accounts that it disabled spam filtering on durning the upgrade.

[gonecrazy]

Ok, when you go into user details on a email user and the spam filtering box isn't checked after the upgrade it seems related to the dsm 3 upgrade script not changeing the .mailfilter file to the new spamassassin exception and clamassassin exception format. You can go into every email on the system and check the spam box and it will rebuild the .mailfilter file correctly. This is a nececity, becouse other wise if its a local system email (from a email from that domain to anouther email address in the same domain) the clamwrap script is killing the message that it feeds to spamassassin becouse of the newer version of courier and then spamassassin feeds just its headers back to the mta, and you get a blank message with no from, no date, no body or headers at all.

The dsm 3 upgrade should rewrite all of the .mailfilter files if they exsist, we now have to go in and touch each user individual and the mail that they have recived since the upgrade has been lost. Makes for lots of unhappy customers.

[Staff]

It seems it only destroyed about half of the user_prefs files, and left some of them untouched, i would think the upgrade script has a slight issue. It seems to be the same accounts that it disabled spam filtering on durning the upgrade.

The upgrade scripts don't touch the spamassassin files. The RPM upgrade to SpamAssassin may change the global ones, but the local ones simply arn't touched.

The dsm 3 upgrade should rewrite all of the .mailfilter files if they exsist, we now have to go in and touch each user individual and the mail that they have recived since the upgrade has been lost.
The only major change in these files actually occured after the DSM3 upgrade script was complete. Because of the numerous issues reported with the "clamwrap" script we have added functionality to use a new script called "clamassassin", which is actively maintained and updated.

I'll place a bug into our tracker and we will look at how realistic re-writing every system user's mail filter files are. The issue becomes that in re-writing these files we need a substantial amount of logic to ensure that we do not damage custom entries.

Anytime an xfilter command fails inside of an exception block within the courier filter langauge, a temporary failure is returned. Assuming you resolve this issue for your users before the message is perminantly returned you should be able to avoid any lost mail. In the upgrades we've performed, I've have not seen a situation where mail was being returned after a successful update.