"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) > > 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 > > 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.
