You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2004/12/10 21:27:36 UTC
[Bug 4024] New: SPF and X-Envelope-From and sendmail
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
Summary: SPF and X-Envelope-From and sendmail
Product: Spamassassin
Version: 3.0.1
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Plugins
AssignedTo: dev@spamassassin.apache.org
ReportedBy: imark@tippingmar.com
The USAGE document says:
However,sendmail will not expose the MAIL FROM: sender address by default. So
if you're using sendmail, please add this to /etc/sendmail.cf :
H?l?X-Envelope-From: $f
This works fine as long as the message is received from a server that is not
also set to add this header. But if the header has already been added by a
previous server, then sendmail won't add another one. The existing header will
be below the latest Received: line so SpamAssasin won't trust it and no SPF
checks will be done. By SPF I mean the real SPF checks, not the SPF_HELO
checks.
Example headers from one that works:
X-Envelope-From: cpicciotto@kalisystems.com
Return-Path: <cp...@kalisystems.com>
Received: from picciotto.net (picciotto.net [66.91.143.194])
by mail.tippingmar.com (8.12.10/8.12.10) with ESMTP id iBAJ9Ye1001721
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <ma...@tippingmar.com>; Fri, 10 Dec 2004 11:09:35 -0800
Received: from [192.168.0.4] (cpe-66-91-125-24.hawaii.rr.com [66.91.125.24])
(authenticated bits=0)
by picciotto.net (8.12.11/8.12.11) with ESMTP id iBAJ9QC5015715
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
for <ma...@tippingmar.com>; Fri, 10 Dec 2004 09:09:26 -1000
Message-ID: <41...@kalisystems.com>
Example of one that doesn't work:
Return-Path: <cp...@kalisystems.com>
Received: from picciotto.net (picciotto.net [66.91.143.194])
by mail.tippingmar.com (8.12.10/8.12.10) with ESMTP id iBAIise1001311
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <ma...@tippingmar.com>; Fri, 10 Dec 2004 10:44:55 -0800
X-Envelope-From: cpicciotto@kalisystems.com
Received: from [192.168.0.4] (cpe-66-91-125-24.hawaii.rr.com [66.91.125.24])
(authenticated bits=0)
by picciotto.net (8.12.11/8.12.11) with ESMTP id iBAIijMY015420
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
for <ma...@tippingmar.com>; Fri, 10 Dec 2004 08:44:45 -1000
Message-ID: <41...@kalisystems.com>
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4024] SPF and X-Envelope-From and sendmail
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
------- Additional Comments From imark@tippingmar.com 2005-01-09 16:30 -------
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.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4024] SPF and X-Envelope-From and sendmail
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
------- Additional Comments From spamassassin@dostech.ca 2005-01-10 16:34 -------
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
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4024] SPF and X-Envelope-From and sendmail
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
------- Additional Comments From quinlan@pathname.com 2005-01-10 13:53 -------
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.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4024] SPF and X-Envelope-From and sendmail
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
------- Additional Comments From spamassassin@dostech.ca 2005-01-10 21:11 -------
Created an attachment (id=2597)
--> (http://bugzilla.spamassassin.org/attachment.cgi?id=2597&action=view)
patch against trunk
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4024] SPF and X-Envelope-From and sendmail
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
spamassassin@dostech.ca changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |spamassassin@dostech.ca
------- Additional Comments From spamassassin@dostech.ca 2005-01-08 23:01 -------
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
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4024] SPF and X-Envelope-From and sendmail
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
------- Additional Comments From spamassassin@dostech.ca 2005-01-09 19:01 -------
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
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4024] SPF and X-Envelope-From and sendmail
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
------- Additional Comments From imark@tippingmar.com 2005-01-10 09:22 -------
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.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4024] SPF and X-Envelope-From and sendmail
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
------- Additional Comments From spamassassin@dostech.ca 2005-01-10 20:53 -------
Created an attachment (id=2596)
--> (http://bugzilla.spamassassin.org/attachment.cgi?id=2596&action=view)
patch against 3.0
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4024] SPF and X-Envelope-From and sendmail
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
------- Additional Comments From jm@jmason.org 2005-01-10 10:48 -------
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.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4024] SPF and X-Envelope-From and sendmail
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
------- Additional Comments From imark@tippingmar.com 2004-12-15 14:22 -------
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.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.