Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: SpamAssassin: devel

[Bug 6764] When used with fetchmail, SA can inappropriately test

 

 

SpamAssassin devel RSS feed   Index | Next | Previous | View Threaded


bugzilla-daemon at bugzilla

Feb 22, 2012, 11:12 AM

Post #1 of 6 (181 views)
Permalink
[Bug 6764] When used with fetchmail, SA can inappropriately test

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764

Kevin A. McGrail <kmcgrail [at] pccc> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |kmcgrail [at] pccc
Resolution| |INVALID

--- Comment #1 from Kevin A. McGrail <kmcgrail [at] pccc> 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.


bugzilla-daemon at bugzilla

Feb 22, 2012, 4:15 PM

Post #2 of 6 (173 views)
Permalink
[Bug 6764] When used with fetchmail, SA can inappropriately test [In reply to]

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764

Mark Porthouse <mark [at] markporthouse> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |mark [at] markporthouse
Resolution|INVALID |

--- Comment #2 from Mark Porthouse <mark [at] markporthouse> 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.


bugzilla-daemon at bugzilla

Feb 23, 2012, 5:38 AM

Post #3 of 6 (174 views)
Permalink
[Bug 6764] When used with fetchmail, SA can inappropriately test [In reply to]

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764

RW <rwmaillists [at] googlemail> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |rwmaillists [at] googlemail

--- Comment #3 from RW <rwmaillists [at] googlemail> 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.


bugzilla-daemon at bugzilla

Feb 23, 2012, 6:10 AM

Post #4 of 6 (174 views)
Permalink
[Bug 6764] When used with fetchmail, SA can inappropriately test [In reply to]

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764

--- Comment #4 from Mark Porthouse <mark [at] markporthouse> 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: <bob [at] domain>
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 [at] localhos
Delivered-To: alice [at] localhost
Received: from finaldestination.personaldomain.tld (localhost.localdomain
[127.0.0.1])
by finaldestination.personaldomain.tld (Postfix) with ESMTP id 92BFB121525
for <alice [at] localhos>; 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 <alice [at] localhos> (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" <bob [at] domain>
To: "'Alice'" <alice [at] domain>
References: <004901ccf083$e77d91d0$b678b570$@domain.tld>
<4F437473.9080400 [at] personaldomain> <4F437518.4060309 [at] domain>
<005e01ccf087$d62dd1c0$82897540$@domain.tld> <4F437A1F.6040508 [at] domain>
In-Reply-To: <4F437A1F.6040508 [at] domain>
Subject: [SPAM] An email that falls victim to SA
Date: Tue, 21 Feb 2012 11:06:57 -0000
Message-ID: <006201ccf088$ee2851a0$ca78f4e0$@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 [at] domain

2.2.2.2 is the IP address of the mail.domain.tld server

alice [at] localhos (personaldomain.tld) is the final recipient on the server
finaldestination.personaldomain.tld

alice [at] domain 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.


bugzilla-daemon at bugzilla

Feb 23, 2012, 6:47 AM

Post #5 of 6 (172 views)
Permalink
[Bug 6764] When used with fetchmail, SA can inappropriately test [In reply to]

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764

--- Comment #5 from RW <rwmaillists [at] googlemail> 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.


bugzilla-daemon at bugzilla

Feb 23, 2012, 6:58 AM

Post #6 of 6 (173 views)
Permalink
[Bug 6764] When used with fetchmail, SA can inappropriately test [In reply to]

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764

Kevin A. McGrail <kmcgrail [at] pccc> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |INVALID

--- Comment #6 from Kevin A. McGrail <kmcgrail [at] pccc> 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.

SpamAssassin devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.