On 11 Oct 2007, at 16:02, Fabian Cenedese wrote: > Hi > > I recently had a case where xmail got about a dozen mails at the same > time (with PSYNC). So I then had several threads doing virus scanning > and spam checking. As each thread only got a little CPU time they > timed out and the mails slipped through without being checked. > > Apart from increasing the filter timeout time I would also like to lower > the number of threads doing the filtering in filter.in.tab. Are these the > SMAIL threads? So I need to give a lower -Qn argument? > > I don't mind if a mail has to wait some minutes before it is filtered, > the filter is more important then the immediate delivery. > > Are there any other effects with less threads? Is the responsiveness > still the same (should be so as they are handled from POP3/SMTP)?
That would/used to likely cause a kernel panic on my NetBSD server (k6-400/128MB ram. I used both xmail commandline parameters and filter scripts to limit number processed simultaneously. I'm not sure which settings as this was a long while back. In the filter script I inserted a check on what filter was already running and a wait until < 2 were running before next one progressed. Spamassassin perl seemed to be main culprit rather than fprot. My test was to send a dozen emails from a remote account, 4 x ok, 4 x virus and 4 x spam and with number of simultaneous processes at 4 I'd occasionally have a problem so settled for 2 and there is only a short delay introduced such that from my remote account the sending client didn't timeout with all having been delivered within 30 - 40 sec. David > Is there anything else that can be done in the filters except to > check if the @@FILE is still available to handle long filter runs? > - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
