Re: is lock needed when using spamd/c combo

2007-10-02 Thread Obantec Support


- Original Message - 
From: Matthias Häker [EMAIL PROTECTED]

To: spamassassin-users users@spamassassin.apache.org
Sent: Monday, October 01, 2007 4:49 PM
Subject: Re: is lock needed when using spamd/c combo





John D. Hardin schrieb:

On Mon, 1 Oct 2007, Obantec Support wrote:



DROPPRIVS=yes
:0fw
*  512000
| /usr/bin/spamc
:0:
* ^X-Spam-Status: Yes
$HOME/mail/spam





SPAM='spam'

:0fw: $SPAM$LOGNAME.lock

this will scan only one message for one user at a time.


Matthias



Hi

i thought the reason for using spamd/spamc was to provide a more efficient 
processing of spam thru spamassassin.

does locking each mail coming in not increase the overhead?

Mark



Re: is lock needed when using spamd/c combo

2007-10-02 Thread John D. Hardin
On Tue, 2 Oct 2007, Obantec Support wrote:

 From: Matthias Häker [EMAIL PROTECTED]
 
  SPAM='spam'
 
  :0fw: $SPAM$LOGNAME.lock
 
  this will scan only one message for one user at a time.
 
 i thought the reason for using spamd/spamc was to provide a more
 efficient processing of spam thru spamassassin.
 does locking each mail coming in not increase the overhead?

No, locking the spamc rule means SA will be scanning only one message
at a time (either globally or per-user, depending on how you create
the lock), thus it *reduces* the overhead.

Locking the spamc/spamassassin rule is a resource-usage-control method
similar to limiting the number of child processes you allow spamd to
spawn.

I do this on my virtual-hosted MTA as it is very memory-limited.

If you have a well-provisioned MTA box, then don't lock the spamc 
rule. Let SA scan as many messages as the resources allow, and control 
resource usage through the SA maximum-child-process limit.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED]
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Pelley: Will you pledge not to test a nuclear weapon?
  Ahmadeinejad: CIA! Secret prison in Europe! Abu Ghraib!
   -- Mahmoud Ahmadeinejad clumsily dodges a question
(60 minutes interview, 9/20/2007)
---
 236 days until the Mars Phoenix lander arrives at Mars



is lock needed when using spamd/c combo

2007-10-01 Thread Obantec Support

Hi

3.2.3 SA on FC3

just need to ensure i have the master .procmailrc syntax correct for spamc

i am using 


DROPPRIVS=yes
:0fw
*  512000
| /usr/bin/spamc
:0:
* ^X-Spam-Status: Yes
$HOME/mail/spam

do i need to use the lock as per the procmail.example which uses

:0fw: spamassassin.lock
*  512000
| spamassassin


Mark


Re: is lock needed when using spamd/c combo

2007-10-01 Thread John D. Hardin
On Mon, 1 Oct 2007, Obantec Support wrote:

 DROPPRIVS=yes
 :0fw
 *  512000
 | /usr/bin/spamc
 :0:
 * ^X-Spam-Status: Yes
 $HOME/mail/spam

That looks okay. There's a more complex example at 
http://www.impsec.org/~jhardin/antispam that you might want to look 
at.

 do i need to use the lock as per the procmail.example which uses
 
 :0fw: spamassassin.lock
 *  512000
 | spamassassin

You only need to lock around the spamc call if you explicitly want to
scan only one message at a time. If you don't have low-resource issues
on the SA box, you probably don't need to do that.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED]
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Pelley: Will you pledge not to test a nuclear weapon?
  Ahmadeinejad: CIA! Secret prison in Europe! Abu Ghraib!
   -- Mahmoud Ahmadeinejad clumsily dodges a question
(60 minutes interview, 9/20/2007)
---
 237 days until the Mars Phoenix lander arrives at Mars



Re: is lock needed when using spamd/c combo

2007-10-01 Thread Matthias Häker



John D. Hardin schrieb:

On Mon, 1 Oct 2007, Obantec Support wrote:

  

DROPPRIVS=yes
:0fw
*  512000
| /usr/bin/spamc
:0:
* ^X-Spam-Status: Yes
$HOME/mail/spam





SPAM='spam'

:0fw: $SPAM$LOGNAME.lock

this will scan only one message for one user at a time.


Matthias