On 17 Jan 2002, Sidney Markowitz wrote:
> On Thu, 2002-01-17 at 13:01, brad wrote:
> > Are you recomending spamd -d -L -D is ok and then call it with the
> > procmailrc of spamc -f
>
> Well, "recommend" is too strong a word, since I don't run a large volume
> mailserver to lots of customers.But I
brad said:
> Has anyone successfully used the milter as a direct plugin yet? My
> procmailrc in /usr/local/etc/ is just invoking the spamc -f process.
Georg himself (the author) has ;) I would recommend it BTW. It would
remove those procmail processes from the picture, bringing the load down.
Worked.
I am now scanning all the mail, the load average on the system is
load averages: 0.83, 1.00, 0.98
spamd -u nobody -d -L
and removed the spam.lock. Procmail is at about 60 processes per second
but it seems to be clearing them quickly. Most email gets scanned in 0 or
1 second. I have seen
I would recommend:
spamd -d -L -a -c
and
spamc -f
for production systems. But I don't much care for DNS-blacklists. If you're using SA on high volumes of mail, I would think you want to carefully think about your DNS design before removing the -L. If you're using SA on low volumes, I
On Thu, 2002-01-17 at 12:29, brad wrote:
:0fw:spam.lock
| spamc -f
:0e
{
EXITCODE=$?
}
and no there are not hundreds of spamc processes that I noticed. I did
Yeah, as I thought. You're using a (probably global) lockfile on this recipe, so procmail is waiting for the previous spamc
On Thu, 2002-01-17 at 13:01, brad wrote:
> Are you recomending spamd -d -L -D is ok and then call it with the
> procmailrc of spamc -f
Well, "recommend" is too strong a word, since I don't run a large volume
mailserver to lots of customers.But I do know that I run spamd -d -L -c
and put spamc -f
Are you recomending spamd -d -L -D is ok and then call it with the
procmailrc of spamc -f
Brad
On 17 Jan 2002, Sidney Markowitz wrote:
> On Thu, 2002-01-17 at 10:51, brad wrote:
> > SA takes 5-7 seconds per message and can leave
> > hundreds of procmail processes running.
>
> That sounds like a
:0fw:spam.lock
| spamc -f
:0e
{
EXITCODE=$?
}
and no there are not hundreds of spamc processes that I noticed. I did
mention that the perl Net::DNS module was found, and in the -D debug it is
not installed. Could this be part of the issue? I am doing razor lookups
and rbl lookups.
brad
On 17
Could you send us your procmail recipe? And also do you see as many spamc processes as procmail processes? If not, you're probably having procmail globally lock something, and thereby serializing the highly parallelizable DNS lookups.
C
On Thu, 2002-01-17 at 12:05, brad wrote:
Has
Has anyone successfully used the milter as a direct plugin yet? My
procmailrc in /usr/local/etc/ is just invoking the spamc -f process.
Brad
On 17 Jan 2002, Craig Hughes wrote:
> On Thu, 2002-01-17 at 10:51, brad wrote:
>
> Problem: CPU usage with procmail to high, MTA stops accepting emai
On Thu, 2002-01-17 at 10:51, brad wrote:
Problem: CPU usage with procmail to high, MTA stops accepting email
because of load average / Sendmail 8.11 has problems with SA and
unexpected or long error codes.
Potential Resolutions and what I have learned thus far please feel free to
adjust:
On Thu, 2002-01-17 at 10:51, brad wrote:
> SA takes 5-7 seconds per message and can leave
> hundreds of procmail processes running.
That sounds like a problem right there. I run spamc/spamd with -L option
to skip all network access and it takes a tiny fraction of a second per
message. Razor and t
Problem: CPU usage with procmail to high, MTA stops accepting email
because of load average / Sendmail 8.11 has problems with SA and
unexpected or long error codes.
Potential Resolutions and what I have learned thus far please feel free to
adjust:
Don't run your smtp server / pop3 server and SA
13 matches
Mail list logo
