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

Mailing List Archive: SpamAssassin: users

With fetchmail, SA can inappropriately test

 

 

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


lists1 at markporthouse

Feb 23, 2012, 9:32 AM

Post #1 of 3 (373 views)
Permalink
With fetchmail, SA can inappropriately test

Hello,

I've just experienced a *very unusual scenario* where SA is checking the
reputation of the dynamic public IP address of the sending desktop
client's authorised SMTP connection to their SMTP server.

Usually SA would check the reputation of the IP address of SMTP relay,
not the reputation of the dynamic IP address of the sending desktop.
However, in this case there is no SMTP relay...

The scenario is this:
bob [at] domain sends an email to alice [at] domain He does this across
the internet from his dynamic IP address using SMTP auth so that the
domain.tld mailserver will deliver his message (which is delivered
straight into the alice [at] domain mailbox on the same server).
Alice uses fetchmail to pick up mail from her alice [at] domain mailbox
and place it into her alice [at] personaldomain mailbox on another server.
Spamassassin is running on the second server, the personaldomain.tld
server (the one that runs the Fetchmail transaction).

In my mind Spamassassin sees that the last transaction is the Fetchmail
transaction and knows not to check the reputation of the IP address of
domain.tld (POP) mail server. So it then checks the IP address of the
machine that delivered to the domain.tld mail server (normally this
would be the IP address of an SMTP relay which would be likely to have a
good reputation on the Internet). In this case it isn't the address of a
relaying SMTP server, it is the disreputable IP address of the sending
desktop - which we would never want to check.

When fetchmail isn't part of the equation, SA knows not to check the
reputation of the dynamic IP address of the sending desktop. Such a
scenario would be where bob [at] domain sends, from his home PC, to
alice [at] domain and Spamassassin runs on the domain.tld mail server -
it knows not to check Bob's sending IP address.

Here are headers from a real example of the problem, I have swapped user
names, server names and IP addresses (as referenced at the bottom):
------------------------------------------------------------------
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

It is possible that I got ahead of myself and posted this as a bug, but
from the responses here:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6764
However, I have been able to word my explanation better since posting
the 'bug'.

I'm currently not convinced that it isn't a bug, as I don't think that
it is a problem with trusted networks or procmail.

Cheers,

Mark


rwmaillists at googlemail

Feb 23, 2012, 10:36 AM

Post #2 of 3 (351 views)
Permalink
Re: With fetchmail, SA can inappropriately test [In reply to]

On Thu, 23 Feb 2012 17:32:27 +0000
Mark Porthouse wrote:

> Hello,
>
> I've just experienced a *very unusual scenario* where SA is checking
> the reputation of the dynamic public IP address of the sending
> desktop client's authorised SMTP connection to their SMTP server.

>
> I'm currently not convinced that it isn't a bug, as I don't think
> that it is a problem with trusted networks or procmail.

We went though this on the bug tracker. SA is failing to differentiate
between an mx handover and submission. The main way that it does this
via internal and trusted network settings. If you have submission on
the same IP address as the MX server, or you network setting are wrong
then it can fall back to detecting Authentication. In your case no
authentication is recorded in the received header.

This has nothing to do with pop or fetchmail, It's just that submission
servers commonly share an IP address with pop/imap.


What you need to do is determine whether the POP/submission server is
also the MX server. If it isn't then you fix your problem through
configuration, otherwise you have to work around it.


rwmaillists at googlemail

Feb 23, 2012, 3:50 PM

Post #3 of 3 (357 views)
Permalink
Re: With fetchmail, SA can inappropriately test [In reply to]

On Thu, 23 Feb 2012 21:25:40 +0000
Mark Porthouse wrote:

> On 23/02/2012 18:36, RW wrote:
> > We went though this on the bug tracker. SA is failing to
> > differentiate between an mx handover and submission. The main way
> > that it does this via internal and trusted network settings. If you
> > have submission on the same IP address as the MX server, or you
> > network setting are wrong then it can fall back to detecting
> > Authentication. In your case no authentication is recorded in the
> > received header.
>
> Submission is *not* on the same server that SA is running on.

Yes, I know.

> Whilst POP, IMAP and SMTP are running on the one and only MX for that
> domain, SA is running on the server that has just used fetchmail to
> pick up the mail using POP from the MX for the domain.
>
> Surely SA cannot be confident that mail received by the MX (that the
> SA equipped, final destination server fetchmails from) has either
> been sent via an authenticating client or by a relay.

With most ESPs/ISPs it can.

If you retreive mail via fetchmail you really need to extend the
internal network to the remote mx servers because many important tests
that target botnets only run on the handover to the internal network.

Spamassassin provides two ways of preventing FPs from mail client
submissions. The first is to put the submission server into the trusted
network, but not the internal network (this is pretty much the purpose
of the trusted/internal distinction). The second method is that the
tests on the internal network handover are disabled if authentication
is detected in the received header

In your case neither mechanism works. You can't distinguish by IP
address or received header. You can of course just put the server in
trusted networks, but that will degrade Spamassassin's effectiveness
significantly unless the server itself is doing aggression filtering
against botnets.

SpamAssassin users 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.