You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Reindl Harald <h....@thelounge.net> on 2016/01/25 14:11:30 UTC
FSL_HELO_BARE_IP_2 fires on wrong header
there is *no point* on fire a rule on the third Received header when the
HELO is pretty clear "mail1.intellij.net" and matches PTR/A perfectly too
at least 1.5 points is unacceptable for (in general questionable) deep
header inspection
score FSL_HELO_BARE_IP_2 1.998 1.593 1.998 1.593
Received: from mail1.intellij.net (mail1.intellij.net [46.137.178.215])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client
certificate requested) by *** (***) with ESMTPS id 3ppptY4tHlz2wbP for
<***>; Mon, 25 Jan 2016 12:31:33 +0100 (CET)
Received: (qmail 22713 invoked by uid 89); 25 Jan 2016 11:31:31 -0000
Received: from unknown (HELO 46.137.93.51)
(noreply@jetbrains.com@46.137.93.51) by
ip-10-79-47-171.eu-west-1.compute.internal with ESMTPA; 25 Jan 2016
11:31:31 -0000
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.01.2016 um 15:43 schrieb RW:
> On Mon, 25 Jan 2016 15:17:38 +0100
> Reindl Harald wrote:
> one time for the PTR
>>>
>>> Not worth an argument - masschecker set the score based on spam
>>> corpus
>>>
>>> lower the score and have a nice day
>>
>> not worth an argument when it's simply wrong and hits mostly clear
>> ham and is broken by definition looking at *random* headers?
>>
>> cat maillog | grep FSL_HELO_BARE_IP_2 | grep "result: Y" | wc -l
>> 21
>>
>> cat maillog | grep FSL_HELO_BARE_IP_2 | wc -l
>> 130
>>
>> cat maillog | grep FSL_HELO_BARE_IP_2 | grep BAYES_00 | wc -l
>> 93
>
> My numbers are:
>
> Spam 700 out of 3550
> Ham 2 out of 2423 (both from the same person using phpmailer 5.2.2)
>
> You might want to have a look at some of these hits and see if there is
> a pattern to them
i have no access to ham-mails of users (technically and by law) since
it's only a gateway handover non-rejected mail to the final hops
but i am pretty sure BAYES_00 messages with no URIBL/DNSBL hist are not
spam in this setup without complaints
the mail because of which i stared the thread was a ham-sample from a
sysadmin to train it as ham for the shared bayes because it did only hit
BAYES_20 instead of BAYES_00
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by RW <rw...@googlemail.com>.
On Mon, 25 Jan 2016 15:17:38 +0100
Reindl Harald wrote:
one time for the PTR
> >
> > Not worth an argument - masschecker set the score based on spam
> > corpus
> >
> > lower the score and have a nice day
>
> not worth an argument when it's simply wrong and hits mostly clear
> ham and is broken by definition looking at *random* headers?
>
> cat maillog | grep FSL_HELO_BARE_IP_2 | grep "result: Y" | wc -l
> 21
>
> cat maillog | grep FSL_HELO_BARE_IP_2 | wc -l
> 130
>
> cat maillog | grep FSL_HELO_BARE_IP_2 | grep BAYES_00 | wc -l
> 93
My numbers are:
Spam 700 out of 3550
Ham 2 out of 2423 (both from the same person using phpmailer 5.2.2)
You might want to have a look at some of these hits and see if there is
a pattern to them.
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.01.2016 um 15:25 schrieb Axb:
> On 01/25/2016 03:17 PM, Reindl Harald wrote:
>> masschecker is not worth an argument in 2016:
>> 02-Jan-2016 00:22:49: SpamAssassin: No update available
>> 03-Jan-2016 00:32:25: SpamAssassin: No update available
>> 04-Jan-2016 00:03:32: SpamAssassin: No update available
>> 05-Jan-2016 01:45:11: SpamAssassin: No update available
>> 06-Jan-2016 01:28:29: SpamAssassin: No update available
>
> I don't find your masscheck contribution in the logs...
you simply would not want my anonymized and header stripped samples
contribute to the masscheck
your typical reaction if someone points out a potential problem "why
don't you do and no i don't see something problematic", nothing new.........
if it would be only about you i could just disable rules or score them
different and be done, consider that i care also about other users which
are not you
> You are aware that you can run your own personal local score generation
> process based on your corpus, right?
> All the code is available in SVN
i don't need it and it won't work with anonymized and stripped samples
and they do their job pretty well (yes i know that you don#t care about
bayes)
BAYES_60 354 1.23 % 7.70 % (OF TOTAL BLOCKED)
BAYES_80 380 1.32 % 8.27 % (OF TOTAL BLOCKED)
BAYES_95 308 1.07 % 6.70 % (OF TOTAL BLOCKED)
BAYES_99 3541 12.34 % 77.11 % (OF TOTAL BLOCKED)
BAYES_999 3173 11.05 % 69.09 % (OF TOTAL BLOCKED)
SPAMMY 4583 10.21 % 99.80 % (OF TOTAL BLOCKED)
i just find it amusing that you come up with "there is no problem,
masscheck will fix that" while you *know* that masscheck don't fix
anything currently
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Axb <ax...@gmail.com>.
On 01/25/2016 03:17 PM, Reindl Harald wrote:
> masschecker is not worth an argument in 2016:
> 02-Jan-2016 00:22:49: SpamAssassin: No update available
> 03-Jan-2016 00:32:25: SpamAssassin: No update available
> 04-Jan-2016 00:03:32: SpamAssassin: No update available
> 05-Jan-2016 01:45:11: SpamAssassin: No update available
> 06-Jan-2016 01:28:29: SpamAssassin: No update available
> 07-Jan-2016 00:36:53: SpamAssassin: No update available
> 08-Jan-2016 01:28:56: SpamAssassin: No update available
> 09-Jan-2016 00:56:22: SpamAssassin: No update available
> 10-Jan-2016 00:47:09: SpamAssassin: No update available
> 11-Jan-2016 00:31:39: SpamAssassin: No update available
> 12-Jan-2016 01:14:41: SpamAssassin: No update available
> 13-Jan-2016 00:39:28: SpamAssassin: No update available
> 14-Jan-2016 00:14:53: SpamAssassin: No update available
> 15-Jan-2016 01:15:31: SpamAssassin: No update available
> 16-Jan-2016 00:30:26: SpamAssassin: No update available
> 17-Jan-2016 01:21:19: SpamAssassin: No update available
> 18-Jan-2016 00:51:34: SpamAssassin: No update available
> 19-Jan-2016 01:38:51: SpamAssassin: No update available
> 20-Jan-2016 00:51:39: SpamAssassin: No update available
> 21-Jan-2016 00:56:00: SpamAssassin: No update available
> 22-Jan-2016 01:33:51: SpamAssassin: No update available
> 23-Jan-2016 01:32:07: SpamAssassin: No update available
> 24-Jan-2016 00:00:21: SpamAssassin: No update available
> 25-Jan-2016 00:22:38: SpamAssassin: No update available
I don't find your masscheck contribution in the logs...
You are aware that you can run your own personal local score generation
process based on your corpus, right?
All the code is available in SVN.
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by John Hardin <jh...@impsec.org>.
On Tue, 26 Jan 2016, Tom Hendrikx wrote:
> However the main cause for FPs seems to me internal mail (reporting
> scripts sending mail to sysadmin or BI people) which is semi-whitelisted
> anyway.
That should only happen if their SA is misconfigured: it checks *external*
relays.
Regardless, I've reduced the max score to 1.5 and tweaked the FP exclusion
a little; see also https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7292
Here's hoping the masscheck corpora sustain scorable levels for the next
week.
FP examples solicited.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
The world has enough Mouse Clicking System Engineers.
-- Dave Pooser
-----------------------------------------------------------------------
Tomorrow: Wolfgang Amadeus Mozart's 260th Birthday
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Reindl Harald <h....@thelounge.net>.
Am 26.01.2016 um 11:20 schrieb Tom Hendrikx:
> If you can't investigate, you either need to put your trust in bayes to
> compensate, or just drop the score. Whining because the rule does not
> match *your* type of mail does not make sense
it is not *my type of mail*
it's the type of mail of different customers from different senders and
the same on the setup of a friendly sysadmin for his *different*
customers where it also hits more ham than spam
we both don't waste our and the time of our customers with investigate
it while a sane rule doing deep header scans (which is *always*
dangerous) could just have a lower maximum score to never reach 1.5
my first job as sysadmin is to make sure mail get delivered and *after
that* filter out spam comes not the other direction
so anybody here: do what you want, i lowered the score for damned good
reasons and don't care about your false positives or not
why i waste my time to point out problematic defaults instead just
change the values local and be done which will happen in the future when
each and every time a big discussion starts telling me what i have to do
or not
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Tom Hendrikx <to...@whyscream.net>.
On 26-01-16 10:33, Reindl Harald wrote:
>
>
> Am 26.01.2016 um 09:45 schrieb Tom Hendrikx:
>> On 25-01-16 16:38, Reindl Harald wrote:
>>>
>>> Am 25.01.2016 um 16:22 schrieb Matus UHLAR - fantomas:
>>>> On 25.01.16 15:17, Reindl Harald wrote:
>>>>> not worth an argument when it's simply wrong and hits mostly clear ham
>>>>> and is broken by definition looking at *random* headers?
>>>>>
>>>>> cat maillog | grep FSL_HELO_BARE_IP_2 | grep "result: Y" | wc -l
>>>>> 21
>>>>>
>>>>> cat maillog | grep FSL_HELO_BARE_IP_2 | wc -l
>>>>> 130
>>>>>
>>>>> cat maillog | grep FSL_HELO_BARE_IP_2 | grep BAYES_00 | wc -l
>>>>> 93
>>>>
>>>> excuse me, did you get a FP?
>>>> Together with BAYES_00?
>>>
>>> excuse but the point of a rule hit is not "did it end in a complete FP"
>>> but "if the rule bahvior is reasonable and hits more spam than ham"
>>>
>>> yet talked with another sysadmin
>>>
>>> same numbers, all spam-hits between 10-36, so without the rule a sure
>>> mitler-reject and most hits where clear ham, a few only rescued with
>>> BAYES_00 and otherwise tagged
>>
>> The way this rule works, sounds to me like it catches a lot of crappy
>> mailers that send through a legitimate relay. I've also seen issues with
>> this and its score is lowered to 0.001 @here too.
>
> i would not call 21 in 26 days "a lot" given they would have been
> rejected anyways but i call 93 wong hits a lot
>
> when only 5 of them would become a real FP because no bayes rescue them
> hell goes on for support calls when it hits registration confirmations
> and like mails which are often driven by phpmailer
>
>> However the main cause for FPs seems to me internal mail (reporting
>> scripts sending mail to sysadmin or BI people) which is semi-whitelisted
>> anyway. This means it only hurts when the client is not able to
>> whitelist (maybe even before mail hits SA).
>
> depends on your number of users / domains
>
>> @Reindl: maybe you could check with your client(s) what type of mail it
>> is? Especially if you see the hits popping at regular (cron-like)
>> intervals. And then inform them that their phpmailer (or whatever crap
>> mailer they use) could need an upgrade.
>
> as mailprovider you are not in the position to educate your customers
> how they have to educate anybody who is sending them email - that don't
> scale and is not your job when you are responsible for incoming mail
> which includes minimize false positives
But you do need to investigate anomalies in the mail setup. If you don't
trust the rule, you need to see why it's triggered on ham mail. I had
the opportunity to work with a few friendly customers in order to do
these kind of things. Maybe you can improve the rule based on your
findings. Or add some meta rules with other non-spam signs (see below).
If you can't investigate, you either need to put your trust in bayes to
compensate, or just drop the score. Whining because the rule does not
match *your* type of mail does not make sense.
In another case, I had a large group of customers being hit by mail from
a legit freemail company whose webmail generated really crappy HTML
messages. The rules triggered (MPART_ALT_DIFF, MIME_HTML_ONLY,
HTML_MIME_NO_HTML_TAG, etc) set the baseline for all webmail generated
messages somewhere at 3.x, putting a lot of legit mail into quarantine
when other rules added up. In the end, I meta'd a lot of stuff in order
to compensate for this webmailer (names and scores made up):
header __CRAPPY_ENVELOPE Return-Path:addr =~ /\@crappy\.tld$/i
meta __FROM_CRAPPY (SPF_PASS && __RETURNPATH_CRAPPY)
# (above check uses more msg features but you get the idea)
meta CRAPPY_COMPENSATE_MPART_ALT_DIFF (__FROM_CRAPPY && MPART_ALT_DIFF)
score CRAPPY_COMPENSATE_MPART_ALT_DIFF -0.7
In order to do this kind of stuff, you need to be able to inspect the
messages.
>
>> In any way, it would be interesting to see what type of ham mail
>> triggers such a rule when masscheck allows such a high score, before
>> starting an argument about it
>
> the mail reported to me was some board-notification of a website
>
> have fun to educate your customers how they have to educate random
> website owners where they receive mail from
>
I didn't educate, I adapted the score after I looked at the specific FP
messages. Or meta'd to compensate the FPs. The board notifications sound
like a good candidate for the latter.
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Reindl Harald <h....@thelounge.net>.
Am 26.01.2016 um 09:45 schrieb Tom Hendrikx:
> On 25-01-16 16:38, Reindl Harald wrote:
>>
>> Am 25.01.2016 um 16:22 schrieb Matus UHLAR - fantomas:
>>> On 25.01.16 15:17, Reindl Harald wrote:
>>>> not worth an argument when it's simply wrong and hits mostly clear ham
>>>> and is broken by definition looking at *random* headers?
>>>>
>>>> cat maillog | grep FSL_HELO_BARE_IP_2 | grep "result: Y" | wc -l
>>>> 21
>>>>
>>>> cat maillog | grep FSL_HELO_BARE_IP_2 | wc -l
>>>> 130
>>>>
>>>> cat maillog | grep FSL_HELO_BARE_IP_2 | grep BAYES_00 | wc -l
>>>> 93
>>>
>>> excuse me, did you get a FP?
>>> Together with BAYES_00?
>>
>> excuse but the point of a rule hit is not "did it end in a complete FP"
>> but "if the rule bahvior is reasonable and hits more spam than ham"
>>
>> yet talked with another sysadmin
>>
>> same numbers, all spam-hits between 10-36, so without the rule a sure
>> mitler-reject and most hits where clear ham, a few only rescued with
>> BAYES_00 and otherwise tagged
>
> The way this rule works, sounds to me like it catches a lot of crappy
> mailers that send through a legitimate relay. I've also seen issues with
> this and its score is lowered to 0.001 @here too.
i would not call 21 in 26 days "a lot" given they would have been
rejected anyways but i call 93 wong hits a lot
when only 5 of them would become a real FP because no bayes rescue them
hell goes on for support calls when it hits registration confirmations
and like mails which are often driven by phpmailer
> However the main cause for FPs seems to me internal mail (reporting
> scripts sending mail to sysadmin or BI people) which is semi-whitelisted
> anyway. This means it only hurts when the client is not able to
> whitelist (maybe even before mail hits SA).
depends on your number of users / domains
> @Reindl: maybe you could check with your client(s) what type of mail it
> is? Especially if you see the hits popping at regular (cron-like)
> intervals. And then inform them that their phpmailer (or whatever crap
> mailer they use) could need an upgrade.
as mailprovider you are not in the position to educate your customers
how they have to educate anybody who is sending them email - that don't
scale and is not your job when you are responsible for incoming mail
which includes minimize false positives
> In any way, it would be interesting to see what type of ham mail
> triggers such a rule when masscheck allows such a high score, before
> starting an argument about it
the mail reported to me was some board-notification of a website
have fun to educate your customers how they have to educate random
website owners where they receive mail from
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Tom Hendrikx <to...@whyscream.net>.
On 25-01-16 16:38, Reindl Harald wrote:
>
> Am 25.01.2016 um 16:22 schrieb Matus UHLAR - fantomas:
>> On 25.01.16 15:17, Reindl Harald wrote:
>>> not worth an argument when it's simply wrong and hits mostly clear ham
>>> and is broken by definition looking at *random* headers?
>>>
>>> cat maillog | grep FSL_HELO_BARE_IP_2 | grep "result: Y" | wc -l
>>> 21
>>>
>>> cat maillog | grep FSL_HELO_BARE_IP_2 | wc -l
>>> 130
>>>
>>> cat maillog | grep FSL_HELO_BARE_IP_2 | grep BAYES_00 | wc -l
>>> 93
>>
>> excuse me, did you get a FP?
>> Together with BAYES_00?
>
> excuse but the point of a rule hit is not "did it end in a complete FP"
> but "if the rule bahvior is reasonable and hits more spam than ham"
>
> yet talked with another sysadmin
>
> same numbers, all spam-hits between 10-36, so without the rule a sure
> mitler-reject and most hits where clear ham, a few only rescued with
> BAYES_00 and otherwise tagged
>
The way this rule works, sounds to me like it catches a lot of crappy
mailers that send through a legitimate relay. I've also seen issues with
this and its score is lowered to 0.001 @here too.
However the main cause for FPs seems to me internal mail (reporting
scripts sending mail to sysadmin or BI people) which is semi-whitelisted
anyway. This means it only hurts when the client is not able to
whitelist (maybe even before mail hits SA).
@Reindl: maybe you could check with your client(s) what type of mail it
is? Especially if you see the hits popping at regular (cron-like)
intervals. And then inform them that their phpmailer (or whatever crap
mailer they use) could need an upgrade.
In any way, it would be interesting to see what type of ham mail
triggers such a rule when masscheck allows such a high score, before
starting an argument about it.
Regards,
Tom
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.01.2016 um 16:22 schrieb Matus UHLAR - fantomas:
> On 25.01.16 15:17, Reindl Harald wrote:
>> not worth an argument when it's simply wrong and hits mostly clear ham
>> and is broken by definition looking at *random* headers?
>>
>> cat maillog | grep FSL_HELO_BARE_IP_2 | grep "result: Y" | wc -l
>> 21
>>
>> cat maillog | grep FSL_HELO_BARE_IP_2 | wc -l
>> 130
>>
>> cat maillog | grep FSL_HELO_BARE_IP_2 | grep BAYES_00 | wc -l
>> 93
>
> excuse me, did you get a FP?
> Together with BAYES_00?
excuse but the point of a rule hit is not "did it end in a complete FP"
but "if the rule bahvior is reasonable and hits more spam than ham"
yet talked with another sysadmin
same numbers, all spam-hits between 10-36, so without the rule a sure
mitler-reject and most hits where clear ham, a few only rescued with
BAYES_00 and otherwise tagged
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Nick Edwards <ni...@gmail.com>.
proven wrong my arse, like everything "proven wrong according to
reindl" means SFA and does NOT make it wrong just because YOU think it
is wrong. I think its right, other members of this list think its
right and the SA devies think its right, live with it, you were
already told what to do to over come if it YOU disagree with it,
acting like a 2yo baby going wah wah wah rolling over the floor temper
tamping to try get his own way will NOT work.
On 1/26/16, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 25.01.2016 um 23:45 schrieb Nick Edwards:
>> Just look at the energy he's spent whining about it -V- the energy he
>> could have spent to lower/zero the score
>
> what happened long ago but a local workaround makes proven wrong
> behavior not right - see below....
>
> i run likely the most customized SA on this planet
>
> -rw-r--r-- 1 root root 80K 2016-01-25 20:24 local-00-bayes-ignore.cf
> -rw-r--r-- 1 root root 3,0K 2016-01-25 13:39 local-01-unister.cf
> -rw-r--r-- 1 root root 1,2K 2015-09-13 07:47 local-02-blocked-tld.cf
> -rw-r--r-- 1 root root 111K 2016-01-25 20:36 local.cf
>
> -------- Weitergeleitete Nachricht --------
> Betreff: Re: FSL_HELO_BARE_IP_2 fires on wrong header
> Datum: Mon, 25 Jan 2016 15:17:38 +0100
> Von: Reindl Harald <h....@thelounge.net>
> An: users@spamassassin.apache.org
>
> ---------------------------------------------------------------------
> > score FSL_HELO_BARE_IP_1 0.1
> > score FSL_HELO_BARE_IP_2 0.1
> ---------------------------------------------------------------------
>
> OK: /usr/bin/systemctl reload spamassassin.service
>
>
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.01.2016 um 23:45 schrieb Nick Edwards:
> Just look at the energy he's spent whining about it -V- the energy he
> could have spent to lower/zero the score
what happened long ago but a local workaround makes proven wrong
behavior not right - see below....
i run likely the most customized SA on this planet
-rw-r--r-- 1 root root 80K 2016-01-25 20:24 local-00-bayes-ignore.cf
-rw-r--r-- 1 root root 3,0K 2016-01-25 13:39 local-01-unister.cf
-rw-r--r-- 1 root root 1,2K 2015-09-13 07:47 local-02-blocked-tld.cf
-rw-r--r-- 1 root root 111K 2016-01-25 20:36 local.cf
-------- Weitergeleitete Nachricht --------
Betreff: Re: FSL_HELO_BARE_IP_2 fires on wrong header
Datum: Mon, 25 Jan 2016 15:17:38 +0100
Von: Reindl Harald <h....@thelounge.net>
An: users@spamassassin.apache.org
---------------------------------------------------------------------
> score FSL_HELO_BARE_IP_1 0.1
> score FSL_HELO_BARE_IP_2 0.1
---------------------------------------------------------------------
OK: /usr/bin/systemctl reload spamassassin.service
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.01.2016 um 23:45 schrieb Nick Edwards:
> just ignore reindl, most the world does (on the few lists he's not
> been booted off - yet), because its his way or the wrong way - in his
> eyes only of course, and history shows your wasting your time trying
> to explain to him thats not how the world works, no-one is here to
> make it work according to his-way.
>
> Just look at the energy he's spent whining about it -V- the energy he
> could have spent to lower/zero the score
i can't remember that anybody asked you
http://www.gossamer-threads.com/lists/spamassassin/users/189665
http://mail-archives.apache.org/mod_mbox/spamassassin-users/201411.mbox/%3CCAMD-=VLKStiPb_6NCn5EY7sNhJO7eAKE9dPpUEffHhH9xM_w=A@mail.gmail.com%3E
http://mail-archives.apache.org/mod_mbox/spamassassin-users/201410.mbox/%3CCAMD-=VJprfqO-g5M4hQiva5wwHONYqrS+EtGES-+KF=GwATtKg@mail.gmail.com%3E
> On 1/26/16, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>> On 25.01.16 15:17, Reindl Harald wrote:
>>> not worth an argument when it's simply wrong and hits mostly clear
>>> ham and is broken by definition looking at *random* headers?
>>>
>>> cat maillog | grep FSL_HELO_BARE_IP_2 | grep "result: Y" | wc -l
>>> 21
>>>
>>> cat maillog | grep FSL_HELO_BARE_IP_2 | wc -l
>>> 130
>>>
>>> cat maillog | grep FSL_HELO_BARE_IP_2 | grep BAYES_00 | wc -l
>>> 93
>>
>> excuse me, did you get a FP?
>> Together with BAYES_00?
>>
>> --
>> Matus UHLAR - fantomas, uhlar@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.
>> He who laughs last thinks slowest
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Nick Edwards <ni...@gmail.com>.
just ignore reindl, most the world does (on the few lists he's not
been booted off - yet), because its his way or the wrong way - in his
eyes only of course, and history shows your wasting your time trying
to explain to him thats not how the world works, no-one is here to
make it work according to his-way.
Just look at the energy he's spent whining about it -V- the energy he
could have spent to lower/zero the score
On 1/26/16, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
> On 25.01.16 15:17, Reindl Harald wrote:
>>not worth an argument when it's simply wrong and hits mostly clear
>>ham and is broken by definition looking at *random* headers?
>>
>>cat maillog | grep FSL_HELO_BARE_IP_2 | grep "result: Y" | wc -l
>>21
>>
>>cat maillog | grep FSL_HELO_BARE_IP_2 | wc -l
>>130
>>
>>cat maillog | grep FSL_HELO_BARE_IP_2 | grep BAYES_00 | wc -l
>>93
>
> excuse me, did you get a FP?
> Together with BAYES_00?
>
> --
> Matus UHLAR - fantomas, uhlar@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.
> He who laughs last thinks slowest.
>
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 25.01.16 15:17, Reindl Harald wrote:
>not worth an argument when it's simply wrong and hits mostly clear
>ham and is broken by definition looking at *random* headers?
>
>cat maillog | grep FSL_HELO_BARE_IP_2 | grep "result: Y" | wc -l
>21
>
>cat maillog | grep FSL_HELO_BARE_IP_2 | wc -l
>130
>
>cat maillog | grep FSL_HELO_BARE_IP_2 | grep BAYES_00 | wc -l
>93
excuse me, did you get a FP?
Together with BAYES_00?
--
Matus UHLAR - fantomas, uhlar@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.
He who laughs last thinks slowest.
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.01.2016 um 15:07 schrieb Axb:
> On 01/25/2016 03:01 PM, Reindl Harald wrote:
>> Am 25.01.2016 um 14:41 schrieb RW:
>>> On Mon, 25 Jan 2016 14:11:30 +0100
>>> Reindl Harald wrote:
>>>
>>>> there is *no point* on fire a rule on the third Received header when
>>>> the HELO is pretty clear "mail1.intellij.net" and matches PTR/A
>>>> perfectly too
>>>
>>> Of course there's a point. It's intended to detect spam software that's
>>> relaying through a real MTA - typically someone else's.
>>
>> no there is no point
>>
>> "Received: from unknown (HELO 46.137.93.51) with ESMTPA" is the MTA
>> client (the A is for Authenticated = SASL)
>>
>>>> at least 1.5 points is unacceptable for (in general questionable)
>>>> deep header inspection
>>>
>>> It works well for me, if you don't like it rescore it
>> it would work well if it only checks the own received header
>>
>> Received: from mail1.intellij.net (mail1.intellij.net [46.137.178.215])
>> "mail1.intellij.net" is one time for the HELO and one time for the PTR
>
> Not worth an argument - masschecker set the score based on spam corpus
>
> lower the score and have a nice day
not worth an argument when it's simply wrong and hits mostly clear ham
and is broken by definition looking at *random* headers?
cat maillog | grep FSL_HELO_BARE_IP_2 | grep "result: Y" | wc -l
21
cat maillog | grep FSL_HELO_BARE_IP_2 | wc -l
130
cat maillog | grep FSL_HELO_BARE_IP_2 | grep BAYES_00 | wc -l
93
masschecker is not worth an argument in 2016:
02-Jan-2016 00:22:49: SpamAssassin: No update available
03-Jan-2016 00:32:25: SpamAssassin: No update available
04-Jan-2016 00:03:32: SpamAssassin: No update available
05-Jan-2016 01:45:11: SpamAssassin: No update available
06-Jan-2016 01:28:29: SpamAssassin: No update available
07-Jan-2016 00:36:53: SpamAssassin: No update available
08-Jan-2016 01:28:56: SpamAssassin: No update available
09-Jan-2016 00:56:22: SpamAssassin: No update available
10-Jan-2016 00:47:09: SpamAssassin: No update available
11-Jan-2016 00:31:39: SpamAssassin: No update available
12-Jan-2016 01:14:41: SpamAssassin: No update available
13-Jan-2016 00:39:28: SpamAssassin: No update available
14-Jan-2016 00:14:53: SpamAssassin: No update available
15-Jan-2016 01:15:31: SpamAssassin: No update available
16-Jan-2016 00:30:26: SpamAssassin: No update available
17-Jan-2016 01:21:19: SpamAssassin: No update available
18-Jan-2016 00:51:34: SpamAssassin: No update available
19-Jan-2016 01:38:51: SpamAssassin: No update available
20-Jan-2016 00:51:39: SpamAssassin: No update available
21-Jan-2016 00:56:00: SpamAssassin: No update available
22-Jan-2016 01:33:51: SpamAssassin: No update available
23-Jan-2016 01:32:07: SpamAssassin: No update available
24-Jan-2016 00:00:21: SpamAssassin: No update available
25-Jan-2016 00:22:38: SpamAssassin: No update available
---------------------------------------------------------------------
> score FSL_HELO_BARE_IP_1 0.1
> score FSL_HELO_BARE_IP_2 0.1
---------------------------------------------------------------------
OK: /usr/bin/systemctl reload spamassassin.service
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Axb <ax...@gmail.com>.
On 01/25/2016 03:01 PM, Reindl Harald wrote:
>
>
> Am 25.01.2016 um 14:41 schrieb RW:
>> On Mon, 25 Jan 2016 14:11:30 +0100
>> Reindl Harald wrote:
>>
>>> there is *no point* on fire a rule on the third Received header when
>>> the HELO is pretty clear "mail1.intellij.net" and matches PTR/A
>>> perfectly too
>>
>> Of course there's a point. It's intended to detect spam software that's
>> relaying through a real MTA - typically someone else's.
>
> no there is no point
>
> "Received: from unknown (HELO 46.137.93.51) with ESMTPA" is the MTA
> client (the A is for Authenticated = SASL)
>
>>> at least 1.5 points is unacceptable for (in general questionable)
>>> deep header inspection
>>
>> It works well for me, if you don't like it rescore it
> it would work well if it only checks the own received header
>
> Received: from mail1.intellij.net (mail1.intellij.net [46.137.178.215])
> "mail1.intellij.net" is one time for the HELO and one time for the PTR
>
Not worth an argument - masschecker set the score based on spam corpus
lower the score and have a nice day.
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by RW <rw...@googlemail.com>.
On Mon, 25 Jan 2016 15:01:29 +0100
Reindl Harald wrote:
> Am 25.01.2016 um 14:41 schrieb RW:
> > On Mon, 25 Jan 2016 14:11:30 +0100
> > Reindl Harald wrote:
> >
> >> there is *no point* on fire a rule on the third Received header
> >> when the HELO is pretty clear "mail1.intellij.net" and matches
> >> PTR/A perfectly too
> >
> > Of course there's a point. It's intended to detect spam software
> > that's relaying through a real MTA - typically someone else's.
>
> no there is no point
>
> "Received: from unknown (HELO 46.137.93.51) with ESMTPA" is the MTA
> client (the A is for Authenticated = SASL)
It's not looking for an IP address, it's looking for a bare IP address
which is an RFC violation. An MUA would have got it right, so the ESMTPA
mean little in this case.
> >> at least 1.5 points is unacceptable for (in general questionable)
> >> deep header inspection
> >
> > It works well for me, if you don't like it rescore it
> it would work well if it only checks the own received header
>
> Received: from mail1.intellij.net (mail1.intellij.net
> [46.137.178.215]) "mail1.intellij.net" is one time for the HELO and
> one time for the PTR
That's what FSL_HELO_BARE_IP_1 is for. It has a much higher score.
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.01.2016 um 14:41 schrieb RW:
> On Mon, 25 Jan 2016 14:11:30 +0100
> Reindl Harald wrote:
>
>> there is *no point* on fire a rule on the third Received header when
>> the HELO is pretty clear "mail1.intellij.net" and matches PTR/A
>> perfectly too
>
> Of course there's a point. It's intended to detect spam software that's
> relaying through a real MTA - typically someone else's.
no there is no point
"Received: from unknown (HELO 46.137.93.51) with ESMTPA" is the MTA
client (the A is for Authenticated = SASL)
>> at least 1.5 points is unacceptable for (in general questionable)
>> deep header inspection
>
> It works well for me, if you don't like it rescore it
it would work well if it only checks the own received header
Received: from mail1.intellij.net (mail1.intellij.net [46.137.178.215])
"mail1.intellij.net" is one time for the HELO and one time for the PTR
Re: FSL_HELO_BARE_IP_2 fires on wrong header
Posted by RW <rw...@googlemail.com>.
On Mon, 25 Jan 2016 14:11:30 +0100
Reindl Harald wrote:
> there is *no point* on fire a rule on the third Received header when
> the HELO is pretty clear "mail1.intellij.net" and matches PTR/A
> perfectly too
Of course there's a point. It's intended to detect spam software that's
relaying through a real MTA - typically someone else's.
> at least 1.5 points is unacceptable for (in general questionable)
> deep header inspection
It works well for me, if you don't like it rescore it.