SA Bugzilla – Bug 5561
FORGED_YAHOO_RCVD false positive
Last modified: 2018-01-18 00:14:45 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.
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.
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
Well nnfmp is an internal Yahoo! Protocol. Is it hitting dkim or spf validation?
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.
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 =~
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.
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.
Recent messages matches the "/by smtp\S+\.yahoo\.com with SMTP/" regex so the patch is not needed anymore.
Yahoo must have standardized their headers so this is no longer a problem.