Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot

2018-04-20 Thread John Hardin
On Fri, 20 Apr 2018, Bill Cole wrote: On 20 Apr 2018, at 14:50 (-0400), John Hardin wrote: Given your findings, I kinda suspect *all* of the tflags=multiple rules are misbehaving from time to time under 3.3.1 - the compiled code may be getting into an infinite loop somehow if the number if

Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot

2018-04-20 Thread Bill Cole
On 20 Apr 2018, at 14:50 (-0400), John Hardin wrote: Given your findings, I kinda suspect *all* of the tflags=multiple rules are misbehaving from time to time under 3.3.1 - the compiled code may be getting into an infinite loop somehow if the number if *real* hits on the rule exceeds some

Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot

2018-04-20 Thread John Hardin
On Fri, 20 Apr 2018, Chris Conn wrote: Yeah, because 3.4.x implements maxhits. So, should I disable the __GENERATE_LEADS family for < 3.4.0? I suspect it would be prudent, but I am surprised the other tflags=multiple rules aren't also problematic in the same manner... Hello, I don`t

Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot

2018-04-20 Thread Chris Conn
Yeah, because 3.4.x implements maxhits. So, should I disable the __GENERATE_LEADS family for < 3.4.0? I suspect it would be prudent, but I am surprised the other tflags=multiple rules aren't also problematic in the same manner... Hello, I don`t think I am in a position to comment on

Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot

2018-04-20 Thread John Hardin
On Fri, 20 Apr 2018, Chris Conn wrote: WTF? If tflags=multiple is supported at all, it should behave properly (i.e. not hitting over and over on the *same bit of text*). maxhits was implemented after 3.3.1; is it possible that there are just a *lot* of instances of "your business" in that

Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot

2018-04-20 Thread Chris Conn
WTF? If tflags=multiple is supported at all, it should behave properly (i.e. not hitting over and over on the *same bit of text*). maxhits was implemented after 3.3.1; is it possible that there are just a *lot* of instances of "your business" in that test message, and it's simply hitting

Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot

2018-04-20 Thread John Hardin
On Fri, 20 Apr 2018, Chris Conn wrote: On 4/18/2018 10:32 AM, Benny Pedersen wrote: Chris Conn skrev den 2018-04-18 16:00: this is a relatively old install, SA 3.3.1 on Centos6 (stock RPMs) maybe solved in centos7 ? I believe I found the issue.  On my Centos6 boxes with SA 3.3.1 (the

Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot

2018-04-20 Thread Chris Conn
On 4/18/2018 10:32 AM, Benny Pedersen wrote: Chris Conn skrev den 2018-04-18 16:00: this is a relatively old install, SA 3.3.1 on Centos6 (stock RPMs) maybe solved in centos7 ? i do not use precompiled problems Hello, I believe I found the issue.  On my Centos6 boxes with SA 3.3.1 (the

Re: spamc --reporttype= not working and curious log message.

2018-04-20 Thread John Hardin
On Fri, 20 Apr 2018, Kevin A. McGrail wrote: If RH/CentOS chose to simply remove those plugins, I would follow like and kind for building the package. +1 -- Kevin A. McGrail Asst. Treasurer & VP Fundraising, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project

Re: spamc --reporttype= not working and curious log message.

2018-04-20 Thread Kevin A. McGrail
If RH/CentOS chose to simply remove those plugins, I would follow like and kind for building the package. -- Kevin A. McGrail Asst. Treasurer & VP Fundraising, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Fri, Apr

Re: spamc --reporttype= not working and curious log message.

2018-04-20 Thread Reio Remma
Neither spamassassin-3.4.0-2.el7.src.rpm (CentOS 7.4) nor spamassassin-3.4.1-17.fc27.src.rpm have the mentioned files in their source at all. Reio On 20.04.18 17:06, Kevin A. McGrail wrote: Giovanni, I was considering killing it as well. And I was going to look at how CentOS handled this in

Re: spamc --reporttype= not working and curious log message.

2018-04-20 Thread Kevin A. McGrail
Giovanni, I was considering killing it as well. And I was going to look at how CentOS handled this in the 3.4.1 for their rpms. -- Kevin A. McGrail Asst. Treasurer & VP Fundraising, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail -

Re: spamc --reporttype= not working and curious log message.

2018-04-20 Thread Giovanni Bechis
On 04/20/18 13:53, Kevin A. McGrail wrote: > FYI, I'm well aware of the 3.4 test issue with rulesrc.  I have it symlinked > to a checkout for my purposes.  I'll document that more. > > I am using CentOS 7 as well for testing and not aware of these perl > dependency issues you are having. 

Re: spamc --reporttype= not working and curious log message.

2018-04-20 Thread Reio Remma
I suspect rpmbuild gleans the requirements from script files when building. Mail-SpamAssassin-3.4.2/lib/Mail/SpamAssassin/Plugin/RabinKarpBody.pm:use RabinKarpAccel; Mail-SpamAssassin-3.4.2/lib/Mail/SpamAssassin/Util/MemoryDump.pm:use Devel::Size qw(size total_size);

Re: spamc --reporttype= not working and curious log message.

2018-04-20 Thread Kevin A. McGrail
FYI, I'm well aware of the 3.4 test issue with rulesrc. I have it symlinked to a checkout for my purposes. I'll document that more. I am using CentOS 7 as well for testing and not aware of these perl dependency issues you are having. Please elaborate further. -- Kevin A. McGrail Asst.

Re: Can't locate Mail/SpamAssassin/Plugin/SpamCop.pm: lib/Mail/SpamAssassin/Plugin/SpamCop.pm: Permission denied

2018-04-20 Thread Matus UHLAR - fantomas
Am Donnerstag, 19. April 2018, 20:53:19 CEST schrieb Rainer Dorsch: Thank you for your reply, Jesse. Hmm.no cd /home/rd/ does not help and there is no lib directory in there you don't need the lib/ directory there. in fact, the problem is that in original directory perl could not check

Re: spamc --reporttype= not working and curious log message.

2018-04-20 Thread Reio Remma
On 20.04.18 9:50, Giovanni Bechis wrote: On 04/19/18 09:24, Reio Remma wrote: [...] *Update:* none of the --option= switches work. handle_user (userdir) unable to find user: '' is caused because I have the -username switch as --username=amavis instead of --username amavis It worked in 3.4.1.

Re: spamc --reporttype= not working and curious log message.

2018-04-20 Thread Reio Remma
On 20.04.18 9:50, Giovanni Bechis wrote: On 04/19/18 09:24, Reio Remma wrote: [...] *Update:* none of the --option= switches work. handle_user (userdir) unable to find user: '' is caused because I have the -username switch as --username=amavis instead of --username amavis It worked in 3.4.1.

Re: spamc --reporttype= not working and curious log message.

2018-04-20 Thread Giovanni Bechis
On 04/19/18 09:24, Reio Remma wrote: [...] > *Update:* none of the --option= switches work. > > handle_user (userdir) unable to find user: '' is caused because I have the > -username switch as --username=amavis instead of --username amavis > > It worked in 3.4.1. > > Is it at all possible

Re: spamc --reporttype= not working and curious log message.

2018-04-20 Thread Giovanni Bechis
On 04/19/18 18:54, Reio Remma wrote: > I ran make test now - not exactly a pass. > cc dev@, I think this is a regression. > There were lots of complaints about: "Maybe you need to kill a running spamd > process?" There was no spamd running. > > The RPM is actually working nicely on our