Bug 7959 - FROM_FMBLA_NEWDOM is misfiring
Summary: FROM_FMBLA_NEWDOM is misfiring
Status: RESOLVED WORKSFORME
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: 3.4.2
Hardware: All All
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-02-28 01:12 UTC by Jerry Benton
Modified: 2022-02-28 03:40 UTC (History)
2 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 Jerry Benton 2022-02-28 01:12:58 UTC
The rule FROM_FMBLA_NEWDOM is firing on random emails across 12 different servers. It even fires on gmail.com. Seems to have started about 48 hours ago with an update.

Servers are running pretty much the standard .pre files except these two are enabled:

loadplugin Mail::SpamAssassin::Plugin::FromNameSpoof
loadplugin Mail::SpamAssassin::Plugin::Phishing

Not sure what other info I can provide, but here is an sa-compile output:

cd Mail-SpamAssassin-CompiledRegexps-body_0
re2c -i -b -o scanner1.c scanner1.re
re2c -i -b -o scanner2.c scanner2.re
re2c -i -b -o scanner3.c scanner3.re
re2c -i -b -o scanner4.c scanner4.re
re2c -i -b -o scanner5.c scanner5.re
re2c -i -b -o scanner6.c scanner6.re
re2c -i -b -o scanner7.c scanner7.re
/usr/bin/perl Makefile.PL PREFIX=/tmp/.spamassassin27306qKrsvDtmp/ignored INSTALLSITEARCH=/var/lib/spamassassin/compiled/5.026/3.004002 
Generating a Unix-style Makefile
Writing Makefile for Mail::SpamAssassin::CompiledRegexps::body_0
Writing MYMETA.yml and MYMETA.json
make PREFIX=/tmp/.spamassassin27306qKrsvDtmp/ignored INSTALLSITEARCH=/var/lib/spamassassin/compiled/5.026/3.004002 
cp body_0.pm blib/lib/Mail/SpamAssassin/CompiledRegexps/body_0.pm
Running Mkbootstrap for body_0 ()
chmod 644 "body_0.bs"
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- body_0.bs blib/arch/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.bs 644
"/usr/bin/perl" "/usr/share/perl/5.26/ExtUtils/xsubpp"  -typemap '/usr/share/perl/5.26/ExtUtils/typemap'  body_0.xs > body_0.xsc
mv body_0.xsc body_0.c
x86_64-linux-gnu-gcc -c   -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g   -DVERSION=\"1.0\" -DXS_VERSION=\"1.0\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.26/CORE"   body_0.c
x86_64-linux-gnu-gcc -c   -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g   -DVERSION=\"1.0\" -DXS_VERSION=\"1.0\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.26/CORE"   scanner1.c
x86_64-linux-gnu-gcc -c   -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g   -DVERSION=\"1.0\" -DXS_VERSION=\"1.0\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.26/CORE"   scanner2.c
x86_64-linux-gnu-gcc -c   -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g   -DVERSION=\"1.0\" -DXS_VERSION=\"1.0\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.26/CORE"   scanner3.c
x86_64-linux-gnu-gcc -c   -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g   -DVERSION=\"1.0\" -DXS_VERSION=\"1.0\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.26/CORE"   scanner4.c
x86_64-linux-gnu-gcc -c   -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g   -DVERSION=\"1.0\" -DXS_VERSION=\"1.0\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.26/CORE"   scanner5.c
x86_64-linux-gnu-gcc -c   -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g   -DVERSION=\"1.0\" -DXS_VERSION=\"1.0\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.26/CORE"   scanner6.c
x86_64-linux-gnu-gcc -c   -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g   -DVERSION=\"1.0\" -DXS_VERSION=\"1.0\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.26/CORE"   scanner7.c
rm -f blib/arch/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so
x86_64-linux-gnu-gcc  -shared -L/usr/local/lib -fstack-protector-strong body_0.o scanner1.o scanner2.o scanner3.o scanner4.o scanner5.o scanner6.o scanner7.o  -o blib/arch/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so  \
      \
  
chmod 755 blib/arch/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so
Manifying 1 pod document
make install PREFIX=/tmp/.spamassassin27306qKrsvDtmp/ignored INSTALLSITEARCH=/var/lib/spamassassin/compiled/5.026/3.004002 
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- body_0.bs blib/arch/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.bs 644
Manifying 1 pod document
Files found in blib/arch: installing files in blib/lib into architecture dependent library tree
Installing /var/lib/spamassassin/compiled/5.026/3.004002/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so
Installing /tmp/.spamassassin27306qKrsvDtmp/ignored/man/man3/Mail::SpamAssassin::CompiledRegexps::body_0.3pm
Appending installation info to /var/lib/spamassassin/compiled/5.026/3.004002/perllocal.pod
cp /tmp/.spamassassin27306qKrsvDtmp/bases_body_0.pl /var/lib/spamassassin/compiled/5.026/3.004002/bases_body_0.pl
Comment 1 Bill Cole 2022-02-28 03:30:50 UTC
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.
Comment 2 Jerry Benton 2022-02-28 03:40:34 UTC
Bill,

Thanks for replying. The earliest I saw the misfires on known good domains was:

2022-02-16 at 23:16 UTC

The last one:

2022-02-17 at 10:29 UTC

It fired on some others after that, but they look like garbage domains.

Thanks for the info. I wasn't aware that was a DNSBL rule. I had it cranked up in score to like 8.5 and I had to scrambled to release emails and drop it to 0.1. 

It doesn't seem to be misfiring now. Thanks again.