You can work around this problem to a large extent by using:

H?l?X-uniquename-Env-From: $f

and then specifying the header name with:
envelope_sender_header X-uniquename-Env-From
in local.cf

so the chances of there already being such a header in the incoming message are 
greatly reduced.

Of course this problem only relates to use of SpamAssassin on gateways or in 
programs like MailScanner, where the message has not yet been given to a 
delivery agent.  When sendmail passes the message to a delivery agent, it adds 
the Return-Path header, which SpamAssassin knows how to use.

Of course there's nothing we can do if the header is added by an untrusted
relay, but we can use it if it was added by a trusted relay.

Adding the HELO value found in the last trusted relay's received header to the
current regex should do the trick.

This also applies to the regexes for Envelope-Sender and Return-Path.


Daryl

I'm not sure what you mean.  The HELO and the Envelope-From are often different
for legitimate messages.  True SPF requires the Envelope-From address.  As noted
in the first post, the problem is with real SPF checks, not the SPF_HELO tests.

What I'm suggesting has nothing to do with SPF checks.  It only has to do with
determining when we can trust the X-Envelope-From, Envelope-Sender and/or Return
Path found in a message, and when we can't.

If these headers are found above the last trusted relay's received header, we
can trust them.  By modifying the current regexes, used to determine if we can
use the 3 aforementioned headers, to include a token that appears in the last
trusted relay's received header (and no sooner, but likely also later) we can
determine whether or not we trust those 3 headers.

I'll write a patch tonight if I can get some other work out of the way.


Daryl

I see.  Currently the header is only trusted if it is above the final Received 
header.  You are saying we can also trust the header if it is above the last 
TRUSTED relay.

daryl -- I'm not sure your position is correct.

it's entirely plausible that a *trusted* relay could forward the mail with a new
envelope-sender address.  my fetchmail setup, for exmaple, does this; also if
the mail is resent via a Mailman/ezmlm mailing list, that will also do that.

Subject: Re:  SPF and X-Envelope-From and sendmail

I would say we should use the first envelope-sender header encountered
above the last trusted received line.

Subject: Re:  SPF and X-Envelope-From and sendmail

The current code won't use the headers, regardless of where they are, if 
it finds an X-Sender header and a fetchmail received header since 
fetchmail may alter the envelope-sender.

I don't suggest that this check be eliminated if we were to check for 
the 3 headers in between the trusted relays' received headers.

That said, is there anytime fetchmail will alter the envelope-sender if 
it doesn't find an X-Sender header?  Should the X-Sender requirement be 
removed (and just look for 'fetchmail') or should we also be looking for 
other headers that may cause fetchmail to alter the envelope-sender?


Daryl

Created attachment 2596 [details]
patch against 3.0

Created attachment 2597 [details]
patch against trunk

Daryl -- do we still need this?

Forgot all about this... need to think about it a bit.

If we do need it, I don't like my implementation.  Looking for the last trusted
helo is lame.

Instead of using the "ALL" pseudo header, we should have an "ALL-TRUSTED" one to
work with.

lowering pri

I can't convince myself that this is a good thing to do.  It's messy and
unreliable.  As soon as you start messing with the return path you've got to
give up on SPF.

r483169 and r483171 removes the bogus info from the USAGE doc.  Closing as WONTFIX.