Shane,
Your example *is* much better. What you are showing, if my
assumptions are correct (I list them below) is everything working
exactly as it is designed to - i.e. both IMP and SA are doing the
correct things.
1) I assume that the receiving host "mail.ischool.utexas.edu" is a
trusted host for the machine where SA runs (apparently the host
"fiat.ischool.utexas.edu").
2) IMP is creating a valid header showing that it received mail from
the machine "cpe-70-112-27-200.austin.res.rr.com", which is a dynamically
assigned address.
3) Here is the problem: You feel that because (likely) some type of
authentication was required for that connection (i.e. between the RR
cable host and "mail."), the SA should not complain.
The answer is what was said before, make it so that "mail." is
not a "trusted" host and you will be saved by the "-notfirsthop" qualifier.
Basically, here you are allowing the user of a dynamic IP to avoid going
through his ISP's servers - which is the very type of situation these rules
are intended to catch. Another way to see it is that "mail." is serving as
if it *were* and ISP's box, and even though you may require some authentication
SA has no way to know that.
It would appear that you have three real choices:
a) disable the rule (not advisable)
b) mark "mail." as "untrusted" for SA (probably the easiest)
c) provide dynamic DNS for all your users, require them to use it and exempt
the domain you pick (probably the most work and you'd still have to validate
the domain membership somehow).
All three of these cases would work, but what you seem to have shown
is both IMP and SA are working correctly, just you have/had a misunderstanding
regarding what these rules are intended to do. They are doing exactly the
correct thing - Imagine the case where someone from across the country
connects to the "mail." machine using the web interface but coming from a
virus infected PC on (picked at random) adelphia cable from Florida. SA
would properly mark and score everything as coming from a dynamic host.
You may *know* that "mail." required some authentication scheme which
you (probably correctly) trust, but SA doesn't know that. By far, the easiest
way to deal with this is to mark "mail." as untrusted - then it will be assumed
to have some sort of authentication (just as an ISP's mail server would), and
there won't be any issue any longer.
You have actually cleared things up quite a bit: Your example, if
my assumptions are correct, shows that neither IMP nor SA is doing anything
wrong or seems to have any bugs - just there is no mechanism to allow them
to "communicate" to each other that a trusted authentication has occurred.
For that issue, you could open a Bugzilla requesting an enhancement to allow
some type of communication of that sort to occur or an enhancement (probably
harder still) to allow another class of hosts (besides just "trusted" and
"untrusted") which are both trusted, but would have the "-notfirsthop"
qualifier applied to them, not to a prior host (i.e. pretend that that host
was the "firsthop").
Best of luck,
Paul Shupak
[EMAIL PROTECTED]
P.S. Sorry for "top-posting", but this is one of those rare cases where it
seemed appropriate, since I left you message intact below.
>Return-Path: <[EMAIL PROTECTED]>
>Received: from mail.apache.org (hermes.apache.org [209.237.227.199])
> by mailhub.plectere.com (Postfix) with SMTP id BDE3668AD
> for <[EMAIL PROTECTED]>; Thu, 3 Mar 2005 08:57:29 -0800 (PST)
>Received: (qmail 89672 invoked by uid 500); 3 Mar 2005 16:57:28 -0000
>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
>Precedence: bulk
>list-help: <mailto:[EMAIL PROTECTED]>
>list-unsubscribe: <mailto:[EMAIL PROTECTED]>
>List-Post: <mailto:[email protected]>
>List-Id: <users.spamassassin.apache.org>
>Delivered-To: mailing list [email protected]
>Received: (qmail 89659 invoked by uid 99); 3 Mar 2005 16:57:28 -0000
>X-ASF-Spam-Status: No, hits=0.1 required=10.0
> tests=FORGED_RCVD_HELO
>X-Spam-Check-By: apache.org
>Received-SPF: pass (hermes.apache.org: local policy)
>Received: from fiat.ischool.utexas.edu (HELO fiat.ischool.utexas.edu)
>(128.83.248.27)
> by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 03 Mar 2005 08:57:26 -0800
>Received: from shanew.net (fiat.ischool.utexas.edu [128.83.248.27])
> by fiat.ischool.utexas.edu (8.12.11/8.12.11) with ESMTP id
> j23GvLGD004371
> (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
> for <[email protected]>; Thu, 3 Mar 2005 10:57:22 -0600
>Received: from shanew.net (localhost.localdomain [127.0.0.1])
> by shanew.net (8.12.11/8.12.11) with ESMTP id j23GvEUt027149
> for <[email protected]>; Thu, 3 Mar 2005 10:57:15 -0600
>Received: from localhost ([EMAIL PROTECTED])
> by shanew.net (8.12.11/8.12.11/Submit) with ESMTP id j23GvENJ027146
> for <[email protected]>; Thu, 3 Mar 2005 10:57:14 -0600
>Date: Thu, 3 Mar 2005 10:57:14 -0600 (CST)
>From: Shane Williams <[EMAIL PROTECTED]>
>To: [email protected]
>Subject: Re: Webmail and IP rules
>In-Reply-To: <[EMAIL PROTECTED]>
>Message-ID: <[EMAIL PROTECTED]>
>References: <[EMAIL PROTECTED]>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>X-shanew-MailScanner-Information: Please contact the ISP for more information
>X-shanew-MailScanner: Found to be clean
>X-MailScanner-From: [EMAIL PROTECTED]
>X-iSchool-MailScanner-Info: Contact [EMAIL PROTECTED] for help
>X-iSchool-MailScanner: Found to be clean
>X-Virus-Checked: Checked
>
>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: <[EMAIL PROTECTED]>
>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 <[EMAIL PROTECTED]>; 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
> <[EMAIL PROTECTED]>; 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: <[EMAIL PROTECTED]>
>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 <[EMAIL PROTECTED]>; 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
> <[EMAIL PROTECTED]>; 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 | [EMAIL PROTECTED]
>Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
