On 2022-01-20 at 16:21:40 UTC-0500 (Thu, 20 Jan 2022 16:21:40 -0500)
Joe Acquisto-j4 <j...@j4computers.com>
is rumored to have said:
Am 20.01.22 um 15:47 schrieb Joe Acquisto-j4:
Where can I get some idea of what the rule below actually checks
for? I
noticed some normally passed email was flagged as SPAM.
Started seeing it sometime after making some configuration changes
to local
settings on postfix, attempting to isolate a "bug". But before
reverting
them all, or one at a time, I'd rather have a clue. Semi-informed
hacking
about can be problematic.
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20)
* 1.8 FSL_HELO_NON_FQDN_1 No description available
in most cases by read the name with common sense
HELO: should be known what it is
NON: none should be clear
FQDN: should be known what it is
the description would be something like "HELO with no full qualified
domain name" and won't help you either if you don't know that
standard
things when it comes to email
the FSL_ prefix is as usual a shortname of the guy who wrote the rule
I would still like to examine that rule, but have not found it despite
some
effort to do so. Are they in "plain text" file or obfuscated/indexed
in some
manner? Doing a text search across the system might take time, but is
a wasted effort if not in plain text.
The exact location is distro/build-specific, but in someplace like
/var/db/spamassassin/3.004006 you should have a directory tree of rules
in 'channels' including updates_spamassassin_org, which includes a file
named 72_active.cf, with this line:
header FSL_HELO_NON_FQDN_1 X-Spam-Relays-External =~ /^[^\]]+
helo=[a-zA-Z0-9-_]+ /i
Essentially: a SMTP handoff was recorded by a trustworthy reciever in
which the sender used a HELO/EHLO argument which had no '.' in it, and
so cannot be a fully-qualified domain name. The X-Spam-Relays-*
pseudo-headers are synthesized by SpamAssassin from the Received headers
of the message.
Reason is, I do not see anything that should trigger this rule, based
on the
suggestions. Even reverted a couple of setting, see them reflected in
headers, but it still triggers. So, I am missing something.
To figure out what matched, you'll need to check a message with the
"rules" debug channel on:
spamassassin -t -D rules < suspect.eml
HOWEVER: In looking at your message, I'm 99.9% sure that what matched
was a Received header recording a client calling itself simply 'mail'
using an RFC1918 IP address which is also constructing a Message-Id
using just 'mail' as the hostname part. Whatever that machine is, it
should be using a FQDN instead of a bare hostname. Also, you could (and
probably should) add that machine to your internal_networks setting,
since an RFC1918 address is pretty much the definition of internal.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
