spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hendrikx <...@whyscream.net>
Subject Re: FSL_HELO_BARE_IP_2 fires on wrong header
Date Tue, 26 Jan 2016 10:20:32 GMT


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.

Mime
View raw message