You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Raimar Sandner <li...@404not-found.de> on 2006/07/06 04:10:22 UTC
false positive with dialup to gmx, problem with HELO_DYNAMIC?
Hi!
SpamAssassin version 3.1.3 is reporting a false positive if the
sender (gmx address) has a dialup connection and the recepiant (also
gmx address) uses fetchmail to pull the message from pop.gmx.net
(see example below). The HELO_DYNAMIC rules apply because mail.gmx.net
does not add authentication tokens to the recieved header, and because
mail.gmx.net does not relay the message.
Is there a way to tell SA that I'm positive about mail.gmx.net to
only allow authenticated connections, similar to trusted_networks?
Adding mail.gmx.net to trusted_networks does not help.
Or have I missed the point of HELO_DYNAMICs?
Cheers
Raimar Sandner
=================================== example
[9097] dbg: dns: is DNS available? 1
[9097] dbg: received-header: found fetchmail marker outside trusted area, ignored
[9097] dbg: dns: looking up PTR record for '84.56.243.215'
[9097] dbg: dns: PTR for '84.56.243.215': 'dslb-084-056-243-215.pools.arcor-ip.net'
[9097] dbg: received-header: parsed as [ ip=84.56.243.215 rdns=dslb-084-056-243-215.pools.arcor-ip.net helo=dslb-084-056-243-215.pools.arcor-ip.net by=mail.gmx.net ident= envfrom= intl=0 id= auth= ]
[9097] dbg: received-header: relay 84.56.243.215 trusted? no internal? no
[9097] dbg: metadata: X-Spam-Relays-Trusted:
[9097] dbg: metadata: X-Spam-Relays-Untrusted: [ ip=84.56.243.215 rdns=dslb-084-056-243-215.pools.arcor-ip.net helo=dslb-084-056-243-215.pools.arcor-ip.net by=mail.gmx.net ident= envfrom= intl=0 id= auth= ]
[9097] dbg: metadata: X-Spam-Relays-Internal:
[9097] dbg: metadata: X-Spam-Relays-External: [ ip=84.56.243.215 rdns=dslb-084-056-243-215.pools.arcor-ip.net helo=dslb-084-056-243-215.pools.arcor-ip.net by=mail.gmx.net ident= envfrom= intl=0 id= auth= ]
<snip>
[9097] dbg: check: is spam? score=7.755 required=5.0
[9097] dbg: check: tests=BAYES_00,HELO_DYNAMIC_DHCP,HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,SPF_FAIL
[9097] dbg: check: subtests=__CD,__CT,__CTYPE_HAS_BOUNDARY,__ENV_AND_HDR_FROM_MATCH,__HAS_MSGID,__HAS_RCVD,__HAS_SUBJECT,__MIME_VERSION,__MSGID_OK_DIGITS,__NONEMPTY_BODY,__RCVD_IN_NJABL,__SANE_MSGID,__SARE_BODY_BLANKS_5_100,__SARE_BODY_BLNK_5_100,__SARE_HEAD_HDR_XGMXAV,__SARE_HEAD_MIME_VALID,__SARE_HEAD_RECV_GMX,__SARE_WHITELIST_FLAG,__TOCC_EXISTS,__USER_AGENT
Content analysis details: (7.8 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
4.2 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr
1)
3.1 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP)
1.1 SPF_FAIL SPF: sender does not match SPF record (fail)
[SPF failed: Please see http://www.openspf.org/why.html?sender=...%40gmx.de&ip=84.56.243.215&receiver=localhost]
-2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
[score: 0.0000]
1.9 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP
[84.56.243.215 listed in combined.njabl.org]
Return-Path: <.....@gmx.de>
X-Flags: 0000
Delivered-To: GMX delivery to ...@gmx.de
Received: from pop.gmx.net [213.165.64.22]
by localhost with POP3 (fetchmail-6.3.4)
for <rs...@localhost> (single-drop); Thu, 06 Jul 2006 00:03:40 +0200 (CEST)
Received: (qmail invoked by alias); 05 Jul 2006 22:03:21 -0000
Received: from dslb-084-056-243-215.pools.arcor-ip.net (EHLO localhost) [84.56.243.215]
by mail.gmx.net (mp039) with SMTP; 06 Jul 2006 00:03:21 +0200
X-Authenticated: #3609755
Date: Thu, 6 Jul 2006 00:03:12 +0200
From: Raimar Sandner <.....@gmx.de>
To: ...@gmx.de
Subject: Test
Message-ID: <20...@bluescreen.404not-found.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j"
Content-Disposition: inline
User-Agent: Mutt/1.5.11
X-GMX-Antivirus: -1 (not scanned, may not use virus scanner)
X-GMX-Antispam: -2 (not scanned, spam filter disabled)
X-GMX-UID: TEbFK1cPMydyFcxBXWpl/+5raGRhZtpE
=================================== end example
Re: false positive with dialup to gmx, problem with HELO_DYNAMIC?
Posted by jdow <jd...@earthlink.net>.
From: "Raimar Sandner" <li...@404not-found.de>
> On 01:51 Thu 06 Jul , Daryl C. W. O'Shea wrote:
>
>> Removing mail.gmx.net from your trusted networks will work. Of course
>> you can only do that if both 213.165.64.21 and 213.165.64.20 don't
>> appear in mail relayed via your (or gmx.net's) MXes.
>
> I tried both, mail.gmx.net in trusted networks and not in trusted
> network. The result is exactly the same. You are right if the
> scenario is:
>
> dialup sender --> mail.gmx.net --> myprovider.com --> fetchmail
>
> because then X-Spam-Relays-Untrusted will contain an aditional
> record for mail.gmx.net relaying the mail to myprovider.com,
> HELO_DYNAMICs don't match.
>
> But with
>
> dialup sender --> mail.gmx.net --> fetchmail
>
> there is only one record in X-Spam-Relays-Untrusted, and therefore
> the HELO_DYNAMICs will match.
Strangely enough that is EXACTLY the situation the rule is supposed
to catch. Your correspondent will have to change his habits or email
configuration. (Or you whitelist the whole range of addresses she
might use.)
{o.o} Joanne
Re: false positive with dialup to gmx, problem with HELO_DYNAMIC?
Posted by Raimar Sandner <li...@404not-found.de>.
On 01:51 Thu 06 Jul , Daryl C. W. O'Shea wrote:
> Removing mail.gmx.net from your trusted networks will work. Of course
> you can only do that if both 213.165.64.21 and 213.165.64.20 don't
> appear in mail relayed via your (or gmx.net's) MXes.
I tried both, mail.gmx.net in trusted networks and not in trusted
network. The result is exactly the same. You are right if the
scenario is:
dialup sender --> mail.gmx.net --> myprovider.com --> fetchmail
because then X-Spam-Relays-Untrusted will contain an aditional
record for mail.gmx.net relaying the mail to myprovider.com,
HELO_DYNAMICs don't match.
But with
dialup sender --> mail.gmx.net --> fetchmail
there is only one record in X-Spam-Relays-Untrusted, and therefore
the HELO_DYNAMICs will match.
Re: false positive with dialup to gmx, problem with HELO_DYNAMIC?
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Raimar Sandner wrote:
> Hi!
>
> SpamAssassin version 3.1.3 is reporting a false positive if the
> sender (gmx address) has a dialup connection and the recepiant (also
> gmx address) uses fetchmail to pull the message from pop.gmx.net
> (see example below). The HELO_DYNAMIC rules apply because mail.gmx.net
> does not add authentication tokens to the recieved header, and because
> mail.gmx.net does not relay the message.
>
> Is there a way to tell SA that I'm positive about mail.gmx.net to
> only allow authenticated connections, similar to trusted_networks?
> Adding mail.gmx.net to trusted_networks does not help.
Removing mail.gmx.net from your trusted networks will work. Of course
you can only do that if both 213.165.64.21 and 213.165.64.20 don't
appear in mail relayed via your (or gmx.net's) MXes.
Daryl