Mailing List Archive: X-Spam-Relays-External envfrom= not reliable

X-Spam-Relays-External envfrom= not reliable

Jan 6, 2021, 7:50 PM

Post #1 of 3 (144 views)

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 [ In reply to ]

rwmaillists at googlemail

Jan 7, 2021, 6:16 AM

Post #2 of 3 (144 views)

Permalink

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.

Re: X-Spam-Relays-External envfrom= not reliable [ In reply to ]

jhardin at impsec

Jan 7, 2021, 8:20 AM

Post #3 of 3 (144 views)

Permalink

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