Karsten Bräckelmann-2 wrote:
>
> Mentioning some numbers is good, though too qualitative. How many mails
> is that per day, in absolute numbers?
>
Maybe 1-10 a day in total. I have several email accounts there and it
happens with all of them although not in a serious amount per account.
Karsten Bräckelmann-2 wrote:
>
> 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.
>
The problem is not size related. The spam emails that pass often are only
one line text mails. My settings do not specify a max-size since the default
value seems to suit me.
Karsten Bräckelmann-2 wrote:
>
> 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.)
>
The logfiles do not report any problems. I ran procmail with VERBOSE=yes for
some time now and it shows that even the unprocessed emails get passed to
spamc.
Karsten Bräckelmann-2 wrote:
>
> 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.
>
Maildir is beeing used as maildir storage. I just use the mbox file for
detected spam emails instead of forgetting them right away. Thanks for the
hint with locking, I added the colon to the line concerning the mbox write
access.
Karsten Bräckelmann-2 wrote:
>
> 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
>
I checked the logs and that does not seem to be the cause of the problem. My
log shows 'II' in most cases and rarely more than 3 threads running. My max
threads is 5 I think.
I try and add locking to the spamc call now in all the .procmailrc files. I
will come back to you =)
Many thanks for all the hints so far!
--
View this message in context:
http://www.nabble.com/Some-emails-pass-spamassassin-unprocessed-tp22119041p22355105.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
