Bug 5561 - FORGED_YAHOO_RCVD false positive
Summary: FORGED_YAHOO_RCVD false positive
Status: RESOLVED INVALID
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (Eval Tests) (show other bugs)
Version: 3.0.0
Hardware: All All
: P4 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-16 08:17 UTC by Adam Jenkins
Modified: 2018-01-18 00:14 UTC (History)
7 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Jenkins 2007-07-16 08:17:11 UTC
I've received several legit emails sent via servers web12345.mail.re2.yahoo.com
not just the (normal?) web12345.mail.yahoo.com servers.

Adding a line to EvalTests.pm like
if ($rcvd =~ /by web\S+\.mail\.re2\.yahoo\.com via HTTP/) { return 0; }
has fixed that problem for me, and those emails now seem to be given a more
accurate score.

NB: I can only confirm this with 3.0.0 under OpenBSD but I had a quick look at
the source for 3.2.1 and I am fairly sure the issue hasn't been resolved in
3.2.1, and clearly this issue is not dependent on platform/OS.  I'd be
interested in seeing if others are having similar issues with yahoo.com servers
so we can make the rule as useful as possible.
Comment 1 bugs 2013-05-14 07:48:05 UTC
I have the same problems with version 3.3.2:

Received: from nm1-vm0.bullet.mail.ird.yahoo.com ([77.238.189.95]:22958)
	by example.com with [XMail 1.27 SSLtag ESMTP Server] ()
	id <S8BFA8> for <XXXXXX@example.com> from <XXXXXXX@yahoo.com>;
	Tue, 14 May 2013 09:14:19 +0200

triggers FORGED_YAHOO_RCVD. 77.238.189.95 belongs to 77.238.188.0/23 which is obviously a YAHOONET

In my opinion, finding forged yahoo mails with regex isn't the right solution, if yahoo often changes the name conventions for his servers.

A DNS-Solution/WHOIS-Solution would be a better choice.
Comment 2 Dan Malm 2016-01-13 14:34:27 UTC
Received: from [216.39.60.181] by nm26.bullet.mail.gq1.yahoo.com with NNFMP; 16 Nov 2015 15:15:03 -0000
Received: from [98.137.12.219] by tm17.bullet.mail.gq1.yahoo.com with NNFMP; 16 Nov 2015 15:15:03 -0000
Received: from [127.0.0.1] by omp1027.mail.gq1.yahoo.com with NNFMP; 16 Nov 2015 15:15:03 -0000

A mail with these Received-headers also trigger FORGED_YAHOO_RCVD in 3.4.1
Comment 3 Kevin A. McGrail 2016-01-13 15:27:37 UTC
Well nnfmp is an internal Yahoo! Protocol.  Is it hitting dkim or spf validation?
Comment 4 Dan Malm 2016-01-15 13:36:05 UTC
It passes SPF, DKIM and DMARC, no problems. Now the data from all reports I've received all seem to be from yahoo delivery status notification so those headers might not be relevant as they're only the "orignal headers" shown in the DSN... The "received" headers that triggers the rule might only appear once the mail reaches our servers... So I'm gonna see if I can grab some more relevant headers somewhere or if I can reproduce the issue myself. But quite a lot of mails seems to trigger this rule , and most do come from yahoo IPs and pass the SPF, DKIM and DMARC checks.
Comment 5 nomen nescio 2017-06-06 09:17:50 UTC
Mails with the following (and similar) received headers also falsely triggered FORGED_YAHOO_RCVD:

Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Fri, 2 Jun 2017 11:11:30 +0000

The following patch fixed the issue:

Index: lib/Mail/SpamAssassin/Plugin/HeaderEval.pm
===================================================================
--- lib/Mail/SpamAssassin/Plugin/HeaderEval.pm  (revision 1797757)
+++ lib/Mail/SpamAssassin/Plugin/HeaderEval.pm  (working copy)
@@ -528,6 +528,7 @@
             { return 0; }
 
   if ($rcvd =~ /by web\S+\.mail\S*\.yahoo\.com via HTTP/) { return 0; }
+  if ($rcvd =~ /by \S+\.mail\S*\.yahoo\.com with HTTP/) { return 0; }
   if ($rcvd =~ /by smtp\S+\.yahoo\.com with SMTP/) { return 0; }
   my $IP_ADDRESS = IP_ADDRESS;
   if ($rcvd =~
Comment 6 RW 2017-06-08 11:47:45 UTC
Yahoo have had a DMARC reject policy for over a year and before that they didn't exactly have a spotless reputation. I don't see why a spammer would put any effort into forging Yahoo email in 2017. 

Maybe someone with more spam could verify this but I have only 6 hits on this rule out of 5k spams and not one contains any spoofed yahoo headers, they seem more like the careless use of the Yahoo domain. 

It doesn't seem worth playing wackamole with Yahoo changes, I'd just look for a DKIM-Signature header with d=yahoo.com in it.
Comment 7 Dave Jones 2018-01-17 20:16:04 UTC
I don't have a single hit on FORGED_YAHOO_RCVD in the past 2 weeks.  I don't see this patch in the 3.4.1 code so this Received: header problem must have gone away on it's own.  I say we close this 10 year old non-issue.
Comment 8 Giovanni Bechis 2018-01-17 22:41:04 UTC
Recent messages matches the "/by smtp\S+\.yahoo\.com with SMTP/" regex so the patch is not needed anymore.
Comment 9 Dave Jones 2018-01-18 00:14:45 UTC
Yahoo must have standardized their headers so this is no longer a problem.