According to the following references, SA should use the Return-Path header instead of EnvelopeFrom, but is clearly not doing it.
https://cwiki.apache.org/confluence/display/spamassassin/EnvelopeSenderInReceived > perldoc Mail::SpamAssassin::Conf envelope_sender_header Name-Of-Header SpamAssassin will attempt to discover the address used in the 'MAIL FROM:' phase of the SMTP transaction that delivered this message, if this data has been made available by the SMTP server. This is used in the "EnvelopeFrom" pseudo-header, and for various rules such as SPF checking. By default, various MTAs will use different headers, such as the following: X-Envelope-From Envelope-Sender X-Sender Return-Path SpamAssassin will attempt to use these, if some heuristics (such as the header placement in the message, or the absence of fetchmail signatures) appear to indicate that they are safe to use. However, it may choose the wrong headers in some mailserver configurations. (More discussion of this can be found in bug 2142 and bug 4747 in the SpamAssassin BugZilla.) To avoid this heuristic failure, the "envelope_sender_header" setting may be helpful. Name the header that your MTA or MDA adds to messages containing the address used at the MAIL FROM step of the SMTP transaction. If the header in question contains "<" or ">" characters at the start and end of the email address in the right-hand side, as in the SMTP transaction, these will be stripped. If the header is not found in a message, or if it's value does not contain an "@" sign, SpamAssassin will issue a warning in the logs and fall back to its default heuristics. (Note for MTA developers: we would prefer if the use of a single header be avoided in future, since that precludes 'downstream' spam scanning. "https://wiki.apache.org/spamassassin/EnvelopeSenderInReceived"; details a better proposal, storing the envelope sender at each hop in the "Received" header.) example: envelope_sender_header X-SA-Exim-Mail-From On Friday, December 12th, 2025 at 9:18 PM, otto.cooper <[email protected]> wrote: > > > Hello, > > I encountered the following problem when using welcomelist_from_spf. > > The comand "spamassassin -t --debug <test.eml" shows that the rule fails, > because it is not using the envelope-from header. > > This is how the header is generated and used locally. > > The envelope-from header is not generated by default, so I added the > following rule in postfix's sender_access: > > /(.*)/ prepend X-Envelope-From: <$1> > > > As a result, the header is added after the last Received. > > Additionally, a sub-header envelope-from is added as part of Received-SPF, > immediately after the last Received. > > Finally, in SpamAssassin, I set the following variables: > > > envelope_sender_header X-Envelope-From > > always_trust_envelope_sender 1 > > > loadplugin Mail::SpamAssassin::Plugin::SPF > > spf_timeout 5 > > ignore_received_spf_header 0 > > use_newest_received_spf_header 0 > > > When running the debugger, this is what I see. > > > [...] dbg: message: X-Envelope-From header found after 1 or more Received > > lines, cannot trust envelope-from > > > [...] dbg: spf: EnvelopeFrom not found in first external Received header > > [...] dbg: spf: EnvelopeFrom header not found > > [...] dbg: spf: cannot get EnvelopeFrom, cannot use SPF by DNS > > > The test.eml contains a single Received-SPF. > > What is the problem? > > SA is ignoring envelope_sender_header, and looking for EnvelopeFrom instead > of X-Envelope-From. > > SA is ignoring the envelope-from included in the Received-SPF header. > > If I rename X-Envelope-From to EnvelopeFrom in test.eml, the debugger shows > that the header is found and used. > > I have a rule that says welcomelist_from_spf *@example.com from test.eml, but > the resulting score is still high. > > I used X-Envelope-From in a few postfix rules, and I can change it to > EnvelopeFrom if needed. > However, the envelope from is the address used in the Return-Path header, > which is included > by default and happens to be the topmost header, so no special header ought > to be added in the first place.
