On Fri, 2009-02-20 at 03:31 -0800, an anonymous Nabble user wrote:
> Hello,
> I am running the Spamd Daemon version 3.2.5 on my Linux web and mail server
> and in general it works well. From time to time (somewhere in between 1-10%
> of all emails) spam passes the filter - but not because spamassassin decides
> that it is ham but because the email never gets processed by spamassassin
> (the header shows no X-Spam at all).
Mentioning some numbers is good, though too qualitative. How many mails
is that per day, in absolute numbers?
> The .procmailrc looks like this:
> :0fw
> |spamc
Without locking here, you can easily resource drain your server during
peaks. Think a "smart" spammer sending a couple mails to you (and/or
other users) at the same time. How many spamd children are running max?
While all of them are busy, excess mails won't be processed.
Keep in mind that the lock file probably is per user, while the max
spamd processes is server-wide.
Of course, never forget that there's a default max-size per message.
Unless told otherwise, spamc won't scan mail that's larger than 500
kByte. Probably not your issue, though, unless (most) of the unprocessed
mail you're talking about actually *is* large.
Also, this is the spamc default of "safe fallback". That means, if there
is any issue in communicating with the daemon, the message will be
passed along unprocessed. But let's re-schedule that for later. (See
follow-up post.)
> :0
> * ^X-Spam-Flag: YES
> $HOME/junk
>
> :0 w
> | /usr/bin/deliverquota $MAILDIR
Unrelated: Are you using mbox or maildir storage? The $MAILDIR hints you
actually are using maildir format, though the junk folder is an mbox
file!
With mbox, you seriously should add locking to any delivering recipe.
> As I mentioned before everything works fine in 90+% of all incoming mails.
> Any hints on what might happen to the emails that simply get passed along
> unchecked? Could it be that if the server is busy processing other email he
> skips a few?
Yes. Check your logs. If you are running out of spamd children, you'll
see something like this in the logs:
prefork: child states BBBB
One state indicating char per children. B is busy, I means idle. Idle
processes are ready to take a message. If you're seeing too many busy
children, you're server can't handle the load.
In that case, you /can/ increase the number of children, if you got
plenty of RAM. Limiting the parallel resource usage by locking (in
procmail) can help, too. And it definitely would be worth investigating
more, like how long the children take for processing a message. Too long
scan times can amplify this.
guenther
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
