You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Chris <cp...@earthlink.net> on 2006/05/27 16:12:36 UTC
lint failure with 3.1.2
During the CPAN upgrade from 3.1.0 to 3.1.2 last night I could have swore I
saw --lint being ran as a test. However, when I got up this morning I
found this in my RDJ output email folder:
[9324] warn: config: SpamAssassin failed to parse line, "MAKEPENIBIG .33" is
not valid for "score", skipping: score MAKEPENIBIG .33
[9324] warn: config: SpamAssassin failed to parse line, "hilton_b64 .01" is
not valid for "score", skipping: score hilton_b64 .01
[9324] warn: config: SpamAssassin failed to parse line, "MY_XXX_BODY .55" is
not valid for "score", skipping: score MY_XXX_BODY .55
[9324] warn: config: SpamAssassin failed to parse line, "MY_LIFE .66" is not
valid for "score", skipping: score MY_LIFE .66
[9324] warn: config: SpamAssassin failed to parse line, "SUBJECT_XXX_2 .33"
is not valid for "score", skipping: score SUBJECT_XXX_2 .33
[9324] warn: config: SpamAssassin failed to parse line, "MY_LRGROD .85" is
not valid for "score", skipping: score MY_LRGROD .85
[9324] warn: trusted_networks doesn't contain internal_networks entry
'192.168/16'
[9324] warn: lint: 7 issues detected, please rerun with debug enabled for
more information
Here is my local.cf entry for trusted_networks:
clear_trusted_networks
trusted_networks 127/8
internal_networks 192.168/16
The others above appear to be from the 'adult.cf' rule file, which has been
running fine with 3.1.0. Any suggestions?
--
Chris
Registered Linux User 283774 http://counter.li.org
09:03:30 up 12 days, 21:03, 2 users, load average: 0.38, 0.22, 0.12
Mandriva Linux 10.1 Official, kernel 2.6.8.1-12mdk
Re: lint failure with 3.1.2
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 5/27/2006 11:44 PM, Loren Wilton wrote:
>>From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
>
>
>>>[9324] warn: config: SpamAssassin failed to parse line, "MY_LRGROD .85"
>
> is
>
>>>not valid for "score", skipping: score MY_LRGROD .85
>>
>>I thought this was required in 3.1.0 (but not 3.0.x) too, but anyway,
>>all of these scores require a leading zero.
>
>
> This changed on 3.1.1. 3.1.0 was fine with the leading decimal point.
Yeah, score validation was added in February.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4795
Daryl
Re: lint failure with 3.1.2
Posted by Loren Wilton <lw...@earthlink.net>.
> From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
> > [9324] warn: config: SpamAssassin failed to parse line, "MY_LRGROD .85"
is
> > not valid for "score", skipping: score MY_LRGROD .85
>
> I thought this was required in 3.1.0 (but not 3.0.x) too, but anyway,
> all of these scores require a leading zero.
This changed on 3.1.1. 3.1.0 was fine with the leading decimal point.
Loren
Re: lint failure with 3.1.2
Posted by Loren Wilton <lw...@earthlink.net>.
> Thanks Loren, so I guess the best rule would be to upgrade each time a new
> version is released whether its minor or major that way something like
this
> shouldn't happen again.
Well I don't know about that. You would have hit this complaint in lint one
release sooner, and might have had more chance of noticing it in the release
documentation since it might have been in the summary. But in the end you
would have had to do the same thing to fix the problem.
Loren
Re: lint failure with 3.1.2
Posted by Chris <cp...@earthlink.net>.
On Saturday 27 May 2006 11:02 pm, Loren Wilton wrote:
> > Thanks, I believe I see what you're saying. I have no idea either why
> > it worked fine in 3.1.0. I've commented out the internal_networks
> > entry for now and everything lints fine now.
>
> 'worked fine' and 'linted clean' may be two different things. It linted
> clean in 3.1.0 because the checks weren't as good as they should have
> been. Daryl improved them for 3.1.2, so now you are seeing an error or
> warning or whatever it is.
>
> I don't recall if the internal usage also got stricter on 3.1.2, so it
> might have worked before but would stop working on 3.1.2,
>
> Loren
Thanks Loren, so I guess the best rule would be to upgrade each time a new
version is released whether its minor or major that way something like this
shouldn't happen again.
--
Chris
Registered Linux User 283774 http://counter.li.org
09:22:28 up 13 days, 21:22, 1 user, load average: 0.10, 0.33, 0.44
Mandriva Linux 10.1 Official, kernel 2.6.8.1-12mdk
Re: lint failure with 3.1.2
Posted by Loren Wilton <lw...@earthlink.net>.
> Thanks, I believe I see what you're saying. I have no idea either why it
> worked fine in 3.1.0. I've commented out the internal_networks entry for
> now and everything lints fine now.
'worked fine' and 'linted clean' may be two different things. It linted
clean in 3.1.0 because the checks weren't as good as they should have been.
Daryl improved them for 3.1.2, so now you are seeing an error or warning or
whatever it is.
I don't recall if the internal usage also got stricter on 3.1.2, so it might
have worked before but would stop working on 3.1.2,
Loren
Re: lint failure with 3.1.2
Posted by Chris <cp...@earthlink.net>.
On Saturday 27 May 2006 4:01 pm, Sanford Whiteman wrote:
> >> > internal_networks 192.168/16
> >
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Isn't this the internal_networks entry?
>
> Yes, and the warning is telling you that the value '192.168/16' (not
> the the name 'internal_networks') is not duplicated in
>
> trusted_networks, as would normally be expected. 3.0.x docs say:
> > MXes for your domain(s) and internal relays should also be specified
> > using the internal_networks setting. When there are 'trusted' hosts
> > that are not MXes or internal relays for your domain(s) they should
> > only be specified in trusted_networks.
>
> As for why this linted OK before, couldn't tell ya. Haven't looked at
> 3.1.2 yet.
>
> --Sandy
Thanks, I believe I see what you're saying. I have no idea either why it
worked fine in 3.1.0. I've commented out the internal_networks entry for
now and everything lints fine now.
Thanks
Chris
--
Chris
Registered Linux User 283774 http://counter.li.org
16:29:41 up 13 days, 4:29, 1 user, load average: 0.68, 0.41, 0.21
Mandriva Linux 10.1 Official, kernel 2.6.8.1-12mdk
Re[2]: lint failure with 3.1.2
Posted by Sanford Whiteman <sw...@cypressintegrated.com>.
>> > internal_networks 192.168/16
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Isn't this the internal_networks entry?
Yes, and the warning is telling you that the value '192.168/16' (not
the the name 'internal_networks') is not duplicated in
trusted_networks, as would normally be expected. 3.0.x docs say:
> MXes for your domain(s) and internal relays should also be specified
> using the internal_networks setting. When there are 'trusted' hosts
> that are not MXes or internal relays for your domain(s) they should
> only be specified in trusted_networks.
As for why this linted OK before, couldn't tell ya. Haven't looked at
3.1.2 yet.
--Sandy
Re: lint failure with 3.1.2
Posted by Chris <cp...@earthlink.net>.
On Saturday 27 May 2006 5:50 pm, jdow wrote:
> > Yeah, you'll need those hosts' IPs along with any intermediate relays
> > such as the IP(s) of any POP3 servers your mail might go through.
>
> trusted_networks 127/8 192.168/16 207.217.121/24 209.86.93/24
>
> That works here on earlier versions nicely. And those on the right are
> both the incoming pop servers and the outgoing smtp servers. The latter
> are probably not needed but are non-destructive.
>
> {^_^}
Thanks Joanne, appreciate it. Lints with no problems now.
--
Chris
Registered Linux User 283774 http://counter.li.org
18:53:10 up 13 days, 6:53, 1 user, load average: 0.54, 0.34, 0.18
Mandriva Linux 10.1 Official, kernel 2.6.8.1-12mdk
Re: lint failure with 3.1.2
Posted by jdow <jd...@earthlink.net>.
From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
> Chris wrote:
>> On Saturday 27 May 2006 4:33 pm, you wrote:
>>
>>>> Any why did --lint work fine every
>>>> time in 3.1.0? Commenting out the internal_networks entry and
>>>> restarting SA, --lint shows no errorrs now, why?
>>> We're continuously improving the config parser's ability to detect
>>> configuration *logic* errors. SA 3.1.1 was the first to thoroughly test
>>> the logically configuration of trusted and internal network settings, in
>>> addition to the already present syntactical checking.
>>>
>>>> If I remember correctly I had setup
>>>> my trusted and internal networks the same as I had seen in a message
>>>> from JoAnne, I could be wrong though.
>>> It's wrong, trust me. ;)
>>>
>>> See http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760 for a
>>> whole lot of background and insight into this issue.
>>>
>>>
>>> Like I said before, you need to use at least this (without an
>>> internal_networks line):
>>>
>>> trusted_networks 127/8 192.168/16
>>>
>>>
>>> Additionally, if your MX knows it's public IP you need to add it to the
>>> list of trusted_networks.
>>>
>>> If you're using fetchmail to get your Earthlink mail and running it
>>> through SA, you should also add all of the relays through Earthlink's
>>> network (right up to and including their MXes) to your trusted_networks
>>> too.
>>>
>>>
>>> Daryl
>>
>> Thanks Daryl. Yes, fetchmail picksup from EL, thru procmail which calls SA.
>> If I understand you correctly on my trusted_networks line I'll need the ips
>> for these:
>>
>> type=MX> [5 mx1.earthlink.net., 5 mx2.earthlink.net., 5 mx3.earthlink.net.,
>> 5 mx4.earthlink.net., 5 mx5.earthlink.net., 5 mx6.earthlink.net., 5
>> mx7.earthlink.net., 5 mx8.earthlink.net., 5 mx9.earthlink.net., 5
>> mxa.earthlink.net., 5 mxb.earthlink.net., 5 mxc.earthlink.net., 5
>> mxd.earthlink.net., 5 mxe.earthlink.net., 5 mxf.earthlink.net., 5
>> mxg.earthlink.net., 5 mxh.earthlink.net., 5 mxi.earthlink.net., 5
>> mxj.earthlink.net., 5 mxk.earthlink.net.]
>>
>> Or am I still showing my ignorance here?
>
> Yeah, you'll need those hosts' IPs along with any intermediate relays
> such as the IP(s) of any POP3 servers your mail might go through.
trusted_networks 127/8 192.168/16 207.217.121/24 209.86.93/24
That works here on earlier versions nicely. And those on the right are
both the incoming pop servers and the outgoing smtp servers. The latter
are probably not needed but are non-destructive.
{^_^}
Re: lint failure with 3.1.2
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Chris wrote:
> On Saturday 27 May 2006 4:33 pm, you wrote:
>
>>> Any why did --lint work fine every
>>> time in 3.1.0? Commenting out the internal_networks entry and
>>> restarting SA, --lint shows no errorrs now, why?
>> We're continuously improving the config parser's ability to detect
>> configuration *logic* errors. SA 3.1.1 was the first to thoroughly test
>> the logically configuration of trusted and internal network settings, in
>> addition to the already present syntactical checking.
>>
>>> If I remember correctly I had setup
>>> my trusted and internal networks the same as I had seen in a message
>>> from JoAnne, I could be wrong though.
>> It's wrong, trust me. ;)
>>
>> See http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760 for a
>> whole lot of background and insight into this issue.
>>
>>
>> Like I said before, you need to use at least this (without an
>> internal_networks line):
>>
>> trusted_networks 127/8 192.168/16
>>
>>
>> Additionally, if your MX knows it's public IP you need to add it to the
>> list of trusted_networks.
>>
>> If you're using fetchmail to get your Earthlink mail and running it
>> through SA, you should also add all of the relays through Earthlink's
>> network (right up to and including their MXes) to your trusted_networks
>> too.
>>
>>
>> Daryl
>
> Thanks Daryl. Yes, fetchmail picksup from EL, thru procmail which calls SA.
> If I understand you correctly on my trusted_networks line I'll need the ips
> for these:
>
> type=MX> [5 mx1.earthlink.net., 5 mx2.earthlink.net., 5 mx3.earthlink.net.,
> 5 mx4.earthlink.net., 5 mx5.earthlink.net., 5 mx6.earthlink.net., 5
> mx7.earthlink.net., 5 mx8.earthlink.net., 5 mx9.earthlink.net., 5
> mxa.earthlink.net., 5 mxb.earthlink.net., 5 mxc.earthlink.net., 5
> mxd.earthlink.net., 5 mxe.earthlink.net., 5 mxf.earthlink.net., 5
> mxg.earthlink.net., 5 mxh.earthlink.net., 5 mxi.earthlink.net., 5
> mxj.earthlink.net., 5 mxk.earthlink.net.]
>
> Or am I still showing my ignorance here?
Yeah, you'll need those hosts' IPs along with any intermediate relays
such as the IP(s) of any POP3 servers your mail might go through.
Basically you want to take a look at the headers from an assortment of
your mail and add the IPs of any host your mail passes through starting
with the Earthlink MXes. Do NOT include Earthlink's MSAs (SMTP servers
Earthlink users submit mail to). This all goes in your
trusted_networks. There's no need for separate internal_networks in
your setup.
Daryl
Re: lint failure with 3.1.2
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Chris wrote:
> On Saturday 27 May 2006 12:21 pm, Daryl C. W. O'Shea wrote:
>
>>> [9324] warn: trusted_networks doesn't contain internal_networks entry
>>> '192.168/16'
>>> [9324] warn: lint: 7 issues detected, please rerun with debug enabled
>>> for more information
>>>
>>> Here is my local.cf entry for trusted_networks:
>>>
>>> clear_trusted_networks
>>> trusted_networks 127/8
>>> internal_networks 192.168/16
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Isn't this the internal_networks entry?
Yeah, and like the error says, the 192.168/16 network isn't also listed
in trusted_networks like it should be.
> Any why did --lint work fine every
> time in 3.1.0? Commenting out the internal_networks entry and restarting
> SA, --lint shows no errorrs now, why?
We're continuously improving the config parser's ability to detect
configuration *logic* errors. SA 3.1.1 was the first to thoroughly test
the logically configuration of trusted and internal network settings, in
addition to the already present syntactical checking.
> If I remember correctly I had setup
> my trusted and internal networks the same as I had seen in a message from
> JoAnne, I could be wrong though.
It's wrong, trust me. ;)
See http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760 for a
whole lot of background and insight into this issue.
Like I said before, you need to use at least this (without an
internal_networks line):
trusted_networks 127/8 192.168/16
Additionally, if your MX knows it's public IP you need to add it to the
list of trusted_networks.
If you're using fetchmail to get your Earthlink mail and running it
through SA, you should also add all of the relays through Earthlink's
network (right up to and including their MXes) to your trusted_networks too.
Daryl
Re: lint failure with 3.1.2
Posted by Chris <cp...@earthlink.net>.
On Saturday 27 May 2006 12:21 pm, Daryl C. W. O'Shea wrote:
> > [9324] warn: trusted_networks doesn't contain internal_networks entry
> > '192.168/16'
> > [9324] warn: lint: 7 issues detected, please rerun with debug enabled
> > for more information
> >
> > Here is my local.cf entry for trusted_networks:
> >
> > clear_trusted_networks
> > trusted_networks 127/8
> > internal_networks 192.168/16
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Isn't this the internal_networks entry? Any why did --lint work fine every
time in 3.1.0? Commenting out the internal_networks entry and restarting
SA, --lint shows no errorrs now, why? If I remember correctly I had setup
my trusted and internal networks the same as I had seen in a message from
JoAnne, I could be wrong though.
>
> Exactly what the error message says. Your trusted_networks (12/78)
> doesn't contain your internal_networks (192.168/16).
>
> You need to add your internal_networks entry to your list of
> trusted_networks.
>
> BTW... if internal_networks are the same as trusted_networks, there's no
> need to declare internal_networks as trusted_networks will be used if
> internal_networks aren't defined.
>
>
> Daryl
--
Chris
Registered Linux User 283774 http://counter.li.org
12:44:00 up 13 days, 44 min, 1 user, load average: 0.20, 0.19, 0.11
Mandriva Linux 10.1 Official, kernel 2.6.8.1-12mdk
Re: lint failure with 3.1.2
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Chris wrote:
> During the CPAN upgrade from 3.1.0 to 3.1.2 last night I could have swore I
> saw --lint being ran as a test. However, when I got up this morning I
> found this in my RDJ output email folder:
>
> [9324] warn: config: SpamAssassin failed to parse line, "MAKEPENIBIG .33" is
> not valid for "score", skipping: score MAKEPENIBIG .33
> [9324] warn: config: SpamAssassin failed to parse line, "hilton_b64 .01" is
> not valid for "score", skipping: score hilton_b64 .01
> [9324] warn: config: SpamAssassin failed to parse line, "MY_XXX_BODY .55" is
> not valid for "score", skipping: score MY_XXX_BODY .55
> [9324] warn: config: SpamAssassin failed to parse line, "MY_LIFE .66" is not
> valid for "score", skipping: score MY_LIFE .66
> [9324] warn: config: SpamAssassin failed to parse line, "SUBJECT_XXX_2 .33"
> is not valid for "score", skipping: score SUBJECT_XXX_2 .33
> [9324] warn: config: SpamAssassin failed to parse line, "MY_LRGROD .85" is
> not valid for "score", skipping: score MY_LRGROD .85
I thought this was required in 3.1.0 (but not 3.0.x) too, but anyway,
all of these scores require a leading zero.
> [9324] warn: trusted_networks doesn't contain internal_networks entry
> '192.168/16'
> [9324] warn: lint: 7 issues detected, please rerun with debug enabled for
> more information
>
> Here is my local.cf entry for trusted_networks:
>
> clear_trusted_networks
> trusted_networks 127/8
> internal_networks 192.168/16
Exactly what the error message says. Your trusted_networks (12/78)
doesn't contain your internal_networks (192.168/16).
You need to add your internal_networks entry to your list of
trusted_networks.
Even after you do that though, your configuration is still probably
wrong. 127/8 is also internal and unless your mail server is NATed and
doesn't see your public IP, you also need to add your public IP to both
internal and trusted networks.
BTW... if internal_networks are the same as trusted_networks, there's no
need to declare internal_networks as trusted_networks will be used if
internal_networks aren't defined.
Daryl
Re: lint failure with 3.1.2
Posted by Chris <cp...@earthlink.net>.
On Saturday 27 May 2006 10:31 am, Kai Schaetzl wrote:
> Chris wrote on Sat, 27 May 2006 09:12:36 -0500:
> > The others above appear to be from the 'adult.cf' rule file, which has
> > been running fine with 3.1.0. Any suggestions?
>
> Contact the maintainer of that ruleset. I suspect 3.1.2 doesn't like
> scores that start with "." My --lint is still fine which means I'm not
> using that ruleset.
>
> Kai
Why did the rule set work fine with 3.1.0? No --lint problems ever with it.
Any idea on why it choking on [9324] warn: trusted_networks doesn't contain
internal_networks entry
'192.168/16' when in fact its there?
--
Chris
Registered Linux User 283774 http://counter.li.org
11:33:18 up 12 days, 23:33, 1 user, load average: 0.53, 0.32, 0.16
Mandriva Linux 10.1 Official, kernel 2.6.8.1-12mdk
Re: lint failure with 3.1.2
Posted by Chris <cp...@earthlink.net>.
On Saturday 27 May 2006 10:31 am, Kai Schaetzl wrote:
> Chris wrote on Sat, 27 May 2006 09:12:36 -0500:
> > The others above appear to be from the 'adult.cf' rule file, which has
> > been running fine with 3.1.0. Any suggestions?
>
> Contact the maintainer of that ruleset. I suspect 3.1.2 doesn't like
> scores that start with "." My --lint is still fine which means I'm not
> using that ruleset.
>
> Kai
I see sometime back the adult.cf rule was changed to 70_sare_adult.cf, don't
know why I left the original there, so that takes care of most of the
errors, the only one left is the internal_networks error.
--
Chris
Registered Linux User 283774 http://counter.li.org
11:45:07 up 12 days, 23:45, 2 users, load average: 0.76, 0.51, 0.30
Mandriva Linux 10.1 Official, kernel 2.6.8.1-12mdk
Re: lint failure with 3.1.2
Posted by Kai Schaetzl <ma...@conactive.com>.
Chris wrote on Sat, 27 May 2006 09:12:36 -0500:
> The others above appear to be from the 'adult.cf' rule file, which has been
> running fine with 3.1.0. Any suggestions?
Contact the maintainer of that ruleset. I suspect 3.1.2 doesn't like scores
that start with "." My --lint is still fine which means I'm not using that
ruleset.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com