Mailing List Archive

1 2 3 4 5 6  View All
Re: Argument "perl_version" isn't numeric [ In reply to ]
Am 30.11.2014 um 19:44 schrieb Ted Mittelstaedt:
> This issue has been discussed here:
>
> http://askubuntu.com/questions/554537/argument-perl-version-isnt-numeric-in-numeric-ge-at-eval-534-line-1
>
> There is a link to patches for 2 Perl modules that turn off
> the warnings. Worked for me when I applied those patches.

unacceptable workaround

frankly doing so may get you fired because you risk to break other
packages from the operating system with unknown side-affects and
recommend such actions should start with a big warning

* Fedora 20 is one of the most recent OS environments
* SpamAssassin 3.4.0 is the recent upstream version
* Perl 5.18.4 is recent (Fri Oct 03 2014)
"if perl_version >= 5.010000" must not throw warning with perl 5.18.x

nobody right in has mind is patching perl-modules installed with the OS
package-managment in case of recent SA installed with the
package-managment to work around broken rules on a production server

the issue was introduced with SA rule-updates and has to be fixed there

> On 11/30/2014 4:42 AM, Reindl Harald wrote:
>>
>> Am 30.11.2014 um 05:39 schrieb John Hardin:
>>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>>>> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>>>>
>>>>> However, it is a *warning*, not a fatal error. And it's better than
>>>>> the
>>>>> rule killing lint and blocking sa-update completely on an install that
>>>>> uses an older perl
>>>>
>>>> don't get me wrong but this *warning* triggers cron mails and spits
>>>> messages in case of every SA related command - that's unacceptable and
>>>> in fact worser than without that check
>>>>
>>>> before *only* outdated perl versions where affected, now it hits also
>>>> recent Fedora setups working before without any warning and with that
>>>> rule included
>>>
>>> As I said, I underestimated the reaction to doing that.
>>>
>>>> if that rule can't work in most environments and not made
>>>> conditionally it has to be dropped at all because it has more
>>>> drawbacks than benefits
>>>
>>> It has already been commented out in my sandbox.
>>>
>>> But this effectively means we cannot add new features to SA conditionals
>>> because they might do this to older installs
>>
>> which new features?
>> which newer perl?
>>
>> spamassassin-3.4.0-7.fc20.x86_64
>> perl-5.18.4-291.fc20.x86_64
>>
>> that "fix" for older versions is just broken and leads to warnings on a
>> recent SA with a recent perl while as first people with outdated setups
>> complained all was fine here
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 2014-11-30 03:08, Martin Gregorie wrote:
> On Sat, 2014-11-29 at 20:39 -0800, John Hardin wrote:
>> But this effectively means we cannot add new features to SA conditionals
>> because they might do this to older installs.
>>
> Can SA set a $too_old flag to say that that the Perl version number
> check failed?
>
> If so, it seems the me that, at runtime, it would be reasonable to
> exclude new version-dependent features if either the $too_old flag is
> set or the version number is lower than the feature needs. It would also
> be reasonable for sa_update to report the exclusion since that serves to
> remind the sysadmin to upgrade.
>
>
> Martin

That gets unnecessarily annoying to sysadmins running things like Scientific
Linux 6. Spamassassin is not going to get updated to 3.4.whizzy. And going off
distro often invites annoying problems that require a lot of effort to deal
with. I know *I* do not like to invite problems when I can stay on distro and
use the freed up time for other important work.

Now, if you guys could work with RHEL, SUSE, and other major distros to make it
easy for them to upgrade spamassassin that situation might change. But SA seems
to be moderately low on the criticality lists for major distros.

{^_^} Joanne
Re: Argument "perl_version" isn't numeric [ In reply to ]
Am 30.11.2014 um 19:48 schrieb Ted Mittelstaedt:
> On 11/29/2014 8:39 PM, John Hardin wrote:
>>> if that rule can't work in most environments and not made
>>> conditionally it has to be dropped at all because it has more
>>> drawbacks than benefits
>>
>> It has already been commented out in my sandbox.
>>
>> But this effectively means we cannot add new features to SA conditionals
>> because they might do this to older installs.
>>
>
> No, just release patches to the older versions to Conf.pm and Parser.pm
>
> These are not COMPILED modules so it is easy to patch them.
>
> The people who even notice the warnings are going to be competent enough
> to run patch, and for the people who are running SpamAssassin who aren't
> competent enough to be able to do that, I doubt they will be noticing
> log entries

stop that polemic! competent people would not patch files from a RPM package

the solution is not to publish rules not working on the last official SA
upstream version

[root@mail-gw:~]$ rpm -q --file
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Conf.pm
spamassassin-3.4.0-7.fc20.x86_64
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 2014-11-30 10:48, Ted Mittelstaedt wrote:
>
>
> On 11/29/2014 8:39 PM, John Hardin wrote:
>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>>> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>>>
>>>> However, it is a *warning*, not a fatal error. And it's better than the
>>>> rule killing lint and blocking sa-update completely on an install that
>>>> uses an older perl
>>>
>>> don't get me wrong but this *warning* triggers cron mails and spits
>>> messages in case of every SA related command - that's unacceptable and
>>> in fact worser than without that check
>>>
>>> before *only* outdated perl versions where affected, now it hits also
>>> recent Fedora setups working before without any warning and with that
>>> rule included
>>
>> As I said, I underestimated the reaction to doing that.
>>
>>> if that rule can't work in most environments and not made
>>> conditionally it has to be dropped at all because it has more
>>> drawbacks than benefits
>>
>> It has already been commented out in my sandbox.
>>
>> But this effectively means we cannot add new features to SA conditionals
>> because they might do this to older installs.
>>
>
> No, just release patches to the older versions to Conf.pm and Parser.pm
>
> These are not COMPILED modules so it is easy to patch them.
>
> The people who even notice the warnings are going to be competent enough
> to run patch, and for the people who are running SpamAssassin who aren't
> competent enough to be able to do that, I doubt they will be noticing log entries.
>
> Ted

Put a sock in it, Ted. For some, perhaps you, sysadmin is a hobby. For others it
is a necessary pain in the ass. Going off distro for some "patches" is precisely
what we wish to avoid with these long term professional distros. And you're
telling US that we have to risk the stability of the system? "Brown vaguely
stinky soft spludgy material such as emanates from the South end of a North
facing fertile male bovine."

{`,'}
Re: Argument "perl_version" isn't numeric [ In reply to ]
Now now, be nice!

This issue affects ANY piece of OSS software that has multiple dependencies.

SpamAssassin has HUNDREDS of dependencies on different Perl modules.

Using your nasty logic if the author of Perl::Date or whatever
decided to make a change that broke SA than it's our tough luck, eh?

The authors of any OSS project - like SA, like any of the modules that
SA depends on - that depends on OTHER OSS
projects need to navigate this dependency hell with same guiding
principle that is used for Sendmail and other OSS projects:

Be liberal in what you accept, conservative in what you send.

Meaning this - you write a package like SA, or a package like
Perl::Date, that has published interfaces and API's, you need to do your
best to maintain consistency, and you need to be accepting
of changes that others make to the best of your ability.

If the SA authors want to add bells and whistles to a functioning design
that require certain newer versions of dependent programs that's fine -
but they need to install logic in those bells and whistles that either
makes them backwards compatible with older dependent programs or turns
those bells and whistles off.

If it turns out that an older released SA has a design flaw that makes
that impossible to do then patches need to be released for those older
versions.

There's no need to take a scorched Earth My way or the highway approach.

Ted

On 11/30/2014 10:50 AM, Dave Pooser wrote:
> On 11/30/14 12:34 PM, "Paul R. Ganci"<ganci@nurdog.com> wrote:
>
>> So just so I understand something is it expected that those of us with
>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
>> just for spamassassin's sa-update? The whole idea of running servers
>> with those versions of server software is for stability.
>
> Yep. And the whole point of running SpamAssassin with sa-update is for
> flexibility and agility. The two goals are necessarily in conflict. So...
> Looks like you have a few options:
> 1) Don't run SA on RHEL
> 2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
> to new spam in the interest of keeping your system static
> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
> third-party-packages or update from source
> 4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
> with output redirected to /dev/null, and write your own monitoring script
> to tell you if sa-update broke spamd
> 5) Run SA in some kind of container or VM so you can optimize for
> spamassassin without tainting the purity of your RHEL install
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 11/30/2014 11:50 AM, Dave Pooser wrote:
> On 11/30/14 12:34 PM, "Paul R. Ganci" <ganci@nurdog.com> wrote:
>
>> So just so I understand something is it expected that those of us with
>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
>> just for spamassassin's sa-update? The whole idea of running servers
>> with those versions of server software is for stability.
> Yep. And the whole point of running SpamAssassin with sa-update is for
> flexibility and agility. The two goals are necessarily in conflict. So...
> Looks like you have a few options:
> 1) Don't run SA on RHEL
> 2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
> to new spam in the interest of keeping your system static
> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
> third-party-packages or update from source
> 4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
> with output redirected to /dev/null, and write your own monitoring script
> to tell you if sa-update broke spamd
> 5) Run SA in some kind of container or VM so you can optimize for
> spamassassin without tainting the purity of your RHEL install
You have to be joking if I am going to update my systems for sa-update.
It seems that this is a pretty much arrogant decision by spamassassin
development team. The problem is in sa-update. It should be fixed there.

--
Paul (ganci@nurdog.com)
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, 30 Nov 2014, Dave Pooser wrote:

> On 11/30/14 12:34 PM, "Paul R. Ganci" <ganci@nurdog.com> wrote:
>
>> So just so I understand something is it expected that those of us with
>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
>> just for spamassassin's sa-update? The whole idea of running servers
>> with those versions of server software is for stability.
>
> Yep.

Um, nope. The whole point to this was to allow SA rules to deal gracefully
with older perl versions.

The problem at hand is not caused by the perl version that is installed,
and upgrading the version of perl will not fix it; it's caused by a single
rule that uses recent perl syntax (and which caused sa-update to fail lint
on perl 5.8.8) trying to avoid problems on older perl by using a brand new
SA feature, and use of that feature on older SA generates a warning.

I apologize, I thought that a warning was preferable to a fatal error, and
I underestimated the impact of the warning, and have again completely
disabled the rule in question until the situation is resolved, however
that ends up happening. This change did not go out in the last update,
hopefully it will be in the next.

> And the whole point of running SpamAssassin with sa-update is for
> flexibility and agility. The two goals are necessarily in conflict. So...
> Looks like you have a few options:
> 1) Don't run SA on RHEL
> 2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
> to new spam in the interest of keeping your system static
> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
> third-party-packages or update from source
> 4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
> with output redirected to /dev/null, and write your own monitoring script
> to tell you if sa-update broke spamd
> 5) Run SA in some kind of container or VM so you can optimize for
> spamassassin without tainting the purity of your RHEL install

6) You patch, or RHEL (et. al.) patches the official SA distro package,
with the tiny change that implements perl_version support in conditionals
and avoids this warning, so that rule development can safely use perl
features from newer versions of perl without risking a *fatal* error in
sa-update at sites using older versions of perl.

7) SA implements some other more-complex, more-backwards-compatible method
of checking the version of perl in conditionals, such as a new function
that can be checked in a can().

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
Ted, I simply do not feel well enough just now to be nice. I reiterate my prior
observation about vaguely stinky and spludgy material such as emanates from the
South end of North facing fertile male bovines.

I have enough headaches with pure distro modules. I really REALLY *R*E*A*L*L*Y*
do not want to go through the nonsense again with off distro modules. I ran SA
off distro for a few years. I got tired of it. Too much stuff was starting to break.

Sorry if I am abusive - no - I'm not sorry. I feel like warmed over poo with
this blasted headcold. I DO NOT NEED THIS SORT OF AGGRAVATION JUST NOW PEEING ON
ME FROM MY LOGS.

{`,'}

On 2014-11-30 11:07, Ted Mittelstaedt wrote:
> Now now, be nice!
>
> This issue affects ANY piece of OSS software that has multiple dependencies.
>
> SpamAssassin has HUNDREDS of dependencies on different Perl modules.
>
> Using your nasty logic if the author of Perl::Date or whatever
> decided to make a change that broke SA than it's our tough luck, eh?
>
> The authors of any OSS project - like SA, like any of the modules that SA
> depends on - that depends on OTHER OSS
> projects need to navigate this dependency hell with same guiding
> principle that is used for Sendmail and other OSS projects:
>
> Be liberal in what you accept, conservative in what you send.
>
> Meaning this - you write a package like SA, or a package like Perl::Date, that
> has published interfaces and API's, you need to do your best to maintain
> consistency, and you need to be accepting
> of changes that others make to the best of your ability.
>
> If the SA authors want to add bells and whistles to a functioning design that
> require certain newer versions of dependent programs that's fine - but they need
> to install logic in those bells and whistles that either makes them backwards
> compatible with older dependent programs or turns those bells and whistles off.
>
> If it turns out that an older released SA has a design flaw that makes that
> impossible to do then patches need to be released for those older
> versions.
>
> There's no need to take a scorched Earth My way or the highway approach.
>
> Ted
>
> On 11/30/2014 10:50 AM, Dave Pooser wrote:
>> On 11/30/14 12:34 PM, "Paul R. Ganci"<ganci@nurdog.com> wrote:
>>
>>> So just so I understand something is it expected that those of us with
>>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
>>> just for spamassassin's sa-update? The whole idea of running servers
>>> with those versions of server software is for stability.
>>
>> Yep. And the whole point of running SpamAssassin with sa-update is for
>> flexibility and agility. The two goals are necessarily in conflict. So...
>> Looks like you have a few options:
>> 1) Don't run SA on RHEL
>> 2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
>> to new spam in the interest of keeping your system static
>> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
>> third-party-packages or update from source
>> 4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
>> with output redirected to /dev/null, and write your own monitoring script
>> to tell you if sa-update broke spamd
>> 5) Run SA in some kind of container or VM so you can optimize for
>> spamassassin without tainting the purity of your RHEL install
>
Re: Argument "perl_version" isn't numeric [ In reply to ]
John, if you make it a warning - warn ONCE not ever blessed time the file is run
and CLEARLY state this is a warning only and is not fatal. PLEASE PLEASE PLEASE

{o.o}

On 2014-11-30 11:11, John Hardin wrote:
> On Sun, 30 Nov 2014, Dave Pooser wrote:
>
>> On 11/30/14 12:34 PM, "Paul R. Ganci" <ganci@nurdog.com> wrote:
>>
>>> So just so I understand something is it expected that those of us with
>>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
>>> just for spamassassin's sa-update? The whole idea of running servers
>>> with those versions of server software is for stability.
>>
>> Yep.
>
> Um, nope. The whole point to this was to allow SA rules to deal gracefully with
> older perl versions.
>
> The problem at hand is not caused by the perl version that is installed, and
> upgrading the version of perl will not fix it; it's caused by a single rule that
> uses recent perl syntax (and which caused sa-update to fail lint on perl 5.8.8)
> trying to avoid problems on older perl by using a brand new SA feature, and use
> of that feature on older SA generates a warning.
>
> I apologize, I thought that a warning was preferable to a fatal error, and I
> underestimated the impact of the warning, and have again completely disabled the
> rule in question until the situation is resolved, however that ends up
> happening. This change did not go out in the last update, hopefully it will be
> in the next.
>
>> And the whole point of running SpamAssassin with sa-update is for
>> flexibility and agility. The two goals are necessarily in conflict. So...
>> Looks like you have a few options:
>> 1) Don't run SA on RHEL
>> 2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
>> to new spam in the interest of keeping your system static
>> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
>> third-party-packages or update from source
>> 4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
>> with output redirected to /dev/null, and write your own monitoring script
>> to tell you if sa-update broke spamd
>> 5) Run SA in some kind of container or VM so you can optimize for
>> spamassassin without tainting the purity of your RHEL install
>
> 6) You patch, or RHEL (et. al.) patches the official SA distro package,
> with the tiny change that implements perl_version support in conditionals and
> avoids this warning, so that rule development can safely use perl features from
> newer versions of perl without risking a *fatal* error in sa-update at sites
> using older versions of perl.
>
> 7) SA implements some other more-complex, more-backwards-compatible method of
> checking the version of perl in conditionals, such as a new function that can be
> checked in a can().
>
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, 30 Nov 2014, jdow wrote:

> John, if you make it a warning - warn ONCE not ever blessed time the file is
> run and CLEARLY state this is a warning only and is not fatal. PLEASE PLEASE
> PLEASE
>
> {o.o}

The reason it warns twice is the rule evaluation and promotion process
separates the two rules during publication. They are together in a single
if() in the sandbox file; if they were published that way there would only
be one warning. I don't know how complicated it would be to change that
behavior, probably very.

In the SA log it clearly states it's a warning. I don't know why that
information would be stripped when emitting to STDERR. And fixing that
wouldn't help existing SA installs.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
We have to realize that people who run the government can and do
change. Our society and laws must assume that bad people -
criminals even - will run the government, at least part of the
time. -- John Gilmore
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 30. nov. 2014 20.02.27 jdow <jdow@earthlink.net> wrote:

> Now, if you guys could work with RHEL, SUSE, and other major distros to make it
> easy for them to upgrade spamassassin that situation might change. But SA seems
> to be moderately low on the criticality lists for major distros.

I stopped using rpm based distro when redhat dropped support for redhat 8,
after that i changed to freebsd and gentoo, but to be more constructive to
rpm clients needs more attention to get svn version build as rpm packages

Ruleupdates should have being if version before if perl_version, so this
the test of perl was only done on svn version of sa, it have nothing to do
with update or change dependice of perl installed
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, 30 Nov 2014, Benny Pedersen wrote:

> Ruleupdates should have being if version before if perl_version, so this the
> test of perl was only done on svn version of sa, it have nothing to do with
> update or change dependice of perl installed

Sadly that doesn't work. The else branch of a conditional still gets
partially parsed, so the perl_version type warning is still emitted even
if it is inside a conditional that evaluates to false.

Try this:

if 0 > 0
if fnord > 0
meta SYN_ERROR
endif
endif

SA won't generate a warning about the syntax of the SYN_ERROR rule, but it
will emit a warning about fnord not being numeric.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
We have to realize that people who run the government can and do
change. Our society and laws must assume that bad people -
criminals even - will run the government, at least part of the
time. -- John Gilmore
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 11/30/2014 10:59 AM, Reindl Harald wrote:
>
>
> Am 30.11.2014 um 19:44 schrieb Ted Mittelstaedt:
>> This issue has been discussed here:
>>
>> http://askubuntu.com/questions/554537/argument-perl-version-isnt-numeric-in-numeric-ge-at-eval-534-line-1
>>
>>
>> There is a link to patches for 2 Perl modules that turn off
>> the warnings. Worked for me when I applied those patches.
>
> unacceptable workaround
>
> frankly doing so may get you fired because you risk to break other
> packages from the operating system with unknown side-affects and
> recommend such actions should start with a big warning
>
> * Fedora 20 is one of the most recent OS environments
> * SpamAssassin 3.4.0 is the recent upstream version
> * Perl 5.18.4 is recent (Fri Oct 03 2014)
> "if perl_version >= 5.010000" must not throw warning with perl 5.18.x
>
> nobody right in has mind is patching perl-modules installed with the OS
> package-managment in case of recent SA installed with the
> package-managment to work around broken rules on a production server
>

This is an issue of degrees. Those patches came off the SA distro
they are not some 3rd parties idea of a great change that ought to be
made in SA. When the next version of SA is released those will be
incorporated in it - and if you run updates on your OS, assuming
your package maintainers are following the new releases of SA - your
going to get them eventually.

So your going to have to deal with those changes eventually as well as
any "unknown side effects"

> the issue was introduced with SA rule-updates and has to be fixed there
>

When the fix to allow older SA versions to silently accept the new
rule updates is a simple TEXT modification of 2 text Perl modules, you
are overreacting.

I agree that making such a change on a production server for something
like the operating system that is used by -everything- is risky. In
that case, perhaps it would have to rise to the importance of an
emergency security hole that was just discovered, for an out-of-band
patch to be made.

And of course, it was a bit too fast to make that change in SVN and not
give it a longer time to "cook" and for various distros to get updated
with it.

But in this case, you can make this MINOR change during an off-period,
give it 15 minutes and your going to know if it suddenly sends the CPU
to 100% or something, and you can pull it right back out ASAP.

The ENTIRE REASON that Perl modules are written in text and parsed
IS SO THEY CAN BE EASILY MODIFIED. That's the whole point of Perl.

This is a minor change to Conf.pm and Parser.pm. Those 2 modules are
only used in SA. Download and read the patches and decide if they are
significant or not.

Ted

>> On 11/30/2014 4:42 AM, Reindl Harald wrote:
>>>
>>> Am 30.11.2014 um 05:39 schrieb John Hardin:
>>>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>>>>> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>>>>>
>>>>>> However, it is a *warning*, not a fatal error. And it's better than
>>>>>> the
>>>>>> rule killing lint and blocking sa-update completely on an install
>>>>>> that
>>>>>> uses an older perl
>>>>>
>>>>> don't get me wrong but this *warning* triggers cron mails and spits
>>>>> messages in case of every SA related command - that's unacceptable and
>>>>> in fact worser than without that check
>>>>>
>>>>> before *only* outdated perl versions where affected, now it hits also
>>>>> recent Fedora setups working before without any warning and with that
>>>>> rule included
>>>>
>>>> As I said, I underestimated the reaction to doing that.
>>>>
>>>>> if that rule can't work in most environments and not made
>>>>> conditionally it has to be dropped at all because it has more
>>>>> drawbacks than benefits
>>>>
>>>> It has already been commented out in my sandbox.
>>>>
>>>> But this effectively means we cannot add new features to SA
>>>> conditionals
>>>> because they might do this to older installs
>>>
>>> which new features?
>>> which newer perl?
>>>
>>> spamassassin-3.4.0-7.fc20.x86_64
>>> perl-5.18.4-291.fc20.x86_64
>>>
>>> that "fix" for older versions is just broken and leads to warnings on a
>>> recent SA with a recent perl while as first people with outdated setups
>>> complained all was fine here
>
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 11/30/2014 11:06 AM, jdow wrote:
> On 2014-11-30 10:48, Ted Mittelstaedt wrote:
>>
>>
>> On 11/29/2014 8:39 PM, John Hardin wrote:
>>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>>>> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>>>>
>>>>> However, it is a *warning*, not a fatal error. And it's better than
>>>>> the
>>>>> rule killing lint and blocking sa-update completely on an install that
>>>>> uses an older perl
>>>>
>>>> don't get me wrong but this *warning* triggers cron mails and spits
>>>> messages in case of every SA related command - that's unacceptable and
>>>> in fact worser than without that check
>>>>
>>>> before *only* outdated perl versions where affected, now it hits also
>>>> recent Fedora setups working before without any warning and with that
>>>> rule included
>>>
>>> As I said, I underestimated the reaction to doing that.
>>>
>>>> if that rule can't work in most environments and not made
>>>> conditionally it has to be dropped at all because it has more
>>>> drawbacks than benefits
>>>
>>> It has already been commented out in my sandbox.
>>>
>>> But this effectively means we cannot add new features to SA conditionals
>>> because they might do this to older installs.
>>>
>>
>> No, just release patches to the older versions to Conf.pm and Parser.pm
>>
>> These are not COMPILED modules so it is easy to patch them.
>>
>> The people who even notice the warnings are going to be competent enough
>> to run patch, and for the people who are running SpamAssassin who aren't
>> competent enough to be able to do that, I doubt they will be noticing
>> log entries.
>>
>> Ted
>
> Put a sock in it, Ted. For some, perhaps you, sysadmin is a hobby. For
> others it is a necessary pain in the ass.

Sysadmining is a joy to me. It also happens to be one I am paid to do.

If it's a pain in the ass for you - I pity you. Your stuck in the wrong
job.

> Going off distro for some
> "patches" is precisely what we wish to avoid with these long term
> professional distros.

I think you mean what "I" wish to avoid.

> And you're telling US that we have to risk the
> stability of the system? "Brown vaguely stinky soft spludgy material
> such as emanates from the South end of a North facing fertile male bovine."
>

No I am telling you to use your head for something other than a place to
hang your hat. Read the patches. Decide if they are significant enough
to risk the stability of the system. If they are then don't apply them.

I have. They aren't. I applied them. As did many others on the thread
I posted, none of whom reported any ill effects.

As I said before, I really, really pity you and I'm sorry you feel so
trapped in your job. Honestly, there really is a better way to live.
Take up painting, music, whatever. Do what you love. Do it well and
people will pay you for it. And don't look back.

Ted

> {`,'}
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 11/30/14 1:07 PM, "Paul R. Ganci" <ganci@nurdog.com> wrote:

>You have to be joking if I am going to update my systems for sa-update.
>It seems that this is a pretty much arrogant decision by spamassassin
>development team. The problem is in sa-update. It should be fixed there.

You have to be joking if you think that spamassassin rules development
should forever be restricted to whatever crufty version of perl is still
present in the oldest still-supported vendor distro. The decision to
standardize on a 2006-era release of perl in RedHat 5 is not the fault of
the spamassassin team. The decision to run spamassassin on a distribution
that is constitutionally opposed to modern perl is not the fault of the
spamassassin team. The problem is in the system administrator who tries to
hammer every use case into the same square hole. It should be fixed there.
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"...Life is not a journey to the grave with the intention of arriving
safely in one pretty and well-preserved piece, but to slide across the
finish line broadside, thoroughly used up, worn out, leaking oil, and
shouting GERONIMO!!!" -- Bill McKenna
Re: Argument "perl_version" isn't numeric [ In reply to ]
Am 30.11.2014 um 20:58 schrieb Dave Pooser:
> On 11/30/14 1:07 PM, "Paul R. Ganci" <ganci@nurdog.com> wrote:
>
>> You have to be joking if I am going to update my systems for sa-update.
>> It seems that this is a pretty much arrogant decision by spamassassin
>> development team. The problem is in sa-update. It should be fixed there.
>
> You have to be joking if you think that spamassassin rules development
> should forever be restricted to whatever crufty version of perl is still
> present in the oldest still-supported vendor distro

what about people stop to contribute to that thread until the understand
what happens? "The problem is in sa-update. It should be fixed there" is
the correct answer - period

it's *not* about a "crufty version of perl"

it's about a perl version check not existing in SpamAssassin 3.4.0
it's visible on recent perl versions
without the version checks issing the warnings they had no problem
Re: Argument "perl_version" isn't numeric [ In reply to ]
Am 30.11.2014 um 20:50 schrieb Ted Mittelstaedt:
> When the fix to allow older SA versions to silently accept the new
> rule updates is a simple TEXT modification of 2 text Perl modules, you
> are overreacting

no - i react correctly

* the problem was introduced with sa-update
* the problem has to be fixed with sa-update

problems have to be fixed at the root cause instead work around
downstream, that's a bad attitude and lead to problems sooner or later

if there would be a official SpamAssassin 3.4.1 we could discuss about
distributions should rapidly update their packages or even apply patches
local

until that happened rule-updates must not rely on features not supported
by the current GA version and hence i *really* don't get the point of
that discussion
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 2014-11-30 11:58, Ted Mittelstaedt wrote:
>
>
> On 11/30/2014 11:06 AM, jdow wrote:
>> On 2014-11-30 10:48, Ted Mittelstaedt wrote:
>>>
>>>
>>> On 11/29/2014 8:39 PM, John Hardin wrote:
>>>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>>>>> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>>>>>
>>>>>> However, it is a *warning*, not a fatal error. And it's better than
>>>>>> the
>>>>>> rule killing lint and blocking sa-update completely on an install that
>>>>>> uses an older perl
>>>>>
>>>>> don't get me wrong but this *warning* triggers cron mails and spits
>>>>> messages in case of every SA related command - that's unacceptable and
>>>>> in fact worser than without that check
>>>>>
>>>>> before *only* outdated perl versions where affected, now it hits also
>>>>> recent Fedora setups working before without any warning and with that
>>>>> rule included
>>>>
>>>> As I said, I underestimated the reaction to doing that.
>>>>
>>>>> if that rule can't work in most environments and not made
>>>>> conditionally it has to be dropped at all because it has more
>>>>> drawbacks than benefits
>>>>
>>>> It has already been commented out in my sandbox.
>>>>
>>>> But this effectively means we cannot add new features to SA conditionals
>>>> because they might do this to older installs.
>>>>
>>>
>>> No, just release patches to the older versions to Conf.pm and Parser.pm
>>>
>>> These are not COMPILED modules so it is easy to patch them.
>>>
>>> The people who even notice the warnings are going to be competent enough
>>> to run patch, and for the people who are running SpamAssassin who aren't
>>> competent enough to be able to do that, I doubt they will be noticing
>>> log entries.
>>>
>>> Ted
>>
>> Put a sock in it, Ted. For some, perhaps you, sysadmin is a hobby. For
>> others it is a necessary pain in the ass.
>
> Sysadmining is a joy to me. It also happens to be one I am paid to do.
>
> If it's a pain in the ass for you - I pity you. Your stuck in the wrong job.

I am doing it because it is a necessary job, somebody needs to do it, and I can
do it. This is NOT a large company. The theme park market is remarkably small so
we have to double and triple up on our jobs to stay afloat.

>> Going off distro for some
>> "patches" is precisely what we wish to avoid with these long term
>> professional distros.
>
> I think you mean what "I" wish to avoid.

If you have fun putting your systems at risk - have fun. I'd not want to employ
you. I guess I'm too conservative.

>> And you're telling US that we have to risk the
>> stability of the system? "Brown vaguely stinky soft spludgy material
>> such as emanates from the South end of a North facing fertile male bovine."
>>
>
> No I am telling you to use your head for something other than a place to
> hang your hat. Read the patches. Decide if they are significant enough to risk
> the stability of the system. If they are then don't apply them.

I might tell you precisely the same thing. How much do you ENJOY seeing nasty
messages crop up from cron jobs that had been working perfectly? I really do not
enjoy it and get rate acerbic when it happens.

> I have. They aren't. I applied them. As did many others on the thread I
> posted, none of whom reported any ill effects.

It is an accident of history that has me still watching this list. Loren and I
both had some fun building rules back in the SARE days. That wore off. Revenue
concerns took over. It pays infinitely (literally) better to design a tool that
allows 1024 audio in, 1024 audio out, ridiculous numbers of playbacks through an
audio matrix with gains on each cross point, equalization where needed, and so
forth. (It's not huge amounts of money. But anything other than zero divided by
zero is an infinite improvement in income. And when hungry one gets bloody
minded about that detail.)

> As I said before, I really, really pity you and I'm sorry you feel so trapped in
> your job. Honestly, there really is a better way to live. Take up painting,
> music, whatever. Do what you love. Do it well and people will pay you for it.
> And don't look back.

Again - put a dirty sock in it. I AM doing what I love. But that comes with a
side dose of trying to make life easier for us by doing what I can with system
administration on our barriers between the cold cold outside world and our cosy
little system here.

> Ted

{`,'} Joanne

>> {`,'}
>
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 11/30/2014 11:17 AM, jdow wrote:
> Ted, I simply do not feel well enough just now to be nice. I reiterate
> my prior observation about vaguely stinky and spludgy material such as
> emanates from the South end of North facing fertile male bovines.
>
> I have enough headaches with pure distro modules. I really REALLY
> *R*E*A*L*L*Y* do not want to go through the nonsense again with off
> distro modules. I ran SA off distro for a few years. I got tired of it.
> Too much stuff was starting to break.
>

In this situation I simply don't see that the patch recommendation
was all that big of a deal. It's a patch that's already going to be
included in the next version of SA, so if you really are running a
complete "on-distro" system and you are running updates on it, then
sooner or later most distro maintainers are going to include it and you
will get it the next time you run updates on your system.

> Sorry if I am abusive - no - I'm not sorry. I feel like warmed over poo
> with this blasted headcold. I DO NOT NEED THIS SORT OF AGGRAVATION JUST
> NOW PEEING ON ME FROM MY LOGS.
>

Nobody does, but...hypothetically, how many people screaming about this
"mistake" paid any money to the guy who created this program?

I save my nastiest screaming for companies like Microsoft who not only
periodically screw me over but they make me pay them to do it!!!

Ted

> {`,'}
>
> On 2014-11-30 11:07, Ted Mittelstaedt wrote:
>> Now now, be nice!
>>
>> This issue affects ANY piece of OSS software that has multiple
>> dependencies.
>>
>> SpamAssassin has HUNDREDS of dependencies on different Perl modules.
>>
>> Using your nasty logic if the author of Perl::Date or whatever
>> decided to make a change that broke SA than it's our tough luck, eh?
>>
>> The authors of any OSS project - like SA, like any of the modules that SA
>> depends on - that depends on OTHER OSS
>> projects need to navigate this dependency hell with same guiding
>> principle that is used for Sendmail and other OSS projects:
>>
>> Be liberal in what you accept, conservative in what you send.
>>
>> Meaning this - you write a package like SA, or a package like
>> Perl::Date, that
>> has published interfaces and API's, you need to do your best to maintain
>> consistency, and you need to be accepting
>> of changes that others make to the best of your ability.
>>
>> If the SA authors want to add bells and whistles to a functioning
>> design that
>> require certain newer versions of dependent programs that's fine - but
>> they need
>> to install logic in those bells and whistles that either makes them
>> backwards
>> compatible with older dependent programs or turns those bells and
>> whistles off.
>>
>> If it turns out that an older released SA has a design flaw that makes
>> that
>> impossible to do then patches need to be released for those older
>> versions.
>>
>> There's no need to take a scorched Earth My way or the highway approach.
>>
>> Ted
>>
>> On 11/30/2014 10:50 AM, Dave Pooser wrote:
>>> On 11/30/14 12:34 PM, "Paul R. Ganci"<ganci@nurdog.com> wrote:
>>>
>>>> So just so I understand something is it expected that those of us with
>>>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl
>>>> versions
>>>> just for spamassassin's sa-update? The whole idea of running servers
>>>> with those versions of server software is for stability.
>>>
>>> Yep. And the whole point of running SpamAssassin with sa-update is for
>>> flexibility and agility. The two goals are necessarily in conflict.
>>> So...
>>> Looks like you have a few options:
>>> 1) Don't run SA on RHEL
>>> 2) Run SA on RHEL but turn off sa-update and sacrifice automated
>>> reaction
>>> to new spam in the interest of keeping your system static
>>> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
>>> third-party-packages or update from source
>>> 4) Run SA on RHEL with system perl and system SpamAssassin, run
>>> sa-update
>>> with output redirected to /dev/null, and write your own monitoring
>>> script
>>> to tell you if sa-update broke spamd
>>> 5) Run SA in some kind of container or VM so you can optimize for
>>> spamassassin without tainting the purity of your RHEL install
>>
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 30. nov. 2014 20.53.19 John Hardin <jhardin@impsec.org> wrote:

> On Sun, 30 Nov 2014, Benny Pedersen wrote:
>
> > Ruleupdates should have being if version before if perl_version, so this the
> > test of perl was only done on svn version of sa, it have nothing to do with
> > update or change dependice of perl installed
>
> Sadly that doesn't work. The else branch of a conditional still gets
> partially parsed, so the perl_version type warning is still emitted even
> if it is inside a conditional that evaluates to false.
>
> Try this:
>
> if 0 > 0

Psudo if trunc

> if fnord > 0

Psudo fnord would exists in trunc

> meta SYN_ERROR
> endif
> endif
>
> SA won't generate a warning about the syntax of the SYN_ERROR rule, but it
> will emit a warning about fnord not being numeric.

Not if trunc installed, hopefully, is it a svn tag check in sa ?

Hopefully it would be resolved in future sa verions to not break any admin
legs :)
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 11/30/2014 12:09 PM, Reindl Harald wrote:
>
> Am 30.11.2014 um 20:50 schrieb Ted Mittelstaedt:
>> When the fix to allow older SA versions to silently accept the new
>> rule updates is a simple TEXT modification of 2 text Perl modules, you
>> are overreacting
>
> no - i react correctly
>
> * the problem was introduced with sa-update
> * the problem has to be fixed with sa-update
>
> problems have to be fixed at the root cause instead work around
> downstream, that's a bad attitude and lead to problems sooner or later
>

Ah, but is this really a problem? I guess the $64K question is, does
the new rule that's version dependent increase the "spam catch" Because
if it does, then I don't regard it as a problem. Instead, I
want it!

> if there would be a official SpamAssassin 3.4.1 we could discuss about
> distributions should rapidly update their packages or even apply patches
> local
>

But, is that going to help most of the people complaining about the
problem? They still will have elderly Perl versions. If 3.4.1 requires
a newer Perl version they will be stuck at 3.4.0 since their maintainers
won't update. If new version-dependent rules require new
Perl versions then what?

> until that happened rule-updates must not rely on features not supported
> by the current GA version and hence i *really* don't get the point of
> that discussion
>

If the new version dependent rule update gives the spamfighting
community a significant compelling advantage against the spammers, then
Damn the torpedoes and full speed ahead!!!! I'll happily put in 2
minor patches to take advantage of the rule! What I spend in possible
headache doing that will be more than made up by the increased spam I
don't have to deal with!!

Ted
Re: Argument "perl_version" isn't numeric [ In reply to ]
Am 30.11.2014 um 21:30 schrieb Ted Mittelstaedt:
> On 11/30/2014 12:09 PM, Reindl Harald wrote:
>>
>> Am 30.11.2014 um 20:50 schrieb Ted Mittelstaedt:
>>> When the fix to allow older SA versions to silently accept the new
>>> rule updates is a simple TEXT modification of 2 text Perl modules, you
>>> are overreacting
>>
>> no - i react correctly
>>
>> * the problem was introduced with sa-update
>> * the problem has to be fixed with sa-update
>>
>> problems have to be fixed at the root cause instead work around
>> downstream, that's a bad attitude and lead to problems sooner or later
>
> Ah, but is this really a problem? I guess the $64K question is, does
> the new rule that's version dependent increase the "spam catch" Because
> if it does, then I don't regard it as a problem. Instead, I
> want it!

the answer to the $64K is simple: look in you rlogs, and *no*
0.001 will not have a impact in context of "the new version dependent
rule update gives the spamfighting community a significant compelling
advantage against the spammers"

why don't you just verify that at your own before assume things?

spamass-milter had rejected all relevant messages clearly without it
_______________________________________________________________

[root@localhost:~]$ sa-score.sh PDS_FROM_2_EMAILS
/var/lib/spamassassin/3.004000/updates_spamassassin_org
score PDS_FROM_2_EMAILS 1.402 0.001 1.402 0.001

[root@localhost:~]$ cat maillog | grep PDS_FROM_2_EMAILS
Nov 26 08:43:01 mail-gw spamd[13080]: spamd: result: Y 16 -
BAYES_50,CUST_DNSWL_2,FORGED_OUTLOOK_HTML,FROM_MISSPACED,FROM_MISSP_EH_MATCH,FROM_MISSP_MSFT,HTML_MESSAGE,MIME_HTML_ONLY,PDS_FROM_2_EMAILS,RCVD_IN_MSPIKE_H2,SPF_NONE,TO_NO_BRKTS_FROM_MSSP,TO_NO_BRKTS_MSFT,T_FROM_MISSP_DKIM
scantime=0.4,size=1962,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=19781,mid=<201411260742.sAQ7ghX0026176@smtp08.msg.oleane.net>,bayes=0.499989,autolearn=disabled
Nov 26 08:45:13 mail-gw spamd[13080]: spamd: result: Y 9 -
BAYES_50,CUST_DNSWL_2,CUST_DNSWL_5,FROM_MISSPACED,FROM_MISSP_EH_MATCH,HTML_MESSAGE,LOTS_OF_MONEY,MIME_HTML_ONLY,MONEY_FROM_MISSP,PDS_FROM_2_EMAILS,RCVD_IN_MSPIKE_H2,SPF_NONE,TO_NO_BRKTS_FROM_MSSP,T_FROM_MISSP_DKIM
scantime=0.2,size=2356,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=19806,mid=<0MPvIk-1Xphnn3lcw-0050kY@mrelayeu.kundenserver.de>,bayes=0.499996,autolearn=disabled
Nov 26 18:10:19 mail-gw spamd[8290]: spamd: result: Y 15 -
BAYES_50,CUST_DNSWL_2,FROM_MISSP_PHISH,HTML_IMAGE_ONLY_20,HTML_MESSAGE,MIME_HTML_ONLY,MISSING_DATE,MISSING_MID,PDS_FROM_2_EMAILS,SPF_NONE
scantime=1.3,size=3023,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=25917,mid=(unknown),bayes=0.493467,autolearn=disabled
Nov 27 04:49:23 mail-gw spamd[6160]: spamd: result: Y 11 -
BAYES_20,CUST_DNSBL_19,CUST_DNSWL_2,CUST_DNSWL_5,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,FROM_MISSPACED,FROM_MISSP_FREEMAIL,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,LOTS_OF_MONEY,MIME_HTML_ONLY,MONEY_FROM_MISSP,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,RCVD_IN_MSPIKE_H2,SPF_PASS,TO_NO_BRKTS_FROM_MSSP,T_FROM_MISSP_DKIM
scantime=0.5,size=2359,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=29086,mid=<20141127034919.8BB0C2DB881@wt1c42874ffc.nazwa.pl>,bayes=0.140299,autolearn=disabled
Nov 27 06:40:16 mail-gw spamd[4064]: spamd: result: Y 13 -
BAYES_50,CUST_DNSWL_6,FORGED_OUTLOOK_HTML,FROM_MISSP_MSFT,HTML_IMAGE_ONLY_20,HTML_MESSAGE,MIME_HTML_ONLY,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,TO_NO_BRKTS_MSFT
scantime=1.0,size=3439,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=29596,mid=<0MXWgY-1XNRVV1s2g-00WYjm@mrelayeu.kundenserver.de>,bayes=0.511470,autolearn=disabled
Nov 27 08:30:33 mail-gw spamd[4065]: spamd: result: . -2 -
BAYES_00,CUST_DNSWL_2,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_FONT_SIZE_HUGE,HTML_MESSAGE,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_PASS,T_RP_MATCHES_RCVD,T_TVD_FUZZY_SECTOR
scantime=0.7,size=23175,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=30274,mid=<20141127082938.42682@letter.eyepin.com>,bayes=0.000000,autolearn=disabled
Nov 27 09:33:08 mail-gw spamd[4066]: spamd: result: Y 19 -
BAYES_50,CUST_DNSBL_5,FROM_MISSPACED,FROM_MISSP_EH_MATCH,HTML_MESSAGE,MIME_HTML_ONLY,MISSING_DATE,MISSING_MID,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,TO_NO_BRKTS_FROM_MSSP,T_FROM_MISSP_DKIM
scantime=4.7,size=1915,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=30915,mid=(unknown),bayes=0.586026,autolearn=disabled
Nov 27 09:35:14 mail-gw spamd[4066]: spamd: result: Y 10 -
BAYES_50,FROM_MISSP_PHISH,HTML_IMAGE_ONLY_16,HTML_MESSAGE,LOTS_OF_MONEY,MIME_HTML_ONLY,MONEY_FROM_MISSP,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,T_REMOTE_IMAGE
scantime=1.7,size=3018,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=30947,mid=<20141127083458.3218630001D9@master.webbian.de>,bayes=0.494638,autolearn=disabled
Nov 27 16:16:17 mail-gw spamd[2551]: spamd: result: . -2 -
BAYES_00,CUST_DNSWL_2,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,T_RP_MATCHES_RCVD
scantime=0.4,size=1662,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=35461,mid=<nfpeev.pom63m@dpd-business.at>,bayes=0.000064,autolearn=disabled
Nov 27 19:20:10 mail-gw spamd[2553]: spamd: result: Y 13 -
BAYES_50,CUST_DNSWL_2,FREEMAIL_FROM,FROM_MISSPACED,FROM_MISSP_EH_MATCH,FROM_MISSP_FREEMAIL,HTML_MESSAGE,MIME_HTML_ONLY,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_NONE,SUBJECT_NEEDS_ENCODING,SUBJ_ILLEGAL_CHARS,T_FROM_MISSP_DKIM,T_RP_MATCHES_RCVD
scantime=2.2,size=2088,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=37148,mid=<54100E990B0790E0@vsmtp4.tin.it>,bayes=0.533918,autolearn=disabled
Nov 27 21:44:20 mail-gw spamd[2554]: spamd: result: Y 14 -
BAYES_50,CUST_DNSBL_8,CUST_DNSWL_5,FROM_MISSPACED,FROM_MISSP_EH_MATCH,HTML_MESSAGE,MIME_HTML_ONLY,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,RCVD_IN_MSPIKE_BL,RCVD_IN_MSPIKE_L5,SPF_NONE,TO_NO_BRKTS_FROM_MSSP,T_FROM_MISSP_DKIM
scantime=0.2,size=2477,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=37955,mid=<0Lyh7L-1XwY8z2VV9-0164y5@mrelayeu.kundenserver.de>,bayes=0.465341,autolearn=disabled
Nov 28 00:42:04 mail-gw spamd[2556]: spamd: result: Y 9 -
BAYES_20,FROM_MISSPACED,FROM_MISSP_EH_MATCH,FROM_MISSP_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,TO_NO_BRKTS_FROM_MSSP,T_FROM_MISSP_DKIM
scantime=0.3,size=2492,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=38719,mid=<20141127234150.A405E4B04D3F@main4.simsforum.de>,bayes=0.180433,autolearn=disabled
Nov 28 00:42:04 mail-gw spamd[2555]: spamd: result: Y 9 -
BAYES_20,FROM_MISSPACED,FROM_MISSP_EH_MATCH,FROM_MISSP_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,TO_NO_BRKTS_FROM_MSSP,T_FROM_MISSP_DKIM
scantime=0.4,size=2461,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=38718,mid=<20141127234149.A2CDA4B04D33@main4.simsforum.de>,bayes=0.180433,autolearn=disabled
Nov 28 01:52:52 mail-gw spamd[2556]: spamd: result: Y 19 -
BAYES_50,FROM_MISSP_PHISH,HTML_IMAGE_ONLY_20,HTML_MESSAGE,LOTS_OF_MONEY,MIME_HTML_ONLY,MONEY_FROM_MISSP,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,T_REMOTE_IMAGE,URIBL_BLACK,URIBL_DBL_ABUSE_MALW
scantime=0.7,size=4540,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=38999,mid=<20141128005236.19A726B01DA@lxmail3.lxcluster.at>,bayes=0.499719,autolearn=disabled
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 2014-11-30 12:19, Ted Mittelstaedt wrote:
>
>
> On 11/30/2014 11:17 AM, jdow wrote:
>> Ted, I simply do not feel well enough just now to be nice. I reiterate
>> my prior observation about vaguely stinky and spludgy material such as
>> emanates from the South end of North facing fertile male bovines.
>>
>> I have enough headaches with pure distro modules. I really REALLY
>> *R*E*A*L*L*Y* do not want to go through the nonsense again with off
>> distro modules. I ran SA off distro for a few years. I got tired of it.
>> Too much stuff was starting to break.
>>
>
> In this situation I simply don't see that the patch recommendation
> was all that big of a deal. It's a patch that's already going to be included in
> the next version of SA, so if you really are running a
> complete "on-distro" system and you are running updates on it, then
> sooner or later most distro maintainers are going to include it and you will get
> it the next time you run updates on your system.
>
>> Sorry if I am abusive - no - I'm not sorry. I feel like warmed over poo
>> with this blasted headcold. I DO NOT NEED THIS SORT OF AGGRAVATION JUST
>> NOW PEEING ON ME FROM MY LOGS.
>>
>
> Nobody does, but...hypothetically, how many people screaming about this
> "mistake" paid any money to the guy who created this program?
>
> I save my nastiest screaming for companies like Microsoft who not only
> periodically screw me over but they make me pay them to do it!!!
>
> Ted

Linux does not provide adequate facilities for some of the work I do. So I have
SL6.5 and Win 7 running, both. So far one Windows update has cost a lot of
people some sincere heartburn, fortunately not me. In that time I've been
RedHatted at least once. It seems I had to upgrade to SL6.6 in order to keep
receiving updates because I have Octave on the system as a tool for digital
filter work. I've also had nVidia make a bloody mess of the system as well.
(Nouveau at the time the system was put on line simply did not work at all
adequately.) So the score is pretty much 3 Linux pains in the ass for 1 Windows
potential pain in the ass. That said, I do NOT trust Windows bare to the
Internet. I do (mostly) trust Linux in that role. So I run both. I pick the OS
of choice based on which does the job I need better with less effort on my part.
I am slowing down as I get into my eighth decade now. So extra efforts forced
upon me by sloppy thought processes or arrogance really twist my teat and I get
angry.

My one happy thought in terms of one Ted Mittelstaedt is that he, too, will get
old and suffer, too. And if he does not mature somewhat he will suffer worse
than me. Somehow that thought warms my nasty cold little heart.

{^_^}

>> {`,'}
>>
>> On 2014-11-30 11:07, Ted Mittelstaedt wrote:
>>> Now now, be nice!
>>>
>>> This issue affects ANY piece of OSS software that has multiple
>>> dependencies.
>>>
>>> SpamAssassin has HUNDREDS of dependencies on different Perl modules.
>>>
>>> Using your nasty logic if the author of Perl::Date or whatever
>>> decided to make a change that broke SA than it's our tough luck, eh?
>>>
>>> The authors of any OSS project - like SA, like any of the modules that SA
>>> depends on - that depends on OTHER OSS
>>> projects need to navigate this dependency hell with same guiding
>>> principle that is used for Sendmail and other OSS projects:
>>>
>>> Be liberal in what you accept, conservative in what you send.
>>>
>>> Meaning this - you write a package like SA, or a package like
>>> Perl::Date, that
>>> has published interfaces and API's, you need to do your best to maintain
>>> consistency, and you need to be accepting
>>> of changes that others make to the best of your ability.
>>>
>>> If the SA authors want to add bells and whistles to a functioning
>>> design that
>>> require certain newer versions of dependent programs that's fine - but
>>> they need
>>> to install logic in those bells and whistles that either makes them
>>> backwards
>>> compatible with older dependent programs or turns those bells and
>>> whistles off.
>>>
>>> If it turns out that an older released SA has a design flaw that makes
>>> that
>>> impossible to do then patches need to be released for those older
>>> versions.
>>>
>>> There's no need to take a scorched Earth My way or the highway approach.
>>>
>>> Ted
>>>
>>> On 11/30/2014 10:50 AM, Dave Pooser wrote:
>>>> On 11/30/14 12:34 PM, "Paul R. Ganci"<ganci@nurdog.com> wrote:
>>>>
>>>>> So just so I understand something is it expected that those of us with
>>>>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl
>>>>> versions
>>>>> just for spamassassin's sa-update? The whole idea of running servers
>>>>> with those versions of server software is for stability.
>>>>
>>>> Yep. And the whole point of running SpamAssassin with sa-update is for
>>>> flexibility and agility. The two goals are necessarily in conflict.
>>>> So...
>>>> Looks like you have a few options:
>>>> 1) Don't run SA on RHEL
>>>> 2) Run SA on RHEL but turn off sa-update and sacrifice automated
>>>> reaction
>>>> to new spam in the interest of keeping your system static
>>>> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
>>>> third-party-packages or update from source
>>>> 4) Run SA on RHEL with system perl and system SpamAssassin, run
>>>> sa-update
>>>> with output redirected to /dev/null, and write your own monitoring
>>>> script
>>>> to tell you if sa-update broke spamd
>>>> 5) Run SA in some kind of container or VM so you can optimize for
>>>> spamassassin without tainting the purity of your RHEL install
>>>
>
Re: Argument "perl_version" isn't numeric [ In reply to ]
How does the usual person not a member of the right mailing lists learn of this
patch? An hour spent Googling and vetting patches is an hour taken from my life
time. Fortunately for me I was still a member of this list. So I learned I can
just ignore the fool thing cluttering my mailbox. (I may even write an SA rule
to force marking it as extreme spam so that it sorts away from places where
important messages should appear. I like the irony of that idea.)

Have a nice day - you, too, will get really old and hurt a lot someday.....

{^_^}

On 2014-11-30 12:30, Ted Mittelstaedt wrote:
>
>
> On 11/30/2014 12:09 PM, Reindl Harald wrote:
>>
>> Am 30.11.2014 um 20:50 schrieb Ted Mittelstaedt:
>>> When the fix to allow older SA versions to silently accept the new
>>> rule updates is a simple TEXT modification of 2 text Perl modules, you
>>> are overreacting
>>
>> no - i react correctly
>>
>> * the problem was introduced with sa-update
>> * the problem has to be fixed with sa-update
>>
>> problems have to be fixed at the root cause instead work around
>> downstream, that's a bad attitude and lead to problems sooner or later
>>
>
> Ah, but is this really a problem? I guess the $64K question is, does the new
> rule that's version dependent increase the "spam catch" Because if it does,
> then I don't regard it as a problem. Instead, I
> want it!
>
>> if there would be a official SpamAssassin 3.4.1 we could discuss about
>> distributions should rapidly update their packages or even apply patches
>> local
>>
>
> But, is that going to help most of the people complaining about the problem?
> They still will have elderly Perl versions. If 3.4.1 requires
> a newer Perl version they will be stuck at 3.4.0 since their maintainers won't
> update. If new version-dependent rules require new
> Perl versions then what?
>
>> until that happened rule-updates must not rely on features not supported
>> by the current GA version and hence i *really* don't get the point of
>> that discussion
>>
>
> If the new version dependent rule update gives the spamfighting community a
> significant compelling advantage against the spammers, then Damn the torpedoes
> and full speed ahead!!!! I'll happily put in 2 minor patches to take advantage
> of the rule! What I spend in possible headache doing that will be more than
> made up by the increased spam I don't have to deal with!!
>
> Ted
>
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 11/30/14, 2:04 PM, "Reindl Harald" <h.reindl@thelounge.net> wrote:

>it's *not* about a "crufty version of perl"
>
>it's about a perl version check not existing in SpamAssassin 3.4.0
>it's visible on recent perl versions
>without the version checks issing the warnings they had no problem

OK, I could have been clearer there. Let me spell out my logic:

1) Red Hat is not going to release a new version of SpamAssassin for their
existing distros. That's not how they roll.
2) Any rule that uses a regex that requires a version of Perl later than
the 2006-era Perl 5.8.8 will cause a fatal sa-update error unless it's
wrapped in a version check
3) Using version_check creates a non-fatal warning on versions of SA =<
3.4.0

So, we have three options
1) Force Red Hat users to endure a warning unless they update their
spamassassin outside of normal distro channels to gain version_check
capabilities
2) Take the version_check out and break sa-update on computers running
older versions of perl
3) Write all spamassassin rules to use the lowest-common-denominator perl,
which would be the "crufty version of perl" I referred to above.

Do you see a fourth option?
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"...Life is not a journey to the grave with the intention of arriving
safely in one pretty and well-preserved piece, but to slide across the
finish line broadside, thoroughly used up, worn out, leaking oil, and
shouting GERONIMO!!!" -- Bill McKenna

1 2 3 4 5 6  View All