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.
