Spamassassin configure errors

[dory36]

When a user wants anything other than the offered configure options in Spamassassin (such as whitelist_to or blacklist_to), the user_prefs file must be edited manually.

The next time the user visits the cpanel spamassassin configure screen, these new entries show up in an editable box, which looks nice to the user -- if only they would work the way you'd expect.

Not only do edits not seem to get written, the extra lines are duplicated every time the user edits and saves the configuration via the GUI.

Any ideas or workarounds?

Thanks,
Bill

 

[spiff06]

Cool.

Have you tested that the whitelist_to option thus applied works (at least until the next visit to the SA cPanel screen), or is cPanel's SA forcibly configured to ignore options other than those offered by default?

I could live with avoiding trips to the cPanel SA page and editing the file (/home/<user>/.spamassassin/user_prefs, if I'm not mistaken) manually, at least until a fix is made to provide more SA options in cPanel.

EDIT: Actually, if you've tested this and found your manual change to work, then it must be pretty easy for script experts to figure out a way to properly handle these options.

Eric

 

[jsteel]

Has anyone actually ever gotten customized user_prefs to work on accounts created through the Manage Accounts interface in cPanel, or will this file only impact the default username's account?

 

[spiff06]

Manual additions to this file, such as "whitelist_to [email protected]", appear to be working fine, and affect all email accounts on the domain.

Thus, addition of "whitelist_to *@yahoogroups.com" in this file means SA will not check any email sent to yahoo groups' subscribers, and place it as is in the recipient's inbox.

I wager that since options can be manually entered in this file, it may be worth a shot to try some per-user options.

Eric

 

[jsteel]

We've got global options in there but they don't seem to be getting read at all.

Our note about other users was a result of another posting we found stating that the additons to that file only impact the default email account and no others.

 

[dory36]

I haven't seen cases where only the default account is affected. We have dozens of cases where every address in the domain gets the same treatment, and didn't do anything special to make that happen.

We make changes using either the configure SpamAssassin panel in cpanel or by editing user_prefs. Otherwise we pretty much do everything in cpanel.

Either way, the changes affect all the addresses in the domain.

Bill

 

[spiff06]

Some SA expert should jump in here and tell us. Indeed I've just realized that my whitelist_to entry has only been checked against the default account.

Eric

EDIT: Thanks, Dory36, for the (simultaneous) reply

 

[jsteel]

Let's hope an SA expert responds. From what I have gathered, the user_prefs file will only impact the default account unless the 'allow_user_rules' option is added and set to true in the master local.cf; however, it's noted that doing so is a security vulnerability. This information was gleaned from SA docs and forums all over the net, including http://mywebpages.comcast.net/mkettler/sa/SA-rules-howto.txt.

Based on this, I'm not sure how dory36 ever got it to impact all accounts without making that config addition.

Seems kinda senseless that we have an anti-spam tool that can't be configured by our users (though they believe they can from reading the SA site), without us opening a potential hole in the server.

 

[dory36]

Yes - we have that addon. I forgot about it -- it was quite a while ago.

I'm not sure how vulnerable this really makes things, but in any event, most of our users have access only to the config panel in the xmail theme of cpanel.

 

[jsteel]

Originally posted by dory36
Yes - we have that addon. I forgot about it -- it was quite a while ago.

I'm not sure how vulnerable this really makes things, but in any event, most of our users have access only to the config panel in the xmail theme of cpanel.

If they have access to the user_prefs file for editing, then it could be quite vulnerable based on the SA docs.