adding headers to all mails with spamassassin

Hi,

After a lot of stuffing around I finally managed to get a configuration that fulfills your requirements. You can customise the sieve filter to add the appropriate header - I used Spam-test in this case - and to relocate to the appropriate spam folder - I used the 'spam' folder in this case.

These steps assume that you have spamassassin filtering running already.

1. Add "sourcespamfilter1optin spam" to the tcp_local channel.

2. Add the following to option.dat:

spamfilter1_config_file=/opt/SUNWmsgsrv/config/spamassassin.opt

spamfilter1_library=/opt/SUNWmsgsrv/lib/libspamass.so

spamfilter1_optional=1

spamfilter1_string_action=data:, \

require ["spamtest","relational","comparator-i;ascii-numeric","fileinto","addheader"]; \

spamadjust "$U"; addheader "Spam-Test: $U"; \

if spamtest :value "ge" :comparator "i;ascii-numeric" "5" {fileinto "spam";} \

else {keep;}

3. Add the following to /opt/SUNWmsgsrv/config/spamassassin.opt

!enable debug of spamassassin if set to 1

debug=0

!host/interface spamd process is listening on

host=localhost

! This port setting should match what spamd listens on, by default its 783

port=783

!return a result regardless of whether spam or not

mode=2

!need to have an empty field, otherwise spamadjust "$U" doesn't work

field=

!verdict not used with mode=2

verdict=

Regards,

Shane.

shane_hjorth at 2007-7-7 3:06:24 >

Hi,

This example would replace your current configuration - but you could customise the example to process emails how you like. The secret is in the use of "mode=2" to always call the spamfilter sieve rule and the use of the spamtest/spamadjust sieve actions.

The example provided will add a 'Spam-test: [True|False];<spam-score>/<spam threshold>' header to all emails (including ham emails as you requested), moving spam emails (ones with a score of 5 or more) to a "spam" folder.

You could also customise the filter provided to say discard emails that score greater then 10 (which is also pretty common).

Regards,

Shane.

shane_hjorth at 2007-7-7 3:06:24 >

Hi,

Unfortunately due to a limit in the size of the argument to the spamfilter1_string_action parameter the sieve filter that does the heavy lifting has been moved to a channel level sieve.

So to discard the email over 10, tag emails below 10 (ham & spam) and file emails from 5-10 into a spam folder you need to do the following:

Replace the previous spamfilter1_string_action with:

spamfilter1_string_action=data:, require ["addheader","spamtest"]; \

spamadjust "$U"; addheader "Spam-test: $U"

Create a file called spamassassin.filter in your msg_base/config/ directory and add the following:

require ["spamtest","relational","comparator-i;ascii-numeric","fileinto"];

if spamtest :value "ge" :comparator "i;ascii-numeric" "10" {discard;}

elsif spamtest :value "ge" :comparator "i;ascii-numeric" "5" {fileinto "spam";}

else {keep;}

Add the following in your imta.cnf file to the ims-ms channel definition:

destinationfilter file:IMTA_TABLE:spamassassin.filter

>do you add the spam header on ham too?

Yes. ALL scanned emails gets a header added - no harm really.

>how do you deal with spam in general?

At my previous employee we did what was listed above. Discard spam > 10, tag all emails with the score and filter emails into a spam folder for those emails between 5 and 10 (actually this was customisable/user but that means having a different sieve filter/user and you need to write a custom admin interface for that - most users used the default level to filter into a spam folder).

Also make sure you write an expiry rule for the spam folder so that the spam emails don't build up and consume a users quota e.g. expire emails in the spam folder greater then 30 days.

Regards,

Shane.

shane_hjorth at 2007-7-7 3:06:24 >

Hi,

As I noted earlier, the $U substitution occurs prior to the rule being evaluated, and given that the entire length of the spamfilter1_string_action is currently limited to 256 characters, if you were to pass in a whole bunch of rules hit (via $U) it would exceed the limit.

For future reference though you set use_check=0 in the spamassassin.opt file to return the rules hit, this will give you a header like the following:

Spam-test:False ; 0.2 / 5.0 ; ALL_TRUSTED,MISSING_HEADERS,MISSING_SUBJECT,TO_CC_NONE

Regards,

Shane.

shane_hjorth at 2007-7-7 3:06:24 >

> hi jay - no i didn't. how can i set the aci

> permissions to allow this on everyone's SPAM folder.

> from a previous post, i see i could use the DS

> console ... any details? you also said it could be

> done in webmail, does this mean share the spam folder

> - would that be sufficient (which perms: read, read

> write, read/write manage, for anyone, or

> anyone@mydomanin.com)?

Write is what you need. For the Messaging Server.

>

> p.s. when i try the initial example (for writing

> headers on all mail but only filing actual spam) it

> seems to work, but i see the spam-test header twice -

> is it looping (or being evaluated twice -maybe on

> another channel)? what's really odd is sometimes the

> first one is false, and the second one is true - i

> wonder if it were reversed, would the message not be

> filed?

>

> when i addtag - here is how the message appears in my

> spam folder (note score discrepency - which

> corresponds exactly to the two different Spam-test

> scores as above) - sometimes the placement of the tag

> is jumbled too... e.g. the score and tag will come

> after the subject, etc.

>

> Space Monkey 998.7 [SPAM detected True ; 997.5 /

> 5.0] test

>

> i should mention, as i look back on my older spam

> (from my original config, which files spam, and only

> writes headers on spam) the header was being written

> twice as well, the subject tags in these are also

> sometimes jumbled.

>

> thanks,

> s7

>

> .

I'll answer what I know, and hopefully, Shane will help out.

jay_plesset at 2007-7-7 3:06:24 >

Hi,

Please try turning on sieve filter logging (LOG_FILTER=1 in option.dat) and see what is logged in mail.log_current when you send a message.

Given the addition of two headers, I suspect you are either processing the message twice somehow or you are filtering the message twice e.g. one filter in the option.dat and another at the user-level or channel level.

Regards,

Shane.

shane_hjortha at 2007-7-21 15:29:11 >

Hi,

> will this help even if i'm not using a sieve filter?

I think you will find you are...

> since to have a sieve filter fileinto folders, i

> have to give write permission to the system for each

> of these folders, i tried your first example which i

> don't think uses sieve?

Yep it uses sieve. The rule is specified in the option.dat file.

> in ims-ms i have: destinationspamfilteroptin SPAM

> in tcp_local i have: sourcespamfilteroptin SPAM

There is two things wrong with this:

1. You are calling the filter twice for some reason and this would be causing you all sorts of issues (such as what you have already described).

I would only use the tcp_local version since you only want spam filtering for emails that come from outside your organisation (tcp_local). Scanning emails from within your organisation is a waste of time & effort.

2. The rule should have a number in it e.g. sourcespamfilter1optin

So you should have a rule something like:

tcp_local sourcespamfilter1optin spam

Regards,

Shane.

shane_hjortha at 2007-7-21 15:29:11 >

Hi,

Why have you got emails going from tcp_local -> tcp_scan -> ims-ms? I assume this is some kind of virus processing step?

If so that is probably causing the problem. In my example I am going directly from tcp_local -> ims-ms, therefore any store related sieve actions (such as fileinto) can occur since it applies to the ims-ms straight away.

You may have to add in a channel-level filter on ims-ms to use spamtest which does the fileinto etc. There is an example in this thread which goes through the steps required:

Re: adding headers to all mails with spamassassin

24/10/2006 10:32 (reply 7 of 18)

Regards,

Shane.

shane_hjortha at 2007-7-21 15:29:11 >