FORGED_YAHOO_RCVD still causing false positives

[Sebastian Arcus <s....@open-t.co.uk>]

I see this has come up again and again. Since FORGED_YAHOO_RCVD seems to 
work by checking the address of the Yahoo smtp server in the headers 
against a predefined list of Yahoo servers in SA, and Yahoo seems to add 
new servers all the time - which causes false positives, is there much 
point to this check?

If not, maybe the default score should be lowered at least to something 
like 0.2 or 0.3 (I think is at 1.5 at the moment).

Re: FORGED_YAHOO_RCVD still causing false positives

[Dan Malm <da...@one.com>]

On 09/15/2017 02:26 PM, RW wrote:
> On Fri, 15 Sep 2017 11:50:25 +0100
> Sebastian Arcus wrote:
> 
>> I see this has come up again and again. Since FORGED_YAHOO_RCVD seems
>> to work by checking the address of the Yahoo smtp server in the
>> headers against a predefined list of Yahoo servers in SA, and Yahoo
>> seems to add new servers all the time - which causes false positives,
> 
> It's based on Yahoo received header formats, but they are liable to
> change.
> 
>> is there much point to this check?
> 
> The rule was created and scored when spoofing Yahoo was very common,
> but it isn't any more. I don't think it's worth keeping as it is - high
> maintenance and error prone.
> 

Since yahoo has DMARC with p=reject, just validating DMARC and rejecting
when it tells you to should make the FORGED_YAHOO_RCVD rule redundant.
I've had the score for that rule set to 0 for quite some time.

Re: FORGED_YAHOO_RCVD still causing false positives

[Sebastian Arcus <s....@open-t.co.uk>]

On 15/09/17 14:34, Kevin A. McGrail wrote:
> On 9/15/2017 8:26 AM, RW wrote:
>> The rule was created and scored when spoofing Yahoo was very common,
>> but it isn't any more. I don't think it's worth keeping as it is - high
>> maintenance and error prone.
> 
> Agreed.  Score FORGED_YAHOO_RCVD to zero locally and will get a bug open 
> to deprecate it.
> 
> Regards,
> 
> KAM

Much appreciated - thank you both!

Re: FORGED_YAHOO_RCVD still causing false positives

[Alex <my...@gmail.com>]

Hi,

On Fri, Sep 15, 2017 at 9:34 AM, Kevin A. McGrail
<ke...@mcgrail.com> wrote:
> On 9/15/2017 8:26 AM, RW wrote:
>>
>> The rule was created and scored when spoofing Yahoo was very common,
>> but it isn't any more. I don't think it's worth keeping as it is - high
>> maintenance and error prone.
>
>
> Agreed.  Score FORGED_YAHOO_RCVD to zero locally and will get a bug open to
> deprecate it.

This then invalidates KAM_GRABBAG5 and KAM_UAH_YAHOOGROUP_SENDER from KAM.cf.

Re: FORGED_YAHOO_RCVD still causing false positives

["Kevin A. McGrail" <ke...@mcgrail.com>]

On 9/15/2017 8:26 AM, RW wrote:
> The rule was created and scored when spoofing Yahoo was very common,
> but it isn't any more. I don't think it's worth keeping as it is - high
> maintenance and error prone.

Agreed.  Score FORGED_YAHOO_RCVD to zero locally and will get a bug open 
to deprecate it.

Regards,

KAM

Re: FORGED_YAHOO_RCVD still causing false positives

[RW <rw...@googlemail.com>]

On Fri, 15 Sep 2017 11:50:25 +0100
Sebastian Arcus wrote:

> I see this has come up again and again. Since FORGED_YAHOO_RCVD seems
> to work by checking the address of the Yahoo smtp server in the
> headers against a predefined list of Yahoo servers in SA, and Yahoo
> seems to add new servers all the time - which causes false positives,

It's based on Yahoo received header formats, but they are liable to
change.

> is there much point to this check?

The rule was created and scored when spoofing Yahoo was very common,
but it isn't any more. I don't think it's worth keeping as it is - high
maintenance and error prone.