"Dan Mahoney (Gushi)" <d...@prime.gushi.org> writes:
Hey there all,
Recently, we noticed that one of our system's "cron" mails started
getting caught by our spam filter (because it had lots of hostnames in
it about failed ssh logins, which the uribl plugin didn't like).
This system is listed (v4 and v6) in trusted_networks -- and it sends
it straight to our MX host via v6. (no SMTP auth)
trusted_networks are NOT machines that you trust to not send spam. They
are machines on other people's networks which you trust not to forge
Received headers and which only talk to you directly. Like a secondary
MX. You don't really trust the networks or the machines or their users,
but only their Received headers.
internal_networks should include machines which you expect to never send
you spam and whose mail you want to see no matter how spammy it looks:
machines (and users) that you are expected to fix so that they don't
send spam. These are also expected to write trustworthy Received
headers.
We're getting a warning about "unparseable relay", but I think that's
just the DMA [freebsd's default mailer] throwing it off:
Received: from dmahoney (uid 10302)
(envelope-from dmaho...@bommel.dayjob.org)
id 237584
by bommel.dayjob.org (DragonFly Mail Agent v0.13 on
bommel.dayjob.org);
Thu, 07 Dec 2023 19:45:29 +0000
That is an extremely disappointing Received header. Is there another one
indicating an SMTP handoff or is this a strictly local-local delivery?
I also noticed that the all_trusted rule did not fire -- perhaps,
again, because of the above unparseable relay.
Correct.
It would take some work to make that generally useful to SA except as an
idiosyncratic indicator of local submission.
Is DMA putting a crappy header in that would cause this not to break
if we were running a local postfix/sendmail?
Probably, but I'm not 100% clear on how this mail is travelling. Can you
clarify and/or provide more complete headers?
Maybe I'm unclear on how this all works, but I thought that putting a
host in trusted_networks basically sidestepped spam processing.
No. It ADDS the potential for processing that ingests the Received
header written by the "trusted" machine
There are ALL_TRUSTED and NO_RELAYS rules which have weak negative (ham)
scores and I believe ALL_TRUSTED is shortcircuited by default in the
distribution rules. I've written and tested a slight variant
ALL_INTERNAL rule, but I saw no compelling reason to have it in the
default rules.
SpamAssassin itself does not have any "don't look at this" switch. If
you want your own mail to be exempted, you need to match some pattern in
the mail that is unlikely to be spoofable. That can require any or all
of setting the *_networks correctly, making glue layer includes a
parseable Received header, and making your DNS and machine naming nicely
harmonious.
What's the "correct" way to do this? These are boxes that do not
normally relay mail -- they only generate it from system reports and
cron jobs, and generally speaking, only to us.
Just don't send those messages to SpamAssassin. How you do that depends
on your MTA and your choice of glue. I do this on my own tiny network in
MIMEDefang, where I have bespoke non-portable code very specifically
identifying my automated mail generators and not checking them with SA.
If you can't readily do that, make sure your mail generators don't
create sloppy Received headers, the glue layer gives you a usable local
Received header (a real issue with milters,) that you have proper
*_networks settings, and all your machines call themselves by resolvable
names which are actually theirs. With that sort of hygiene, you can then
tweak the scores of ALL_TRUSTED and/or NO_RELAYS or craft special rules
that give you some large negative score and probably shortcircuit those.
It may also be enough to make all of those automated mail generators
send to addresses which use one of these mechanisms (from 'perldoc
Mail::SpamAssassin::Conf')
There are three levels of To-welcomelisting, "welcomelist_to",
"more_spam_to" and "all_spam_to". Users in the first level may
still
get some spammish mails blocked, but users in "all_spam_to"
should
never get mail blocked.
Those are all implemented through rules which you can adjust scores for
and/or shortcircuit just to be sure.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
