[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spamassassin-devel
Subject:    Re: X-Spam-Relays-External envfrom= not reliable
From:       John Hardin <jhardin () impsec ! org>
Date:       2021-01-07 16:20:58
Message-ID: alpine.LNX.2.21.2101070808380.26617 () athena ! impsec ! org
[Download RAW message or body]


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

[prev in list] [next in list] [prev in thread] [next in thread]