Greetings and salutations,

We use sendmail, spamassassin, and the spamass-milter at our site.  If a
user authenticates, we give them -100 spam points.  After a somewhat recent
update, we discovered our rule is not matched any longer.  The details:

Using
$ spamassassin --version
SpamAssassin version 3.2.1 (gentoo)
  running on Perl version 5.8.8

And previously 3.1.8

being run via spamass-milter configured in sendmail 8.14.0, we have in our
/etc/spamassassin/local.cf configuration:

header  LOCAL_AUTH_RCVD2        ALL =~ /(authenticated bits=0)/
score   LOCAL_AUTH_RCVD2        -100.0

spamd starts with: SPAMD_OPTS="-m 50 -c -H -u spamc"

If I send this email:
#start
From: [EMAIL PROTECTED]
To: Mike Cross <[EMAIL PROTECTED]>
Subject: test
Date: Tue, 19 Jun 2007 12:38:41 -0400
Return-Path: <[EMAIL PROTECTED]>
Received: from [192.168.15.109] (c-24-61-193-245.hsd1.nh.comcast.net
[24.61.193.245])
        (authenticated bits=0)
        by postal.iol.unh.edu (8.14.0/8.14.0) with ESMTP id l5JFE2AY006703
        (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
        for <[EMAIL PROTECTED]>; Tue, 19 Jun 2007 11:14:02 -0400
Message-ID: <[EMAIL PROTECTED]>
Date: Tue, 19 Jun 2007 11:14:04 -0400
From: [EMAIL PROTECTED]
Reply-To:  [EMAIL PROTECTED]
Organization: UNH-IOL
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To:  [EMAIL PROTECTED]
Subject: spam test
Content-Type: multipart/mixed; boundary="----------=_4677F2BE.7E5AE742"
Content-Transfer-Encoding: 7bit
#end

through spamassassin as a user by running
spamassassin < test.email

then the lines in the configuration file are applied as they properly match
the "(authenticated bits=0)":

#start
X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on
postal.iol.unh.edu
X-Spam-Level: 
X-Spam-Status: No, score=-96.7 required=8.0 tests=ALL_TRUSTED,
        HEADER_COUNT_SUBJECT,INVALID_DATE,LOCAL_AUTH_RCVD2 autolearn=ham
version=3.2.1
From: [EMAIL PROTECTED]
To: Mike Cross <[EMAIL PROTECTED]>
Subject: test
Date: Tue, 19 Jun 2007 12:38:41 -0400
Return-Path: <[EMAIL PROTECTED]>
Received: from [192.168.15.109] (c-24-61-193-245.hsd1.nh.comcast.net
[24.61.193.245])
        (authenticated bits=0)
        by postal.iol.unh.edu (8.14.0/8.14.0) with ESMTP id l5JFE2AY006703
        (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
        for <[EMAIL PROTECTED]>; Tue, 19 Jun 2007 11:14:02 -0400
Message-ID: <[EMAIL PROTECTED]>
Date: Tue, 19 Jun 2007 11:14:04 -0400
From: [EMAIL PROTECTED]
Reply-To:  [EMAIL PROTECTED]
Organization: UNH-IOL
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To:  [EMAIL PROTECTED]
Subject: spam test
Content-Type: multipart/mixed; boundary="----------=_4677F2BE.7E5AE742"
Content-Transfer-Encoding: 7bit
#end

The problem is that the configuration does not apply to emails sent through
the MTA.  If we try to match other components in that header, it works.

It was working globally in the previous iteration (I apologize I don't have
which specific version of spamassassin this was)

I have a suspicion we're zoomed in too close to see what the issue is.  Any
hints?  If the method we're using to accomplish this requirement is stupid,
I'm listening... thanks folks!
-- 
View this message in context: 
http://www.nabble.com/a-rule-to-allow-authenticated-users-stopped-working%2C-unless-run-at-user-level-tf3952490.html#a11213738
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Reply via email to