You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Shane Williams <sh...@shanew.net> on 2005/03/02 19:29:57 UTC
Webmail and IP rules
I noticed the HELO_DYNAMIC_* thread and the conclusion that IMP adding
a Received header may be a source of problems. I pieced together the
same conclusion just this morning based on several false positives
that went through our campus' IMP-based webmail. In addition to
the several variations of HELO_DYNAMIC_*, I also saw one which hit an
SPF rule (since it didn't get relayed through the "official" relay.
My first question, for anyone who knows the relavent RFCs better than
I, is IMP's behavior of adding a Received header following specs?
Second, has anyone determined the best way to handle this? The two
options that immediately come to mind would be to turn off the
HELO_DYNAMIC_* rules (but I suspect this would cause more false
negatives), or create a score-lowering rule that fires when a
webmail/IMP header is detected (also problematic since a webmail
header isn't necessarily related to the spamminess of the email, only
to the likely existence of false triggers on other rules).
Alternately, is this something that spammassassin should be taking
into account in its analysis? That is, when SA sees a "with HTTP"
descriptor in a received header, it should just ignore that header
altogether (or ignore it in relation to certain rules).
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT iSchool
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Webmail and IP rules
Posted by Shane Williams <sh...@shanew.net>.
Let me make it clear that I'm not convinced yet where the "problem"
really lies. IMP's Received header seems deceptively "real", but for
all I know this meets (or at least doesn't contradict) some RFC. On
the other hand even if the problem should be fixed by the IMP devs, it
may be easier to "fix" spamassassin. I don't know. That's why I
posted.
While the original question about HELO_DYNAMIC_* may have been
complicated by several localhost and 127.0.0.1 appearences in the
headers, neither of my examples have that issue. I'm providing two
examples to maybe help clarify what's happening.
I also want to understand how the trusted_hosts is interacting here.
I have no trusted_networks or internal_networks defined in my config.
Thus, SA is deciding on the fly that since webmailapp1.cc.utexas.edu
and fiat.ischool.utexas.edu are in the same domain, the former is
trusted? Thus, a dynamic address talking directly to webmailapp1
triggers the HELO_DYNAMIC_* rules? And if I tell my SA that
webmailapp1 is not trusted, then those hits go away? What about the
SPF hit in the first example? Or should I be defining
internal_networks instead of trusted_networks?
Return-Path: <xx...@ischool.utexas.edu>
Received: from mail.utexas.edu (fb1-a.its.utexas.edu [128.83.126.200])
by fiat.ischool.utexas.edu (8.12.11/8.12.11) with ESMTP id
j225uOWh008719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA
bits=256 verify=NO) for <xx...@ischool.utexas.edu>; Tue, 1
Mar 2005 23:56:24 -0600
Received: (qmail 84983 invoked by uid 80); 2 Mar 2005 05:56:24 -0000
Received: from cpe-70-112-27-200.austin.res.rr.com
(cpe-70-112-27-200.austin.res.rr.com [70.112.27.200]) by
webmailapp1.cc.utexas.edu (IMP) with HTTP for
<xx...@mail.ischool.utexas.edu>; Tue, 1 Mar 2005 23:56:24
-0600
....
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on
fiat.ischool.utexas.edu at Tue, 01 Mar 2005 23:56:35 -0600
X-Spam-Level: ******
X-Spam-Status: Yes, hits=6.2 required=5.0 tests=BAYES_00=-2.599,
HELO_DYNAMIC_DHCP=1.248,HELO_DYNAMIC_IPADDR=4.4,
SPF_HELO_SOFTFAIL=3.14 autolearn=no version=3.0.1
And, the other (where the localhost part is just Mailman)
Return-Path: <xx...@ischool.utexas.edu>
Received: from fiat.ischool.utexas.edu (localhost [127.0.0.1])
by fiat.ischool.utexas.edu (8.12.11/8.12.11) with ESMTP id
j1O0xH4l005696; Wed, 23 Feb 2005 18:59:17 -0600
Received: from mail.utexas.edu (fb4-a.its.utexas.edu [128.83.126.206])
by fiat.ischool.utexas.edu (8.12.11/8.12.11) with ESMTP id
j1NKMVRX020452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA
bits=256 verify=NO) for <xx...@ischool.utexas.edu>; Wed, 23
Feb 2005 14:22:31 -0600
Received: (qmail 1202 invoked by uid 80); 23 Feb 2005 20:22:31 -0000
Received: from adsl-66-143-178-53.dsl.austtx.swbell.net
(adsl-66-143-178-53.dsl.austtx.swbell.net [66.143.178.53])
by webmailapp3.cc.utexas.edu (IMP) with HTTP for
<xx...@mail.utexas.edu>; Wed, 23 Feb 2005 14:22:31 -0600
....
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on
fiat.ischool.utexas.edu at Wed, 23 Feb 2005 18:59:41 -0600
X-Spam-Level: ******
X-Spam-Status: Yes, hits=6.8 required=5.0 tests=BAYES_00=-2.599,
HELO_DYNAMIC_DHCP=1.248,HELO_DYNAMIC_HCC=3.741,
HELO_DYNAMIC_IPADDR=4.4,NO_REAL_NAME=0.007 autolearn=no
version=3.0.1
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT iSchool
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Webmail and IP rules
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Shane Williams wrote:
> I noticed the HELO_DYNAMIC_* thread and the conclusion that IMP adding
> a Received header may be a source of problems. I pieced together the
> same conclusion just this morning based on several false positives
> that went through our campus' IMP-based webmail. In addition to
> the several variations of HELO_DYNAMIC_*, I also saw one which hit an
> SPF rule (since it didn't get relayed through the "official" relay.
>
> My first question, for anyone who knows the relavent RFCs better than
> I, is IMP's behavior of adding a Received header following specs?
>
> Second, has anyone determined the best way to handle this? The two
> options that immediately come to mind would be to turn off the
> HELO_DYNAMIC_* rules (but I suspect this would cause more false
> negatives), or create a score-lowering rule that fires when a
> webmail/IMP header is detected (also problematic since a webmail
> header isn't necessarily related to the spamminess of the email, only
> to the likely existence of false triggers on other rules).
>
> Alternately, is this something that spammassassin should be taking
> into account in its analysis? That is, when SA sees a "with HTTP"
> descriptor in a received header, it should just ignore that header
> altogether (or ignore it in relation to certain rules).
I just stumbled upon this thread now. I must have missed it, or ignored
it thinking Shane wasn't using 3.0.2 which doesn't have this problem if
you set your trusted networks manually (3.0.2 will extend trust to IMP
hops if trusted_networks is set manually). Since Shane never mentioned
that he was letting SA infer the trust path, the fact that a bug was
still present wasn't obvious.
In any case, I've modified the inferral code to extend trust to (the
supported) authenticated relays, such as IMP's webmail received header.
It'll also work with any webmail software that adds 'with HTTP' tokens,
Sendmail style authentication tokens, or RFC 3848 compatible
authentication tokens.
So... the next major release of SA will fix Shane's problem. Until
then, setting trusted_networks manually will also fix his problem if he
is using SpamAssassin version 3.0.2.
Daryl