# Configuration for CRM114 plugin
# 
# CRM114 INSTALLATION & CONFIGURATION:
# To use this plugin you have to set up CRM114 so that you have these files:
# mailreaver.crm, mailfilter.cf, rewrites.mfp, priolist.mfp, and .CSS files
# (see http://crm114.sourceforge.net/CRM114_Mailfilter_HOWTO.txt for details).
#
# The most important steps are:
#     mkdir ~/.crm114
#     cp mailfilter.cf rewrites.mfp *.crm ~/.crm114
#     cd ~/.crm114
#     cssutil -b -r spam.css
#     cssutil -b -r nonspam.css
#     touch priolist.mfp
#     $EDITOR mailfilter.cf
#     $EDITOR rewrites.mfp
#
# In mailfilter.cf check the option ":add_headers: /yes/"!
# (and do not bother to change the flag_subject_string options --
# this plugin ignores them anyway)
# 
# Plugin CONFIGURATION:
# To use the plugin you probably have to set the crm114_command.
# All other settings should have working default values,
# which are chosen to be cautionary and nonintrusive.
# The commented examples for each settings are my own tested configuration.
#
# Further Notes on Licence and Implementation are in crm114.pm and its POD
# 
#############################################################################

# these two lines are necessary to activate the plugin:
# for older versions <0.7
# loadplugin crm114 crm114.pm
# for newer versions >=0.7
loadplugin Mail::SpamAssassin::Plugin::CRM114 crm114.pm
full      CRM114_CHECK  eval:check_crm()

# this high priority is not necessary. but running late allows us
# to compare the CRM score and the result of all previous SA tests
#
# 899 is chosen as an optimization because FuzzyOCR runs at 900
# thus if CRM already yields a high SA score,
# then FuzzyOCR will decide to skip its tests
priority  CRM114_CHECK  899

# commandline to execute CRM114
# default: crm -u ~/.crm114 mailreaver.crm
#crm114_command /usr/local/bin/crm -u /var/amavis/.crm114 mailreaver.crm

# let SA add header lines to processed mails
#add_header all CRM114-Version _CRM114VERSION_
#add_header all CRM114-CacheID _CRM114CACHEID_
add_header all CRM114-Status _CRM114STATUS_ ( _CRM114SCORE_ )

# ignore existing X-Spam or X-Virus headers
# if SpamAssassin is called by Amavis then use the same value as Amavis does.
# that way a SA-check from Amavis and on from the command line both see the same
# Headers
# default: 0
#crm114_remove_existing_spam_headers 1
#crm114_remove_existing_virus_headers 1

# dynamic score
# values: 0 - returns subtest results 
#         1 - returns a dynamic CRM score (default)
#crm114_dynscore 1

# dynamic score normalization factor
# CRM score have much higher absolute values and different signs than SA scores
# (usual ham-scores are between 15 and 40, scores from -10 to 10 are undecided,
# previously seen spam easily gets -200).
# With dynamic scoring the SA score is calculated by: <CRM score> * crm114_dynscore_factor
#
# Notes: - this has to be a negative number!
#        - the absolute value should be quite low (certainly <.3, probably <=.2),
#          otherwise the returned score would override all other tests.
# default: calculate factor so that CRM-score -25 yields the SA required spam threshold
#crm114_dynscore_factor -0.05

# static scores
# without dynamic scores these scores are used
# default values are respectively -3, 3, -0.5, 0.5, and 0 for good, spam,
# probably good, probably spam, and unsure.  good/spam depend on crm114's
# classification the probably good/spam values are used
# for |crm114-score| >= 5 (i.e. a crm114-classification of unsure)
# leaving |crm114-score| < 5 for 'really' unsure  
#crm114_staticscore_good      -3.0
#crm114_staticscore_prob_good -0.5
#crm114_staticscore_unsure     0.0
#crm114_staticscore_prob_spam  0.5
#crm114_staticscore_spam       3.0

# custom crm114 thresholds; these settings override variables :good_threshold:
# and :spam_threshold: in mailfilter.cf, and are also used to determine
# additional classes prob_good/prob_spam when crm114_dynscore is false.
# default values are +10 for good threshold and -10 for spam threshold
#crm114_good_threshold  10
#crm114_spam_threshold -10

# should CRM114 be trained by SA?
# If enabled, then a call to Mail::SpamAssassin->learn() or
# "spamassassin --report/--revoke" also calls the CRM114 plugin.
# Since CRM114 uses a "Train On Error" strategy the plugin will check the
# reported mail and only learn it if it is not classified correctly.
# default: 0
#crm114_learn 1

# should CRM114 be trained by SA-autolearn?
# If enabled, then SA's autolearn also calls the CRM114 plugin.
#
# This is different from :automatic_training: in CRM114's mailfilter.cf
# because SA's score is influenced by several different factors while
# CRM114 has to rely on its own classification. 
# But anyway: Only activate this if you know what you're doing!
# (in other words: if non-learning SA rules (without AWL and Bayes) are
# already well tuned and are known to provide good results)
# default: 0
#crm114_autolearn 1

# should we preserve the message and its CRM114-CacheID for training
# or discard it?
#
# to let CRM114 store messages into reaver_cache and use the cache for
# manual learning enable it in mailfilter.cf, set this option, and
# include the CacheID into all Mails with
# "add_header all CRM114-CacheID _CRM114CACHEID_"
# -- otherwise disable this option to strip CacheIDs before training
# default: 0
#crm114_use_cacheid 1

# if both crm114_lookup_cacheid and crm114_use_cacheid are true
# and CRM114-CacheID is not found in the message, do a lookup in the
# reaver_cache/texts directory; crm114_cache_dir also needs to be set
# default: 0
#crm114_lookup_cacheid 1

# a reaver_cache/texts directory used to lookup cacheid
# if crm114_lookup_cacheid is set
# default: ~/.crm114/reaver_cache
#crm114_cache_dir path

# should we skip CRM114 if other tests indicate certain spam/ham?
#
# disable CRM114 if a message already has a score (from other tests)
# less than crm114_autodisable_negative_score or
# more than crm114_autodisable_score.
#
# default: -999/999 
# crm114_autodisable_negative_score -999
# crm114_autodisable_score 999