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 > 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"
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 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;i>=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 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"
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 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"
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;i>=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 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;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
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
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
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= to= proto=ESMTP helo= 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=, 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=, 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= to= proto=ESMTP helo= Aug 29 02:09:44 mail-gw postfix/cleanup[24086]: 3hkh540hvnz1w: message-id= Aug 29 02:09:44 mail-gw spamd[24069]: spamd: processing message for sa-milt:189 Aug 29 02:09:44 mail-gw spamd[24069]: spamd: identified spam (5.1/5.0) for sa-milt:189 in 0.3 seconds, 4784 bytes. Aug 29 02:09:44 mail-gw spamd[24069]: spamd: result: Y 5 - ADVANCE_FEE_4_NEW,ADVANCE_F
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;i>=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 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;i>=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 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"
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
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;i>=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 42
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;i>=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 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;i>=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 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 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: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 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: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: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 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 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
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
