https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7959
Bill Cole <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|NEW |RESOLVED CC| |[email protected] --- Comment #1 from Bill Cole <[email protected]> --- This was also reported on the users mailing list, and I see evidence of it occurring in the morning (UTC) of 2022-02-27 on a system that I help manage. The last one I see in the logs was shortly before 11:00 UTC. None of the messages I had access to which misfired earlier did so when I retested after 18:00 UTC Unfortunately, we do not have any examples of actual messages that *reproducibly* misfire on FROM_FMBLA_NEWDOM. Because it is a DNSBL rule and the DNSBL behind it (the 'fresh' sub-list of fmb.la) is operated by design to be rapidly changing, the most likely explanation for the many misfires is a glitch in the operation of the DNSBL. As with all the other DNSBLs used by SpamAssassin, fmb.la is NOT a service we have any control over, so we can't say for sure what happened during the period of problems. IF you have a message that misfires NOW on FROM_FMBLA_NEWDOM, that would indicate that there is a persistent problem with SpamAssassin that we could address or with the DNSBL that the operators of fmb.la could address. Absent such evidence, and because my own retests of earlier-misfiring messages did not misfire, I can only conclude that this was a transient mistake by fmb.la and is not actionable by us. Recent network mass-checks (see ruleqa.spamassassin.org) consistently show FROM_FMBLA_NEWDOM over 99.5% accurate, so this does not seem to be a frequent sort of incident which would merit review of the rule's inclusion and scoring. -- You are receiving this mail because: You are the assignee for the bug.
