You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Karl Boyken <bo...@divms.uiowa.edu> on 2008/01/24 16:22:47 UTC
Upgrade 3.2.3->3.2.4 breaks rule override
We're running SpamAssassin from MIMEDefang 2.63 on RedHat Linux
Enterprise Server 5. We recently upgraded SpamAssassin from 3.2.3 to
3.2.4. We'd configured sa-mimedefang.cf to use a local Spamhaus mirror
for __RCVD_IN_ZEN, RCVD_IN_XBL and RCVD_IN_PBL. I just copied over the
"header" lines from 20_dnsbl_tests.cf and replaced zen.spamhaus.org.
with the domain that the local mirror uses. The hack was working. But
when we upgraded to 3.2.4, it broke. Any suggestions as to how to
configure SpamAssassin to use the local Spamhaus mirror? Thanks.
Karl Boyken
--
Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)
Re: Redo: Upgrade 3.2.3->3.2.4 breaks rule override
Posted by Matthias Leisi <ma...@leisi.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kris Deugau schrieb:
|> I appreciate the advice to hack our DNS configuration, but I'd prefer
|> to keep all my SpamAssassin tweaks in the SpamAssassin config file and
|> not have to document and (subsequently remember to actually look at
|> the documentation ;) ) that I had to hack DNS as well.
|
| Well, if you're keeping a local mirror of the zone, it makes sense to
| tweak your DNS to return local data on queries to the "real" zone,
| because what if someone decides later on to add a DNSBL check in
| sendmail? What if someone finds some other use in some other place for
I *strongly* support Kris' advice. We see an awful lot of
misconfigurations of people who use their rsync'ed copy of dnswl.org
data *without* configuring their DNS servers.
Yes, I'm aware that - especially in company environments - it can be
tedious (often, at least network and mail teams need to talk to each
other...), but it is indispensible to get this right -- otherwise, the
whole rsync'ing exercise provides more trouble(shooting) than it's worth.
- -- Matthias, for dnswl.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
iD8DBQFHmuijxbHw2nyi/okRApkqAKC606su45A7396ycEC5p9EEdrc1QACfZOVT
Eu/hNFg6qPNfGevQ/5qtvXY=
=YF4Y
-----END PGP SIGNATURE-----
Re: Redo: Upgrade 3.2.3->3.2.4 breaks rule override
Posted by Karl Boyken <bo...@divms.uiowa.edu>.
Kris, thanks for the help. It looks to me like the problem may lie in
the way MIMEDefang 2.63 is interacting with SpamAssassin. When I run
spamassassin -D on a message that causes hits on the SpamHaus tests, it
scores correctly. Time to pester the MIMEDefang developers, maybe.
Karl
Kris Deugau wrote:
> Karl Boyken wrote:
>> We're running SpamAssassin from MIMEDefang 2.63 on RedHat Linux
>> Enterprise Server 5. With previous versions, I'd hacked our site-wide
>> configuration file to use a local Spamhaus mirror. The file I hacked
>> was the MIMEDefang config file sa-mimedefang.cf, which is equivalent
>> to hacking the site-wide local.cf file in a plain SpamAssassin setup.
>> I.e., I am specifically NOT hacking any of the files in
>> /usr/share/spamassassin.
>
> *nod* OK, that avoids overwriting-by-upgrading.
>
>> My hack was thus:
>>
>> grep zen /usr/share/spamassassin/20_dnsbl_tests.cf >> sa-mimedefang.cf
>>
>> and then I hacked the result "header" lines, substituting the
>> domainname our local mirror uses for "zen.spamhaus.org."
>
> I assume you did this (again) after upgrading? I don't recall when
> Spamhaus introduced the zen aggregate list and deprecated the other
> individual sublists, nor do I recall when that might have made its way
> into SpamAssassin - checking back shows identical tests in 3.2.3,
> anyway, so even if you didn't re-redefine the tests after upgrading it
> should still be working.
>
>> In versions prior to 3.2.4, this hack worked. SpamAssassin used our
>> local Spamhaus mirror, and RVCD_IN_XBL, RCVD_IN_PBL, and RCVD_IN_SBL
>> hits were appearing in our logs.
>>
>> But when I upgraded SpamAssassin to 3.2.4, the hack broke. A look at
>> the BIND query logs showed that SpamAssassin was still querying the
>> mirror, but now, the Spamhaus tests were no longer showing up in the
>> logs.
>
> ... hmm. How are you logging the tests? Are you seeing hits in the
> delivered mail? (either in your inbox or spam folder)
>
> What if you take a message that did, or should have, hit one of those
> rules and run it through the spamassassin command-line client on your
> mail server? spamassassin -D?
>
> ... are *any* DNS rules hitting after the upgrade?
>
>> I appreciate the advice to hack our DNS configuration, but I'd prefer
>> to keep all my SpamAssassin tweaks in the SpamAssassin config file and
>> not have to document and (subsequently remember to actually look at
>> the documentation ;) ) that I had to hack DNS as well.
>
> Well, if you're keeping a local mirror of the zone, it makes sense to
> tweak your DNS to return local data on queries to the "real" zone,
> because what if someone decides later on to add a DNSBL check in
> sendmail? What if someone finds some other use in some other place for
> that data? Each place the data gets queried then has to maintain
> configuration and/or notes that say "for queries to zen.spamhaus.org,
> query <local zone name> instead".
>
> But yeah, it *is* a little more tedious to get that right. <g>
>
>> So, is it possible to hack the site-wide SpamAssassin config file (in
>> my case, MIMEDefang's sa-mimedefang.cf) to use our local Spamhaus mirror?
>
> I can't see where things are going wrong for you; what you've done
> should work just fine. MIMEDefang used to require all SA site
> configuration in sa-mimedefang.cf for some odd reason, but it's been
> quite a while (~10-15 SA releases, probably ~10 MD releases) since that
> was the case.
>
> -kgd
--
Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)
Re: Redo: Upgrade 3.2.3->3.2.4 breaks rule override
Posted by Kris Deugau <kd...@vianet.ca>.
Karl Boyken wrote:
> We're running SpamAssassin from MIMEDefang 2.63 on RedHat Linux
> Enterprise Server 5. With previous versions, I'd hacked our site-wide
> configuration file to use a local Spamhaus mirror. The file I hacked
> was the MIMEDefang config file sa-mimedefang.cf, which is equivalent to
> hacking the site-wide local.cf file in a plain SpamAssassin setup. I.e.,
> I am specifically NOT hacking any of the files in /usr/share/spamassassin.
*nod* OK, that avoids overwriting-by-upgrading.
> My hack was thus:
>
> grep zen /usr/share/spamassassin/20_dnsbl_tests.cf >> sa-mimedefang.cf
>
> and then I hacked the result "header" lines, substituting the domainname
> our local mirror uses for "zen.spamhaus.org."
I assume you did this (again) after upgrading? I don't recall when
Spamhaus introduced the zen aggregate list and deprecated the other
individual sublists, nor do I recall when that might have made its way
into SpamAssassin - checking back shows identical tests in 3.2.3,
anyway, so even if you didn't re-redefine the tests after upgrading it
should still be working.
> In versions prior to 3.2.4, this hack worked. SpamAssassin used our
> local Spamhaus mirror, and RVCD_IN_XBL, RCVD_IN_PBL, and RCVD_IN_SBL
> hits were appearing in our logs.
>
> But when I upgraded SpamAssassin to 3.2.4, the hack broke. A look at
> the BIND query logs showed that SpamAssassin was still querying the
> mirror, but now, the Spamhaus tests were no longer showing up in the logs.
... hmm. How are you logging the tests? Are you seeing hits in the
delivered mail? (either in your inbox or spam folder)
What if you take a message that did, or should have, hit one of those
rules and run it through the spamassassin command-line client on your
mail server? spamassassin -D?
... are *any* DNS rules hitting after the upgrade?
> I appreciate the advice to hack our DNS configuration, but I'd prefer to
> keep all my SpamAssassin tweaks in the SpamAssassin config file and not
> have to document and (subsequently remember to actually look at the
> documentation ;) ) that I had to hack DNS as well.
Well, if you're keeping a local mirror of the zone, it makes sense to
tweak your DNS to return local data on queries to the "real" zone,
because what if someone decides later on to add a DNSBL check in
sendmail? What if someone finds some other use in some other place for
that data? Each place the data gets queried then has to maintain
configuration and/or notes that say "for queries to zen.spamhaus.org,
query <local zone name> instead".
But yeah, it *is* a little more tedious to get that right. <g>
> So, is it possible to hack the site-wide SpamAssassin config file (in my
> case, MIMEDefang's sa-mimedefang.cf) to use our local Spamhaus mirror?
I can't see where things are going wrong for you; what you've done
should work just fine. MIMEDefang used to require all SA site
configuration in sa-mimedefang.cf for some odd reason, but it's been
quite a while (~10-15 SA releases, probably ~10 MD releases) since that
was the case.
-kgd
Redo: Upgrade 3.2.3->3.2.4 breaks rule override
Posted by Karl Boyken <bo...@divms.uiowa.edu>.
Let me try this again:
We're running SpamAssassin from MIMEDefang 2.63 on RedHat Linux
Enterprise Server 5. With previous versions, I'd hacked our site-wide
configuration file to use a local Spamhaus mirror. The file I hacked
was the MIMEDefang config file sa-mimedefang.cf, which is equivalent to
hacking the site-wide local.cf file in a plain SpamAssassin setup.
I.e., I am specifically NOT hacking any of the files in
/usr/share/spamassassin.
My hack was thus:
grep zen /usr/share/spamassassin/20_dnsbl_tests.cf >> sa-mimedefang.cf
and then I hacked the result "header" lines, substituting the domainname
our local mirror uses for "zen.spamhaus.org."
In versions prior to 3.2.4, this hack worked. SpamAssassin used our
local Spamhaus mirror, and RVCD_IN_XBL, RCVD_IN_PBL, and RCVD_IN_SBL
hits were appearing in our logs.
But when I upgraded SpamAssassin to 3.2.4, the hack broke. A look at
the BIND query logs showed that SpamAssassin was still querying the
mirror, but now, the Spamhaus tests were no longer showing up in the logs.
I appreciate the advice to hack our DNS configuration, but I'd prefer to
keep all my SpamAssassin tweaks in the SpamAssassin config file and not
have to document and (subsequently remember to actually look at the
documentation ;) ) that I had to hack DNS as well.
So, is it possible to hack the site-wide SpamAssassin config file (in my
case, MIMEDefang's sa-mimedefang.cf) to use our local Spamhaus mirror?
Thanks.
--
Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)
Re: Upgrade 3.2.3->3.2.4 breaks rule override
Posted by Kris Deugau <kd...@vianet.ca>.
Karl Boyken wrote:
> We're running SpamAssassin from MIMEDefang 2.63 on RedHat Linux
> Enterprise Server 5. We recently upgraded SpamAssassin from 3.2.3 to
> 3.2.4. We'd configured sa-mimedefang.cf to use a local Spamhaus mirror
> for __RCVD_IN_ZEN, RCVD_IN_XBL and RCVD_IN_PBL. I just copied over the
> "header" lines from 20_dnsbl_tests.cf and replaced zen.spamhaus.org.
> with the domain that the local mirror uses. The hack was working. But
> when we upgraded to 3.2.4, it broke. Any suggestions as to how to
> configure SpamAssassin to use the local Spamhaus mirror? Thanks.
Need more detail to be certain about how best to fix the problem; you
don't mention how you installed SA or what you mean by 'I just copied
over the "header" lines...'
A couple of suggestions:
1) Mirror the Spamhaus data "properly" by configuring your DNS machines
to refer to the local data when anything from that zone is requested.
For example, with a BIND resolver, you'd (IIRC) add a "forwarder" entry
for zen.spamhaus.org pointing to the local authoritative server. In the
long run this is probably a better solution than fiddling with upstream
SA rule definitions.
2) Move your hack to the right place in the SA configuration. It sounds
like you edited the files in /usr/share/spamassassin - those files are
provided by SA itself, and are supposedly clearly documented as "Don't
touch - these WILL be overwritten by upgrades!!" Simply place your
changed configuration in local.cf (or some other .cf file in the same
location), and SA will use that instead of its defaults.
Wading through spamassassin -D --lint should give you more info on where
the underlying problem is coming from.
-kgd
Re: Upgrade 3.2.3->3.2.4 breaks rule override
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 24.01.08 09:22, Karl Boyken wrote:
> We're running SpamAssassin from MIMEDefang 2.63 on RedHat Linux
> Enterprise Server 5. We recently upgraded SpamAssassin from 3.2.3 to
> 3.2.4. We'd configured sa-mimedefang.cf to use a local Spamhaus mirror
> for __RCVD_IN_ZEN, RCVD_IN_XBL and RCVD_IN_PBL. I just copied over the
> "header" lines from 20_dnsbl_tests.cf and replaced zen.spamhaus.org.
> with the domain that the local mirror uses. The hack was working. But
> when we upgraded to 3.2.4, it broke. Any suggestions as to how to
> configure SpamAssassin to use the local Spamhaus mirror? Thanks.
don't play with spamassassin, configure your DNS server to use the mirror
first.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I don't have lysdexia. The Dog wouldn't allow that.