Re: FSL_HELO_BARE_IP_2 fires on wrong header
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 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 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
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 signature.asc Description: OpenPGP digital signature
Re: FSL_HELO_BARE_IP_2 fires on wrong header
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
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 signature.asc Description: OpenPGP digital signature
Re: FSL_HELO_BARE_IP_2 fires on wrong header
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
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 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 > 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
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 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 signature.asc Description: OpenPGP digital signature
Re: FSL_HELO_BARE_IP_2 fires on wrong header
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=gwat...@mail.gmail.com%3E On 1/26/16, Matus UHLAR - fantomas 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, 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. He who laughs last thinks slowest signature.asc Description: OpenPGP digital signature
Re: FSL_HELO_BARE_IP_2 fires on wrong header
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 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, 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. > He who laughs last thinks slowest. >
Re: FSL_HELO_BARE_IP_2 fires on wrong header
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 signature.asc Description: OpenPGP digital signature
Re: FSL_HELO_BARE_IP_2 fires on wrong header
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, 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. He who laughs last thinks slowest.
Re: FSL_HELO_BARE_IP_2 fires on wrong header
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 Ham2 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 signature.asc Description: OpenPGP digital signature
Re: FSL_HELO_BARE_IP_2 fires on wrong header
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 Ham2 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
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 3541.23 % 7.70 % (OF TOTAL BLOCKED) BAYES_80 3801.32 % 8.27 % (OF TOTAL BLOCKED) BAYES_95 3081.07 % 6.70 % (OF TOTAL BLOCKED) BAYES_99 3541 12.34 %77.11 % (OF TOTAL BLOCKED) BAYES_9993173 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 signature.asc Description: OpenPGP digital signature
Re: FSL_HELO_BARE_IP_2 fires on wrong header
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
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 signature.asc Description: OpenPGP digital signature
Re: FSL_HELO_BARE_IP_2 fires on wrong header
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
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
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 signature.asc Description: OpenPGP digital signature
Re: FSL_HELO_BARE_IP_2 fires on wrong header
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.
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 - Received: from unknown (HELO 46.137.93.51) (nore...@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 - signature.asc Description: OpenPGP digital signature
