Jeff Mincy wrote:
> I agree with everything you wrote but only when bayes autolearning is
> turned off. Bayes learning holds an exclusive lock to the bayes
> database particularly during expiration.
But the example was calling spamc. Bayes autolearning would be
occuring in the spamd side of thin
On Oct 28, 2014 at 07:40 -0400, David F. Skoll wrote:
=>On Mon, 27 Oct 2014 23:50:20 -0700
=>Ian Zimmerman wrote:
=>
=>> Or you could run dovecot and its sieve plugin. Sieve is a real
=>> standard (RFC 5228) which procmail never was.
=>
=>It may be a standard, but it's nowhere near as flexible a
On 10/27/2014 8:37 PM, Bob Proulx wrote:
In the first email:
# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
Thanks, that was my thought as well and your analysis on using spamc and
removing the lock was EXACTLY where my thought proc
On Tue, 28 Oct 2014, Jeff Mincy wrote:
I agree with everything you wrote but only when bayes autolearning is
turned off. Bayes learning holds an exclusive lock to the bayes
database particularly during expiration.
If spamc does bayes autolearning and starts an expiration then other
spamc runs
From: Bob Proulx
Date: Mon, 27 Oct 2014 18:37:35 -0600
In the first email:
# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 40
| spamc -x
Kevin A. McGrail
On Mon, 27 Oct 2014 23:50:20 -0700
Ian Zimmerman wrote:
> Or you could run dovecot and its sieve plugin. Sieve is a real
> standard (RFC 5228) which procmail never was.
It may be a standard, but it's nowhere near as flexible as Perl.
I have very unusual filtering requirements (for example, rule
On Fri, 24 Oct 2014 08:43:41 -0400,
"David F. Skoll" wrote:
David> Procmail is also unmaintained abandonware, as far as I can tell.
David> If you use SpamAssassin, you probably like Perl, so I would
David> recommend Email::Filter instead. It's far more flexible than
David> procmail and lets you
In the first email:
# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 40
| spamc -x
Kevin A. McGrail wrote:
> geoff.spamassassin140903 wrote:
> > Kevin A. McGrail wrote:
> > > Using procmail withou
Am 27.10.2014 um 21:04 schrieb Daniel Staal:
> --As of October 27, 2014 8:29:52 PM +0100, Robert Schetterer is alleged
> to have said:
>
>> by the way
>>
>> http://www.exploit-db.com/exploits/34896/
>>
>> always have a shellshock patched system these days with postfix/procmail
>
> --As for the re
--As of October 27, 2014 8:29:52 PM +0100, Robert Schetterer is alleged to
have said:
by the way
http://www.exploit-db.com/exploits/34896/
always have a shellshock patched system these days with postfix/procmail
--As for the rest, it is mine.
Interesting. I dug a bit further out of curios
Am 27.10.2014 um 19:55 schrieb Bob Proulx:
> David F. Skoll wrote:
>> "Kevin A. McGrail" wrote:
>>> Procmail has some weird syntax
>>
>> Procmail is also unmaintained abandonware, as far as I can tell.
>
> That isn't really a fair assessment of procmail. It is like saying
> that 'cp' is unmaintai
David F. Skoll wrote:
> "Kevin A. McGrail" wrote:
> > Procmail has some weird syntax
>
> Procmail is also unmaintained abandonware, as far as I can tell.
That isn't really a fair assessment of procmail. It is like saying
that 'cp' is unmaintained abandonware. The original authors no longer
main
On 10/24/2014 8:43 AM, David F. Skoll wrote:
...I would recommend Email::Filter instead.
Definitely will try it out! Thanks.
On Thu, 23 Oct 2014 18:00:29 -0400
"Kevin A. McGrail" wrote:
> Procmail has some weird syntax
Procmail is also unmaintained abandonware, as far as I can tell.
If you use SpamAssassin, you probably like Perl, so I would recommend
Email::Filter instead. It's far more flexible than procmail and le
On Thu, 23 Oct 2014, geoff.spamassassin140...@alphaworks.co.uk wrote:
On 04/09/2014 15:56, John Hardin wrote:
On Thu, 4 Sep 2014, Geoff Soper wrote:
> I've got an issue whereby spam messages seem to be somehow bypassing SA
> and getting into my inbox.
>
> : 0fw: spamassassin.lock
> * <
On 23/10/2014 23:00, Kevin A. McGrail wrote:
On 10/23/2014 5:47 PM, geoff.spamassassin140...@alphaworks.co.uk wrote:
On 04/09/2014 11:29, Kevin A. McGrail wrote:
Using procmail without MTA glue is OK for many uses. I am wondering
how many spamd connections you allow and if you have checked you
On 10/23/2014 5:47 PM, geoff.spamassassin140...@alphaworks.co.uk wrote:
On 04/09/2014 11:29, Kevin A. McGrail wrote:
Using procmail without MTA glue is OK for many uses. I am wondering
how many spamd connections you allow and if you have checked your logs?
I also cannot remember but the uses
On 10/23/2014 11:51 PM, geoff.spamassassin140...@alphaworks.co.uk wrote:
On 04/09/2014 15:56, John Hardin wrote:
On Thu, 4 Sep 2014, Geoff Soper wrote:
I've got an issue whereby spam messages seem to be somehow bypassing
SA and getting into my inbox.
:0fw: spamassassin.lock
* < 40
| spamc
On 04/09/2014 15:56, John Hardin wrote:
On Thu, 4 Sep 2014, Geoff Soper wrote:
I've got an issue whereby spam messages seem to be somehow bypassing
SA and getting into my inbox.
:0fw: spamassassin.lock
* < 40
| spamc -x
Are the messages that bypass SA always rather large?
No, unfortu
On 04/09/2014 11:29, Kevin A. McGrail wrote:
Using procmail without MTA glue is OK for many uses. I am wondering how many
spamd connections you allow and if you have checked your logs?
I also cannot remember but the uses of a lock file seem odd for something that
can thread. Any one know if
On Thu, 4 Sep 2014, Geoff Soper wrote:
I've got an issue whereby spam messages seem to be somehow bypassing SA
and getting into my inbox.
:0fw: spamassassin.lock
* < 40
| spamc -x
Are the messages that bypass SA always rather large?
--
John Hardin KA7OHZhttp://www.i
On 09/04/2014 12:29 PM, Kevin A. McGrail wrote:
Using procmail without MTA glue is OK for many uses. I am wondering how many
spamd connections you allow and if you have checked your logs?
I also cannot remember but the uses of a lock file seem odd for something that
can thread. Any one know
Using procmail without MTA glue is OK for many uses. I am wondering how many
spamd connections you allow and if you have checked your logs?
I also cannot remember but the uses of a lock file seem odd for something that
can thread. Any one know if that is a good idea to remove?
Regards,
KAM
>>
On 04.09.14 07:51, Geoff Soper wrote:
References:
<1014212314.119.1394801251166.JavaMail.TPIWEB$@virus.tw.shuttle.com>,<6d30dd2234165a4fb52082d093514b87132b0...@tpiex04.shuttle.corp>
<16437ca7e285c5498f501fae7eeb7d131323f...@tpiex04.shuttle.corp>,<53282f7c.9010...@alphaworks.co.uk>
<16437ca7e285
Hi,
I've got an issue whereby spam messages seem to be somehow bypassing SA and
getting into my inbox. I call SA via procmail as per
https://wiki.apache.org/spamassassin/UsedViaProcmail
The exact procmail file that calls SA is as follows:
#
#Standard SA call to be included from .procmailrc fil
25 matches
Mail list logo
