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 2019/01/25 21:04:24 UTC
[Bug 7686] New: RCVD_IN_PBL false positive from X-Originating-IP
despite existence of ESMTPSA header
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7686
Bug ID: 7686
Summary: RCVD_IN_PBL false positive from X-Originating-IP
despite existence of ESMTPSA header
Product: Spamassassin
Version: 3.4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: minor
Priority: P2
Component: spamassassin
Assignee: dev@spamassassin.apache.org
Reporter: jordan@websavers.ca
Target Milestone: Undefined
Hey there,
Here's the headers:
Return-Path: barrington@i********t.ca
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sumac.websavers.ca
X-Spam-Flag: YES
X-Spam-Level: *****
X-Spam-Status: Yes, score=5.6 required=2.5 tests=BAYES_60,HTML_MESSAGE,
RCVD_IN_PBL,RDNS_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0
X-Spam-Report:
* 1.5 BAYES_60 BODY: Bayes spam probability is 60 to 80%
* [score: 0.6066]
* -0.0 SPF_PASS SPF: sender matches SPF record
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
* [142.68.14.248 listed in zen.spamhaus.org]
* 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Original-To: jm@i********t.ca
Delivered-To: jm@i********t.ca
Received: from webmail.websavers.ca (base.websavers.ca [192.95.53.248])
by sumac.websavers.ca (Postfix) with ESMTPSA id 9DA8A92564
for jm@i********t.ca; Thu, 24 Jan 2019 14:16:37 -0400 (AST)
Authentication-Results: sumac.websavers.ca;
spf=pass (sender IP is 192.95.53.248) smtp.mailfrom=bt@i********t.ca
smtp.helo=webmail.websavers.ca
Received-SPF: pass (sumac.websavers.ca: connection is authenticated)
MIME-Version: 1.0
Date: Thu, 24 Jan 2019 18:16:37 +0000
Content-Type: multipart/alternative;
boundary="--=_RainLoop_989_989733652.1548353797"
X-Mailer: RainLoop/1.12.1
From: bt@i********t.ca
Message-ID: 4928e3dd2bbaa60234fa97d7e8ecd7c9@i********t.ca
Subject: Friday Soup
To: "JM" jm@i********t.ca
X-Originating-IP: 142.68.14.248
I've read a lot of bug reports and mailing list commentary on this, all of
which are dismissed as invalid because there's no authenticated SMTP header,
which makes sense to me.
In this instance, however, the final Received header clearly indicates that
it's using ESMTPSA -- authenticated SMTP. Shouldn't the PBL lookup only be
happening against that IP and not the X-Originating-IP header address?
I've since disabled use of the X-Originating-IP header in rainloop to avoid
this from triggering again, but ultimately I think that's a pretty handy header
to have when troubleshooting issues, so I'd like to be able to use it.
Is this a bug, or is my understanding about which IPs should be checked against
the PBL flawed?
Thanks in advance for the commentary.
-Jordan
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7686] RCVD_IN_PBL false positive from X-Originating-IP despite
existence of ESMTPSA header
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7686
--- Comment #6 from Bill Cole <bi...@apache.org> ---
(In reply to Jordan from comment #5)
> In other words, external receiving servers would not check the
> x-originating-ip header *anyway* because the message is already coming from
> an untrusted source that is found higher up in the delivery chain?
>
> And in our case, it *is* checking x-originating-ip solely because the
> webmail server is already trusted, so x-originating-ip is the only untrusted
> IP left to check?
>
> Do I have that right?
YES
It is important to understand that "trusted" in SpamAssassin does not mean
"believed to not pass spam" but rather "believed to accurately record the
source of mail in parseable headers."
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7686] RCVD_IN_PBL false positive from X-Originating-IP despite
existence of ESMTPSA header
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7686
--- Comment #3 from Jordan <jo...@websavers.ca> ---
Something I'm still not clear on:
In the example provided we happen to operate both the RainLoop webmail system
that the message was sent *from* and the *receiving* server.
The spamassassin headers and PBL checks were done on the *receiving* server.
Therefore its on the *receiving* server that I would need to set msa_networks.
Great, this would solve things for when our servers happen to be the receiving
server.
But configuring msa_networks in Spamassassin does absolutely nothing when
someone sends a message to some server using Spamassassin that's out of our
control.
So I think I'm back to square one with the options being:
1. Disable the x-originating-ip header in RainLoop and simply do without its
diagnostic aid
2. Compile my own latest version of Spamassassin and deal with the binary
package differences, then hope that this *was* a bug which was fixed between
3.4.0 and 3.4.2
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7686] RCVD_IN_PBL false positive from X-Originating-IP despite
existence of ESMTPSA header
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7686
--- Comment #4 from Bill Cole <bi...@apache.org> ---
(In reply to Jordan from comment #3)
> Something I'm still not clear on:
>
> In the example provided we happen to operate both the RainLoop webmail
> system that the message was sent *from* and the *receiving* server.
>
> The spamassassin headers and PBL checks were done on the *receiving* server.
> Therefore its on the *receiving* server that I would need to set
> msa_networks.
>
> Great, this would solve things for when our servers happen to be the
> receiving server.
>
> But configuring msa_networks in Spamassassin does absolutely nothing when
> someone sends a message to some server using Spamassassin that's out of our
> control.
Machines that do not trust your webmail server (i.e. have it in
trusted_networks) would not check the it claims to have received the message
from.
This is not a bug, it's a configuration problem. If you need advice on how to
set up your *_networks you can find a wide range of SA users on the
SpamAssassin Users mailing list, possibly including someone who has run into
the same issue and can help in more depth.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7686] RCVD_IN_PBL false positive from X-Originating-IP despite
existence of ESMTPSA header
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7686
Bill Cole <bi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |billcole@apache.org
--- Comment #1 from Bill Cole <bi...@apache.org> ---
FIRST: You've reported the bug against (and your example shows) SpamAssassin
v3.4.0, which is obsolete, buggy and insecure. You should upgrade, and your
problem MAY have been fixed during the 4+ years between the releases of 3.4.0
and 3.4.2.
Which IP SA checks against PBL (if any) is determined in large part by the
internal_networks, trusted_networks, and msa_networks settings. The IP that is
checked is the last external address (i.e. NOT in internal_networks) which is
recorded by a trusted relay as the source of the message. If the last trusted
relay is in msa_networks, the IP it records as the source is NOT checked. In
this case, I suspect that the problem is that you have 192.95.53.248 in
trusted_networks and internal_networks, but not msa_networks. Any machine which
accepts initial submissions (i.e. from PBL-eligible machines) should be in all
3 network lists in most cases. See the documentation of
Mail::SpamAssassin::Conf for more information.
If this doesn't help you solve your problem, in order to look more closely at
this we would need a full example to reproduce the problem: a complete and
valid unredacted message which demonstrates the bug AND the relevant
configuration parameters, most importantly the *_networks settings.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7686] RCVD_IN_PBL false positive from X-Originating-IP despite
existence of ESMTPSA header
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7686
--- Comment #5 from Jordan <jo...@websavers.ca> ---
Hey Bill,
Thanks again for your quick comments!
I have no problem configuring spamassassin accordingly. I'm still a bit
confused about this part:
> Machines that do not trust your webmail server (i.e. have it in trusted_networks) would not check the it claims to have received the message from.
For clarity, should that read:
---
Machines that do not trust your webmail server (i.e. do not have the webmail
server IP in trusted_networks) would not check where it claims to have received
the message from.
---
In other words, external receiving servers would not check the x-originating-ip
header *anyway* because the message is already coming from an untrusted source
that is found higher up in the delivery chain?
And in our case, it *is* checking x-originating-ip solely because the webmail
server is already trusted, so x-originating-ip is the only untrusted IP left to
check?
Do I have that right?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7686] RCVD_IN_PBL false positive from X-Originating-IP despite
existence of ESMTPSA header
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7686
--- Comment #7 from Jordan <jo...@websavers.ca> ---
Thank you very much for the details -- I greatly appreciate it! We'll get our
msa_networks configured accordingly so it properly handles internal delivery.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7686] RCVD_IN_PBL false positive from X-Originating-IP despite
existence of ESMTPSA header
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7686
Jordan <jo...@websavers.ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jordan@websavers.ca
Resolution|--- |WORKSFORME
Status|NEW |RESOLVED
--- Comment #2 from Jordan <jo...@websavers.ca> ---
(In reply to Bill Cole from comment #1)
Thanks Bill!
> FIRST: You've reported the bug against (and your example shows) SpamAssassin v3.4.0, which is obsolete, buggy and insecure. You should upgrade, and your problem MAY have been fixed during the 4+ years between the releases of 3.4.0 and 3.4.2.
I figured that would be an issue. I'm using CentOS 7, and so getting updates
sadly means recompiling from src RPM, which isn't always a smooth process. It's
too bad you guys never got a repo of your own set up as was discussed here:
https://lists.apache.org/thread.html/ae9c9281fece9c8d9d21d18fe7f035ef804f080fe10f0707e3715004@%3Cusers.spamassassin.apache.org%3E
We'll be discussing internally how best to proceed as if we compile our own,
then we also have to ensure to stay on top of updates manually (rather than
relying on the standard yum update channels.
---
Will be testing and confirming the missing value from msa_networks as
suggested. I think between not running latest release and my likely
misconfiguration of msa_networks, it's safe to mark this resolved -- if I find
otherwise in my tests, we can always re-open it.
-Jordan
--
You are receiving this mail because:
You are the assignee for the bug.