You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Matt Wills <fm...@virtualvermont.com> on 2005/06/24 03:21:00 UTC

Customizing headers

Following an example I saw elsewhere, I thought I would get cute and 
customize my headers:

clear_headers
add_header all Flag _YESNOCAPS_
add_header spam Level _STARS(*)_
fold_headers 1
add_header all Summary Score _HITS_ (Spam threshold is _REQD_); 
Tests: _TESTSSCORES(, )_

Looks great, just what I had in mind.

Yes, looks great, but now the spam is just being flagged. Instead of 
going to its spam mailbox, the headers tell me it is spam, the score 
(7.69), threshold (5.0), tests, etc., but the mail comes through to 
my regular mailbox.

I am assuming that one or more of the options above negate sending 
spam to the spam mailbox, but which one, and how do I tell it where 
it should go?

Matt
-- 
"A vacuum is a hell of a lot better than some
of the stuff that nature replaces it with."
           --Tennessee Williams

Re: Customizing headers

Posted by mouss <us...@free.fr>.
Erwin Zavala wrote:
> Could some explain to me what each of these line says.  If you are
> going to refer me to the manual,  please save it.  I am asking this
> question because I cannot understand the syntax from the manual.
> 


The manual is actually not very difficult to read, but since you asked, 
here is a try (If I'm wrong, I hope I'll be soon corrected).

>>clear_headers

by default, SA will add some headers. when you want to customize these 
headers, use clear_headers. now, SA won't add default headers, so we 
need to configure new onces, which is done next.

>>add_header all Flag _YESNOCAPS_

To all messages (both spam and ham), add a header "X-Spam-Flag", and put 
YES or NO in its value, depending on whether it is spam or ham.

An example header would be:
	X-Spam-Flag: YES

you can change the header name, but it always start with X-Spam-. to use 
a header of X-Spam-Erwin, just use "add_header all Erwin ...".
also, the value field may be customized. there are some "magical" 
strings that have special meaning. Here _YESNOCAPS_ means either "YES" 
or "NO" (fully capitalized. if you prefer "Yes" or "No", use _YESNO_ 
instead).

>>add_header spam Level _STARS(*)_

if the message is spam, add a header named "X-Spam-Level", and in its 
value, put N '*' where N is the (rounded to int) spam score. to avoid 
too long headers, N <= 50.

An example header would be:
	X-Spam-Level: **********


if you prefer other characters, you can for instance use _STARS(s)_, 
this way you'll get "sssss" instead of "*****". use this if you want to 
filter this header in MDAs and MUAs and don't like having to deal with 
the fact that '*' is a special char (in most MDAs, you'll need to escape 
it. in MUAs, that's no certain...).


>>fold_headers 1
This is the default. It means SA headers will be "folded", that is, 
multi-line (with the rfc-mandated whitespace in continuation lines of 
course).

If you prefer a very long header on one line, then use '0' instead of 
'1'. but this is rarely justifiable.

>>add_header all Summary Score _HITS_ (Spam threshold is _REQD_); 
 >>    Tests: _TESTSSCORES(, )_

[the above is all on one line. I've wrapped to make sure a MUA won't 
wrap it wrong;-]

To all messages, add a header of the form:

X-Spam-Summary: core _HITS_ (Spam threshold is _REQD_); Tests: ...

where
- _HITS_ is the score of the message
- _REQD_ is the configured threshold (above which a message is 
considered spam).
- _TESTSCORES(,)_ is the list of matched tests together with their 
score. as the manual says, an example would be "AWL=-3.0,...".





Re: Customizing headers

Posted by Erwin Zavala <er...@gmail.com>.
Could some explain to me what each of these line says.  If you are
going to refer me to the manual,  please save it.  I am asking this
question because I cannot understand the syntax from the manual.

> clear_headers
> add_header all Flag _YESNOCAPS_
> add_header spam Level _STARS(*)_
> fold_headers 1
> add_header all Summary Score _HITS_ (Spam threshold is _REQD_);
> Tests: _TESTSSCORES(, )_
> 


On 6/23/05, Matt Wills <fm...@virtualvermont.com> wrote:
> Following an example I saw elsewhere, I thought I would get cute and
> customize my headers:
> 
> clear_headers
> add_header all Flag _YESNOCAPS_
> add_header spam Level _STARS(*)_
> fold_headers 1
> add_header all Summary Score _HITS_ (Spam threshold is _REQD_);
> Tests: _TESTSSCORES(, )_
> 
> Looks great, just what I had in mind.
> 
> Yes, looks great, but now the spam is just being flagged. Instead of
> going to its spam mailbox, the headers tell me it is spam, the score
> (7.69), threshold (5.0), tests, etc., but the mail comes through to
> my regular mailbox.
> 
> I am assuming that one or more of the options above negate sending
> spam to the spam mailbox, but which one, and how do I tell it where
> it should go?
> 
> Matt
> --
> "A vacuum is a hell of a lot better than some
> of the stuff that nature replaces it with."
>           --Tennessee Williams
>

Re: Customizing headers

Posted by jdow <jd...@earthlink.net>.
From: "jdow" <jd...@earthlink.net>

> So I created a custom header, sort of like "X-Spoo: Before SpamAssassin".
> Then I look for the usual first SpamAssassin header as well. If the
> former exists and the latter does not I apply a small subject markup
> and then feed it to regular SpamAssassin slightly niced to keep machine
> load down.
> 
> I wish I could get the error message to spit out the actual eval rule
> that was kicking out the error. Then I could feed it to the developers
> perhaps with a fix. But the error message is not generated my any of
> the SpamAssassin perl files. So I have to use indirect tricks.
> 
> (The only eval rules I have are in SARE rules. But it seems to be
> related to specific sorts of things in my user_prefs rules. Lately
> the working hypothesis is "full" rules are causing the glitch.)
> 
> Anyway - this is an example of how procmail can be used as a diagnostic
> as well as sorting tool.

Ah - and that new procmailrc setup just showed me that it was not the
full rule that caused the mistrigger. Something else is doing it. I wonder
if I have too many user_prefs rules....

And customizing headers is enabling this trouble shooting. They also show
me that "spamassassin" itself does not experience the hit when spamc/spamd
does.

{^_-}

Here is the procmail recipe:
===8<---
:0 fw
* ^X-Spoo: Before
{
   :0 fw
   * !^X-Spam-Checker-Version:
   {
      :0 fw
      | sed -e 's/Subject:/Subject: [ZZ Missed]/'

      :0 fw
      | nice -n 1 /usr/bin/spamassassin
   }
}



Re: Customizing headers

Posted by jdow <jd...@earthlink.net>.
From: "Matt Wills" <FM...@VirtualVermont.com>

> At 09:45 PM 6/23/2005, jdow wrote:
>
> It is not SpamAssassin that sends things to your spam mail box. It is
> >your milter, procmail, or other similar tool which reads the headers
> >SpamAssassin adds and sorts the mail into your spam mailbox. You
> >apparently destroyed the piece of header format that was being used
> >in the test.
> >
> >{^_^}
>
> That answers it.
>
> The procmailrc is exactly as was automatically set up on my FreeBSD server
> with the auto-install. Near the bottom, I see a recipe that appears to say
> "If the X-Spam-Status is Yes, put it in the var/mail/spam mailbox".
>
> With my customized headings, I have no X-Spam-Status header.
>
> Thanks for pointing me there.
>
> Matt

Glad I helped. I'm currently fiddling procmailrc rules to track down an
annoyance with PerMsgStatus.pm. If I have a "full" rule as a user it
will randomly trigger a security error trying to run as a user. The
same message will not always trigger the error. But when I get the
error SpamAssassin leaves no markup.

So I created a custom header, sort of like "X-Spoo: Before SpamAssassin".
Then I look for the usual first SpamAssassin header as well. If the
former exists and the latter does not I apply a small subject markup
and then feed it to regular SpamAssassin slightly niced to keep machine
load down.

I wish I could get the error message to spit out the actual eval rule
that was kicking out the error. Then I could feed it to the developers
perhaps with a fix. But the error message is not generated my any of
the SpamAssassin perl files. So I have to use indirect tricks.

(The only eval rules I have are in SARE rules. But it seems to be
related to specific sorts of things in my user_prefs rules. Lately
the working hypothesis is "full" rules are causing the glitch.)

Anyway - this is an example of how procmail can be used as a diagnostic
as well as sorting tool.

{^_^}



Re: Customizing headers

Posted by Matt Wills <FM...@VirtualVermont.com>.
At 09:45 PM 6/23/2005, jdow wrote:

It is not SpamAssassin that sends things to your spam mail box. It is
>your milter, procmail, or other similar tool which reads the headers
>SpamAssassin adds and sorts the mail into your spam mailbox. You
>apparently destroyed the piece of header format that was being used
>in the test.
>
>{^_^}

That answers it.

The procmailrc is exactly as was automatically set up on my FreeBSD server 
with the auto-install. Near the bottom, I see a recipe that appears to say 
"If the X-Spam-Status is Yes, put it in the var/mail/spam mailbox".

With my customized headings, I have no X-Spam-Status header.

Thanks for pointing me there.

Matt 



Re: Customizing headers

Posted by jdow <jd...@earthlink.net>.
From: "Matt Wills" <fm...@virtualvermont.com>

> Following an example I saw elsewhere, I thought I would get cute and 
> customize my headers:
> 
> clear_headers
> add_header all Flag _YESNOCAPS_
> add_header spam Level _STARS(*)_
> fold_headers 1
> add_header all Summary Score _HITS_ (Spam threshold is _REQD_); 
> Tests: _TESTSSCORES(, )_
> 
> Looks great, just what I had in mind.
> 
> Yes, looks great, but now the spam is just being flagged. Instead of 
> going to its spam mailbox, the headers tell me it is spam, the score 
> (7.69), threshold (5.0), tests, etc., but the mail comes through to 
> my regular mailbox.
> 
> I am assuming that one or more of the options above negate sending 
> spam to the spam mailbox, but which one, and how do I tell it where 
> it should go?
> 
> Matt

It is not SpamAssassin that sends things to your spam mail box. It is
your milter, procmail, or other similar tool which reads the headers
SpamAssassin adds and sorts the mail into your spam mailbox. You
apparently destroyed the piece of header format that was being used
in the test.

{^_^}


Re: Customizing headers

Posted by Loren Wilton <lw...@earthlink.net>.
> I am assuming that one or more of the options above negate sending
> spam to the spam mailbox, but which one, and how do I tell it where
> it should go?

Unknown.  SA doesn't route mail, it just marks it.  Something else in your
processing chain is looking at the markup to do the routing.  Postfix,
Amvis, maybe something else depending on how you have things set up.

        Loren


Re: Customizing headers

Posted by Matt Kettler <mk...@evi-inc.com>.
Matt Wills wrote:
> Following an example I saw elsewhere, I thought I would get cute and
> customize my headers:
> 
> clear_headers
> add_header all Flag _YESNOCAPS_
> add_header spam Level _STARS(*)_
> fold_headers 1
> add_header all Summary Score _HITS_ (Spam threshold is _REQD_); Tests:
> _TESTSSCORES(, )_
> 
> Looks great, just what I had in mind.
> 
> Yes, looks great, but now the spam is just being flagged. Instead of
> going to its spam mailbox, the headers tell me it is spam, the score
> (7.69), threshold (5.0), tests, etc., but the mail comes through to my
> regular mailbox.
> 
> I am assuming that one or more of the options above negate sending spam
> to the spam mailbox, but which one, and how do I tell it where it should
> go?

Where mail goes isn't a function of spamassassin. Period. SpamAssassin is
physically incapable of attempting to direct mail to a spambox. It's in the
wrong part of the mail change.


I'm guessing you've got some kind of procmail or mail client rule that looks for
SA's spam tag and moves the mail to your spambox. Find that, and change it to
fit the new tag format.

The old behavior you were seeing wasn't being done by SA, just a byproduct of
some other program interpreting SA's output.