We figured it out. Wanted to post something back for the next guy-
there's a patch for spamass-milter. We simplified it down to always
allowing authenticated users.
in the spamass-milter 0.3.1 soure code, in the file called
spamass-milter.cpp, search for a couple lines that look like
struct c
digitalsushi wrote:
I've changed my sendmail configuration to be more verbose about the
authentication information.
To add to this, I've discovered that it can match any token in the Received:
line that does NOT include an equals sign in it:
spamass-milter probably isn't checking the macros fo
On Wed, 20 Jun 2007, digitalsushi wrote:
> header LOCAL_AUTH_RCVD2ALL =~ /(authenticated bits=0)/
That's vulnerable to forgery.
If you're checking Received headers this way to whitelist, you
*really* want to include your local hostname and/or IP information in
the RE. That will make it
On Wed, 20 Jun 2007, digitalsushi wrote:
> header BLAH Received =~ /blah/
> score BLAH -800.0
>
> And it's not picking it up. So I really have no idea what the
> pattern is.
N.B.: if you're using a plugin/milter to have the MTA pass messages to
SA during the SMTP phase (i.e. before the
One last update and I'll shut up for a bit.
I've updated my server to make my Received headers look literally like this:
Received: from [132.177.124.246] (doombox.iol.unh.edu [132.177.124.246])
(user=mikecrelay mech=PLAIN bits=0)
blah
by postal.iol.unh.edu (8.14.0/8.14.0) with ESMTP
I've changed my sendmail configuration to be more verbose about the
authentication information.
To add to this, I've discovered that it can match any token in the Received:
line that does NOT include an equals sign in it:
Received: from [132.177.124.246] (doombox.iol.unh.edu [132.177.124.246])
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 vers
