I am already using the no_default_msa, but the system does accept mail
both as an MTA and MSA. I am using DAEMON_OPTIONS to listen on port 465
etc, but even adding the M=C (no canonify) switch, the From: header
rewriting still occurs.
I've tested with another system using Postfix, and it does the same thing.
Weird.
Thanks,
Kirk
On 2024-07-17 10:55 a.m., Dave Funk wrote:
The SMTP protocol RFCs are pretty clear, anything in angle-brackets
'<' & '>' take priority in defining an address field. So technically
that's a legit local address and sendmail is doing default MSA
processing on it (IE treating it as a bare username that needs the
local hostname added).
Is this sendmail instance just an incoming MTA or is it also used as
an outgoing MSA for your users?
If it's just an incoming MTA (IE your users have another instance
they're using for outgoing MSA service) then just turn off the MSA
feature for that specific sendmail instance to stop that processing:
"FEATURE(` no_default_msa')"
On Wed, 17 Jul 2024, Kirk Ismay wrote:
I have a spammer using a malformed From header, as follows:
From: <UPS>sha...@marketcrank.com
The envelope from is: direcc...@delher.com.mx, and I've set up blocks
for that address.
Sendmail is munging the From: header to change <UPS> to
<u...@my.host.name>, so it ends up looking like a local address to my
users.
How do I detect similar mangled From headers in Spamassassin?
Also does anyone know how to prevent Sendmail from rewriting the From
header like this? The documentation for confFROM_HEADER is a
somewhat cryptic:
https://www.sendmail.org/~ca/email/doc8.12/cf/m4/tweaking_config.html#confFROM_HEADER
I'd rather it say <UPS@suspected-spammer> instead, or reject it
entirely.
Thanks,
Kirk
