You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ruga <ru...@protonmail.com> on 2017/01/23 22:43:02 UTC
Ignore third-party SA headers
spam that already includes SA headers is getting through without local SA filtering. Is it posible to tell the local SA to always add its own headers, possibly taking note of the existence of former SA headers while rewriting them out of the way?
Re: Ignore third-party SA headers
Posted by Antony Stone <An...@spamassassin.open.source.it>.
On Monday 23 January 2017 at 23:43:02, Ruga wrote:
> spam that already includes SA headers is getting through without local SA
> filtering. Is it posible to tell the local SA to always add its own
> headers, possibly taking note of the existence of former SA headers while
> rewriting them out of the way?
How does SA fit into your system - what MTA & glue are you using to pass the
messages for SA scoring?
It sounds like you may have something like MailScanner, in which case this is
not an SA question.
Antony.
--
Is it venison for dinner again? Oh deer.
Please reply to the list;
please *don't* CC me.
Re: Ignore third-party SA headers
Posted by Chris <cp...@embarqmail.com>.
On Mon, 2017-01-23 at 17:43 -0500, Ruga wrote:
> spam that already includes SA headers is getting through without
> local SA filtering. Is it posible to tell the local SA to always add
> its own headers, possibly taking note of the existence of former
> SA headers while rewriting them out of the way?
>
I think this is what you mean:
bayes_ignore_header Old-X-Spam-Status
bayes_ignore_header Old-X-Spam-Score
bayes_ignore_header Old-X-Spam-Bar
bayes_ignore_header Old-X-Spam-Report
Put the above in your local.cf. From the SA Wiki:
If you or any upstream service has added any additional headers to the
emails which may mislead Bayes, those should probably be removed before
feeding the email to sa-learn. Alternatively, use the
bayes_ignore_header setting in your local.cf (as detailed in the man
page for Mail::SpamAssassin::Conf)
If this is not what you're referring to I apologize.
Chris
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
19:19:09 up 6 days, 2:09, 2 users, load average: 0.42, 0.38, 0.28
Ubuntu 16.04.1 LTS, kernel 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6
17:47:47 UTC 2017
Re: Ignore third-party SA headers
Posted by Chris <cp...@embarqmail.com>.
On Wed, 2017-01-25 at 22:29 -0800, Ian Zimmerman wrote:
> On 2017-01-26 01:03, RW wrote:
>
> >
> > Probably what's happening is that these are emails over 500 kB
> > which
> > by default are just passed through by spamc without sending them to
> > spamd. If they don't get sent to spamd the existing SA headers
> > don't
> > get stripped.
> >
> > You can to set the -s parameter on spamc to something larger that
> > the
> > largest spam you want to filter.
>
> I have never been clear about this, in two ways.
>
> The relevant bit of man spamc says:
>
> -s max_size, --max-size=max_size
>
> Set the maximum message size which will be sent to spamd -- any
> bigger
> than this threshold and the message will be returned unprocessed
> (default: 500 KB). If spamc gets handed a message bigger than this,
> it
> won't be passed to spamd. The maximum message size is 256 MB.
>
> The size is specified in bytes, as a positive integer greater than
> 0.
> For example, -s 500000.
>
> My first confusion is that even if there's a knob I can turn up on
> spamc, there's a "maximum message size". What does that mean? Does
> spamd have its own limit? Is it really that high? And what happens
> if
> I break it?
>
> Second, is the default 500 * 1000 bytes or 512 * 1024 bytes? The
> example seems to suggest the latter.
>
Here's the procmail recipe I have for large messages
:0 fh w
* > 100000
* ^Subject:\/.*
| formail -I "Subject: {* -BIG- *} $MATCH"
I don't know if you're using procmail or if this is relative to your
question but since you were asking about large messages this is how I
tag them that way they're not even sent to spamc and are easy to spot
in my inbox.
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
15:58:43 up 23:19, 1 user, load average: 0.20, 0.23, 0.33
Ubuntu 16.04.1 LTS, kernel 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6
17:47:47 UTC 2017
Re: Ignore third-party SA headers
Posted by Ian Zimmerman <it...@primate.net>.
On 2017-01-26 01:03, RW wrote:
> Probably what's happening is that these are emails over 500 kB which
> by default are just passed through by spamc without sending them to
> spamd. If they don't get sent to spamd the existing SA headers don't
> get stripped.
>
> You can to set the -s parameter on spamc to something larger that the
> largest spam you want to filter.
I have never been clear about this, in two ways.
The relevant bit of man spamc says:
-s max_size, --max-size=max_size
Set the maximum message size which will be sent to spamd -- any bigger
than this threshold and the message will be returned unprocessed
(default: 500 KB). If spamc gets handed a message bigger than this, it
won't be passed to spamd. The maximum message size is 256 MB.
The size is specified in bytes, as a positive integer greater than 0.
For example, -s 500000.
My first confusion is that even if there's a knob I can turn up on
spamc, there's a "maximum message size". What does that mean? Does
spamd have its own limit? Is it really that high? And what happens if
I break it?
Second, is the default 500 * 1000 bytes or 512 * 1024 bytes? The
example seems to suggest the latter.
--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html
Re: Ignore third-party SA headers
Posted by RW <rw...@googlemail.com>.
On Thu, 26 Jan 2017 05:12:56 -0500
Ruga wrote:
> > Probably what's happening is that these are emails over 500 kB
> 500.000 bytes: spamc's default max-size
> 512.000 bytes: spamc's local default max-size
> 005.155 bytes: size of the specific spam
Have you been able to reproduce this by feeding one of the spams into
spamc?
You've configured spamc so that if there's an error it passes the
unmodified email to procmail rather than have postfix requeue it.
Is there anything that might have caused that? Are there any errors in
the logs? Might spamd have been down? Have you set spamd's
--max-children to match the 10 filter processes?
Re: Ignore third-party SA headers
Posted by Ruga <ru...@protonmail.com>.
500.000 bytes: spamc's default max-size
512.000 bytes: spamc's local default max-size
005.155 bytes: size of the specific spam
-------- Original Message --------
Subject: Re: Ignore third-party SA headers
Local Time: 26 January 2017 2:03 AM
UTC Time: 26 January 2017 01:03
From: rwmaillists@googlemail.com
To: users@spamassassin.apache.org
On Wed, 25 Jan 2017 10:48:29 -0500
Ruga wrote:
> SA runs as follows.
>
> master.cf, last line of section smtp:
> > -o content_filter=spamcheck
>
> spamcheck unix - n n - 10 pipe
> flags=Rq
> user=spamd
> argv=/usr[/sbin/spamc](http://org.OpenServer/share/spamd/bin/spamc)
> --dest=127.0.0.1 --port=783 --filter-retries=3 --filter-retry-sleep=2
> --headers
> --pipe-to /usr[/sbin/sendmail](http://org.OpenServer/port-465/sbin/sendmail)
> -G -i -f ${sender} -- ${recipient}
>
>....
>
> Why SA accepts the third-party X-Spam header instead of producing its
> own?
Probably what's happening is that these are emails over 500 kB which by
default are just passed through by spamc without sending them to spamd.
If they don't get sent to spamd the existing SA headers don't get
stripped.
You can to set the -s parameter on spamc to something larger that the
largest spam you want to filter.
Re: Ignore third-party SA headers
Posted by RW <rw...@googlemail.com>.
On Wed, 25 Jan 2017 10:48:29 -0500
Ruga wrote:
> SA runs as follows.
>
> master.cf, last line of section smtp:
> > -o content_filter=spamcheck
>
> spamcheck unix - n n - 10 pipe
> flags=Rq
> user=spamd
> argv=/usr[/sbin/spamc](http://org.OpenServer/share/spamd/bin/spamc)
> --dest=127.0.0.1 --port=783 --filter-retries=3 --filter-retry-sleep=2
> --headers
> --pipe-to /usr[/sbin/sendmail](http://org.OpenServer/port-465/sbin/sendmail)
> -G -i -f ${sender} -- ${recipient}
>
>....
>
> Why SA accepts the third-party X-Spam header instead of producing its
> own?
Probably what's happening is that these are emails over 500 kB which by
default are just passed through by spamc without sending them to spamd.
If they don't get sent to spamd the existing SA headers don't get
stripped.
You can to set the -s parameter on spamc to something larger that the
largest spam you want to filter.
Re: Ignore third-party SA headers
Posted by Joe Quinn <he...@gmail.com>.
On 1/25/2017 10:48 AM, Ruga wrote:
> SA runs as follows.
>
> master.cf, last line of section smtp:
> > -o content_filter=spamcheck
>
> spamcheck unix - n n - 10 pipe
> flags=Rq
> user=spamd
> argv=/usr/sbin/spamc <http://org.OpenServer/share/spamd/bin/spamc>
> --dest=127.0.0.1 --port=783 --filter-retries=3 --filter-retry-sleep=2
> --headers
> --pipe-to /usr/sbin/sendmail
> <http://org.OpenServer/port-465/sbin/sendmail> -G -i -f ${sender} --
> ${recipient}
>
>
>
>
>
>
>> spam that already includes SA headers is getting through without
>> local SA filtering. Is it posible to tell the local SA to always add
>> its own headers, possibly taking note of the existence of former
>> SA headers while rewriting them out of the way?
>
> The spam contains the following header, generated by a third-party relay:
>
> X-Spam-Flag: YES
> X-Spam-Score: 15.015
> X-Spam-Level: ***************
> X-Spam-Status: Yes, score=15.015 tagged_above=-9999 required=7
> tests=[DKIM_SIGNED=-0.1, DKIM_VALID=-0.01, DKIM_VERIFIED=-0.01,
> INVALUEMENT_SIP=4, RCVD_IN_BL=0.01, RCVD_IN_MANY_BL=2,
> RCVD_IN_SORBS_SPAM=0.5, RCVD_IN_TWO_BL=1, RCVD_IN_UCEPROTECT1=1,
> RCVD_IN_UCEPROTECT2=1, RCVD_IN_UCEPROTECT3=1, RCVD_IN_UNSUBSCORE=2,
> SUBJ_ALL_CAPS=1.625, TO_NO_BRKTS_NOTLIST=1] autolearn=disabled
>
> Why SA accepts the third-party X-Spam header instead of producing its own?
>
What is spamcheck?
Re: Ignore third-party SA headers
Posted by Ruga <ru...@protonmail.com>.
SA runs as follows.
master.cf, last line of section smtp:
> -o content_filter=spamcheck
spamcheck unix - n n - 10 pipe
flags=Rq
user=spamd
argv=/usr[/sbin/spamc](http://org.OpenServer/share/spamd/bin/spamc)
--dest=127.0.0.1 --port=783 --filter-retries=3 --filter-retry-sleep=2
--headers
--pipe-to /usr[/sbin/sendmail](http://org.OpenServer/port-465/sbin/sendmail) -G -i -f ${sender} -- ${recipient}
spam that already includes SA headers is getting through without local SA filtering. Is it posible to tell the local SA to always add its own headers, possibly taking note of the existence of former SA headers while rewriting them out of the way?
The spam contains the following header, generated by a third-party relay:
X-Spam-Flag: YES X-Spam-Score: 15.015 X-Spam-Level: *************** X-Spam-Status: Yes, score=15.015 tagged_above=-9999 required=7 tests=[DKIM_SIGNED=-0.1, DKIM_VALID=-0.01, DKIM_VERIFIED=-0.01, INVALUEMENT_SIP=4, RCVD_IN_BL=0.01, RCVD_IN_MANY_BL=2, RCVD_IN_SORBS_SPAM=0.5, RCVD_IN_TWO_BL=1, RCVD_IN_UCEPROTECT1=1, RCVD_IN_UCEPROTECT2=1, RCVD_IN_UCEPROTECT3=1, RCVD_IN_UNSUBSCORE=2, SUBJ_ALL_CAPS=1.625, TO_NO_BRKTS_NOTLIST=1] autolearn=disabled
Why SA accepts the third-party X-Spam header instead of producing its own?
Re: Ignore third-party SA headers
Posted by Joe Quinn <he...@gmail.com>.
On 1/23/2017 5:43 PM, Ruga wrote:
> spam that already includes SA headers is getting through without local
> SA filtering. Is it posible to tell the local SA to always add its own
> headers, possibly taking note of the existence of former SA headers
> while rewriting them out of the way?
>
SA never short-circuits from pre-existing headers. Look at where your
mailflow calls SA (postfix, amavis, mimedefang, etc).