You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Kirk Ismay <ki...@ismay.ca> on 2024/07/17 17:17:16 UTC
Blocking Malformed "From" Headers
I have a spammer using a malformed From header, as follows:
From: <UPS>sharon@marketcrank.com
The envelope from is: direccion@delher.com.mx, and I've set up blocks
for that address.
Sendmail is munging the From: header to change <UPS> to
<UP...@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 <UP...@suspected-spammer> instead, or reject it entirely.
Thanks,
Kirk
Re: Blocking Malformed "From" Headers
Posted by Kirk Ismay <ki...@ismay.ca>.
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>sharon@marketcrank.com
>>
>> The envelope from is: direccion@delher.com.mx, and I've set up blocks
>> for that address.
>>
>> Sendmail is munging the From: header to change <UPS> to
>> <UP...@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 <UP...@suspected-spammer> instead, or reject it
>> entirely.
>>
>> Thanks,
>> Kirk
>>
>>
>
Re: Blocking Malformed "From" Headers
Posted by Dave Funk <db...@engineering.uiowa.edu>.
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>sharon@marketcrank.com
>
> The envelope from is: direccion@delher.com.mx, and I've set up blocks for
> that address.
>
> Sendmail is munging the From: header to change <UPS> to <UP...@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 <UP...@suspected-spammer> instead, or reject it entirely.
>
> Thanks,
> Kirk
>
>
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St.
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Blocking Malformed "From" Headers
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 2024-07-17 at 13:17:16 UTC-0400 (Wed, 17 Jul 2024 10:17:16 -0700)
Kirk Ismay <ki...@ismay.ca>
is rumored to have said:
> I have a spammer using a malformed From header, as follows:
>
> From: <UPS>sharon@marketcrank.com
>
> The envelope from is: direccion@delher.com.mx, and I've set up blocks
> for that address.
>
> Sendmail is munging the From: header to change <UPS> to
> <UP...@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?
I believe SA already has a more general rule that will catch the *BAD*
form, but depending on how you've integrated SA and Sendmail, it may
only see the "cleaned up" form that Sendmail provides. I believe SA sees
the unmolested headers only in a milter interface, NOT if you've got it
hooked into a mailer.
If not, here's a rule that should work:
header FROM_ANGLE_UNQUAL From =~ /<[^<\@]*>[^\@]*\@/
> 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 <UP...@suspected-spammer> instead, or reject it
> entirely.
>
> Thanks,
> Kirk
Remove FEATURE(always_add_domain) from your .mc and remake sendmail.cf.
Consult the Ops guide and/or cf/README for all of the effects of that.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com
addresses)
Not Currently Available For Hire