You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by John Hardin <jh...@impsec.org> on 2021/01/07 03:50:08 UTC
X-Spam-Relays-External envfrom= not reliable
I was troubleshooting a spam here that didn't hit a rule I expected it to
hit, and found something I think needs some discussion...
The rule was looking at X-Spam-Relays-External envfrom= to determine the
envelope sender domain. When running the message in my testbed, I found
that the envfrom= was not populated at all, and this is why the rule
missed.
The envelope sender was available in a Return-Path header.
Not all MTAs put the envelope sender address into the Received header they
generate.
Would it be justified to populate the envfrom= in X-Spam-Relays-External
from Return-Path (and/or potentially X-Envelope-From) if it's not
available in any Received header?
If not, then rules looking at X-Spam-Relays-External envfrom= will not
work reliably in all environments and should be replaced with checks of
Return-Path.
@smf if you're still around: the __FSL_ENVFROM_* rules fall afoul of this.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Je ne suis pas Charlie. Je suis armé.
-----------------------------------------------------------------------
Tomorrow: the 6th anniversary of the Charlie Hebdo massacre
Re: X-Spam-Relays-External envfrom= not reliable
Posted by John Hardin <jh...@impsec.org>.
On Thu, 7 Jan 2021, RW wrote:
> On Wed, 6 Jan 2021 19:50:08 -0800 (PST)
> John Hardin wrote:
>
>> The rule was looking at X-Spam-Relays-External envfrom= to determine
>> the envelope sender domain. When running the message in my testbed, I
>> found that the envfrom= was not populated at all, and this is why the
>> rule missed.
>>
>> The envelope sender was available in a Return-Path header.
>>
>> Not all MTAs put the envelope sender address into the Received header
>> they generate.
>>
>> Would it be justified to populate the envfrom= in
>> X-Spam-Relays-External from Return-Path (and/or potentially
>> X-Envelope-From) if it's not available in any Received header?
>>
>> If not, then rules looking at X-Spam-Relays-External envfrom= will
>> not work reliably in all environments and should be replaced with
>> checks of Return-Path.
>
> See the documentation for the pseudoheader "EnvelopeFrom".
Rats. Thanks for pointing that out.
> Most cases could use that - especially the __FSL_ENVFROM_ rules, which
> are last-external.
Agreed. I will probably fix those after evaluating the impact of the
change.
> The only published rule using "envfrom=" is __ENVFROM_GOOG_TRIX. This
> does slightly benefit from going deep. Maybe it could check both
I did that yesterday (checking return-path rather then envelopefrom) when
I noticed this.
> or be rewritten to allow for SRS in EnvelopeFrom.
I will probably do that now that I know about that header.
> Relays-External contains per relay information. I think it should
> require a strong reason to depart from that.
Agreed, hence bringing it up for discussion.
> An alternative would be an additional AllEnvelopeFrom pseudoheader, but
> it looks like a very minor problem at the moment.
I don't see a need for that at the moment.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Je ne suis pas Charlie. Je suis armé.
-----------------------------------------------------------------------
Today: the 6th anniversary of the Charlie Hebdo massacre
Re: X-Spam-Relays-External envfrom= not reliable
Posted by RW <rw...@googlemail.com>.
On Wed, 6 Jan 2021 19:50:08 -0800 (PST)
John Hardin wrote:
> The rule was looking at X-Spam-Relays-External envfrom= to determine
> the envelope sender domain. When running the message in my testbed, I
> found that the envfrom= was not populated at all, and this is why the
> rule missed.
>
> The envelope sender was available in a Return-Path header.
>
> Not all MTAs put the envelope sender address into the Received header
> they generate.
>
> Would it be justified to populate the envfrom= in
> X-Spam-Relays-External from Return-Path (and/or potentially
> X-Envelope-From) if it's not available in any Received header?
>
> If not, then rules looking at X-Spam-Relays-External envfrom= will
> not work reliably in all environments and should be replaced with
> checks of Return-Path.
See the documentation for the pseudoheader "EnvelopeFrom". Most cases
could use that - especially the __FSL_ENVFROM_ rules, which are
last-external.
The only published rule using "envfrom=" is __ENVFROM_GOOG_TRIX. This
does slightly benefit from going deep. Maybe it could check both or be
rewritten to allow for SRS in EnvelopeFrom.
Relays-External contains per relay information. I think it should
require a strong reason to depart from that. An alternative would
be an additional AllEnvelopeFrom pseudoheader, but it looks like a very
minor problem at the moment.