Mailing List Archive

"Dan Mahoney (Gushi)" <danm@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)
>
> 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 dmahoney@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
>
> I also noticed that the all_trusted rule did not fire -- perhaps,
> again, because of the above unparseable relay.
>
> Is DMA putting a crappy header in that would cause this not to break
> if we were running a local postfix/sendmail?
>
> Maybe I'm unclear on how this all works, but I thought that putting a
> host in trusted_networks basically sidestepped spam processing.
> 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.

The correct way is probably to read the RFC about Received and see if
it's compliant, and then decide that it's too broad and you really need
something parseable, and then either patch DMA to emit something
compatible or patch SA to parse what DMA writes.

What you posted doesn't look terrible. It's clearly a local inject from
a process.

"Dan Mahoney (Gushi)" <danm@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 dmahoney@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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire