And finally, according to the following reference, SA was not supposed to ignore X-Envelope-From.
> perldoc Mail::SpamAssassin::Plugin::SPF welcomelist_from_spf [email protected] Previously whitelist_from_spf which will work interchangeably until 4.1. Works similarly to welcomelist_from, except that in addition to matching a sender address, a check against the domain's SPF record must pass. The first parameter is an address to welcomelist, and the second is a string to match the relay's rDNS. Just like welcomelist_from, multiple addresses per line, separated by spaces, are OK. Multiple "welcomelist_from_spf" lines are also OK. *The headers checked for welcomelist_from_spf addresses are the same headers used for SPF checks (Envelope-From, Return-Path, X-Envelope-From, etc).* Since this welcomelist requires an SPF check to be made, network tests must be enabled. It is also required that your trust path be correctly configured. See the section on "trusted_networks" for more info on trust paths. e.g. welcomelist_from_spf [email protected] [email protected] welcomelist_from_spf *@example.com I am using Mail-SpamAssassin version 4.0.2 from OpenBSD, which is the same as the cpan version. On Friday, December 12th, 2025 at 9:44 PM, Otto Cooper <[email protected]> wrote: > 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.
