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 2010/02/11 20:22:20 UTC
[Bug 6334] New: RCVD_IN_PBL false positives against IMP "Received"
header
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6334
Summary: RCVD_IN_PBL false positives against IMP "Received"
header
Product: Spamassassin
Version: 3.3.0
Platform: All
OS/Version: All
Status: NEW
Severity: critical
Priority: P5
Component: Rules
AssignedTo: dev@spamassassin.apache.org
ReportedBy: shea@lovan.com
The IMP web-based email client (http://www.horde.org/imp) writes a "Received:"
header to messages containing the current IP address of the logged-in sender.
The header is almost identical to those generated by Exim or Sendmail except
that instead of being received "with esmtp" or "with smtp" it is tagged "with
HTTP".
The problem is that if the IP address in the IMP-added Received line is listed
in the Spamhaus PBL, then it triggers the RCVD_IN_PBL test. Given that the
point of that test is to spot people going around their ISPs' MTAs to send
unauthenticated messages, this behavior seems to be a bug in the RCVD_IN_PBL
rule.
This problem probably goes back into the 3.2.x series but became critical with
3.3.0 when the default scores went from {0 0.509 0 0.905} to {0 3.558 0 3.335}.
Here are the message headers from an affected message:
--- Message Headers Begin ---
Return-Path: <xx...@umail.ucsb.edu>
Received: from outgoing-1.umail.ucsb.edu (outgoing-1.umail.ucsb.edu
[128.111.151.61])
by lifesci.lifesci.ucsb.edu (8.14.3/8.14.1) with ESMTP id o15NJLEl029472
for <yy...@lifesci.ucsb.edu>; Fri, 5 Feb 2010 15:19:21 -0800 (PST)
Received: from web-1.umail.ucsb.edu ([128.111.151.41] helo=localhost)
by outgoing-1.umail.ucsb.edu with esmtp (Exim 4.63)
(envelope-from <xx...@umail.ucsb.edu>)
id 1NdXSK-0001uA-ML
for yyy@lifesci.ucsb.edu; Fri, 05 Feb 2010 15:19:20 -0800
Received: from adsl-68-120-70-160.dsl.irvnca.pacbell.net
(adsl-68-120-70-160.dsl.irvnca.pacbell.net [68.120.70.160]) by
webaccess.umail.ucsb.edu (Horde Framework) with HTTP; Fri, 05 Feb 2010
15:19:20 -0800
Message-ID: <20...@webaccess.umail.ucsb.edu>
Date: Fri, 05 Feb 2010 15:19:20 -0800
From: "User #1" <xx...@umail.ucsb.edu>
To: "User #2" <yy...@lifesci.ucsb.edu>
Subject: OUR SUBJECT
MIME-Version: 1.0
Content-Type: text/plain;
charset=ISO-8859-1;
DelSp="Yes";
format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.3.4)
X-Originating-IP: 68.120.70.160
X-Remote-Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2)
Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2
(lifesci.lifesci.ucsb.edu [128.111.226.5]); Fri, 05 Feb 2010 15:19:21 -0800
(PST)
X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on lifesci
X-Spam-Flag: YES
X-Spam-Level: *****
X-Spam-Status: Yes, score=5.9 required=5.0 tests=BAYES_50,HELO_NO_DOMAIN,
RCVD_IN_PBL,RDNS_NONE autolearn=no version=3.3.0
X-Virus-Scanned: clamav-milter 0.95.1-exp at lifesci
X-Virus-Status: Clean
--- Message Headers End ---
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6334] RCVD_IN_PBL false positives against IMP "Received" header
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6334
--- Comment #6 from Karsten Bräckelmann <gu...@rudersport.de> 2010-02-16 18:49:01 UTC ---
Btw, according to the Received headers, there seems to be a hop missing from
webaccess (.228) to web-1 (.41), unless they actually are the same machine.
Also from the docs:
"Trusted relays that accept mail directly from dial-up connections should
not be listed in internal_networks. List them only in trusted_networks."
This applies to .41, which appears to also be webaccess. I'm slightly confused
about the machines involved and their actual roles, but continuing on my
previous guesswork of settings...
Having the above quote in mind and relying on webaccess exclusively allowing
authenticated use, the following explicit settings will treat .41 as the one to
check:
trusted_networks 128.111.151.61 128.111.151.41
internal_networks 128.111.151.61
The underlying issue, though, seems to be that the Originating IP is seen as
the submitting host on *two* headers.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6334] RCVD_IN_PBL false positives against IMP "Received" header
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6334
Shea Lovan <sh...@lovan.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |shea@lovan.com
Resolution|INVALID |
--- Comment #2 from Shea Lovan <sh...@lovan.com> 2010-02-16 16:36:18 UTC ---
I am afraid I need to reopen the bug. The other servers are *not* on my
internal network (as defined in SA). Yes, the systems (other than the
originating DSL IP) are located on our campus network. However, our campus
does not have a centralized email system and I don't have my SA installation
configured see the other email servers on campus as "internal."
I do however have them listed in "trusted_networks". From what I understand,
that should have ensured that this inbound connection to the IMP server
(webaccess.umail.ucsb.edu) was treated as an authenticated/trusted source.
Is the actual problem that the first Received header does not include the IMP
server's IP address (it has the valid hostname which resolves to
trusted_network IP space) and so the trust link in broken?
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6334] RCVD_IN_PBL false positives against IMP "Received" header
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6334
--- Comment #4 from Karsten Bräckelmann <gu...@rudersport.de> 2010-02-16 18:22:32 UTC ---
(In reply to comment #2)
> The other servers are *not* on my internal network (as defined in SA). [...]
> I do however have them listed in "trusted_networks".
Did you specifically set up internal networks at all? Note from the
internal_networks docs:
"If trusted_networks is set and internal_networks is not, the value of
trusted_networks will be used for this parameter."
> that should have ensured that this inbound connection to the IMP server
> (webaccess.umail.ucsb.edu) was treated as an authenticated/trusted source.
As per my previous comment, looks like it is. The external / untrusted IP
picked up is not from the Received header, but X-Originating-IP.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6334] RCVD_IN_PBL false positives against IMP "Received" header
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6334
Shea Lovan <sh...@lovan.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |INVALID
--- Comment #5 from Shea Lovan <sh...@lovan.com> 2010-02-16 18:31:42 UTC ---
Looks like the troubles between trusted and internal networks
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6334] RCVD_IN_PBL false positives against IMP "Received" header
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6334
--- Comment #3 from Karsten Bräckelmann <gu...@rudersport.de> 2010-02-16 18:14:25 UTC ---
Trustpath and network setting woodoo. *sigh* From the debug output (SA 3.2.5,
mind you, there are possibly relevant code-changes in 3.3), using
trusted_networks 128.111.151.61 128.111.151.41
X-Spam-Relays-Trusted:
[ ip=128.111.151.61 rdns=outgoing-1.umail.ucsb.edu
helo=outgoing-1.umail.ucsb.edu
by=lifesci.lifesci.ucsb.edu ident= envfrom= intl=1 id=o15NJLEl029472
auth= msa=0 ]
[ ip=128.111.151.41 rdns=web-1.umail.ucsb.edu helo=localhost
by=outgoing-1.umail.ucsb.edu ident=
envfrom=xxx@umail.ucsb.edu intl=1 id=1NdXSK-0001uA-ML
auth= msa=0 ]
[ ip=68.120.70.160 rdns=adsl-68-120-70-160.dsl.irvnca.pacbell.net
helo=adsl-68-120-70-160.dsl.irvnca.pacbell.net
by=webaccess.umail.ucsb.edu ident= envfrom= intl=1 id=
auth=HTTP msa=0 ]
Hmm, why is that one in trusted? Deemed the same as the trusted .41 above, plus
authenticated user?
X-Spam-Relays-Untrusted:
[ ip=68.120.70.160 rdns= helo= by= ident= envfrom= intl=0 id= auth= msa=0 ]
Harvested from the X-Originating-IP: header. That's what trips PBL.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6334] RCVD_IN_PBL false positives against IMP "Received" header
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6334
Karsten Bräckelmann <gu...@rudersport.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Karsten Bräckelmann <gu...@rudersport.de> 2010-02-15 16:55:31 UTC ---
This is unrelated to PBL or the respective SA rule.
The problem is, that all SMTP servers in the chain are in your internal
network, including the user's outgoing SMTP. Given the user's outgoing SMTP is
considered internal, the handing-over IP *is* the user's IP.
In such a case, actual botnet spam is indistinguishable from users submitting
directly into your internal network.
While I admit this is an issue, unless the SA network settings are carefully
set up, and/or the user's outgoing SMTP is distinct from your inbound MX --
IMHO this is not a bug.
Closing. Please feel free to re-open, if you still believe this to be a SA bug.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.