|
SA Bugzilla – Full Text Bug Listing |
Summary: | FORGED_YAHOO_RCVD false positive | ||
---|---|---|---|
Product: | Spamassassin | Reporter: | Adam Jenkins <adam> |
Component: | Rules (Eval Tests) | Assignee: | SpamAssassin Developer Mailing List <dev> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | bugs, dam, davej, giovanni, info, kmcgrail, rwmaillists |
Priority: | P4 | ||
Version: | 3.0.0 | ||
Target Milestone: | Undefined | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Adam Jenkins
2007-07-16 08:17:11 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. 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. |