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 2012/02/22 19:45:52 UTC
[Bug 6764] New: When used with fetchmail, SA can inappropriately
test
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764
Bug #: 6764
Summary: When used with fetchmail, SA can inappropriately test
Product: Spamassassin
Version: 3.3.1
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: spamassassin
AssignedTo: dev@spamassassin.apache.org
ReportedBy: mark@markporthouse.net
Classification: Unclassified
The problem only occurs in the rare scenario where:
bob@domain.tld sends an email to alice@domain.tld
and
spamassassin is running on a second server, the personaldomain.tld server
and
alice@personaldomain.tld fetches the mail of alice@domain.tld from their
domain.tld mailbox into their personaldomain.tld server mailbox using
fetchmail.
In this scenario spamassassin on personaldomain.tld tests the smtp transaction
between the sending PC (which may be on a dynamic IP address) and the
domain.tld receiving server.
In no circumstances would anyone wish to use SA to test the transaction between
the sending mail client and the SMTP server used by that mail client (normally
you would test the transaction between the sender's SMTP server and the
recipient's SMTP server). Yet, this is what is happening in this instance
(probably because their isn't another transaction that you would want to test).
In this scenario there is no need to test the fetchmail transaction (a
fetchmail transaction would never be tested), which might be why spamassassin
is looking at the transaction into the recipient's server - which in this rare
case of the sender's smtp server being the recipient's server means that the
transaction being looked at is the one between mail client and the smtp server
set for that mail client.
Spamassassin cannot, after all, look at the internal mail server process which
receives the authenticated SMTP from the sending client and passes it into the
recipient's mailbox.
Basically, in this rare scenario, Spamassassin, on the server running
fetchmail, should not do any tests.
However, I'm not sure how it could be programmed to deduce that it is
experiencing this scenario where it should not do any tests!
--
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 6764] When used with fetchmail, SA can inappropriately test
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764
Kevin A. McGrail <km...@pccc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |INVALID
--- Comment #6 from Kevin A. McGrail <km...@pccc.com> 2012-02-23 14:58:07 UTC ---
Please discuss this on the users list if you feel it's a bug. To me, it is
either an administrative issue.
--
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 6764] When used with fetchmail, SA can inappropriately test
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764
--- Comment #5 from RW <rw...@googlemail.com> 2012-02-23 14:47:08 UTC ---
This is what I said: "it could be that the service provider does submission on
mx servers and fails to record authentication, in which case you either need
workarounds or to ditch the provider."
The following contains no record of authentication:
Received: from LaptopPC (dynamicip.someisp.tld [1.1.1.1]) by mail.domain.tld
with SMTP.
This is not a 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.
[Bug 6764] When used with fetchmail, SA can inappropriately test
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764
Mark Porthouse <ma...@markporthouse.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |mark@markporthouse.net
Resolution|INVALID |
--- Comment #2 from Mark Porthouse <ma...@markporthouse.net> 2012-02-23 00:15:49 UTC ---
Please bear with me, I do believe that I have a valid point here and I
recognise that the scenario is fairly unusual - but the scenario needs to be
understood to understand why this is likely to be a bug:
I don't believe that it is simply a matter of procmail needing to recognise the
fetchmail injection. Ideally you don't want to turn off the SA tests simply
because a fetchmail has occurred. When there is a fetchmail transaction you
will still want to run SA tests on the message.
SA always tests the last leg into the mail server that it is running on,
*except* when fetchmail is employed as the last leg. So, rather than testing
the fetchmail leg it tests the leg before (the leg into the mailbox that
fetchmail is picking up from). In this case it must *not* run route tests on
that leg because that leg is (surprisingly) the leg from the (probably
untrustworthy) IP address of the sending client.
SA needs to look at each of the legs of the message's journey and recognise
that it *shouldn't* examine the first transaction from email client to the
sending user's SMTP server, even though it might actually be the last leg
before the fetchmail transaction (it knows not to test the fetchmail leg).
Currently SA is testing the sending email client's send transaction to its
authenticating SMTP server - which it would *never* normally do.
In an identical scenario, but where there is no fetchmail last leg, SA knows
not to check the transaction from sending email client to its authenticating
SMTP server. For some reason, when there is a fetchmail last leg SA does not
know not to do route tests on that previous (first) leg, rather it simply
assumes that it should test that leg.
So, I was wrong to say that SA shouldn't run at all in the scenario I've given,
rather it just shouldn't run message route tests and only run message content
tests.
Perhaps this entry would be better classified under 'score generation' or
'Rules' or something, as it seems clear that we don't want SA to *not* run in
this scenario, just for it not to run route type tests.
--
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 6764] When used with fetchmail, SA can inappropriately test
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764
RW <rw...@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rwmaillists@googlemail.com
--- Comment #3 from RW <rw...@googlemail.com> 2012-02-23 13:38:36 UTC ---
If I'm reading this right, and we strip away all this talk about domains, the
problem occurs when someone submits an email through the service provider from
which you pull mail with fetchmail.
Spamassassin already deals with is this as well as it can. It is possible that
you have hit a specific bug, but it's more likely that you haven't setup
internal/trusted/msa networks properly. Failing that it could be that the
service provider does submission on mx servers and fails to record
authentication, in which case you either need workarounds or to ditch the
provider.
If you fully understand the issues and still think you have a bug then you need
to provide your internal/trusted/msa network setting and a sample set of
headers. Otherwise I would suggest you read the documentation first and then go
to the user mailing list.
--
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 6764] When used with fetchmail, SA can inappropriately test
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764
Kevin A. McGrail <km...@pccc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |kmcgrail@pccc.com
Resolution| |INVALID
--- Comment #1 from Kevin A. McGrail <km...@pccc.com> 2012-02-22 19:12:42 UTC ---
This is discussion for the user mailing list discussion as it is an
implementation question and not a bug.
My immediate $0.02 is that if you are using procmail, you need to change your
procmail recipe to recognize the fetchmail injection.
--
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 6764] When used with fetchmail, SA can inappropriately test
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764
--- Comment #4 from Mark Porthouse <ma...@markporthouse.net> 2012-02-23 14:10:50 UTC ---
Not merely "when someone submits an email through the service provider from
which you pull mail with fetchmail", more specifically:
when someone submits an email *to* the *actual mail server* (via auth smtp from
their desktop client connecting to that very mail server) from which you pull
mail with fetchmail.
Now, Spamassassin must not 'trust' that submission of email to the mail server
- that would open the door to spam generated by a trojan on desktop PC using
valid authenticating credentials, but it *must not* do route type tests on that
submission - because, of course, they will score badly because nobody wants to
trust just any old PC on the internet.
As I don't think that this an issue about "internal/trusted/msa network
setting" (I'm not willing to trust any old authenticating desktop client) I
won't submit those settings for now.
However, here is a sample header on a received message received with this
problem (where you can see that SA is scoring the dynamic IP of the sending
client!):
Return-Path: <bo...@domain.tld>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
finaldestination.personaldomain.tld
X-Spam-Flag: YES
X-Spam-Level: ******
X-Spam-Status: Yes, score=6.6 required=5.0 tests=BAYES_00,DOS_OUTLOOK_TO_MX,
FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,KHOP_DYNAMIC,RCVD_IN_PBL,RCVD_IN_RP_RNBL,
RDNS_DYNAMIC autolearn=no version=3.3.1
X-Spam-Report:
* 0.0 FSL_HELO_NON_FQDN_1 FSL_HELO_NON_FQDN_1
* 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
* [1.1.1.1 listed in zen.spamhaus.org]
* 1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL,
* https://senderscore.org/blacklistlookup/
* [1.1.1.1 listed in bl.score.senderscore.com]
* -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000]
* 1.0 RDNS_DYNAMIC Delivered to internal network by host with
* dynamic-looking rDNS
* 0.0 KHOP_DYNAMIC Relay looks like a dynamic address
* 0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly
* 2.8 DOS_OUTLOOK_TO_MX Delivered direct to MX with Outlook headers
X-Original-To: alice@localhost
Delivered-To: alice@localhost.personaldomain.tld
Received: from finaldestination.personaldomain.tld (localhost.localdomain
[127.0.0.1])
by finaldestination.personaldomain.tld (Postfix) with ESMTP id 92BFB121525
for <al...@localhost>; Tue, 21 Feb 2012 12:00:05 +0000 (GMT)
Received: from mail.domain.tld [2.2.2.2]
by finaldestination.personaldomain.tld with POP3 (fetchmail-6.3.17)
for <al...@localhost> (single-drop); Tue, 21 Feb 2012 12:00:05 +0000 (GMT)
Received: from LaptopPC (dynamicip.someisp.tld [1.1.1.1]) by mail.domain.tld
with SMTP;
Tue, 21 Feb 2012 11:07:00 +0000
From: "Bob" <bo...@domain.tld>
To: "'Alice'" <al...@domain.tld>
References: <00...@domain.tld>
<4F...@personaldomain.tld> <4F...@domain.tld>
<00...@domain.tld> <4F...@domain.tld>
In-Reply-To: <4F...@domain.tld>
Subject: [SPAM] An email that falls victim to SA
Date: Tue, 21 Feb 2012 11:06:57 -0000
Message-ID: <00...@domain.tld>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGdnF/FHhGEqV4Yrs225zGBTpWLTwLTwKJuAZnSI0UBXVVPSAHyqMEQlmfsjGA=
Content-Language: en-gb
X-SmarterMail-TotalSpamWeight: 0 (Authenticated)
X-Spam-Prev-Subject: An email that falls victim to SA
Notes about the above headers:
1.1.1.1 (dynamicip.someisp.tld) is the dynamically assigned IP address of the
sending client sending as bob@domain.tld
2.2.2.2 is the IP address of the mail.domain.tld server
alice@localhost (personaldomain.tld) is the final recipient on the server
finaldestination.personaldomain.tld
alice@domain.tld is the address that the email is sent to and a mailbox on the
domain.tld server (where fetchmail picks up from and delivers to Alice's
mailbox on finaldestination.personaldomain.tld
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.