Re: ALL_TRUSTED always shown in X-Spam-Status header
On Nov 11, 2018, at 13.35, Benny Pedersen wrote: > > listsb skrev den 2018-11-11 19:20: > >> thanks, agreed. is continuation of this discussion ok here? or >> should i take to the amavis list? > > its important that networks ip ranges is equal in all software used > > its not done automatic > > ALL_TRUSTED is not a amavis problem to solve > > so keep it here, until solved slightly resurrecting this, for posterity. i've recently upgraded, amavis to 2.11.0 and spamassassin to 3.4.2. since then, this behavior has stopped and i no longer see ALL_TRUSTED in scoring details. i probably won't pursue the root cause, but wanted to at least close the topic from my perspective. thanks everyone for the assistance.
Re: ALL_TRUSTED always shown in X-Spam-Status header
On Sun, 11 Nov 2018, John Hardin wrote: On Sat, 10 Nov 2018, listsb wrote: what am i misunderstanding? Is there some possibility that you're stripping external Received headers? (grasping at straws here) Heh. Ignore that. I have *got* to learn to catch up *before* replying to stuff... :) -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Britain used to be the most powerful empire in the world. Now they're terrified of pocketknives. How the mighty have fallen. -- Matt Walsh --- Today: Veterans Day
Re: ALL_TRUSTED always shown in X-Spam-Status header
On Sat, 10 Nov 2018, listsb wrote: On Nov 10, 2018, at 21.01, John Hardin wrote: On Sat, 10 Nov 2018, listsb wrote: i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following: grep -riF 'internal_networks' /etc/spamassassin/* /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.50/32 /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.212/32 here is a set of sample headers, slightly sanitized: http://dpaste.com/33J7SF5 how can i troubleshoot why this is happening? thanks! internal_networks != trusted_networks. i'm not sure i understand. from the documentation here: https://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html it says: "If trusted_networks is not set and internal_networks is, the value of internal_networks will be used for this parameter" Ah, apologies - I wasn't aware of that behavior. I presume you are not explicitly setting any trusted networks, so while it's conceptually correct, I withdraw my comment as unhelpful in this case... additionally, how would absence of either setting result in ALL_TRUSTED getting matched? I *think* there's some defaults included (perhaps the local network?) - I've never focused on that detail before, I've always just set it up for my environment. what am i misunderstanding? Is there some possibility that you're stripping external Received headers? (grasping at straws here) -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Britain used to be the most powerful empire in the world. Now they're terrified of pocketknives. How the mighty have fallen. -- Matt Walsh --- Today: Veterans Day
Re: ALL_TRUSTED always shown in X-Spam-Status header
listsb skrev den 2018-11-11 19:20: thanks, agreed. is continuation of this discussion ok here? or should i take to the amavis list? its important that networks ip ranges is equal in all software used its not done automatic ALL_TRUSTED is not a amavis problem to solve so keep it here, until solved
Re: ALL_TRUSTED always shown in X-Spam-Status header
>On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote:
>>i've just noticed that every mail received seems to be hitting the
ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i
have the following:
>>
>>>grep -riF 'internal_networks' /etc/spamassassin/*
>>/etc/spamassassin/99_local-config.cf:internal_networks
198.19.20.50/32
>>/etc/spamassassin/99_local-config.cf:internal_networks
198.19.20.212/32
>>
>>here is a set of sample headers, slightly sanitized:
>>
>>http://dpaste.com/33J7SF5
>>
>>how can i troubleshoot why this is happening?
On 11.11.18 19:23, Henrik K wrote:
>Are you perhaps using amavisd-new 2.11.x ? It has originating bug that
>makes it always hit ALL_TRUSTED.
>
>https://gitlab.com/amavis/amavis/issues/6
On Sun, Nov 11, 2018 at 06:43:27PM +0100, Matus UHLAR - fantomas wrote:
is it the right issue? This one mentions DKIM not signing.
Can it be the patch that causes everything hitting ALL_TRUSTED?
You have also commented you need to investigate the patch, have you already?
On 11.11.18 20:00, Henrik K wrote:
Yes
https://lists.amavis.org/pipermail/amavis-users/2018-November/005539.html
https://lists.amavis.org/pipermail/amavis-users/2018-November/005540.html
It's trivial to see from logs. Incoming external mail is always marked
AcceptedInternal / LOCAL.
current problem is not mentioned there, only here in this list (which is not
even amavis list).
Passed CLEAN {AcceptedInternal,Quarantined}, LOCAL
Amavisd-new passes originating flag to SpamAssassin internally with some
suppl_attr magic.. that's why it's even harder to diagnose, if you don't
know that it happens in the background..
I believe this only applies when originating flag is set.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Posli tento mail 100 svojim znamim - nech vidia aky si idiot
Send this email to 100 your friends - let them see what an idiot you are
Re: ALL_TRUSTED always shown in X-Spam-Status header
On Nov 11, 2018, at 13.18, Matus UHLAR - fantomas wrote: > >>> On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following: > grep -riF 'internal_networks' /etc/spamassassin/* /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.50/32 /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.212/32 here is a set of sample headers, slightly sanitized: http://dpaste.com/33J7SF5 how can i troubleshoot why this is happening? > >>> On Nov 11, 2018, at 12.23, Henrik K wrote: >>> Are you perhaps using amavisd-new 2.11.x ? It has originating bug that >>> makes it always hit ALL_TRUSTED. >>> >>> https://gitlab.com/amavis/amavis/issues/6 > > On 11.11.18 13:08, listsb wrote: >> i'm currently using 2.9.0. > > in such case, according to previous message, it's important to check amavis > settings. thanks, agreed. is continuation of this discussion ok here? or should i take to the amavis list?
Re: ALL_TRUSTED always shown in X-Spam-Status header
On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following: grep -riF 'internal_networks' /etc/spamassassin/* /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.50/32 /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.212/32 here is a set of sample headers, slightly sanitized: http://dpaste.com/33J7SF5 how can i troubleshoot why this is happening? On Nov 11, 2018, at 12.23, Henrik K wrote: Are you perhaps using amavisd-new 2.11.x ? It has originating bug that makes it always hit ALL_TRUSTED. https://gitlab.com/amavis/amavis/issues/6 On 11.11.18 13:08, listsb wrote: i'm currently using 2.9.0. in such case, according to previous message, it's important to check amavis settings. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. One OS to rule them all, One OS to find them, One OS to bring them all and into darkness bind them
Re: ALL_TRUSTED always shown in X-Spam-Status header
> On Nov 11, 2018, at 12.23, Henrik K wrote: > > On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: >> hi- >> >> i've just noticed that every mail received seems to be hitting the >> ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come >> from. i have the following: >> >>> grep -riF 'internal_networks' /etc/spamassassin/* >> /etc/spamassassin/99_local-config.cf:internal_networks >> 198.19.20.50/32 >> /etc/spamassassin/99_local-config.cf:internal_networks >> 198.19.20.212/32 >> >> here is a set of sample headers, slightly sanitized: >> >> http://dpaste.com/33J7SF5 >> >> how can i troubleshoot why this is happening? > > Are you perhaps using amavisd-new 2.11.x ? It has originating bug that > makes it always hit ALL_TRUSTED. > > https://gitlab.com/amavis/amavis/issues/6 i'm currently using 2.9.0.
Re: ALL_TRUSTED always shown in X-Spam-Status header
> On Nov 11, 2018, at 12.05, RW wrote: > > On Sun, 11 Nov 2018 10:35:18 -0500 > listsb wrote: > >>> On Nov 11, 2018, at 09.01, Matus UHLAR - fantomas >>> wrote: >>> >>> On 10.11.18 20:04, listsb wrote: i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message > >>> show us an example of such mail. With complete headers. >> >> sure - http://dpaste.com/3MHN5HD.txt > > When I ran it through SA with your internal network I didn't get > ALL_TRUSTED. I suspect that there's some other config being used, maybe > in amavisd-new. thanks, that's helpful. you're right, i don't get ALL_TRUSTED either when running through just spamassassin directly - i am indeed using amavis.
Re: ALL_TRUSTED always shown in X-Spam-Status header
On Sun, Nov 11, 2018 at 06:43:27PM +0100, Matus UHLAR - fantomas wrote:
> >On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote:
> >>i've just noticed that every mail received seems to be hitting the
> >>ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come
> >>from. i have the following:
> >>
> >>>grep -riF 'internal_networks' /etc/spamassassin/*
> >>/etc/spamassassin/99_local-config.cf:internal_networks
> >>198.19.20.50/32
> >>/etc/spamassassin/99_local-config.cf:internal_networks
> >>198.19.20.212/32
> >>
> >>here is a set of sample headers, slightly sanitized:
> >>
> >>http://dpaste.com/33J7SF5
> >>
> >>how can i troubleshoot why this is happening?
>
> On 11.11.18 19:23, Henrik K wrote:
> >Are you perhaps using amavisd-new 2.11.x ? It has originating bug that
> >makes it always hit ALL_TRUSTED.
> >
> >https://gitlab.com/amavis/amavis/issues/6
>
> is it the right issue? This one mentions DKIM not signing.
>
> Can it be the patch that causes everything hitting ALL_TRUSTED?
>
> You have also commented you need to investigate the patch, have you already?
Yes
https://lists.amavis.org/pipermail/amavis-users/2018-November/005539.html
https://lists.amavis.org/pipermail/amavis-users/2018-November/005540.html
It's trivial to see from logs. Incoming external mail is always marked
AcceptedInternal / LOCAL.
Passed CLEAN {AcceptedInternal,Quarantined}, LOCAL
Amavisd-new passes originating flag to SpamAssassin internally with some
suppl_attr magic.. that's why it's even harder to diagnose, if you don't
know that it happens in the background..
Re: ALL_TRUSTED always shown in X-Spam-Status header
Amavisd does not use spamassassin *networks settings Orignation bug is not spamassassin problem Benny On 11. november 2018 18.24.05 Henrik K wrote: On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: hi- i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following: >grep -riF 'internal_networks' /etc/spamassassin/* /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.50/32 /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.212/32 here is a set of sample headers, slightly sanitized: http://dpaste.com/33J7SF5 how can i troubleshoot why this is happening? Are you perhaps using amavisd-new 2.11.x ? It has originating bug that makes it always hit ALL_TRUSTED. https://gitlab.com/amavis/amavis/issues/6
Re: ALL_TRUSTED always shown in X-Spam-Status header
On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following: >grep -riF 'internal_networks' /etc/spamassassin/* /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.50/32 /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.212/32 here is a set of sample headers, slightly sanitized: http://dpaste.com/33J7SF5 how can i troubleshoot why this is happening? On 11.11.18 19:23, Henrik K wrote: Are you perhaps using amavisd-new 2.11.x ? It has originating bug that makes it always hit ALL_TRUSTED. https://gitlab.com/amavis/amavis/issues/6 is it the right issue? This one mentions DKIM not signing. Can it be the patch that causes everything hitting ALL_TRUSTED? You have also commented you need to investigate the patch, have you already? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I don't have lysdexia. The Dog wouldn't allow that.
Re: ALL_TRUSTED always shown in X-Spam-Status header
On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: > hi- > > i've just noticed that every mail received seems to be hitting the > ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come > from. i have the following: > > >grep -riF 'internal_networks' /etc/spamassassin/* > /etc/spamassassin/99_local-config.cf:internal_networks > 198.19.20.50/32 > /etc/spamassassin/99_local-config.cf:internal_networks > 198.19.20.212/32 > > here is a set of sample headers, slightly sanitized: > > http://dpaste.com/33J7SF5 > > how can i troubleshoot why this is happening? Are you perhaps using amavisd-new 2.11.x ? It has originating bug that makes it always hit ALL_TRUSTED. https://gitlab.com/amavis/amavis/issues/6
Re: ALL_TRUSTED always shown in X-Spam-Status header
> On Nov 11, 2018, at 09.01, Matus UHLAR - fantomas wrote: > > On 10.11.18 20:04, listsb wrote: >> i've just noticed that every mail received seems to be hitting the >> ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come >> from. i have the following: >> >>> grep -riF 'internal_networks' /etc/spamassassin/* >> /etc/spamassassin/99_local-config.cf:internal_networks >> 198.19.20.50/32 >> /etc/spamassassin/99_local-config.cf:internal_networks >> 198.19.20.212/32 >> >> here is a set of sample headers, slightly sanitized: >> >> http://dpaste.com/33J7SF5 >> >> how can i troubleshoot why this is happening? > > show us an example of such mail. With complete headers. sure - http://dpaste.com/3MHN5HD.txt
Re: ALL_TRUSTED always shown in X-Spam-Status header
On 10.11.18 20:04, listsb wrote: i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following: grep -riF 'internal_networks' /etc/spamassassin/* /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.50/32 /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.212/32 here is a set of sample headers, slightly sanitized: http://dpaste.com/33J7SF5 how can i troubleshoot why this is happening? show us an example of such mail. With complete headers. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
Re: ALL_TRUSTED always shown in X-Spam-Status header
On Nov 10, 2018, at 21.01, John Hardin wrote: > > On Sat, 10 Nov 2018, listsb wrote: > >> hi- >> >> i've just noticed that every mail received seems to be hitting the >> ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come >> from. i have the following: >> >>> grep -riF 'internal_networks' /etc/spamassassin/* >> /etc/spamassassin/99_local-config.cf:internal_networks >> 198.19.20.50/32 >> /etc/spamassassin/99_local-config.cf:internal_networks >> 198.19.20.212/32 >> >> here is a set of sample headers, slightly sanitized: >> >> http://dpaste.com/33J7SF5 >> >> how can i troubleshoot why this is happening? >> >> thanks! > > internal_networks != trusted_networks. i'm not sure i understand. from the documentation here: https://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html it says: "If trusted_networks is not set and internal_networks is, the value of internal_networks will be used for this parameter" additionally, how would absence of either setting result in ALL_TRUSTED getting matched? what am i misunderstanding?
Re: ALL_TRUSTED always shown in X-Spam-Status header
On Sat, 10 Nov 2018, listsb wrote: hi- i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following: grep -riF 'internal_networks' /etc/spamassassin/* /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.50/32 /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.212/32 here is a set of sample headers, slightly sanitized: http://dpaste.com/33J7SF5 how can i troubleshoot why this is happening? thanks! internal_networks != trusted_networks. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- If you trust the government, you obviously failed history class. -- Don Freeman --- Tomorrow: Veterans Day
ALL_TRUSTED always shown in X-Spam-Status header
hi- i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following: >grep -riF 'internal_networks' /etc/spamassassin/* /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.50/32 /etc/spamassassin/99_local-config.cf:internal_networks 198.19.20.212/32 here is a set of sample headers, slightly sanitized: http://dpaste.com/33J7SF5 how can i troubleshoot why this is happening? thanks!
How to configure FOO=-1.0 in X-Spam-Status ?
Hi I'm seeing X-Spam-Status headers from some other installation come with =$x appended to the individual matches, which evidently helps figuring out why a mail is being classified the way it is. I've spent more than an hour on googling and rtfm but couldn't figure it out. Also, grep does not turn on any occurrence of 'Spam-Status' in the source code, and I don't feel like reading all of the source code for this right now. Please tell me how I can set this up. Thanks! Christian.
Re: How to configure FOO=-1.0 in X-Spam-Status ?
On 11/12/2015 12:31 PM, Christian Jaeger wrote: Hi I'm seeing X-Spam-Status headers from some other installation come with =$x appended to the individual matches, which evidently helps figuring out why a mail is being classified the way it is. I've spent more than an hour on googling and rtfm but couldn't figure it out. Also, grep does not turn on any occurrence of 'Spam-Status' in the source code, and I don't feel like reading all of the source code for this right now. Please tell me how I can set this up. you didn't rtfm enough :) you should be looking into "Report" http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.txt "TEMPLATE TAGS" for example: report_safe 0 clear_headers add_header all Report _REPORT_ NOTE: if you're using Amavis or some other glue headers may be added by the glue and not SA h2h Axb
Re: How to configure FOO=-1.0 in X-Spam-Status ?
On 2015-11-12 08:20, Bowie Bailey wrote: On 11/12/2015 6:31 AM, Christian Jaeger wrote: Hi I'm seeing X-Spam-Status headers from some other installation come with =$x appended to the individual matches, which evidently helps figuring out why a mail is being classified the way it is. I've spent more than an hour on googling and rtfm but couldn't figure it out. Also, grep does not turn on any occurrence of 'Spam-Status' in the source code, and I don't feel like reading all of the source code for this right now. Please tell me how I can set this up. Show us a sample of the header so we can see exactly what you are looking for. I have this is in my user_prefs for the user that Exim connects to spamassassin as: thebighonker.lerctr.org /usr/local/etc/mail/spamassassin $ sudo su - smmsp Password: $ cd .spamassassin/ $ ls bayes_journal bayes_seen bayes_toks user_prefs $ more user_prefs clear_report_template report SpamScore (_SCORE_/_REQD_) _TESTSSCORES(,)_ $ and this gives: X-Spam-Score: -106.9 (---) X-LERCTR-Spam-Score: -106.9 (---) X-Spam-Report: SpamScore (-106.9/5.0) BAYES_00=-1.9,RCVD_IN_DNSWL_NONE=-0.0001,RCVD_IN_HOSTKARMA_W=-5,SHORTCIRCUIT=-100 X-LERCTR-Spam-Report: SpamScore (-106.9/5.0) BAYES_00=-1.9,RCVD_IN_DNSWL_NONE=-0.0001,RCVD_IN_HOSTKARMA_W=-5,SHORTCIRCUIT=-100 from this Exim Rules: warn message = X-Spam-Score: $spam_score ($spam_bar) spam = smmsp:true warn message = X-LERCTR-Spam-Score: $spam_score ($spam_bar) spam = smmsp:true warn message = X-Spam-Report: $spam_report spam = smmsp:true warn message = X-LERCTR-Spam-Report: $spam_report spam = smmsp:true -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
Re: How to configure FOO=-1.0 in X-Spam-Status ?
On 11/12/2015 6:31 AM, Christian Jaeger wrote: Hi I'm seeing X-Spam-Status headers from some other installation come with =$x appended to the individual matches, which evidently helps figuring out why a mail is being classified the way it is. I've spent more than an hour on googling and rtfm but couldn't figure it out. Also, grep does not turn on any occurrence of 'Spam-Status' in the source code, and I don't feel like reading all of the source code for this right now. Please tell me how I can set this up. Show us a sample of the header so we can see exactly what you are looking for. -- Bowie
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Sun, 26 Oct 2014 13:28:12 -0700 (PDT) John Hardin jhar...@impsec.org wrote: That's an SA directive. It says if the message scores spammy, prepend '[SPAM][JUNGLEVISION SPAM CHECK]' to the Subject header. Ah. Missing some messages here. It does appear that sa is the culprit but why it's doing it is not evident. There's still not enough data. Perhaps turning up debugging would be helpful? jd
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Mon, 27 Oct 2014, jdebert wrote: On Sun, 26 Oct 2014 13:28:12 -0700 (PDT) John Hardin jhar...@impsec.org wrote: That's an SA directive. It says if the message scores spammy, prepend '[SPAM][JUNGLEVISION SPAM CHECK]' to the Subject header. Ah. Missing some messages here. It does appear that sa is the culprit but why it's doing it is not evident. There's still not enough data. Perhaps turning up debugging would be helpful? The apparent culprit is a procmail rule that explicitly passes a message through the mail system again. The message is being scanned twice. If she can either deliver to a local mailbox rather than forwarding to an email address, or modify the procmail rule that calls SA to ignore messages that have already passed through the server once, I think the problem would go away. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- ...the Fates notice those who buy chainsaws... -- www.darwinawards.com --- 4 days until Halloween
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Mon, 27 Oct 2014, John Hardin wrote: On Mon, 27 Oct 2014, jdebert wrote: On Sun, 26 Oct 2014 13:28:12 -0700 (PDT) John Hardin jhar...@impsec.org wrote: That's an SA directive. It says if the message scores spammy, prepend '[SPAM][JUNGLEVISION SPAM CHECK]' to the Subject header. Ah. Missing some messages here. It does appear that sa is the culprit but why it's doing it is not evident. There's still not enough data. Perhaps turning up debugging would be helpful? The apparent culprit is a procmail rule that explicitly passes a message through the mail system again. The message is being scanned twice. If she can either deliver to a local mailbox rather than forwarding to an email address, oops. That should be deliver to a local mail folder. or modify the procmail rule that calls SA to ignore messages that have already passed through the server once, I think the problem would go away. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- ...the Fates notice those who buy chainsaws... -- www.darwinawards.com --- 4 days until Halloween
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Mon, 27 Oct 2014 15:45:03 -0700 (PDT) John Hardin jhar...@impsec.org wrote: On Mon, 27 Oct 2014, jdebert wrote: It does appear that sa is the culprit but why it's doing it is not evident. There's still not enough data. Perhaps turning up debugging would be helpful? The apparent culprit is a procmail rule that explicitly passes a message through the mail system again. The message is being scanned twice. If she can either deliver to a local mailbox rather than forwarding to an email address, or modify the procmail rule that calls SA to ignore messages that have already passed through the server once, I think the problem would go away. It looks as if it's the global procmailrc that always puts all mail, even mail between local users through spamassassin. However, I don't see how going through spamassassin again will modify the header. It's already modified before the user procmail rule sees it. Something appears to be causing the first run of sa to modify the header unconditionally. If global procmail actually does the first run. jd
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Mon, 2014-10-27 at 20:19 -0700, jdebert wrote:
On Mon, 27 Oct 2014 15:45:03 -0700 (PDT)
John Hardin jhar...@impsec.org wrote:
The apparent culprit is a procmail rule that explicitly passes a
message through the mail system again. The message is being scanned
twice. If she can either deliver to a local mailbox rather than
forwarding to an email address, or modify the procmail rule that
calls SA to ignore messages that have already passed through the
server once, I think the problem would go away.
It looks as if it's the global procmailrc that always puts all mail,
even mail between local users through spamassassin. However, I don't
see how going through spamassassin again will modify the header. It's
It is not the second run that modifies the header. It's the first one.
With the second run classifying the mail as not-spam.
already modified before the user procmail rule sees it. Something
appears to be causing the first run of sa to modify the header
unconditionally. If global procmail actually does the first run.
A system-wide procmail recipe feeds mail to SA.
Then there's a user procmail recipe that forwards mail with a Subject
matching /SPAM/ to another dedicated spam dump address with the same
domain, which ends up being delivered to that domain's MX. The same SMTP
server. Now re-processing the original mail (possibly wrapped in an
RFC822 attachment by SA), feeding it to SA due to the system-wide
procmail recipe...
On that second run, the message previously classified spam does not
exceed the threshold. Thus the X-Spam-Status of no, overriding the
previous Status header which is being ignored by SA anyway.
Result: Subject header rewritten by SA, despite final (delivery time)
spam status of no. This thread's Subject.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Sat, 25 Oct 2014, Cathryn Mataga wrote: On 10/25/2014 9:29 PM, John Hardin wrote: On Sat, 25 Oct 2014, Cathryn Mataga wrote: Received: from ecuador.junglevision.com (localhost [127.0.0.1]) by ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id s9P2o1ZZ026032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for megans...@junglevision.com; Fri, 24 Oct 2014 19:50:01 -0700 Received: (from megan@localhost) by ecuador.junglevision.com (8.14.7/8.14.7/Submit) id s9P2o1dN026031 for megans...@junglevision.com; Fri, 24 Oct 2014 19:50:01 -0700 Why is the message hitting ecuador.junglevision.com twice? Would this do it? Maybe it's just failing on the initial spam check and then .procmailrc meganspam checks again for some reason? [root@ecuador megan]# cat .procmailrc : 0 * ^Subject:.*\[SPAM\]* !megans...@junglevision.com Yes, that would do it. I suspect what you really want here is to save the spam to a mail folder rather than forwarding it to a different user, which will send it through the mail system again. [root@ecuador spamassassin]# cat spamassassin-default.rc # send mail through spamassassin : 0fw | /usr/bin/spamassassin You probably should be using spamc there rather than firing off a fresh new spamassassin for each message, which re-parses all of the rules from scratch every time. You also might want to put an exclusion in there for messages having a Received: from ecuador.junglevision.com (localhost [127.0.0.1]) header so that you don't scan messages twice. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- 877 days since the first successful private support mission to ISS (SpaceX)
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Sat, 25 Oct 2014 20:06:00 -0700 Cathryn Mataga cath...@junglevision.com wrote: Okay, here's another header.Shows X-Xpam-Status as no. In local.cf I changed to this, just to be sure. rewrite_header Subject [SPAM][JUNGLEVISION SPAM CHECK] Not familiar with how sendmail rewrites headers. Is this supposed to replace [SPAM] with [JUNGLEVISION SPAM CHECK]? replace the subject with [SPAM][JUNGLEVISION SPAM CHECK] or ...? How does your sa modify the subject? Is it the default SPAM(%score)? It looks as if the message is delivered to megan and then something is resubmitting the message to sendmail. Are you using procmail to forward messages containing SPAM to meganspam? Could that be why sendmail sees the message twice? Are you using milters with sendmail? How hard would it be to disable them one by one and inject test messages with [SPAM] in the subject? What if you turned up spamassassin's and sendmail's debugging? I wonder if that would log the Subject header as it receives the incoming message and handles it. It could tell you if the message is received with [SPAM] already in the header or where [SPAM] is being inserted before delivery. jd
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Sun, 26 Oct 2014, jdebert wrote: On Sat, 25 Oct 2014 20:06:00 -0700 Cathryn Mataga cath...@junglevision.com wrote: Okay, here's another header.Shows X-Xpam-Status as no. In local.cf I changed to this, just to be sure. rewrite_header Subject [SPAM][JUNGLEVISION SPAM CHECK] Not familiar with how sendmail rewrites headers. Is this supposed to replace [SPAM] with [JUNGLEVISION SPAM CHECK]? replace the subject with [SPAM][JUNGLEVISION SPAM CHECK] or ...? That's an SA directive. It says if the message scores spammy, prepend '[SPAM][JUNGLEVISION SPAM CHECK]' to the Subject header. How does your sa modify the subject? Is it the default SPAM(%score)? The rewrite_header. It looks as if the message is delivered to megan and then something is resubmitting the message to sendmail. Are you using procmail to forward messages containing SPAM to meganspam? Could that be why sendmail sees the message twice? Yes. She posted a procmailrc snippet that does exactly that. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- ...the Fates notice those who buy chainsaws... -- www.darwinawards.com --- 5 days until Halloween
Re: How is it that my X-Spam-Status is no, but my header gets marked with
Okay, here's another header.Shows X-Xpam-Status as no. In local.cf I changed to this, just to be sure. rewrite_header Subject [SPAM][JUNGLEVISION SPAM CHECK] Return-Path:me...@ecuador.junglevision.com X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ecuador.junglevision.com X-Spam-Level: * X-Spam-Status: No, score=1.5 required=3.5 tests=BAYES_50,HTML_MESSAGE, MIME_HTML_ONLY,MIME_QP_LONG_LINE autolearn=disabled version=3.3.2 Received: from ecuador.junglevision.com (localhost [127.0.0.1]) by ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id s9P2o1ZZ026032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for megans...@junglevision.com; Fri, 24 Oct 2014 19:50:01 -0700 Received: (from megan@localhost) by ecuador.junglevision.com (8.14.7/8.14.7/Submit) id s9P2o1dN026031 for megans...@junglevision.com; Fri, 24 Oct 2014 19:50:01 -0700 Received: from outbound.audienceview.com (outbound.audienceview.com [65.110.162.244]) by ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id s9P2nvn2026026 for me...@junglevision.com; Fri, 24 Oct 2014 19:49:58 -0700 Received: from AVWEB98 ([127.0.0.1]) by outbound.audienceview.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 24 Oct 2014 19:49:57 -0700 From: tick...@shnsf.com To: me...@junglevision.com Subject: [SPAM][JUNGLEVISION SPAM CHECK] Confirmation of Order Number 684588 * Please Do Not Reply To This Email * Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=39c73e15-d5dd-4652-bd83-b7c65171173c Date: Fri, 24 Oct 2014 19:49:57 -0700 Message-ID: 1c09ad5feea4.tick...@shnsf.com X-OriginalArrivalTime: 25 Oct 2014 02:49:57.0206 (UTC) FILETIME=[5CA4A760:01CFEFFE] X-Spam-Prev-Subject: Confirmation of Order Number 684588 * Please Do Not Reply To This Email *
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Sat, 2014-10-25 at 20:06 -0700, Cathryn Mataga wrote:
Okay, here's another header.Shows X-Xpam-Status as no.
In local.cf I changed to this, just to be sure.
rewrite_header Subject [SPAM][JUNGLEVISION SPAM CHECK]
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
ecuador.junglevision.com
X-Spam-Level: *
X-Spam-Status: No, score=1.5 required=3.5 tests=BAYES_50,HTML_MESSAGE,
MIME_HTML_ONLY,MIME_QP_LONG_LINE autolearn=disabled version=3.3.2
Subject: [SPAM][JUNGLEVISION SPAM CHECK] Confirmation of Order Number
684588 * Please Do Not Reply To This Email *
Somehow, you are passing messages to SA twice.
First one classifies it spam and rewrites the Subject. Second run
doesn't. Added headers, content wrapping, or most likely re-transmission
from trusted networks makes the second run fail.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Sat, 25 Oct 2014, Cathryn Mataga wrote: Received: from ecuador.junglevision.com (localhost [127.0.0.1]) by ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id s9P2o1ZZ026032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for megans...@junglevision.com; Fri, 24 Oct 2014 19:50:01 -0700 Received: (from megan@localhost) by ecuador.junglevision.com (8.14.7/8.14.7/Submit) id s9P2o1dN026031 for megans...@junglevision.com; Fri, 24 Oct 2014 19:50:01 -0700 Why is the message hitting ecuador.junglevision.com twice? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- 877 days since the first successful private support mission to ISS (SpaceX)
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On 10/25/2014 9:29 PM, John Hardin wrote: On Sat, 25 Oct 2014, Cathryn Mataga wrote: Received: from ecuador.junglevision.com (localhost [127.0.0.1]) by ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id s9P2o1ZZ026032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for megans...@junglevision.com; Fri, 24 Oct 2014 19:50:01 -0700 Received: (from megan@localhost) by ecuador.junglevision.com (8.14.7/8.14.7/Submit) id s9P2o1dN026031 for megans...@junglevision.com; Fri, 24 Oct 2014 19:50:01 -0700 Why is the message hitting ecuador.junglevision.com twice? Would this do it? Maybe it's just failing on the initial spam check and then .procmailrc meganspam checks again for some reason? [root@ecuador megan]# cat .procmailrc :0 * ^Subject:.*\[SPAM\]* !megans...@junglevision.com [root@ecuador etc]# pwd /etc [root@ecuador etc]# cat procmailrc DROPPRIVS=yes INCLUDERC=/etc/mail/spamassassin/spamassassin-default.rc Then I have. [root@ecuador spamassassin]# cat spamassassin-default.rc # send mail through spamassassin :0fw | /usr/bin/spamassassin Don't believe there's anything creative happening here, right? Am I missing something obvious?
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Fri, 17 Oct 2014 12:13:49 +0100 Martin Gregorie mar...@gregorie.org wrote: On Thu, 2014-10-16 at 22:37 -0700, Cathryn Mataga wrote: The score is only 1.9, 3.5 required. What's going on here? X-Spam-Status: No, score=1.9 required=3.5 tests=BAYES_50,DKIM_SIGNED, EMAIL_URI_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID, URIBL_BLOCKED autolearn=disabled version=3.3.2 URIBL_BLOCKED usually means that you've exceeded the daily free use limit on URIBL queries. On 17.10.14 10:08, jdebert wrote: Will URIBL_BLOCKED cause [SPAM] to be inserted into Subject? no, it will more likely cause [SPAM] _not_ to be inserted, because it wouldn't be detected. Also, doesn't sa insert something else a bit different? Isn't it likely that someone else inserted that before the OP's server ever saw it? If SA inserts anything to Subject: and what it is, depends only on SA configuration. It's the rewrite_header configuration directive. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. One OS to rule them all, One OS to find them, One OS to bring them all and into darkness bind them
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Mon, 20 Oct 2014 12:39:57 +0200 Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 17.10.14 10:08, jdebert wrote: Will URIBL_BLOCKED cause [SPAM] to be inserted into Subject? no, it will more likely cause [SPAM] _not_ to be inserted, because it wouldn't be detected. Good. Had me worried a bit there. (^_^) Also, doesn't sa insert something else a bit different? Isn't it likely that someone else inserted that before the OP's server ever saw it? If SA inserts anything to Subject: and what it is, depends only on SA configuration. It's the rewrite_header configuration directive. Of course. I was thinking at the time that some other spam filter/tagger that used that by default might have done this. After posting, realised that the config would have to be changed for that. Forgot to ask if it was the case. I recall some cases in the past where spam filtering setups, such as those for antispam appliances did such things by default without adding any headers. I suspected this might be the case here. Too many possibilities, too little data. jd
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On 10/20/14, 9:46 AM, jdebert wrote: On Mon, 20 Oct 2014 12:39:57 +0200 Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 17.10.14 10:08, jdebert wrote: Will URIBL_BLOCKED cause [SPAM] to be inserted into Subject? no, it will more likely cause [SPAM] _not_ to be inserted, because it wouldn't be detected. Good. Had me worried a bit there. (^_^) Also, doesn't sa insert something else a bit different? Isn't it likely that someone else inserted that before the OP's server ever saw it? If SA inserts anything to Subject: and what it is, depends only on SA configuration. It's the rewrite_header configuration directive. Of course. I was thinking at the time that some other spam filter/tagger that used that by default might have done this. After posting, realised that the config would have to be changed for that. Forgot to ask if it was the case. I recall some cases in the past where spam filtering setups, such as those for antispam appliances did such things by default without adding any headers. I suspected this might be the case here. Too many possibilities, too little data. What I'll do then is change the inserted message to something else. Just to verify this. I did manage to get rid of the warning from the dnsdbl list. But I can pull this and try again too.
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Thu, 2014-10-16 at 22:37 -0700, Cathryn Mataga wrote: The score is only 1.9, 3.5 required. What's going on here? X-Spam-Status: No, score=1.9 required=3.5 tests=BAYES_50,DKIM_SIGNED, EMAIL_URI_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID, URIBL_BLOCKED autolearn=disabled version=3.3.2 URIBL_BLOCKED usually means that you've exceeded the daily free use limit on URIBL queries. What DNS server are you using? If its a public one belonging to your ISP or Google, that explains why the blacklists think you exceeded the free limit: they count queries per DNS server since that's what sends the queries to them. To avoid this you should be running a private, non-forwarding DNS server. Martin
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On 10/17/14, 4:13 AM, Martin Gregorie wrote: URIBL_BLOCKED usually means that you've exceeded the daily free use limit on URIBL queries. What DNS server are you using? If its a public one belonging to your ISP or Google, that explains why the blacklists think you exceeded the free limit: they count queries per DNS server since that's what sends the queries to them. To avoid this you should be running a private, non-forwarding DNS server. On 17.10.14 09:17, Cathryn Mataga wrote: I run DNS on my network. I think it should be caching, but maybe that's broken? the question is if it forwards requests to other DNS servers (probably your ISPs) or if you process thousands mails daily... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Two words: Windows survives. - Craig Mundie, Microsoft senior strategist So does syphillis. Good thing we have penicillin. - Matthew Alton
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On 10/17/14, 4:13 AM, Martin Gregorie wrote: On Thu, 2014-10-16 at 22:37 -0700, Cathryn Mataga wrote: The score is only 1.9, 3.5 required. What's going on here? X-Spam-Status: No, score=1.9 required=3.5 tests=BAYES_50,DKIM_SIGNED, EMAIL_URI_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID, URIBL_BLOCKED autolearn=disabled version=3.3.2 URIBL_BLOCKED usually means that you've exceeded the daily free use limit on URIBL queries. What DNS server are you using? If its a public one belonging to your ISP or Google, that explains why the blacklists think you exceeded the free limit: they count queries per DNS server since that's what sends the queries to them. To avoid this you should be running a private, non-forwarding DNS server. I run DNS on my network. I think it should be caching, but maybe that's broken? The thing is, I've had this email at this domain name for over a decade now, no, maybe to the mid 90's? Maybe it's just that I get a HUGE amount of spam. It is a spectacular flow to watch it all go through here. I did disable the dns black whole servers seeing this. So maybe my first instinct on this was correct. We'll see if it gets better. Martin
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On 10/17/14, 9:20 AM, Matus UHLAR - fantomas wrote: On 10/17/14, 4:13 AM, Martin Gregorie wrote: URIBL_BLOCKED usually means that you've exceeded the daily free use limit on URIBL queries. What DNS server are you using? If its a public one belonging to your ISP or Google, that explains why the blacklists think you exceeded the free limit: they count queries per DNS server since that's what sends the queries to them. To avoid this you should be running a private, non-forwarding DNS server. On 17.10.14 09:17, Cathryn Mataga wrote: I run DNS on my network. I think it should be caching, but maybe that's broken? the question is if it forwards requests to other DNS servers (probably your ISPs) or if you process thousands mails daily... I should check. I do well less than 100 legitimate emails a day, but I think I might be pulling in thousand(s)+ of spam.
Re: How is it that my X-Spam-Status is no, but my header gets marked with
Am 17.10.2014 um 18:34 schrieb Cathryn Mataga: On 10/17/14, 9:20 AM, Matus UHLAR - fantomas wrote: On 10/17/14, 4:13 AM, Martin Gregorie wrote: URIBL_BLOCKED usually means that you've exceeded the daily free use limit on URIBL queries. What DNS server are you using? If its a public one belonging to your ISP or Google, that explains why the blacklists think you exceeded the free limit: they count queries per DNS server since that's what sends the queries to them. To avoid this you should be running a private, non-forwarding DNS server. On 17.10.14 09:17, Cathryn Mataga wrote: I run DNS on my network. I think it should be caching, but maybe that's broken? the question is if it forwards requests to other DNS servers (probably your ISPs) or if you process thousands mails daily... I should check. I do well less than 100 legitimate emails a day, but I think I might be pulling in thousand(s)+ of spam if your dns server does forwarding it's worthless because the result is the same: one central ISP DNS with always the same IP is asking the blacklist servers, get blocked and hence gives you that back the legitimate don't count, the DNS requests happen anyways Connections: 251066 Delivered: 42579 Blocked: 208487 signature.asc Description: OpenPGP digital signature
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Fri, 2014-10-17 at 09:34 -0700, Cathryn Mataga wrote: I should check. I do well less than 100 legitimate emails a day, but I think I might be pulling in thousand(s)+ of spam. 1) check that your DNS isn't forwarding requests to another DNS. Its the 'forward' statement(s) in your DNS configuration. 2) If you haven't got an SPF record for your domain, set one up. It's not much use for detecting spam, but will stop you receiving backscatter (spam sent to other domains' non-existent users with your address forged as the sender. Use http://www.kitterman.com/spf/validate.html to validate your SPF record when you've set one up. 3) consider implementing greylisting. When my ISP implemented it, my spam:ham ratio went from 80:20 to 20:80 overnight (I use getmail to retrieve e-mail from a mailbox in my ISP's mail server). Martin
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Fri, 17 Oct 2014 12:13:49 +0100 Martin Gregorie mar...@gregorie.org wrote: On Thu, 2014-10-16 at 22:37 -0700, Cathryn Mataga wrote: The score is only 1.9, 3.5 required. What's going on here? X-Spam-Status: No, score=1.9 required=3.5 tests=BAYES_50,DKIM_SIGNED, EMAIL_URI_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID, URIBL_BLOCKED autolearn=disabled version=3.3.2 URIBL_BLOCKED usually means that you've exceeded the daily free use limit on URIBL queries. Will URIBL_BLOCKED cause [SPAM] to be inserted into Subject? Also, doesn't sa insert something else a bit different? Isn't it likely that someone else inserted that before the OP's server ever saw it? jd
Re: How is it that my X-Spam-Status is no, but my header gets marked with
On Thu, 16 Oct 2014 22:37:20 -0700 Cathryn Mataga cath...@junglevision.com wrote: The score is only 1.9, 3.5 required. What's going on here? From me...@ecuador.junglevision.com Mon Oct 13 08:38:09 2014 Return-Path: me...@ecuador.junglevision.com X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ecuador.junglevision.com X-Spam-Level: * X-Spam-Status: No, score=1.9 required=3.5 tests=BAYES_50,DKIM_SIGNED, EMAIL_URI_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from ecuador.junglevision.com (localhost [127.0.0.1]) by ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id s9DFc8B7015308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for megans...@junglevision.com; Mon, 13 Oct 2014 08:38:08 -0700 Received: (from megan@localhost) by ecuador.junglevision.com (8.14.7/8.14.7/Submit) id s9DFc8xV015307 for megans...@junglevision.com; Mon, 13 Oct 2014 08:38:08 -0700 Recipient changed Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152]) by ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id s9DFc5xN015302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for me...@junglevision.com; Mon, 13 Oct 2014 08:38:06 -0700 Original recipient -- up to here. Received: from uspedd06.edc.cingular.net (uspedd06.edc.cingular.net [135.214.228.40]) by egssmtp03.att.com ( egs 8.14.5 TLS/8.14.5) with ESMTP id s9DFc46P014887 for me...@junglevision.com; Mon, 13 Oct 2014 08:38:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=amcustomercare.att-mail.com; s=egs03; t=1413214685; bh=MI7iSFEx0e8sM2n1cEp/PA3RpmsCaSIBkzWhOYJfYAA=; h=Message-ID:Date:From:To:Subject:Mime-Version:Content-Type: Content-Transfer-Encoding; b=CYX9YX0nPomkMgc9QVja839EteJAXDIlKj0PGU7FS6Na0Bbe2MKs02M/tElklPs4H xkFLgTFYcep3bVF5BvPXbx4GTTTfG8t2SRph/JzCEMIkZUGCyjVnB+l507IiU/8qwZ D318VRDQoTPpXolVQMvP7EWBvn63ZKf49zG/Lh5JnhVqYYxcMyS5XVfJR9VRgt/Y+v lt4nkGSI0L+bf76ajwYTS6bERuSXRkwn7LsqYZkLRzBVbseQVK2oMFjV7pABS3Ru7d B2qDr9tjTuGnAhVrp8dloyU+fBVRc4jcj8Fas1FqgcoXoYFfIgqR2dQNkeKpYl+qRi GvEd3zXt9+ajw== Message-ID: 15150565.1413214684341.javamail.p7edd...@uspedd06.edc.cingular.net ??? Are you using imap to fetch your mail? Date: Mon, 13 Oct 2014 10:38:04 -0500 (CDT) From: ATT Customer Care ica...@amcustomercare.att-mail.com To: me...@junglevision.com Subject: [SPAM] Your ATT wireless bill is ready to view ^^ Fairly sure that this is not from spamassassin. It appears the original recipient is megan@mumble but the address has been rewritten or forwarded to meganspam@mumble. It's only a guess but it appears that some server upstream has changed the subject for you. Have a look at your mail logs to see if the subject came into your server that way. If so, there's probably nothing you can do to stop it. You can however, depending on your server, rewrite subjects to remove such uselessly helpful edits. And perhaps an upstream server has not properly implemented DKIM to authenticate this message or has improperly modified it resulting in it being marked as spam? DKIM auth apparently isn't too easy to get right. jd
Re: How is it that my X-Spam-Status is no, but my header gets marked with
??? Are you using imap to fetch your mail? Thanks guys. Yes I am using imap. What I have is a .procmailrc that forwards to meganspam. That's how this email got to meganspam. Is spamassasin is running twice? Once going to megan@ and then at meganspam@. What I did then is I fished the lost email out of 'meganspam' and and posted it here. [root@ecuador megan]# cat .procmailrc :0 * ^Subject:.*\[SPAM\]* !megans...@junglevision.com :0
How is it that my X-Spam-Status is no, but my header gets marked with
The score is only 1.9, 3.5 required. What's going on here? From me...@ecuador.junglevision.com Mon Oct 13 08:38:09 2014 Return-Path: me...@ecuador.junglevision.com X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ecuador.junglevision.com X-Spam-Level: * X-Spam-Status: No, score=1.9 required=3.5 tests=BAYES_50,DKIM_SIGNED, EMAIL_URI_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from ecuador.junglevision.com (localhost [127.0.0.1]) by ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id s9DFc8B7015308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for megans...@junglevision.com; Mon, 13 Oct 2014 08:38:08 -0700 Received: (from megan@localhost) by ecuador.junglevision.com (8.14.7/8.14.7/Submit) id s9DFc8xV015307 for megans...@junglevision.com; Mon, 13 Oct 2014 08:38:08 -0700 Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152]) by ecuador.junglevision.com (8.14.7/8.14.7) with ESMTP id s9DFc5xN015302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for me...@junglevision.com; Mon, 13 Oct 2014 08:38:06 -0700 Received: from uspedd06.edc.cingular.net (uspedd06.edc.cingular.net [135.214.228.40]) by egssmtp03.att.com ( egs 8.14.5 TLS/8.14.5) with ESMTP id s9DFc46P014887 for me...@junglevision.com; Mon, 13 Oct 2014 08:38:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=amcustomercare.att-mail.com; s=egs03; t=1413214685; bh=MI7iSFEx0e8sM2n1cEp/PA3RpmsCaSIBkzWhOYJfYAA=; h=Message-ID:Date:From:To:Subject:Mime-Version:Content-Type: Content-Transfer-Encoding; b=CYX9YX0nPomkMgc9QVja839EteJAXDIlKj0PGU7FS6Na0Bbe2MKs02M/tElklPs4H xkFLgTFYcep3bVF5BvPXbx4GTTTfG8t2SRph/JzCEMIkZUGCyjVnB+l507IiU/8qwZ D318VRDQoTPpXolVQMvP7EWBvn63ZKf49zG/Lh5JnhVqYYxcMyS5XVfJR9VRgt/Y+v lt4nkGSI0L+bf76ajwYTS6bERuSXRkwn7LsqYZkLRzBVbseQVK2oMFjV7pABS3Ru7d B2qDr9tjTuGnAhVrp8dloyU+fBVRc4jcj8Fas1FqgcoXoYFfIgqR2dQNkeKpYl+qRi GvEd3zXt9+ajw== Message-ID: 15150565.1413214684341.javamail.p7edd...@uspedd06.edc.cingular.net Date: Mon, 13 Oct 2014 10:38:04 -0500 (CDT) From: ATT Customer Care ica...@amcustomercare.att-mail.com To: me...@junglevision.com Subject: [SPAM] Your ATT wireless bill is ready to view Mime-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 7bit ATT: OLAMBRN-284864694 X-Spam-Prev-Subject: Your ATT wireless bill is ready to view X-UID: 682695 Status: O Content-Length: 12557
Re: no subject tagging in case of X-Spam-Status: Yes
Am 29.08.2014 um 04:03 schrieb Karsten Bräckelmann: On Fri, 2014-08-29 at 02:15 +0200, Reindl Harald wrote: look at the attached zp-archive and both messages produced with the same content before you pretend others lying damned - to make it easier i even added a config-diff But no message diff. ;) and now what? maybe you should accept that even new users are no idiots and know what they are talking about Please accept my apologies. It appears something else is going on here, and you in fact did not lie. accepted I'd like to add, though, that I do *not* assume new users to be idiots. Plus, I generally spend quite some time on helping others fixing their problems, including new users, as you certainly have noticed. that's why i was really angry because from the other guy which told me multiple times that i should go to the sa-milter list and refered to 8 years old howtos which are wrong and outdated i had expetced that, not from you which was the first constructive my only intention to reply again to that thread was hey, i found it by myself and if someone else has the same problem now he finds a soultion froma recent year Now, moving forward: I've had a look at the message diffs. Quite interesting, and I honestly want to figure out what's happening. it looks really like spamass-milter is responsible in the second version below it whines it can't extract the score to decide if it's above reject and so it really looks like the milter heavily relies on headers found that out much later last night by plaing with headers in general spamass-milter[14891]: Could not extract score from Yes: Score=5.7, Tag-Level=5.0, Block-Level=10 add_header all Status _YESNO_, score=_SCORE_, tag-level=_REQD_, block-level=10 add_header all Status _YESNO_, Score=_SCORE_, Tag-Level=_REQD_, Block-Level=10 First of all, minus all those different datetime strings, IDs and ordering, the real differences are -Subject: [SPAM] Test^M -X-Spam-Flag: Yes^M +Subject: Test^M So it appears that only the sample with add_header spam Flag has the Subject re-written. correct However, there's something else going on. When re-writing the Subject header, SA adds an X-Spam-Prev-Subject header with the original. Which is clearly missing. the version is killed in smtp_header_checks which is also the reason that i started to play around with headers nobody but me has a reason to know exact versions of running software Thus, something else has a severe impact on which headers are added or modified. In *both* cases, there is at least one SA generated header missing and/or SA modified header not preserved. /^X-Spam-Checker-Version/ IGNORE Definitely involved: Postfix, spamass-milter, SA. And probably some other tool rewriting the message / reflowing headers, as per some previous posts (and the X-Spam-Report header majorly inconvenienced by re-flowing headers). the re-flowing is pretty sure DBMail or more like the gmime library used for split and reconstruct messages in their mime parts to store them seperated and de-duplicated in the database - that's valid and per RFC OK but not nice to read :-) Regarding SA and the features in question: There is no different behavior between calling the plain spamassassin script and using spamc/d. There is absolutely nothing in SA itself that could explain the discrepancy in Subject rewriting, nor the missing X-Spam-Prev-Subject header. as said: pretty sure the milter, but i am happy that it works now My best bet would be on the SA invoking glue, not accepting or overwriting headers as received by SA. Which tool that actually is, I don't know. But I'd be interested to hear about it, if you find out. (The additional empty line between message headers and body in the case without X-Spam-Flag header most likely is just copy-n-paste body. Or possibly another artifact of some tool munging messages.) signature.asc Description: OpenPGP digital signature
Re: no subject tagging in case of X-Spam-Status: Yes
Am 29.08.2014 um 04:26 schrieb Karsten Bräckelmann: On Fri, 2014-08-29 at 02:15 +0200, Reindl Harald wrote: look at the attached zp-archive [...] Since I already had a closer look at the contents including your local cf, and I am here to offer help and didn't mean no harm, some comments regarding the SA config. thanks # resolves a bug with milter always triggering a wrong informational header score UNPARSEABLE_RELAY 0 See the RH bug you filed and its upstream report. Do you still need that? This would be the first instance of continued triggering of that test I ever encountered. well, since there was no software update in the meantime i fear yes, however it don't harm # disable most builtin DNSBL/DNSWL to not collide with webinterface settings score __RCVD_IN_SORBS 0 score __RCVD_IN_ZEN 0 score __RCVD_IN_DNSWL 0 Rules starting with double-underline are non-scoring sub-rules. Assigning a zero score doesn't disable them like it does with regular rules. In the case of RBL sub-rules like the above, it does not prevent DNS queries. It is better to meta __FOO 0 overwrite the sub-rule, rather than set a score that doesn't exist. thanks for the information, i will change that i verfified that it does *really* skip all of them because as i had only all sub-rules listed it still fired the request # unconditional sender whitelists whitelist_from *@apache.org whitelist_from *@bipa.co.at whitelist_from *@centos.org whitelist_from *@dovecot.org [...] uhm i am not terrible happy to not have stripped that block from the config :-( Unconditional whitelisting generally is a bad idea and might appear in forged addresses. i know - i would love the same logic for senders as for MORE_SPAM_TO and ALL_SPAM_TO to and at the end even combine it From/To for mailing-lists you need a big hammer to be present if URIs are blacklisted or in case of security discussions refer to exploits which is not possible on the device i am about to replace which leads anytime something is on the zero-hour-intent-list appears in a message to override whitelists - like the name of the SA config file if some client wraps it in link headers something like that would be me final goal from s...@a.tld to s...@b.tld -100 from @a.tld to s...@b.tld -20 from @a.tld to s...@b.tld -2 which would give a way to implement dropdowns in the admin backend for different trust levels without need to know the underlying scores which could be adjusted transparent since it may make sense to do so in the context of tag-score/block-score in general after going online and analyze things my intention will be no whitelists at all active but only after some time where i can make sure from logs there are no false positives which are more bad than slipped spam but have known working options if needed If possible, it is strongly suggested to use whitelist_from_auth, or at least whitelist_from_rcvd (which requires *_networks be set correctly) oh - fine, that pretty easy, the config is generated from a webUI based script - the networks are correct now, that was only a temporary thing in the other thread to study behavior with hand-written craft before write backends and find out that i can't implement it later as expected whitelist_from_rcvd i already had in mind, but since only my personal domain is live i rely at forging by myself for testing things out signature.asc Description: OpenPGP digital signature
Re: no subject tagging in case of X-Spam-Status: Yes
On Fri, 2014-08-29 at 12:02 +0200, Reindl Harald wrote:
Am 29.08.2014 um 04:03 schrieb Karsten Bräckelmann:
Now, moving forward: I've had a look at the message diffs. Quite
interesting, and I honestly want to figure out what's happening.
it looks really like spamass-milter is responsible
in the second version below it whines it can't extract
the score to decide if it's above reject and so it
really looks like the milter heavily relies on headers
Yay for case in-sensitive parsing...
found that out much later last night by plaing with headers in general
spamass-milter[14891]: Could not extract score from Yes: Score=5.7,
Tag-Level=5.0, Block-Level=10
add_header all Status _YESNO_, score=_SCORE_, tag-level=_REQD_, block-level=10
add_header all Status _YESNO_, Score=_SCORE_, Tag-Level=_REQD_, Block-Level=10
If you use the SA default Status header, or at least the prefix
containing score and required, is header rewriting retained by the
milter without the Flag header?
add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ ...
Given that log line, a likely explanation simply is that the milter
needs to determine the spam status, to decide which SA generated headers
to apply to the message. Your choice of custom Status header is not what
the milter expects, and thus needs to resort to the simple Flag header.
(Note the comma after yes/no, but no comma between score and required.)
First of all, minus all those different datetime strings, IDs and
ordering, the real differences are
-Subject: [SPAM] Test^M
-X-Spam-Flag: Yes^M
+Subject: Test^M
So it appears that only the sample with add_header spam Flag has the
Subject re-written.
correct
However, there's something else going on. When re-writing the Subject
header, SA adds an X-Spam-Prev-Subject header with the original. Which
is clearly missing.
the version is killed in smtp_header_checks which is also
the reason that i started to play around with headers
nobody but me has a reason to know exact versions of running software
Previous-Subject, not Version.
I mentioned this specifically, because the absence of the Previous
Subject header with Subject rewrite clearly shows, SA generated headers
are not unconditionally added to the message, but single headers are
cherry picked.
IOW, header rewriting does work without the Flag header. It is the glue
that decides whether to inherit the rewritten header, and outright
ignores the Previous Subject header.
Thus, something else has a severe impact on which headers are added or
modified. In *both* cases, there is at least one SA generated header
missing and/or SA modified header not preserved.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: no subject tagging in case of X-Spam-Status: Yes
Am 30.08.2014 um 00:35 schrieb Karsten Bräckelmann: On Fri, 2014-08-29 at 12:02 +0200, Reindl Harald wrote: Am 29.08.2014 um 04:03 schrieb Karsten Bräckelmann: Now, moving forward: I've had a look at the message diffs. Quite interesting, and I honestly want to figure out what's happening. it looks really like spamass-milter is responsible in the second version below it whines it can't extract the score to decide if it's above reject and so it really looks like the milter heavily relies on headers Yay for case in-sensitive parsing... found that out much later last night by plaing with headers in general spamass-milter[14891]: Could not extract score from Yes: Score=5.7, Tag-Level=5.0, Block-Level=10 add_header all Status _YESNO_, score=_SCORE_, tag-level=_REQD_, block-level=10 add_header all Status _YESNO_, Score=_SCORE_, Tag-Level=_REQD_, Block-Level=10 If you use the SA default Status header, or at least the prefix containing score and required, is header rewriting retained by the milter without the Flag header? add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ ... yes, that's what i tried to express score= instead of Score= is liked by the milter well, no big deal, i would have preferred it score or Yes/No also starzing lowercase :-) Given that log line, a likely explanation simply is that the milter needs to determine the spam status, to decide which SA generated headers to apply to the message. Your choice of custom Status header is not what the milter expects, and thus needs to resort to the simple Flag header. (Note the comma after yes/no, but no comma between score and required.) it's really only s versus S in score, tried it out before my post First of all, minus all those different datetime strings, IDs and ordering, the real differences are -Subject: [SPAM] Test^M -X-Spam-Flag: Yes^M +Subject: Test^M So it appears that only the sample with add_header spam Flag has the Subject re-written. correct However, there's something else going on. When re-writing the Subject header, SA adds an X-Spam-Prev-Subject header with the original. Which is clearly missing. the version is killed in smtp_header_checks which is also the reason that i started to play around with headers nobody but me has a reason to know exact versions of running software Previous-Subject, not Version. i saw that somewhere in the debug options and wondered too but i referred to the SA version header because doc says you can't remove it and so i explained why it's not there I mentioned this specifically, because the absence of the Previous Subject header with Subject rewrite clearly shows, SA generated headers are not unconditionally added to the message, but single headers are cherry picked. IOW, header rewriting does work without the Flag header. It is the glue that decides whether to inherit the rewritten header, and outright ignores the Previous Subject header. yep - as said: the intention of my post to that topic was only to make public how i fixed it before someone in the future wastes his time with outdated google hits mentioning no longer existing options which are not the reason in that case well, now i know that the milter relies on SA generated headers which was totally unexpected and i work with a lot of server software for many years - give me my daily WTF :-) Thus, something else has a severe impact on which headers are added or modified. In *both* cases, there is at least one SA generated header missing and/or SA modified header not preserved signature.asc Description: OpenPGP digital signature
Re: no subject tagging in case of X-Spam-Status: Yes
Am 25.08.2014 um 11:37 schrieb Reindl Harald: header contains X-Spam-Status: Yes, score=7.5 required=5.0 but the subject does not get [SPAM] tagging with the config below - not sure what i am missing spamassassin-3.4.0-7.fc20.x86_64 spamass-milter-0.3.2-11.fc20.x86_64 spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r 8 -- -s 1048576 perl -T -w /usr/bin/spamd -c -H --max-children=25 --min-children=10 --min-spare=5 --max-spare=15 __ /var/lib/spamass-milter/spamassassin/user_prefs is empty /etc/mail/spamassassin/local.cf is configured below use_bayes 1 bayes_use_hapaxes 1 bayes_expiry_max_db_size 30 bayes_auto_expire 1 bayes_auto_learn 0 bayes_learn_during_report 0 report_safe 0 skip_rbl_checks 1 clear_headers add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ rewrite_header Subject [SPAM] besides the permissions problem after the nightly sa-update the reason was simply clear_headers without add_header spam Flag _YESNO which is entirely unexpected behavior why does the software changing the subject based on a decision made by itself need a header written by itself as base for the next decision to change the subject? signature.asc Description: OpenPGP digital signature
Re: no subject tagging in case of X-Spam-Status: Yes
On Fri, 2014-08-29 at 00:30 +0200, Reindl Harald wrote:
besides the permissions problem after the nightly sa-update the reason
was simply clear_headers without add_header spam Flag _YESNO which
is entirely unexpected behavior
No, that is not the cause.
$ echo -e Subject: Foo\n | ./spamassassin | grep Subject
Subject: [SPAM] Foo
X-Spam-Prev-Subject: Foo
$ cat rules/99_DEVEL.cf
required_score -999# regardless of score, classify spam
# to enforce header rewriting
clear_headers
rewrite_header Subject [SPAM]
Besides, your own reply to my first post to this thread on Mon also
shows this claim to be false. The output of the command I asked you to
run clearly shows clear_headers in your config being in effect and a
rewritten Subject.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: no subject tagging in case of X-Spam-Status: Yes
Am 29.08.2014 um 01:20 schrieb Karsten Bräckelmann: On Fri, 2014-08-29 at 00:30 +0200, Reindl Harald wrote: besides the permissions problem after the nightly sa-update the reason was simply clear_headers without add_header spam Flag _YESNO which is entirely unexpected behavior No, that is not the cause. $ echo -e Subject: Foo\n | ./spamassassin | grep Subject Subject: [SPAM] Foo X-Spam-Prev-Subject: Foo $ cat rules/99_DEVEL.cf required_score -999# regardless of score, classify spam # to enforce header rewriting clear_headers rewrite_header Subject [SPAM] Besides, your own reply to my first post to this thread on Mon also shows this claim to be false. The output of the command I asked you to run clearly shows clear_headers in your config being in effect and a rewritten Subject i verfied that 20 times in my environment removing the line add_header spam Flag _YESNO_ and no tagging maybe the combination of spamass-milter and SA but it's fact signature.asc Description: OpenPGP digital signature
Re: no subject tagging in case of X-Spam-Status: Yes
On Fri, 2014-08-29 at 01:23 +0200, Reindl Harald wrote:
Am 29.08.2014 um 01:20 schrieb Karsten Bräckelmann:
On Fri, 2014-08-29 at 00:30 +0200, Reindl Harald wrote:
besides the permissions problem after the nightly sa-update the reason
was simply clear_headers without add_header spam Flag _YESNO which
is entirely unexpected behavior
No, that is not the cause.
$ echo -e Subject: Foo\n | ./spamassassin | grep Subject
Subject: [SPAM] Foo
X-Spam-Prev-Subject: Foo
$ cat rules/99_DEVEL.cf
required_score -999# regardless of score, classify spam
# to enforce header rewriting
clear_headers
rewrite_header Subject [SPAM]
Besides, your own reply to my first post to this thread on Mon also
shows this claim to be false. The output of the command I asked you to
run clearly shows clear_headers in your config being in effect and a
rewritten Subject
i verfied that 20 times in my environment
removing the line add_header spam Flag _YESNO_ and no tagging
maybe the combination of spamass-milter and SA but it's fact
So far I attributed most of your arguing to being stubborn and
opinionated. Not any longer.
Now you're outright lying.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: no subject tagging in case of X-Spam-Status: Yes
Am 29.08.2014 um 02:15 schrieb Reindl Harald: Am 29.08.2014 um 02:01 schrieb Karsten Bräckelmann: On Fri, 2014-08-29 at 01:23 +0200, Reindl Harald wrote: Besides, your own reply to my first post to this thread on Mon also shows this claim to be false. The output of the command I asked you to run clearly shows clear_headers in your config being in effect and a rewritten Subject i verfied that 20 times in my environment removing the line add_header spam Flag _YESNO_ and no tagging maybe the combination of spamass-milter and SA but it's fact So far I attributed most of your arguing to being stubborn and opinionated. Not any longer. Now you're outright lying look at the attached zp-archive and both messages produced with the same content before you pretend others lying damned - to make it easier i even added a config-diff * current config with the header * frommailer with the SA machine as destination * spam content * click send * fine [SPAM] in the subject * remove add_header spam Flag _YESNO_ from the config * reload SA * press send again in the webform * no [SPAM] in the subject and now what? maybe you should accept that even new users are no idiots and know what they are talking about and here you have the damend logs even containing the original subject of postfix's header_checks - so don't call others names before you have a matching test setup and can *prove* what you claim Aug 29 02:08:24 mail-gw postfix/smtpd[23354]: connect from testserver.rhsoft.net[84.113.92.77] Aug 29 02:08:24 mail-gw postfix/smtpd[23354]: 3hkh3X2YJNz1w: client=testserver.rhsoft.net[84.113.92.77] Aug 29 02:08:24 mail-gw postfix/cleanup[24041]: 3hkh3X2YJNz1w: info: header Subject: Test from testserver.rhsoft.net[84.113.92.77]; from=postmas...@testserver.rhsoft.net to=ha...@rhsoft.net proto=ESMTP helo=testserver.rhsoft.net Aug 29 02:08:24 mail-gw postfix/cleanup[24041]: 3hkh3X2YJNz1w: message-id=5d0902b99004e92eccfc834833cfbdf9a2e51f251409270...@testserver.rhsoft.net Aug 29 02:08:24 mail-gw spamd[21151]: spamd: processing message 5d0902b99004e92eccfc834833cfbdf9a2e51f251409270...@testserver.rhsoft.net for sa-milt:189 Aug 29 02:08:25 mail-gw spamd[21151]: spamd: identified spam (5.1/5.0) for sa-milt:189 in 1.0 seconds, 4784 bytes. Aug 29 02:08:25 mail-gw spamd[21151]: spamd: result: Y 5 - ADVANCE_FEE_4_NEW,ADVANCE_FEE_4_NEW_MONEY,ADVANCE_FEE_5_NEW,ADVANCE_FEE_5_NEW_MONEY,BAYES_99,BAYES_999,CUST_DNSBL_2,CUST_DNSBL_5,CUST_DNSWL_7,DEAR_SOMETHING,LOTS_OF_MONEY,RP_MATCHES_RCVD,T_MONEY_PERCENT,URG_BIZ scantime=1.0,size=4784,user=sa-milt,uid=189,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=32286,mid=5d0902b99004e92eccfc834833cfbdf9a2e51f251409270...@testserver.rhsoft.net,bayes=1.00,autolearn=disabled Aug 29 02:08:25 mail-gw postfix/qmgr[22472]: 3hkh3X2YJNz1w: from=postmas...@testserver.rhsoft.net, size=4597, nrcpt=1 (queue active) Aug 29 02:08:25 mail-gw postfix/smtpd[23354]: disconnect from testserver.rhsoft.net[84.113.92.77] Aug 29 02:08:25 mail-gw postfix/smtp[23363]: 3hkh3X2YJNz1w: to=ha...@rhsoft.net, relay=mail.thelounge.net[10.0.0.15]:10027, delay=1.2, delays=1.1/0/0.04/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 3hkh3Y3RF0z23) Aug 29 02:08:25 mail-gw postfix/qmgr[22472]: 3hkh3X2YJNz1w: removed Aug 29 02:08:38 mail-gw postfix/anvil[23356]: statistics: max connection rate 1/1800s for (smtpd:168.100.1.4) at Aug 29 01:58:38 Aug 29 02:08:38 mail-gw postfix/anvil[23356]: statistics: max connection count 1 for (smtpd:168.100.1.4) at Aug 29 01:58:38 Aug 29 02:08:38 mail-gw postfix/anvil[23356]: statistics: max recipient rate 1/1800s for (smtpd:168.100.1.4) at Aug 29 01:58:38 Aug 29 02:08:38 mail-gw postfix/anvil[23356]: statistics: max cache size 3 at Aug 29 02:08:24 Aug 29 02:09:40 mail-gw spamd[21068]: spamd: server hit by SIGHUP, restarting Aug 29 02:09:40 mail-gw spamd[21068]: spamd: server socket closed, type IO::Socket::IP Aug 29 02:09:42 mail-gw spamd[21068]: spamd: server started on IO::Socket::IP [127.0.0.1]:10027 (running version 3.4.0) Aug 29 02:09:42 mail-gw spamd[21068]: spamd: server pid: 21068 Aug 29 02:09:44 mail-gw postfix/postscreen[22610]: CONNECT from [84.113.92.77]:64250 to [10.0.0.19]:25 Aug 29 02:09:44 mail-gw postfix/postscreen[22610]: PASS OLD [84.113.92.77]:64250 Aug 29 02:09:44 mail-gw postfix/smtpd[23354]: connect from testserver.rhsoft.net[84.113.92.77] Aug 29 02:09:44 mail-gw postfix/smtpd[23354]: 3hkh540hvnz1w: client=testserver.rhsoft.net[84.113.92.77] Aug 29 02:09:44 mail-gw postfix/cleanup[24086]: 3hkh540hvnz1w: info: header Subject: Test from testserver.rhsoft.net[84.113.92.77]; from=postmas...@testserver.rhsoft.net to=ha...@rhsoft.net proto=ESMTP helo=testserver.rhsoft.net Aug 29 02:09:44 mail-gw postfix/cleanup[24086]: 3hkh540hvnz1w: message-id=aa9334ef3b057a98dc80f0589a73153957d112ff1409270...@testserver.rhsoft.net Aug 29 02:09:44 mail-gw spamd[24069]: spamd: processing message
Re: no subject tagging in case of X-Spam-Status: Yes
On Fri, 29 Aug 2014, Reindl Harald wrote:
Am 25.08.2014 um 11:37 schrieb Reindl Harald:
header contains X-Spam-Status: Yes, score=7.5 required=5.0
but the subject does not get [SPAM] tagging with the config
below - not sure what i am missing
spamassassin-3.4.0-7.fc20.x86_64
spamass-milter-0.3.2-11.fc20.x86_64
spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r 8 -- -s
1048576
perl -T -w /usr/bin/spamd -c -H --max-children=25 --min-children=10
--min-spare=5 --max-spare=15
__
/var/lib/spamass-milter/spamassassin/user_prefs is empty
/etc/mail/spamassassin/local.cf is configured below
[snip..]
report_safe 0
skip_rbl_checks 1
clear_headers
add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_
rewrite_header Subject [SPAM]
besides the permissions problem after the nightly sa-update the reason
was simply clear_headers without add_header spam Flag _YESNO which
is entirely unexpected behavior
why does the software changing the subject based on a decision made
by itself need a header written by itself as base for the next decision
to change the subject?
One thing to keep in mind here, you're using a milter and it does things
differently than when spamassassin is used as a filter.
With a milter it gets a copy of the incoming message, passes it on to SA,
it gets the results back from SA and then it makes decisions about how to
change the original message which is still in your MTA. So the milter makes
explicit calls into the MTA saying 'add this header' or 'replace that header
with this other data'. So it's up to your milter to decide what changes it
makes to the resultant message, it could -totally- ignore what SA has done
and produce its own outout.
Bottom line, you need to look at the code of the milter to see what headers
get added/changed in the resulting message output, the SA configs don't have
complete control.
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: no subject tagging in case of X-Spam-Status: Yes
On Fri, 2014-08-29 at 02:15 +0200, Reindl Harald wrote:
look at the attached zp-archive and both messages
produced with the same content before you pretend
others lying damned - to make it easier i even
added a config-diff
But no message diff. ;)
and now what?
maybe you should accept that even new users are
no idiots and know what they are talking about
Please accept my apologies. It appears something else is going on here,
and you in fact did not lie.
I'd like to add, though, that I do *not* assume new users to be idiots.
Plus, I generally spend quite some time on helping others fixing their
problems, including new users, as you certainly have noticed.
Now, moving forward: I've had a look at the message diffs. Quite
interesting, and I honestly want to figure out what's happening.
First of all, minus all those different datetime strings, IDs and
ordering, the real differences are
-Subject: [SPAM] Test^M
-X-Spam-Flag: Yes^M
+Subject: Test^M
So it appears that only the sample with add_header spam Flag has the
Subject re-written.
However, there's something else going on. When re-writing the Subject
header, SA adds an X-Spam-Prev-Subject header with the original. Which
is clearly missing.
Thus, something else has a severe impact on which headers are added or
modified. In *both* cases, there is at least one SA generated header
missing and/or SA modified header not preserved.
Definitely involved: Postfix, spamass-milter, SA. And probably some
other tool rewriting the message / reflowing headers, as per some
previous posts (and the X-Spam-Report header majorly inconvenienced by
re-flowing headers).
Regarding SA and the features in question: There is no different
behavior between calling the plain spamassassin script and using
spamc/d. There is absolutely nothing in SA itself that could explain the
discrepancy in Subject rewriting, nor the missing X-Spam-Prev-Subject
header.
My best bet would be on the SA invoking glue, not accepting or
overwriting headers as received by SA. Which tool that actually is, I
don't know. But I'd be interested to hear about it, if you find out.
(The additional empty line between message headers and body in the case
without X-Spam-Flag header most likely is just copy-n-paste body. Or
possibly another artifact of some tool munging messages.)
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: no subject tagging in case of X-Spam-Status: Yes
On Fri, 2014-08-29 at 02:15 +0200, Reindl Harald wrote:
look at the attached zp-archive [...]
Since I already had a closer look at the contents including your local
cf, and I am here to offer help and didn't mean no harm, some comments
regarding the SA config.
# resolves a bug with milter always triggering a wrong informational header
score UNPARSEABLE_RELAY 0
See the RH bug you filed and its upstream report. Do you still need
that? This would be the first instance of continued triggering of that
test I ever encountered.
# disable most builtin DNSBL/DNSWL to not collide with webinterface settings
score __RCVD_IN_SORBS 0
score __RCVD_IN_ZEN 0
score __RCVD_IN_DNSWL 0
Rules starting with double-underline are non-scoring sub-rules.
Assigning a zero score doesn't disable them like it does with regular
rules. In the case of RBL sub-rules like the above, it does not prevent
DNS queries. It is better to
meta __FOO 0
overwrite the sub-rule, rather than set a score that doesn't exist.
# unconditional sender whitelists
whitelist_from *@apache.org
whitelist_from *@bipa.co.at
whitelist_from *@centos.org
whitelist_from *@dovecot.org
[...]
Unconditional whitelisting generally is a bad idea and might appear in
forged addresses.
If possible, it is strongly suggested to use whitelist_from_auth, or at
least whitelist_from_rcvd (which requires *_networks be set correctly).
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
no subject tagging in case of X-Spam-Status: Yes
Hi header contains X-Spam-Status: Yes, score=7.5 required=5.0 but the subject does not get [SPAM] tagging with the config below - not sure what i am missing spamassassin-3.4.0-7.fc20.x86_64 spamass-milter-0.3.2-11.fc20.x86_64 spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r 8 -- -s 1048576 perl -T -w /usr/bin/spamd -c -H --max-children=25 --min-children=10 --min-spare=5 --max-spare=15 __ /var/lib/spamass-milter/spamassassin/user_prefs is empty /etc/mail/spamassassin/local.cf is configured below use_bayes 1 bayes_use_hapaxes 1 bayes_expiry_max_db_size 30 bayes_auto_expire 1 bayes_auto_learn 0 bayes_learn_during_report 0 report_safe 0 skip_rbl_checks 1 clear_headers add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ rewrite_header Subject [SPAM] score UNPARSEABLE_RELAY 0 bayes_ignore_header X-ACL-Warn bayes_ignore_header X-ASF-Spam-Status bayes_ignore_header X-ASG-Debug-ID bayes_ignore_header X-ASG-Orig-Subj bayes_ignore_header X-ASG-Recipient-Whitelist bayes_ignore_header X-ASG-Tag bayes_ignore_header X-Alimail-AntiSpam bayes_ignore_header X-Amavis-Modified bayes_ignore_header X-Anti-Spam bayes_ignore_header X-Anti-Virus bayes_ignore_header X-Anti-Virus-Version bayes_ignore_header X-AntiAbuse bayes_ignore_header X-Antispam bayes_ignore_header X-Antivirus bayes_ignore_header X-Antivirus-Status bayes_ignore_header X-Antivirus-Version bayes_ignore_header X-Attachment-Id bayes_ignore_header X-Authenticated-As bayes_ignore_header X-Authenticated-Sender bayes_ignore_header X-Authenticated-User bayes_ignore_header X-Authvirus bayes_ignore_header X-Barracuda-Apparent-Source-IP bayes_ignore_header X-Barracuda-BBL-IP bayes_ignore_header X-Barracuda-BRTS-Status bayes_ignore_header X-Barracuda-Bayes bayes_ignore_header X-Barracuda-Connect bayes_ignore_header X-Barracuda-Encrypted bayes_ignore_header X-Barracuda-Envelope-From bayes_ignore_header X-Barracuda-Fingerprint-Found bayes_ignore_header X-Barracuda-Orig-Rcpt bayes_ignore_header X-Barracuda-RBL-IP bayes_ignore_header X-Barracuda-RBL-Trusted-Forwarder bayes_ignore_header X-Barracuda-Spam-Report bayes_ignore_header X-Barracuda-Spam-Score bayes_ignore_header X-Barracuda-Spam-Status bayes_ignore_header X-Barracuda-Start-Time bayes_ignore_header X-Barracuda-UID bayes_ignore_header X-Barracuda-URL bayes_ignore_header X-Barracuda-Virus-Alert bayes_ignore_header X-Cloud-Security bayes_ignore_header X-Coremail-Antispam bayes_ignore_header X-He-Spam bayes_ignore_header X-IronPort-AV bayes_ignore_header X-IronPort-Anti-Spam-Filtered bayes_ignore_header X-IronPort-Anti-Spam-Result bayes_ignore_header X-Ironport bayes_ignore_header X-Klms-Anti bayes_ignore_header X-Klms-Antispam bayes_ignore_header X-Kse-Anti bayes_ignore_header X-Mozilla-Keys bayes_ignore_header X-Mozilla-Status bayes_ignore_header X-Mozilla-Status2 bayes_ignore_header X-PROLinux-SpamCheck bayes_ignore_header X-SPAM-FLAG bayes_ignore_header X-ServerMaster-MailScanner bayes_ignore_header X-Spam-Checker-Version bayes_ignore_header X-Spam-Level bayes_ignore_header X-Spam-Processed bayes_ignore_header X-Spam-Report bayes_ignore_header X-Spam-Score bayes_ignore_header X-Spam-Score-Int bayes_ignore_header X-Spam-Status bayes_ignore_header X-Spam-Threshold bayes_ignore_header X-SpamExperts-Domain bayes_ignore_header X-SpamExperts-Outgoing-Class bayes_ignore_header X-SpamExperts-Outgoing-Evidence bayes_ignore_header X-SpamExperts-Username bayes_ignore_header X-SpamInfo bayes_ignore_header X-Univie-Virus-Scan bayes_ignore_header X-Virus-Checker-Version bayes_ignore_header X-Virus-Scanned bayes_ignore_header X-Virus-Scanner-Version bayes_ignore_header X-VirusChecked bayes_ignore_header X-Virus-Status required_hits 5 score USER_IN_MORE_SPAM_TO -2 score USER_IN_ALL_SPAM_TO -100 score DKIM_SIGNED 0.5 score DKIM_VALID -0.5 score DKIM_VALID_AU -0.5 score ALL_TRUSTED -1 trusted_networks 192.168.196.0/24 signature.asc Description: OpenPGP digital signature
Re: no subject tagging in case of X-Spam-Status: Yes
On 8/25/2014 5:37 AM, Reindl Harald wrote: Hi header contains X-Spam-Status: Yes, score=7.5 required=5.0 but the subject does not get [SPAM] tagging with the config below - not sure what i am missing See http://www.jigsawboys.com/2006/06/28/spamassassin-rewrite-subject-not-working/ Regards, KAM
Re: no subject tagging in case of X-Spam-Status: Yes
Am 25.08.2014 um 16:58 schrieb Kevin A. McGrail: On 8/25/2014 5:37 AM, Reindl Harald wrote: header contains X-Spam-Status: Yes, score=7.5 required=5.0 but the subject does not get [SPAM] tagging with the config below - not sure what i am missing See http://www.jigsawboys.com/2006/06/28/spamassassin-rewrite-subject-not-working/ i found that days ago but where do you see the -m flag below? my original post contained the full ps aux cmd lines spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r 8 -- -s 1048576 signature.asc Description: OpenPGP digital signature
Re: no subject tagging in case of X-Spam-Status: Yes
On 8/25/2014 11:08 AM, Reindl Harald wrote: Am 25.08.2014 um 16:58 schrieb Kevin A. McGrail: On 8/25/2014 5:37 AM, Reindl Harald wrote: header contains X-Spam-Status: Yes, score=7.5 required=5.0 but the subject does not get [SPAM] tagging with the config below - not sure what i am missing See http://www.jigsawboys.com/2006/06/28/spamassassin-rewrite-subject-not-working/ i found that days ago but where do you see the -m flag below? my original post contained the full ps aux cmd lines spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r 8 -- -s 1048576 I don't see the change subject config lines for SA. Also, this is not the user list for spamass-milter. Regards, KAM
Re: no subject tagging in case of X-Spam-Status: Yes
Am 25.08.2014 um 17:11 schrieb Kevin A. McGrail: On 8/25/2014 11:08 AM, Reindl Harald wrote: Am 25.08.2014 um 16:58 schrieb Kevin A. McGrail: On 8/25/2014 5:37 AM, Reindl Harald wrote: header contains X-Spam-Status: Yes, score=7.5 required=5.0 but the subject does not get [SPAM] tagging with the config below - not sure what i am missing See http://www.jigsawboys.com/2006/06/28/spamassassin-rewrite-subject-not-working/ i found that days ago but where do you see the -m flag below? my original post contained the full ps aux cmd lines spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r 8 -- -s 1048576 I don't see the change subject config lines for SA because you stripped anything useful from my orgiginal post /etc/mail/spamassassin/local.cf: clear_headers add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ rewrite_header Subject [SPAM] Also, this is not the user list for spamass-milter uhm the settings below are also inherited from /etc/mail/spamassassin/local.cf as all other settings and scoring so i doubt that the milter with the params below and with no -m or -M is responsible use_bayes 1 bayes_use_hapaxes 1 bayes_expiry_max_db_size 30 bayes_auto_expire 1 bayes_auto_learn 0 signature.asc Description: OpenPGP digital signature
Re: no subject tagging in case of X-Spam-Status: Yes
On 8/25/2014 11:17 AM, Reindl Harald wrote: Am 25.08.2014 um 17:11 schrieb Kevin A. McGrail: On 8/25/2014 11:08 AM, Reindl Harald wrote: Am 25.08.2014 um 16:58 schrieb Kevin A. McGrail: On 8/25/2014 5:37 AM, Reindl Harald wrote: header contains X-Spam-Status: Yes, score=7.5 required=5.0 but the subject does not get [SPAM] tagging with the config below - not sure what i am missing See http://www.jigsawboys.com/2006/06/28/spamassassin-rewrite-subject-not-working/ earn 0 If you read the post I sent, you would have noted you are missing | rewrite_subject 1 | Post follow-ups on an appropriate support forum. This is not it.
Re: no subject tagging in case of X-Spam-Status: Yes
Am 25.08.2014 um 17:21 schrieb Kevin A. McGrail: On 8/25/2014 11:17 AM, Reindl Harald wrote: Am 25.08.2014 um 17:11 schrieb Kevin A. McGrail: On 8/25/2014 11:08 AM, Reindl Harald wrote: Am 25.08.2014 um 16:58 schrieb Kevin A. McGrail: On 8/25/2014 5:37 AM, Reindl Harald wrote: header contains X-Spam-Status: Yes, score=7.5 required=5.0 but the subject does not get [SPAM] tagging with the config below - not sure what i am missing See http://www.jigsawboys.com/2006/06/28/spamassassin-rewrite-subject-not-working/ earn 0 If you read the post I sent, you would have noted you are missing | rewrite_subject 1 https://wiki.apache.org/spamassassin/SubjectRewrite SubjectRewrite in 3.0.x - The rewrite_subject and subject_tag configuration options were deprecated and are now removed. Instead, using rewrite_header Subject [your desired setting]. e.g. rewrite_subject 1 subject_tag SPAM(_SCORE_) becomes rewrite_header Subject SPAM(_SCORE_) Post follow-ups on an appropriate support forum. This is not it why can't you just ignore something you don't bother about instead strip all informations out from my first post which maybe somebody else could found tomorrow and now ignores because stripped follow ups.. signature.asc Description: OpenPGP digital signature
Re: no subject tagging in case of X-Spam-Status: Yes
On Monday 25 August 2014 at 17:21:51 (EU time), Kevin A. McGrail wrote: On 8/25/2014 11:17 AM, Reindl Harald wrote: Am 25.08.2014 um 17:11 schrieb Kevin A. McGrail: On 8/25/2014 11:08 AM, Reindl Harald wrote: Am 25.08.2014 um 16:58 schrieb Kevin A. McGrail: On 8/25/2014 5:37 AM, Reindl Harald wrote: header contains X-Spam-Status: Yes, score=7.5 required=5.0 but the subject does not get [SPAM] tagging with the config below - not sure what i am missing See http://www.jigsawboys.com/2006/06/28/spamassassin-rewrite-subject-not -working/ earn 0 If you read the post I sent, you would have noted you are missing | rewrite_subject 1 Post follow-ups on an appropriate support forum. This is not it. I think you're being unfairly rude to the original poster here. His problem is not specific to spamass-milter (if it were, I would agree with pointing him politely in the direction of another support forum) - but as the link you posted above shows, his problem is with two spamassassin directives, of which he has only one in his configuration. Please let's try to be polite to people who come here asking for assistance; telling them they are not welcome is only going to create a bad impression of the spamassassin community. Thanks, Antony. -- The future is already here. It's just not evenly distributed yet. - William Gibson Please reply to the list; please *don't* CC me.
Re: no subject tagging in case of X-Spam-Status: Yes
Am 25.08.2014 um 17:29 schrieb Antony Stone: Post follow-ups on an appropriate support forum. This is not it. I think you're being unfairly rude to the original poster here. His problem is not specific to spamass-milter (if it were, I would agree with pointing him politely in the direction of another support forum) - but as the link you posted above shows, his problem is with two spamassassin directives, of which he has only one in his configuration. Please let's try to be polite to people who come here asking for assistance; telling them they are not welcome is only going to create a bad impression of the spamassassin community thank you - and BTW there is a good reason why i removed that line day ago while try to find a solution: spamd[23972]: config: failed to parse line, skipping, in /etc/mail/spamassassin/local.cf: rewrite_subject 1 signature.asc Description: OpenPGP digital signature
Re: no subject tagging in case of X-Spam-Status: Yes
On Mon, 2014-08-25 at 11:37 +0200, Reindl Harald wrote:
header contains X-Spam-Status: Yes, score=7.5 required=5.0
but the subject does not get [SPAM] tagging with the config
below - not sure what i am missing
What does this command return?
echo -e Subject: Foo\n | spamassassin --cf=required_score 1
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: no subject tagging in case of X-Spam-Status: Yes
Am 25.08.2014 um 18:00 schrieb Karsten Bräckelmann: On Mon, 2014-08-25 at 11:37 +0200, Reindl Harald wrote: header contains X-Spam-Status: Yes, score=7.5 required=5.0 but the subject does not get [SPAM] tagging with the config below - not sure what i am missing What does this command return? echo -e Subject: Foo\n | spamassassin --cf=required_score 1 as root as expected the modified subject as the milter user the unmodified but as you can see at bottom the user_prefs is completly empty in that case score=0.0 even after delete baeysian data but the score is not the problem, in my origin post you see the message flagged in the header but no subject changed anyways - what can cause the complete different behavior of the restricted user? __ [root@mail-gw:~]$ echo -e Subject: Foo\n | spamassassin --cf=required_score 1 Aug 25 18:46:56.220 [32082] warn: config: created user preferences file: /root/.spamassassin/user_prefs X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail-gw.thelounge.net X-Spam-Status: Yes, score=3.7 required=1.0 tests=MISSING_DATE,MISSING_FROM, MISSING_HEADERS,MISSING_MID,NO_HEADERS_MESSAGE,NO_RECEIVED,NO_RELAYS Subject: [SPAM] Foo X-Spam-Prev-Subject: Foo __ [root@mail-gw:~]$ su - sa-milt [sa-milt@mail-gw:~]$ echo -e Subject: Foo\n | spamassassin --cf=required_score 1 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail-gw.thelounge.net X-Spam-Status: No, score=0.0 required=1.0 tests=none Subject: Foo [sa-milt@mail-gw:~]$ sa-learn --clear [sa-milt@mail-gw:~]$ echo -e Subject: Foo\n | spamassassin --cf=required_score 1 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail-gw.thelounge.net X-Spam-Status: No, score=0.0 required=1.0 tests=none Subject: Foo __ sa-milt:x:189:188:SpamAssassin Milter:/var/lib/spamass-milter:/usr/bin/bash [sa-milt@mail-gw:~]$ ls -lha /var/lib/spamass-milter/ insgesamt 28K drwxr-x--- 4 sa-milt sa-milt 4,0K 2014-08-22 17:19 training drwxr-xr-x 4 sa-milt sa-milt 4,0K 2014-08-21 19:18 . drwxr-xr-x. 27 rootroot4,0K 2014-08-25 17:59 .. drwx-- 2 sa-milt sa-milt 4,0K 2014-08-25 17:58 .spamassassin lrwxrwxrwx 1 sa-milt sa-milt 13 2014-08-20 01:07 spamassassin - .spamassassin -rw--- 1 sa-milt sa-milt 2,4K 2014-08-22 20:03 .bash_history -rw--- 1 sa-milt sa-milt 187 2014-08-19 17:24 .bash_profile -rw--- 1 sa-milt sa-milt 285 2014-08-19 17:25 .bashrc [sa-milt@mail-gw:~]$ cat /var/lib/spamass-milter/.spamassassin/user_prefs # globally maintained because postfix-milter # signed off: Reindl Harald h.rei...@thelounge.net signature.asc Description: OpenPGP digital signature
Re: no subject tagging in case of X-Spam-Status: Yes
On Mon, 2014-08-25 at 18:55 +0200, Reindl Harald wrote:
Am 25.08.2014 um 18:00 schrieb Karsten Bräckelmann:
What does this command return?
echo -e Subject: Foo\n | spamassassin --cf=required_score 1
as root as expected the modified subject
as the milter user the unmodified
[root@mail-gw:~]$ echo -e Subject: Foo\n | spamassassin
--cf=required_score 1
X-Spam-Status: Yes, score=3.7 required=1.0 tests=MISSING_DATE,MISSING_FROM,
MISSING_HEADERS,MISSING_MID,NO_HEADERS_MESSAGE,NO_RECEIVED,NO_RELAYS
Subject: [SPAM] Foo
X-Spam-Prev-Subject: Foo
Exactly as expected. Subject tagging works.
[root@mail-gw:~]$ su - sa-milt
[sa-milt@mail-gw:~]$ echo -e Subject: Foo\n | spamassassin
--cf=required_score 1
X-Spam-Status: No, score=0.0 required=1.0 tests=none
Subject: Foo
No tests at all. I doubt the milter generated all those missing headers
including From and Date, instead of a Received one only. So it seems the
restricted sa-milt user has no read permissions on the SA config.
As that user, have a close look at the -D debug output.
spamassassin -D --lint
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: no subject tagging in case of X-Spam-Status: Yes
Am 25.08.2014 um 19:13 schrieb Karsten Bräckelmann:
On Mon, 2014-08-25 at 18:55 +0200, Reindl Harald wrote:
Am 25.08.2014 um 18:00 schrieb Karsten Bräckelmann:
X-Spam-Status: Yes, score=3.7 required=1.0 tests=MISSING_DATE,MISSING_FROM,
MISSING_HEADERS,MISSING_MID,NO_HEADERS_MESSAGE,NO_RECEIVED,NO_RELAYS
Subject: [SPAM] Foo
X-Spam-Prev-Subject: Foo
Exactly as expected. Subject tagging works.
yes
[root@mail-gw:~]$ su - sa-milt
[sa-milt@mail-gw:~]$ echo -e Subject: Foo\n | spamassassin
--cf=required_score 1
X-Spam-Status: No, score=0.0 required=1.0 tests=none
Subject: Foo
No tests at all. I doubt the milter generated all those missing headers
including From and Date, instead of a Received one only. So it seems the
restricted sa-milt user has no read permissions on the SA config.
As that user, have a close look at the -D debug output.
spamassassin -D --lint
bingo - only a snippet below
thank you so much for setp in that thread
___
the files inside exept one have correct permissions (0644)
but /var/lib/spamassassin/3.004000/updates_spamassassin_org not
that was pretty sure one of the first sa-update cronjobs because
as i started to play around the tagging was fine and i needed to
read manuals how to configure reject above a specific score and
later found out well, and now the tagging don't work
___
on the shell now it looks fine, mail still not tagged, all
services hard restarted and as said at the begin of play
around one time it worked - strange
Subject: Test
X-Spam-Status: Yes, score=1.7 required=1.0 tests=ADVANCE_FEE_4_NEW,
ADVANCE_FEE_4_NEW_MONEY,ADVANCE_FEE_5_NEW,ADVANCE_FEE_5_NEW_MONEY,ALL_TRUST
ED, DEAR_SOMETHING,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,LOTS_OF_MONEY,
T_MONEY_PERCENT,URG_BIZ
i guess i will setup a cronjob to make sure the permissions
below /var/lib/spamassassin/ are 755 and 644 for any item
[root@mail-gw:~]$ cat /usr/local/bin/sa-permissions.sh
#!/usr/bin/bash
/usr/bin/find /var/lib/spamassassin/ -type d -exec /bin/chmod 0755 {} \;
/usr/bin/find /var/lib/spamassassin/ -type f -exec /bin/chmod 0644 {} \;
[root@mail-gw:~]$ sa-permissions.sh
___
[sa-milt@mail-gw:~]$ echo -e Subject: Foo\n | spamassassin
--cf=required_score 1
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
mail-gw.thelounge.net
X-Spam-Status: Yes, score=3.7 required=1.0 tests=MISSING_DATE,MISSING_FROM,
MISSING_HEADERS,MISSING_MID,NO_HEADERS_MESSAGE,NO_RECEIVED,NO_RELAYS
Subject: [SPAM] Foo
X-Spam-Prev-Subject: Foo
___
Aug 25 19:18:58.225 [32610] dbg: config: file or directory
/var/lib/spamassassin/3.004000/updates_spamassassin_org/local.cf not
accessible: Permission denied
Aug 25 19:18:58.226 [32610] dbg: config: file or directory
/var/lib/spamassassin/3.004000/updates_spamassassin_org/regression_tests.cf not
accessible: Permission denied
[sa-milt@mail-gw:~]$ stat
/var/lib/spamassassin/3.004000/updates_spamassassin_org/regression_tests.cf
stat: cannot stat
'/var/lib/spamassassin/3.004000/updates_spamassassin_org/regression_tests.cf':
Permission denied
___
[root@mail-gw:~]$ stat /var/lib/spamassassin/3.004000/updates_spamassassin_org
File: '/var/lib/spamassassin/3.004000/updates_spamassassin_org'
Size: 4096Blocks: 8 IO Block: 4096 directory
Device: 811h/2065d Inode: 41664 Links: 2
Access: (0750/drwxr-x---) Uid: (0/root) Gid: (0/root)
Access: 2014-08-14 19:25:43.022151858 +0200
Modify: 2014-08-25 06:04:43.425632505 +0200
Change: 2014-08-25 06:04:43.425632505 +0200
Birth: -
[root@mail-gw:~]$ chmod 755
/var/lib/spamassassin/3.004000/updates_spamassassin_org
mode of '/var/lib/spamassassin/3.004000/updates_spamassassin_org' changed from
0750 (rwxr-x---) to 0755 (rwxr-xr-x)
[root@mail-gw:~]$ ls /var/lib/spamassassin/3.004000/updates_spamassassin_org/
total 920K
-rw-r--r-- 1 root root 100K 2014-08-25 06:04 languages
-rw-r- 1 root root 718 2014-08-25 06:04 MIRRORED.BY
-rw-r--r-- 1 root root 8.5K 2014-08-25 06:04 10_default_prefs.cf
-rw-r--r-- 1 root root 2.4K 2014-08-25 06:04 10_hasbase.cf
-rw-r--r-- 1 root root 7.5K 2014-08-25 06:04 20_advance_fee.cf
-rw-r--r-- 1 root root 8.9K 2014-08-25 06:04 20_aux_tlds.cf
-rw-r--r-- 1 root root 6.9K 2014-08-25 06:04 20_body_tests.cf
-rw-r--r-- 1 root root 1.9K 2014-08-25 06:04 20_compensate.cf
-rw-r--r-- 1 root root 9.6K 2014-08-25 06:04 20_dnsbl_tests.cf
-rw-r--r-- 1 root root 15K 2014-08-25 06:04 20_drugs.cf
-rw-r--r-- 1 root root 12K 2014-08-25 06:04 20_dynrdns.cf
-rw-r--r-- 1 root root 8.4K 2014-08-25 06:04 20_fake_helo_tests.cf
-rw-r--r-- 1 root root 3.0K 2014-08-25 06:04 20_freemail.cf
-rw-r--r-- 1 root root 42K 2014-08-25 06:04 20_freemail_domains.cf
-rw-r--r
Re: no subject tagging in case of X-Spam-Status: Yes
On Mon, 2014-08-25 at 19:43 +0200, Reindl Harald wrote:
Am 25.08.2014 um 19:13 schrieb Karsten Bräckelmann:
No tests at all. I doubt the milter generated all those missing headers
including From and Date, instead of a Received one only. So it seems the
restricted sa-milt user has no read permissions on the SA config.
As that user, have a close look at the -D debug output.
spamassassin -D --lint
bingo - only a snippet below
thank you so much for setp in that thread
the files inside exept one have correct permissions (0644)
but /var/lib/spamassassin/3.004000/updates_spamassassin_org not
i guess i will setup a cronjob to make sure the permissions
below /var/lib/spamassassin/ are 755 and 644 for any item
A dedicated cron job doesn't make sense. You should add that to the
existing cron job that runs sa-update and conditionally restarts spamd.
Changing permissions has to be done before restarting spamd.
Alternatively, ensure the respective users for spamd, sa-update and the
milter are identical, or at least share a common group.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: no subject tagging in case of X-Spam-Status: Yes
Am 25.08.2014 um 20:03 schrieb Karsten Bräckelmann: On Mon, 2014-08-25 at 19:43 +0200, Reindl Harald wrote: Am 25.08.2014 um 19:13 schrieb Karsten Bräckelmann: No tests at all. I doubt the milter generated all those missing headers including From and Date, instead of a Received one only. So it seems the restricted sa-milt user has no read permissions on the SA config. As that user, have a close look at the -D debug output. spamassassin -D --lint bingo - only a snippet below thank you so much for setp in that thread the files inside exept one have correct permissions (0644) but /var/lib/spamassassin/3.004000/updates_spamassassin_org not i guess i will setup a cronjob to make sure the permissions below /var/lib/spamassassin/ are 755 and 644 for any item A dedicated cron job doesn't make sense. You should add that to the existing cron job that runs sa-update and conditionally restarts spamd. Changing permissions has to be done before restarting spamd. agreed - set it in the systemd-units is preferable that's what i love about systemd - have your own units override distributions ones PermissionsStartOnly=true ExecStartPre=-/usr/local/bin/sa-permissions.sh ExecStart=/usr/sbin/spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r 7.5 -- -s 1048576 PermissionsStartOnly=true ExecStartPre=-/usr/local/bin/sa-permissions.sh ExecStart=/usr/bin/spamd $SPAMDOPTIONS Alternatively, ensure the respective users for spamd, sa-update and the milter are identical, or at least share a common group i guess having 0755 for folders and 0644 for files should be sane and safe spamd itself seems to run as root, most likely because bind on port 783 well, added to the todo-list try a port above 1024 and start the process directly with systemd as the sa-milt user root 1688 0.8 1.8 286596 73144 ?Ss 20:12 0:01 /usr/bin/perl -T -w /usr/bin/spamd -c -H --max-children=25 --min-children=10 --min-spare=5 --max-spare=15 tcp0 0 127.0.0.1:783 0.0.0.0:* LISTEN 1688/perl _ however, it still don't change the subject and if i would not have seen that once before found out how to set the reject-score i would say a problem in the milter, but looking at the yum.log no updates in that area well, not that dramatical important but i am perfectionist signature.asc Description: OpenPGP digital signature
X-Spam-Status: No, but still marked with [SPAM]
I'm getting these messages, some of them real emails, that get marked with [SPAM] even though X-Spam-Status: comes up as No. I updated to the latest build on Fedora though I think this has been going on awhile. It happens with some email accounts but not others. From me...@ecuador.junglevision.com Thu Sep 20 17:42:50 2012 Return-Path: me...@ecuador.junglevision.com X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ecuador.junglevision.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=2.0 tests=FROM_MISSP_REPLYTO, FROM_MISSP_URI,TO_NO_BRKTS_FROM_MSSP autolearn=ham version=3.3.2 Received: from ecuador.junglevision.com (localhost [127.0.0.1]) by ecuador.junglevision.com (8.14.5/8.14.5) with ESMTP id q8L0go5j02679 for megans...@junglevision.com; Thu, 20 Sep 2012 17:42:50 -0700 Received: (from megan@localhost) by ecuador.junglevision.com (8.14.5/8.14.5/Submit) id q8L0goLd026789 for megans...@junglevision.com; Thu, 20 Sep 2012 17:42:50 -0700 Received: from server.cgskies.com (www.cgskies.com [85.17.169.165]) by ecuador.junglevision.com (8.14.5/8.14.5) with ESMTP id q8L0gmKk02678 for me...@junglevision.com; Thu, 20 Sep 2012 17:42:49 -0700 Received: from www.cgtextures.com (www.cgtextures.com [95.211.74.173]) by server.cgskies.com (8.14.4/8.14.4) with ESMTP id q8L0XDp8032570 for me...@junglevision.com; Fri, 21 Sep 2012 02:33:13 +0200 Received: by www.cgtextures.com (Postfix, from userid 101) id 81BF513200F0; Fri, 21 Sep 2012 03:55:56 +0200 (CEST) To: me...@junglevision.com Subject: [SPAM] Action Required to Activate Membership for CGTextures From: CGTextures supportsupp...@cgtextures.com To: me...@junglevision.com Reply-To: CGTextures supportsupp...@cgtextures.com Date: Fri, 21 Sep 2012 03:55:56 +0200 Message-Id: 20120921015556.81bf51320...@www.cgtextures.com X-Spam-Prev-Subject: Action Required to Activate Membership for CGTextures X-UID: 170756 Status: O X-Keywords: NonJunk
Re: X-Spam-Status: No, but still marked with [SPAM]
This is pretty common - enough that I'd appreciate it if you could provide more information on the cause of your problem, and how you fix it, once you do. Yesterday in IRC: 09:40PM ke6i X-Spam-Status: No, score=0.0 required=2.0 tests=FROM_MISSP_REPLYTO, FROM_MISSP_URI,TO_NO_BRKTS_FROM_MSSP autolearn=ham version=3.3.2 I'm getting mail like this marked as spam. But score = 0? Why would it mark this as spam if score is 0 and required is 2. 09:48PM Darxus Sounds like that header, and your [SPAM] subject modification(?) are coming from two different runs of spamassassin. 09:49PM ke6i interesting. Let me study this message some more. 11:51PM ke6i yeah something odd is going on here. I'm seeing 'spamd: processing message ' in maillog twice for each email. There have been a bunch of times I've heard people say spamassassin is simultaneously marking emails as both spam and not spam. Many times the result has been that somehow they were running SA twice on the emails. Never has it come up that SA was actually doing this in a single run. On 09/21, Cathryn Mataga wrote: I'm getting these messages, some of them real emails, that get marked with [SPAM] even though X-Spam-Status: comes up as No. I updated to the latest build on Fedora though I think this has been going on awhile. It happens with some email accounts but not others. From me...@ecuador.junglevision.com Thu Sep 20 17:42:50 2012 Return-Path: me...@ecuador.junglevision.com X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ecuador.junglevision.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=2.0 tests=FROM_MISSP_REPLYTO, FROM_MISSP_URI,TO_NO_BRKTS_FROM_MSSP autolearn=ham version=3.3.2 Received: from ecuador.junglevision.com (localhost [127.0.0.1]) by ecuador.junglevision.com (8.14.5/8.14.5) with ESMTP id q8L0go5j02679 for megans...@junglevision.com; Thu, 20 Sep 2012 17:42:50 -0700 Received: (from megan@localhost) by ecuador.junglevision.com (8.14.5/8.14.5/Submit) id q8L0goLd026789 for megans...@junglevision.com; Thu, 20 Sep 2012 17:42:50 -0700 Received: from server.cgskies.com (www.cgskies.com [85.17.169.165]) by ecuador.junglevision.com (8.14.5/8.14.5) with ESMTP id q8L0gmKk02678 for me...@junglevision.com; Thu, 20 Sep 2012 17:42:49 -0700 Received: from www.cgtextures.com (www.cgtextures.com [95.211.74.173]) by server.cgskies.com (8.14.4/8.14.4) with ESMTP id q8L0XDp8032570 for me...@junglevision.com; Fri, 21 Sep 2012 02:33:13 +0200 Received: by www.cgtextures.com (Postfix, from userid 101) id 81BF513200F0; Fri, 21 Sep 2012 03:55:56 +0200 (CEST) To: me...@junglevision.com Subject: [SPAM] Action Required to Activate Membership for CGTextures From: CGTextures supportsupp...@cgtextures.com To: me...@junglevision.com Reply-To: CGTextures supportsupp...@cgtextures.com Date: Fri, 21 Sep 2012 03:55:56 +0200 Message-Id: 20120921015556.81bf51320...@www.cgtextures.com X-Spam-Prev-Subject: Action Required to Activate Membership for CGTextures X-UID: 170756 Status: O X-Keywords: NonJunk -- I always wonder why birds stay in the same place when they can fly anywhere on the earth. Then I ask myself the same question. - Harun Yahya http://www.ChaosReigns.com
Re: X-Spam-Status: No, but still marked with [SPAM]
Hello Cathryn, Friday, September 21, 2012, 6:21:05 PM, you wrote: CM I'm getting these messages, some of them real emails, that get marked CM with [SPAM] CM even though X-Spam-Status: comes up as No. I updated to the latest build on CM Fedora though I think this has been going on awhile. It happens with CM some email CM accounts but not others Are you sure it's your server that's rewriting the Subject: header? -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgp4TsQ3r0mjw.pgp Description: PGP signature
Re: X-Spam-Status: Yes, score=18.4 - Still delivered.
snowweb pe...@snowweb.co.uk wrote: It seems that if the sender is Exim always delivers it to the inbox, regardless of the how it was classified. Apparently this is because mailservers sending notification of undeliverable mail, identify themselves in this way (for some reason which appears a bit daft to me) The reason the SMTP standard requires this is ensure that a delivery status notice does not generate another delivery status notice. and therefore, everything from is automatically delivered to the inbox. That's the daft part! That's not logical at all. Apply the spam score the same as for any other message, if you can. Joseph Brennan Lead Email Systems Engineer Columbia University Information Technology
Re: X-Spam-Status: Yes, score=18.4 - Still delivered.
Joseph Brennan wrote: The reason the SMTP standard requires this is ensure that a delivery status notice does not generate another delivery status notice. Thanks Joseph. You're right, seems a bit daft. Nevermind, at least I know it's not broken now! Will continue to score as usual on senders. Pete -- View this message in context: http://old.nabble.com/X-Spam-Status%3A-Yes%2C-score%3D18.4---Still-delivered.-tp31591656p31651611.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: X-Spam-Status: Yes, score=18.4 - Still delivered.
Thanks for your responses.
Sorry, forgot temporarily, that SA only classifies spam and other
mechanism's control what is done to it after that. Therefore the issue lies
elsewhere as you rightly say.
It seems that if the sender is Exim always delivers it to the inbox,
regardless of the how it was classified. Apparently this is because
mailservers sending notification of undeliverable mail, identify themselves
in this way (for some reason which appears a bit daft to me) and therefore,
everything from is automatically delivered to the inbox. Personally, I
want it to be delivered in accordance with the spam classification and will
attempt to modify the Exim config files to reflect this.
Regarding rejecting spam, we reject at SMTP, those who have no valid
return-path or if the sending mailserver is in certain RBL's, otherwise we
accept and deliver almost everything, either to the user's inbox or to their
spam folder.
The exception to the above is if the SA score is exceptionally high (like
TEN ABOVE the spam threshold set by the client), this can only be due to
significant issues in the header of the email, then it won't be delivered
but silently dropped. These emails, generally have 'forged_this' and
'forged_that', no RDNS, via dynamic IP, contain masked link to russian
mailserver pretending to be from Paypal, etc. What possible use could the
email in question (above) be to anyone? It didn't even have any displayed
content and the headers are mainly forged. We have no intention of
delivering that kind of thing and even if it did have a return path, we
wouldn't return it as it would probably be forged too and that would
probably make us spammers.
We used to deliver those too, until certain clients contacted us, saying not
to deliver the obvious stuff. By not delivering that it offers them some,
degree of protection against phishing and also makes checking the spam
folder for ham, easier. So far no complaints, although would happily deliver
even those emails for any user upon request. The BAYES databases are user
trainable too, so we never get any issues. Users can control most aspects of
the service, including disabling it.
Thanks again.
Peter
Karsten Bräckelmann-2 wrote:
On Tue, 2011-05-10 at 23:26 -0700, snowweb wrote:
I'm getting many spams in the last few days, with spam scores far above
my
4.0 threshold, which are still being delivered. Wondering if it's to do
with
the fact that they all seem to have no sender.
Uhm, wait -- what else did you expect!?
Sorry if I am mis-interpreting, but what does happen usually with mail
exceeding your SA score threshold? If they are not delivered, are you
rejecting them at SMTP stage, or is your mail processing chain first
accepting the mail, and later *bouncing* identified spam back to the
usually *forged* sender?
To clarify: SA scores a mail. An estimation of how spammy it is. SA does
NOT deliver or reject mail. Any action whatsoever is the duty of other
tools in your mail processing chain.
Whatever takes care of identified spam not being delivered is not SA,
but another tool. Quarantining or proper SMTP rejecting spam would be
possible with both, a sender address *and* a null sender.
I can see how your tools refuse to *bounce* a mail with a null sender,
but still silently doing it -- incorrectly! -- if the envelope from
exists. Which appears to be the difference, why these samples do end up
delivered regardless.
Bouncing spam is a very bad thing to do. Back-scatter, and a disservice
to other mail users. Please, do not do it!
Return-path:
Envelope-to: myu...@mydomain.co.uk
Delivery-date: Wed, 11 May 2011 10:25:05 +0800
Received: from mail by s1.snowweb.info with spam-scanned (Exim 4.67)
id 1QJz6l-0005lL-EX
for myu...@mydomain.co.uk; Wed, 11 May 2011 10:25:04 +0800
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
s1.snowweb.info
X-Spam-Flag: YES
X-Spam-Level: **
[...]
By the way, does anyone have the trim email button figured out? I pressed
it
Nope. No idea what you're talking about here anyway, but it's not SA.
and entered the address that I wanted obfuscate, but it didn't seem to
obfuscate anything, so I changed my address in the message source
manually
to myu...@mydomain.co.uk.
Next time, please use example.com and friends for the domain part.
--
char
*t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8?
c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0;
}}}
--
View this message in context:
http://old.nabble.com/X-Spam-Status%3A-Yes%2C-score%3D18.4---Still-delivered.-tp31591656p31608305.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
X-Spam-Status: Yes, score=18.4 - Still delivered.
I'm getting many spams in the last few days, with spam scores far above my 4.0 threshold, which are still being delivered. Wondering if it's to do with the fact that they all seem to have no sender. I've included the source of a recent one: ** SOURCE STARTS HERE Return-path: Envelope-to: myu...@mydomain.co.uk Delivery-date: Wed, 11 May 2011 10:25:05 +0800 Received: from mail by s1.snowweb.info with spam-scanned (Exim 4.67) id 1QJz6l-0005lL-EX for myu...@mydomain.co.uk; Wed, 11 May 2011 10:25:04 +0800 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on s1.snowweb.info X-Spam-Flag: YES X-Spam-Level: ** X-Spam-ASN: AS24560 122.161.32.0/20 X-Spam-Status: Yes, score=18.4 required=4.0 tests=BAYES_99,EMPTY_MESSAGE, FH_FROMEML_NOTLD,FORGED_OUTLOOK_TAGS,FROM_NO_USER,FSL_HELO_NON_FQDN_1, HELO_NO_DOMAIN,RCVD_IN_BRBL_LASTEXT,RCVD_IN_PBL,RCVD_IN_RP_RNBL, RCVD_IN_SORBS_DUL,RCVD_IN_XBL,RDNS_NONE shortcircuit=no autolearn=no version=3.3.1 X-Spam-Relay-Country: IN X-Spam-Report: * 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100% * [score: 1.] * 1.5 FSL_HELO_NON_FQDN_1 FSL_HELO_NON_FQDN_1 * 1.1 FH_FROMEML_NOTLD E-mail address doesn't have TLD (.com, etc.) * 0.8 FROM_NO_USER From: has no local-part before @ sign * 1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT * [122.161.46.234 listed in bb.barracudacentral.org] * 1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL, * https://senderscore.org/blacklistlookup/ * [122.161.46.234 listed in bl.score.senderscore.com] * 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [122.161.46.234 listed in zen.spamhaus.org] * 0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [122.161.46.234 listed in dnsbl.sorbs.net] * 0.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 2.3 EMPTY_MESSAGE Message appears to have no textual parts and no * Subject: text * 1.2 RDNS_NONE Delivered to internal network by a host with no rDNS * 1.5 HELO_NO_DOMAIN Relay reports its domain incorrectly Received: from [122.161.46.234] (helo=ghar9abff6bacf) by s1.snowweb.info with smtp (Exim 4.67) id 1QJz6k-0005gw-LH for myu...@mydomain.co.uk; Wed, 11 May 2011 10:25:03 +0800 Received: (qmail 8554 by uid 554); Wed, 11 May 2011 07:58:07 -0530 From: To: myu...@mydomain.co.uk Subject: Date: Wed, 11 May 2011 07:42:20 -0530 Message-ID: 004201cc0fb1$90daace0$b29006a0$@com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary==_NextPart_000_0041_01CC0FB1.90DAACE0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjoDfb1RXqDPAYPRxyGAGXqi79COA== Content-Language: en-us --=_NextPart_000_0041_01CC0FB1.90DAACE0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --=_NextPart_000_0041_01CC0FB1.90DAACE0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable --=_NextPart_000_0041_01CC0FB1.90DAACE0-- * end of source ** By the way, does anyone have the trim email button figured out? I pressed it and entered the address that I wanted obfuscate, but it didn't seem to obfuscate anything, so I changed my address in the message source manually to myu...@mydomain.co.uk. Thanks for your help in advance. Peter -- View this message in context: http://old.nabble.com/X-Spam-Status%3A-Yes%2C-score%3D18.4---Still-delivered.-tp31591656p31591656.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: X-Spam-Status: Yes, score=18.4 - Still delivered.
On 10.05.11 23:26, snowweb wrote: I'm getting many spams in the last few days, with spam scores far above my 4.0 threshold, which are still being delivered. delivered? SA doesn't care about delivery, only about detecting spam. The delivery is up to your MTA, e.g. spamass-milter X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on s1.snowweb.info X-Spam-Flag: YES Now SpamAssassin did its work... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Saving Private Ryan... Private Ryan exists. Overwrite? (Y/N)
Re: X-Spam-Status: Yes, score=18.4 - Still delivered.
On Tue, 2011-05-10 at 23:26 -0700, snowweb wrote:
I'm getting many spams in the last few days, with spam scores far above my
4.0 threshold, which are still being delivered. Wondering if it's to do with
the fact that they all seem to have no sender.
Uhm, wait -- what else did you expect!?
Sorry if I am mis-interpreting, but what does happen usually with mail
exceeding your SA score threshold? If they are not delivered, are you
rejecting them at SMTP stage, or is your mail processing chain first
accepting the mail, and later *bouncing* identified spam back to the
usually *forged* sender?
To clarify: SA scores a mail. An estimation of how spammy it is. SA does
NOT deliver or reject mail. Any action whatsoever is the duty of other
tools in your mail processing chain.
Whatever takes care of identified spam not being delivered is not SA,
but another tool. Quarantining or proper SMTP rejecting spam would be
possible with both, a sender address *and* a null sender.
I can see how your tools refuse to *bounce* a mail with a null sender,
but still silently doing it -- incorrectly! -- if the envelope from
exists. Which appears to be the difference, why these samples do end up
delivered regardless.
Bouncing spam is a very bad thing to do. Back-scatter, and a disservice
to other mail users. Please, do not do it!
Return-path:
Envelope-to: myu...@mydomain.co.uk
Delivery-date: Wed, 11 May 2011 10:25:05 +0800
Received: from mail by s1.snowweb.info with spam-scanned (Exim 4.67)
id 1QJz6l-0005lL-EX
for myu...@mydomain.co.uk; Wed, 11 May 2011 10:25:04 +0800
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on s1.snowweb.info
X-Spam-Flag: YES
X-Spam-Level: **
[...]
By the way, does anyone have the trim email button figured out? I pressed it
Nope. No idea what you're talking about here anyway, but it's not SA.
and entered the address that I wanted obfuscate, but it didn't seem to
obfuscate anything, so I changed my address in the message source manually
to myu...@mydomain.co.uk.
Next time, please use example.com and friends for the domain part.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Incorrect X-Spam-Status header
SA is correctly assigning a high score to an email (Content analysis details: (12.0 points, 3.5 required)) but the X-Spam-Status header reads: No, score=0.0 required=3.5 tests=HTML_MESSAGE,MIME_BASE64_TEXT, MIME_QP_LONG_LINE,NO_RELAYS,T_HTML_ATTACH autolearn=unavailable version=3.3.1... any hints? Email Subject: *SPAM* Reset your Twitter password From: Twitter twitter-resetpw-daniel=mydomain@postmaster.twitter.com Date: Tue, 15 Jun 2010 01:54:12 +0200 To: m...@mydomain.com X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mydomain.com X-Spam-Status: No, score=0.0 required=3.5 tests=HTML_MESSAGE,MIME_BASE64_TEXT, MIME_QP_LONG_LINE,NO_RELAYS,T_HTML_ATTACH autolearn=unavailable version=3.3.1 Received: from localhost by mydomain.com with SpamAssassin (version 3.3.1); Mon, 14 Jun 2010 18:57:51 -0400 Message-ID: 4c069fc268b7d_3795925aa4308...@mx008.twitter.com.tmail MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=--=_4C16B3EF.5B551AAE Spam detection software, running on the system mydomain.com, has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hey there. Because of the measures taken to provide safety to our clients, your password has been changed. You can find your new password in attached document. Yours, Twitter= [...] Content analysis details: (12.0 points, 3.5 required) pts rule name description -- -- 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see http://www.spamcop.net/bl.shtml?78.135.14.229] 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [78.135.14.229 listed in dnsbl.sorbs.net] 3.6 RCVD_IN_PBLRBL: Received via a relay in Spamhaus PBL [78.135.14.229 listed in zen.spamhaus.org] 0.7 RCVD_IN_XBLRBL: Received via a relay in Spamhaus XBL 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL [78.135.14.229 listed in psbl.surriel.com] 1.3 RCVD_IN_RP_RNBLRBL: Relay in RNBL, https://senderscore.org/blacklistlookup/ [78.135.14.229 listed in bl.score.senderscore.com] 1.6 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT [78.135.14.229 listed in bb.barracudacentral.org] 1.1 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d 0.1 TVD_RCVD_IPTVD_RCVD_IP 0.0 T_HTML_ATTACH BODY: HTML attachment to bypass scanning? 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.0 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS -2.3 AWLAWL: From: address is in the auto white-list The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. Subject: Reset your Twitter password From: Twitter twitter-resetpw-daniel=mydomain@postmaster.twitter.com Date: Tue, 15 Jun 2010 01:54:12 +0200 To: m...@mydomain.com Return-Path: layoffsid...@rconsultinggroup.com X-Original-To: m...@mydomain.com Delivered-To: m...@mydomain.com Received: from 78-135-14-229.extendbroadband.com (unknown [78.135.14.229]) by mail.zirkin.com (Postfix) with ESMTP id C55DB1E6068B for m...@mydomain.com; Mon, 14 Jun 2010 18:57:46 -0400 (EDT) Received: from mx008.twitter.com (mx008.twitter.com [128.121.146.144]) by mx.google.com with ESMTP id 5qn4711431qfu.10.20100614225412; Tue, 15 Jun 2010 01:54:12 +0200 Received: from twitter.com (localhost [127.0.0.1]) by mx008.twitter.com (Postfix) with ESMTP id 15H31341391 for m...@mydomain.com; Tue, 15 Jun 2010 01:54:12 +0200 Reply-To: nore...@postmaster.twitter.com Message-ID: 4c069fc268b7d_3795925aa4308...@mx008.twitter.com.tmail MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=--9EC4821DA6B730 Hi, m...@mydomain.com Because of the measures taken to provide safety to our clients, your password has been changed. You can find your new password in attached document. The Twitter Team Please do not reply to this message; it was sent from an unmonitored email address. This message is a service email related to your use of Twitter. Reset your Twitter password.eml Content-Description: original message before SpamAssassin Content-Type: message/rfc822 Content-Encoding: 8bit index.html
Re: Incorrect X-Spam-Status header
On Mon, 14 Jun 2010, dannoz wrote:
SA is correctly assigning a high score to an email (Content analysis details:
(12.0 points, 3.5 required)) but the X-Spam-Status header reads: No,
score=0.0 required=3.5 tests=HTML_MESSAGE,MIME_BASE64_TEXT,
MIME_QP_LONG_LINE,NO_RELAYS,T_HTML_ATTACH autolearn=unavailable
version=3.3.1... any hints?
Email
Subject:
[snip..]
Looks like that message got passed thru SA twice, first time thru
a system that was conf'ed to do the report-safe processing
so it wrapped the spam into a MIME attachment, the second time thu
(or thru a different instance of SA) only saw the headers from the
MIME wrapping and decided that it was a ham message.
examine your mail flow carefully to see if there's any chance
it got SA'ed twice.
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: version now in X-Spam-Checker-Version, so remove from X-Spam-Status
On Sat, 2008-09-13 at 01:54 +, Duane Hill wrote:
On Sat, 13 Sep 2008, [EMAIL PROTECTED] wrote:
Gentlemen, I am frustrated by the duplication of information in:
X-Spam-Checker-Version: SpamAssassin
3.2.5-mon_sep__8_23_53_29_2008.jidanni2.jidanni.org (2008-06-10) on
jidanni2.jidanni.org
X-Spam-Status: No, score=0.0 required=1.9 tests=none autolearn=disabled
version=3.2.5-mon_sep__8_23_53_29_2008.jidanni2.jidanni.org
Yay, a 51 char long version string.
Indeed, I'd be annoyed (not frustrated, though) by that, too. However,
it's not the default. Not even close. In my headers, the version string
3.2.5 is barely noticeable.
Then why not just remove it. This is the default:
add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_
autolearn=_AUTOLEARN_ version=_VERSION_
according to 'perldoc Mail::SpamAssassin::Conf'.
Add the above in your local.cf and knock off the 'version=_VERSION_' part.
Problem solved. SpamAssassin _IS_ configurable.
Yeah, just remove it. Or, maybe, stick to a shorter version identifier.
You don't need all that information encoded into that string of yours,
do you?
guenther
--
char *t=[EMAIL PROTECTED];
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
version now in X-Spam-Checker-Version, so remove from X-Spam-Status
Gentlemen, I am frustrated by the duplication of information in: X-Spam-Checker-Version: SpamAssassin 3.2.5-mon_sep__8_23_53_29_2008.jidanni2.jidanni.org (2008-06-10) on jidanni2.jidanni.org X-Spam-Status: No, score=0.0 required=1.9 tests=none autolearn=disabled version=3.2.5-mon_sep__8_23_53_29_2008.jidanni2.jidanni.org Why not just chuck the newly arrived X-Spam-Checker-Version, I said to myself. However, Note that X-Spam-Checker-Version is not removable because the version information is needed by mail administrators OK, then I tried tinkering with version_tag string This tag is appended to the SA version in the X-Spam-Status header...your last name or your initials which doesn't yet mention that it ends up in X-Spam-Checker-Version too... indeed it's either both or nothing. The obvious solution is to not include version in X-Spam-Status anymore, as it is not a statusy item, and naturally belongs instead in X-Spam-Checker-Version, which being a like-it-or-not item, might as well carry it alone.
Re: version now in X-Spam-Checker-Version, so remove from X-Spam-Status
On Sat, 13 Sep 2008, [EMAIL PROTECTED] wrote: Gentlemen, I am frustrated by the duplication of information in: X-Spam-Checker-Version: SpamAssassin 3.2.5-mon_sep__8_23_53_29_2008.jidanni2.jidanni.org (2008-06-10) on jidanni2.jidanni.org X-Spam-Status: No, score=0.0 required=1.9 tests=none autolearn=disabled version=3.2.5-mon_sep__8_23_53_29_2008.jidanni2.jidanni.org Why not just chuck the newly arrived X-Spam-Checker-Version, I said to myself. However, Note that X-Spam-Checker-Version is not removable because the version information is needed by mail administrators OK, then I tried tinkering with version_tag string This tag is appended to the SA version in the X-Spam-Status header...your last name or your initials which doesn't yet mention that it ends up in X-Spam-Checker-Version too... indeed it's either both or nothing. The obvious solution is to not include version in X-Spam-Status anymore, as it is not a statusy item, and naturally belongs instead in X-Spam-Checker-Version, which being a like-it-or-not item, might as well carry it alone. Then why not just remove it. This is the default: add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ autolearn=_AUTOLEARN_ version=_VERSION_ according to 'perldoc Mail::SpamAssassin::Conf'. Add the above in your local.cf and knock off the 'version=_VERSION_' part. Problem solved. SpamAssassin _IS_ configurable. -d
Re: X-Spam-Status does not appear in mail header
Hi sm, The startup parameters may be different. Verify what spamass_milter_flags settings used in rc.conf to start the milter. I'm in doubt we mean the same thing. I verified these settings, an it's not spamass-milter not rewriting headers -- but it does not write *all* headers. IIRC, the X-Spam-Level should appear in each message, regardless of it's spam or not. But the only header I see is X-Spam-Checker-Version. Subject rewriting would be the next step in case of spam, but first of all it has to determine the X-Spam-Level... and to write it to the header, doesn't it? Regards, Marianne
Re: X-Spam-Status does not appear in mail header
Hi Marianne, At 10:33 26-03-2008, Marianne Spiller wrote: I verified these settings, an it's not spamass-milter not rewriting headers -- but it does not write *all* headers. IIRC, the X-Spam-Level should appear in each message, regardless of it's spam or not. But the only header I see is X-Spam-Checker-Version. Subject rewriting would be the next step in case of spam, but first of all it has to determine the X-Spam-Level... and to write it to the header, doesn't it? The X-Spam-Level is added to all messages if you have the following line in your SpamAssassin configuration file: add_header all Level _STARS(*)_ Subject rewriting will be done even without the X-Spam-Level setting as it is based on whether the score is above the required_score. Regards, -sm
X-Spam-Status does not appear in mail header
Hi folks, I have a strange problem on my NetBSD-current box: I installed spamassassin from pkgsrc (V 3.2.3) and configured it in sendmail (INPUT_MAIL_FILTER(`spamassassin'...). It seems to work; there are bayes_seen and bayes_toks, and I can see in `sa-learn --dump magic` my spamassassin seems to learn. But newly arrived mail gets never marked as spam; spamassassin[1] checks it, but the header rewrite is unusual: Mar 25 18:05:06 vinyl spamd[4661]: spamd: processing message [EMAIL PROTECTED] for me:1005 Mar 25 18:05:06 vinyl spamd[4661]: spamd: clean message (0.0/5.0) for me:1005 in 0.1 seconds, 4399 bytes. Mar 25 18:05:06 vinyl spamd[4661]: spamd: result: . 0 - scantime=0.1,size=4399,user=me,uid=1005,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=64556,mid=[EMAIL PROTECTED],autolearn=ham Mar 25 18:05:06 vinyl sm-mta[914]: m2PH54SR000914: Milter add: header: X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on myhost Huh? The only header is X-Spam-Checker-Version, but it does not write a X-Spam-Status or X-Spam-Level header to my messages as I can see in message source. Isn't that strange? Exactly the same setup worked fine under a Debian Xen domU... `spamassassin -D --lint` without any errors. I hope anybody can give me a hint. Best regards, Marianne [1] required_score 5.0 rewrite_header Subject [:.SPAM.:] report_safe 1 use_bayes 1 bayes_path /var/spamassassin/bayes bayes_file_mode 777 bayes_auto_learn 1 bayes_auto_learn_threshold_nonspam 1.0 bayes_auto_learn_threshold_spam 8.0 -- Die einen nennen es 'Zensur', die anderen 'regular expression'.
Re: X-Spam-Status does not appear in mail header
At 10:14 25-03-2008, Marianne Spiller wrote: I have a strange problem on my NetBSD-current box: I installed spamassassin from pkgsrc (V 3.2.3) and configured it in sendmail (INPUT_MAIL_FILTER(`spamassassin'...). [snip] But newly arrived mail gets never marked as spam; spamassassin[1] checks it, but the header rewrite is unusual: Mar 25 18:05:06 vinyl spamd[4661]: spamd: processing message [EMAIL PROTECTED] for me:1005 Mar 25 18:05:06 vinyl spamd[4661]: spamd: clean message (0.0/5.0) for me:1005 in 0.1 seconds, 4399 bytes. Mar 25 18:05:06 vinyl spamd[4661]: spamd: result: . 0 - scantime=0.1,size=4399,user=me,uid=1005,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=64556,mid=[EMAIL PROTECTED],autolearn=ham Mar 25 18:05:06 vinyl sm-mta[914]: m2PH54SR000914: Milter add: header: X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on myhost It's up to your milter to add the headers as you can see from the above. Huh? The only header is X-Spam-Checker-Version, but it does not write a X-Spam-Status or X-Spam-Level header to my messages as I can see in message source. Isn't that strange? Exactly the same setup worked fine under a Debian Xen domU... The rewrite_header Subject [:.SPAM.:] setting from the SpamAssassin configuration is only applicable if your milter reads the message body from spamd. Find out which milter is being used and whether it can be configured to add the headers you need. Regards, -sm
Re: X-Spam-Status does not appear in mail header
Hi, many thanks for your answer. Find out which milter is being used and whether it can be configured to add the headers you need. the milter I'm using is spamass-milter-0.3.1 from pkgsrc, too. I used it under Debian, and it did not need any further configuration. Regards, Marianne -- Die einen nennen es 'Zensur', die anderen 'regular expression'.
Re: X-Spam-Status does not appear in mail header
Hi Marianne, At 12:34 25-03-2008, Marianne Spiller wrote: the milter I'm using is spamass-milter-0.3.1 from pkgsrc, too. This milter can use the message body returned by spamd, including the rewritten headers. I used it under Debian, and it did not need any further configuration. The startup parameters may be different. Verify what spamass_milter_flags settings used in rc.conf to start the milter. Regards, -sm
Several messages a day are not getting scanned (no X-Spam-Status)
I have recently upgraded to SA3.2 (via ISPConfig) and have several users seeing messages come through without any SA processing. On my personal account, I see 2-5 messages a day which don't have a X-Spam-Status and are very obviously spam. SA is called through PROCMAIL and I have confirmed that the messages getting through aren't too big to get blocked by the PROCMAIL script. My thoughts are to write another procmail rule at the end to check for the X-Spam-Status header and if missing feed back into the SA rule. This seems like an unneeded hack, and I hope someone could point me at some other troubleshooting ideas. Thanks, Joe Esposito The Seagroatt Companies Albany, NY -- View this message in context: http://www.nabble.com/Several-messages-a-day-are-not-getting-scanned-%28no-X-Spam-Status%29-tf4030196.html#a11447911 Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Several messages a day are not getting scanned (no X-Spam-Status)
esposj schrieb: I have recently upgraded to SA3.2 (via ISPConfig) and have several users seeing messages come through without any SA processing. On my personal account, I see 2-5 messages a day which don't have a X-Spam-Status and are very obviously spam. SA is called through PROCMAIL and I have confirmed that the messages getting through aren't too big to get blocked by the PROCMAIL script. My thoughts are to write another procmail rule at the end to check for the X-Spam-Status header and if missing feed back into the SA rule. This seems like an unneeded hack, and I hope someone could point me at some other troubleshooting ideas. Thanks, Joe Esposito The Seagroatt Companies Albany, NY you might be using the to: field to determine who the mail is to and scan acording to that - thats not a safe way because it can be forged, use headers such as envelope-to or delivered-to as added by your mta to find out where a mail is really going arni
Re: Several messages a day are not getting scanned (no X-Spam-Status)
arni wrote: you might be using the to: field to determine who the mail is to and scan acording to that - thats not a safe way because it can be forged, use headers such as envelope-to or delivered-to as added by your mta to find out where a mail is really going arni Hi Arni: I'm not using the to field as far as I know. Here's the relevant part of the procmail script. -- :0fw * 256000 | /home/admispconfig/ispconfig/tools/spamassassin/usr/bin/spamassassin --prefs-file=/data/ispcpnfig/web1/user/fakename/.user_prefs -- All the spams getting through are 10k. -- View this message in context: http://www.nabble.com/Several-messages-a-day-are-not-getting-scanned-%28no-X-Spam-Status%29-tf4030196.html#a11448213 Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: X-Spam-Status: No, hits=? required=?
ip guy wrote: Hi all Anyone know why see X-Spam-Status: No, hits=? required=? in the email header after delivery and spam scanning ? My local.cf http://local.cf file looks like this required_score 8.0 report_safe 1 rewrite_header Subject *SPAM* Do you use spamc? Was the message larger than the -s parameter to spamc (default 500k)? If yes to both, then spamc skipped scanning the message because it was too large. There are some large spams out there, but there are relatively few of them. On the other hand, there are lots of large nonspam mails (attachments), and scanning large messages consumes a lot of CPU and memory. You can raise your -s to make spamc feed larger messages to spamd, but be aware that this comes at a price of increased resource usage, so choose a balance that fits your traffic load.
Re: X-Spam-Status: No, hits=? required=?
Maybe i wasn't clear. i guess it was the way i asked. Anyone know why I'd keep seeing this in the mail herders of email scanner for spam X-Spam-Status: No, hits=? required=? My setup currently uses spamc v2.40 on hostA to forward to spamd v3.1.8 on hostB My local.cf on hostB is setup with... required_hits 8.0 rewrite_header Subject *SPAM* It's only temporary setup until i can upgrade the primary MX on hostA On 5/15/07, Matt Kettler [EMAIL PROTECTED] wrote: ip guy wrote: Hi all Anyone know why see X-Spam-Status: No, hits=? required=? in the email header after delivery and spam scanning ? My local.cf http://local.cf file looks like this required_score 8.0 report_safe 1 rewrite_header Subject *SPAM* Do you use spamc? Was the message larger than the -s parameter to spamc (default 500k)? If yes to both, then spamc skipped scanning the message because it was too large. There are some large spams out there, but there are relatively few of them. On the other hand, there are lots of large nonspam mails (attachments), and scanning large messages consumes a lot of CPU and memory. You can raise your -s to make spamc feed larger messages to spamd, but be aware that this comes at a price of increased resource usage, so choose a balance that fits your traffic load.
Re: X-Spam-Status: No, hits=? required=?
On Wed, May 16, 2007 at 02:45:54PM +1000, ip guy wrote: Anyone know why I'd keep seeing this in the mail herders of email scanner for spam X-Spam-Status: No, hits=? required=? Whatever you have calling SA is adding markup. SA won't ever put in question marks. My guess is that it's timing out or something, but you'd have to figure that out. -- Randomly Selected Tagline: You will gain money by a speculation or lottery. pgp4mlq6ykfZt.pgp Description: PGP signature
