Better directions for custom SpamAssassin rule scoring

[sneader]

Let's say that I don't want SpamAssassin to score a certain rule, like FORGED_MUA_OUTLOOK. How do I accomplish this in cPanel?

The directions say you can do it, but they do not give a specific example of what to put into the "score" input field.

Take a look at my screen shot. I tried to add this as "0 FORGED_MUA_OUTLOOK" and also as "FORGED_MUA_OUTLOOK 0" and cPanel happily took it both ways. Is either correct? I have no idea.

A simple example would totally clear this up.

- Scott

SCREEN SHOT:

[sneader]

*bump*

Anybody know how to use this feature?

Anyone at cPanel out there reading, that can get this added to some internal bug track or feature request system?

Thanks!

- Scott

[cPanelDon]

For information on using cPanel to configure SpamAssassin, please reference our official documentation that describes usage and includes detailed examples of defining custom scores for individual tests performed by SpamAssassin; here is the reference menu path with linked documentation:

• cPanel: Main >> Mail >> Spam Assassin™
  • SpamAssassin: Set Individual Test Scores

For additional reference I recommend reviewing the following resources on the official SpamAssassin web site:

• Mail::SpamAssassin::Conf - SpamAssassin configuration file
• SpamAssassin: Documentation
• SpamAssassin: Tests Performed
• FrequentlyAskedQuestions - Spamassassin Wiki
• HowScoresAreAssigned - Spamassassin Wiki
• MailingLists - Spamassassin Wiki
• WhereDoLocalSettingsGo - Spamassassin Wiki

The SpamAssassin user preferences file for each cPanel user account is located within the user's home directory ("~username/") at a path like the following (where "username" represents the cPanel account username):

~username/.spamassassin/user_prefs

A stock-default example of a SpamAssassin user preferences file may be found via SSH access; on a few test systems I noted the following location as the common file system path:

/usr/share/spamassassin/user_prefs.template

Here are the contents of the aforementioned example user preferences file:

# SpamAssassin user preferences file.  See 'perldoc Mail::SpamAssassin::Conf'
# for details of what can be tweaked.
#* 
#* Note: this file is not read by SpamAssassin until copied into the user
#* directory. At runtime, if a user has no preferences in their home directory
#* already, it will be copied for them, allowing them to perform personalised
#* customisation.  If you want to make changes to the site-wide defaults,
#* create a file in /etc/spamassassin or /etc/mail/spamassassin instead.
###########################################################################

# How many points before a mail is considered spam.
# required_score                5

# Whitelist and blacklist addresses are now file-glob-style patterns, so
# "friend@somewhere.com", "*@isp.com", or "*.domain.net" will all work.
# whitelist_from        someone@somewhere.com

# Add your own customised scores for some tests below.  The default scores are
# read from the installed spamassassin rules files, but you can override them
# here.  To see the list of tests and their default scores, go to
# http://spamassassin.apache.org/tests.html .
#
# score SYMBOLIC_TEST_NAME n.nn

# Speakers of Asian languages, like Chinese, Japanese and Korean, will almost
# definitely want to uncomment the following lines.  They will switch off some
# rules that detect 8-bit characters, which commonly trigger on mails using CJK
# character sets, or that assume a western-style charset is in use. 
# 
# score HTML_COMMENT_8BITS      0
# score UPPERCASE_25_50         0
# score UPPERCASE_50_75         0
# score UPPERCASE_75_100        0
# score OBSCURED_EMAIL          0

# Speakers of any language that uses non-English, accented characters may wish
# to uncomment the following lines.   They turn off rules that fire on
# misformatted messages generated by common mail apps in contravention of the
# email RFCs.

# score SUBJ_ILLEGAL_CHARS      0

[sneader]

Hi Don.

I started this thread in Feature Requests because, well, it's primarily a feature request. The instructions for the end-users are incomplete. They need to know how to use the feature. A bonus would be some input sanitization.

The screen shot I provided clearly shows the problem. The users are not told how to enter in the Rule and the Score, and cPanel gladly takes whatever you enter, no matter how it is entered.

As it turns out, after reading the suggested documentation, I found out that if the user wants to score the SA Rule "FORGED_MUA_OUTLOOK" as 0, the user needs to enter it in as:

FORGED_MUA_OUTLOOK 0

i.e. the rule, then a space, then the number (whole numbers or decimal as in #.##)

While I'm glad to now know how to use the feature, the user interface in cPanel needs to be tweaked to explain how to use it. A simple example is all that is probably required.

Thanks for listening.

- Scott

[cpanelkenneth]

Hi Don.

I started this thread in Feature Requests because, well, it's primarily a feature request. The instructions for the end-users are incomplete. They need to know how to use the feature. A bonus would be some input sanitization.

The screen shot I provided clearly shows the problem. The users are not told how to enter in the Rule and the Score, and cPanel gladly takes whatever you enter, no matter how it is entered.

As it turns out, after reading the suggested documentation, I found out that if the user wants to score the SA Rule "FORGED_MUA_OUTLOOK" as 0, the user needs to enter it in as:

FORGED_MUA_OUTLOOK 0

i.e. the rule, then a space, then the number (whole numbers or decimal as in #.##)

While I'm glad to now know how to use the feature, the user interface in cPanel needs to be tweaked to explain how to use it. A simple example is all that is probably required.

Thanks for listening.

- Scott

Looks like the text fields could also be widened so you can actually see the rule you are defining.