Re: header inventory

SpamAssassin is heavily customizable as to what headers it inserts.   
The defaults are:

######################################################################## 
##
# Headers to be added to mail (can be overriden by users in
# ~/.spamassassin/user_prefs)
# Make sure the header stays entirely on one line here

clear_headers

#X-Spam-Checker-Version: SpamAssassin 2.60-cvs (1.188-2003-05-24-exp)
add_header all Checker-Version SpamAssassin _VERSION_ (_SUBVERSION_) on  
_HOSTNAME_

#X-Spam-Flag: YES
add_header spam Flag _YESNOCAPS_

#X-Spam-Level: *************
add_header all Level _STARS(*)_

#X-Spam-Status: Yes, hits=14.0 required=5.0 tests=BAYES_99,CALL_FREE
#         
DATE_IN_PAST_12_24,DCC_CHECK,DRASTIC_REDUCED,FROM_HAS_MIXED_NUMS
#        FROM_HAS_MIXED_NUMS3,HOME_EMPLOYMENT,INVALID_DATE,INVALID_MSGID
#        LINES_OF_YELLING,MSGID_HAS_NO_AT,NO_REAL_NAME,ONCE_IN_LIFETIME
#        REMOVE_SUBJ,SMTPD_IN_RCVD,T_INVALID_DATE_2,T_INVALID_DATE_HMS
#        UNDISC_RECIPS autolearn=spam version=2.60-cvs
add_header all Status "_YESNO_, hits=_HITS_ required=_REQD_  
tests=_TESTS_ autolearn=_AUTOLEARN_ version=_VERSION_"


The range of things which can be inserted into any such defined headers  
is:

TAGS
        The following "tags" can be used as placeholders in certain  
options
        specified below. They will be replaced by the corresponding  
value when
        they are used.

        Some tags can take an argument (in parentheses). The argument is
        optional, and the default is shown below.

         _YESNOCAPS_       "YES"/"NO" for is/isn't spam
         _YESNO_           "Yes"/"No" for is/isn't spam
         _HITS_            message score
         _REQD_            message threshold
         _VERSION_         version (eg. 2.55)
         _SUBVERSION_      sub-version (eg. 1.187-2003-05-15-exp)
         _HOSTNAME_        hostname
         _BAYES_           bayes score
         _AWL_             AWL modifier
         _DATE_            rfc-2822 date of scan
         _STARS(*)_        one * (use any character) for each score  
point (note: this
                           is limited to 50 'stars' to stay on the right  
side of the RFCs)
         _RELAYSTRUSTED_   relays used and deemed to be trusted
         _RELAYSUNTRUSTED_ relays used that can not be trusted
         _AUTOLEARN_       autolearn status ("ham", "no", "spam")
         _TESTS(,)_        tests hit separated by , (or other separator)
         _TESTSSCORES(,)_  as above, except with scores appended (eg.  
AWL=-3.0,...)
         _DCCB_            DCC's "Brand"
         _DCCR_            DCC's results
         _PYZOR_           Pyzor results
         _RBL_             full results for positive RBL queries in DNS  
URI format
         _LANGUAGES_       possible languages of mail
         _PREVIEW_         content preview
         _REPORT_          terse report of tests hits (for header  
reports)
         _SUMMARY_         summary of tests hit for standard report (for  
body reports)
         _CONTACTADDRESS_  contents of the 'report_contact' setting


On Mar 10, 2004, at 5:42 PM, <[email protected]> wrote:

> Perhaps it makes sense for the various filter writers and sysadmins
> on this list to offer an inventory of the various modifications
> each of their systems add to a message, so we can see where people
> agree and where they differ, and get to know patterns of use.
>
>
>
> I'll begin with dbacl. It's a Bayesian procmail filter. Learning
> is performed on mbox archives which may or may not have been filtered
> previously.
>
> The recommended rfc headers to be added by procmail are all optional
> and in the form:
>
> X-DBACL-Says: cat2
> X-DBACL-Scores: cat1 12.7 * 453 cat2 11.3 * 453 cat3 14.9 * 453
>
> The reason for adding headers is purely for the benefit of the MUA, as
> messages are delivered to putative mailboxes by procmail already.
>
> dbacl does not store any other information destined for itself in a  
> message.
> Thus, there is no intended direct feedback loop between filtering and
> (re)learning stages.
>
> Because learning takes place on potentially filtered messages, it is
> important for dbacl to recognize its own headers and skip them. That
> is why the program contains logic to skip all "X-DBACL" prefixed
> headers.
>
> Since procmail does the actual adding of headers, a user is of course
> free to use any headers they like, but using different headers will
> introduce a subtle bias.
>
> There is no structure to the category labels cat1,cat2,cat3 etc.
> which reflect the user's filtering needs. The scores simply represent
> average bits of information per token, under various category  
> assumptions.
>
> -- 
> Laird Breyer.
>
>

[demime 0.99d.1 removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]