On Sun, 16.12.2007 at 11:25:47, Jose-Marcio Martins da Cruz wrote: > A filter shall eventually be able to evaluate resources consumption and > behave adequately. So, if the filter says - sorry, I'm not able to > handle any other new connection now, this is better than accepting and > crashing. This is usually what's done in real life with real people.
I entirely agree. However the filter, clamav-milter, when libmilter/wor- kers.c could not spawn new thread freeze waiting for answer. Limiting the connection number to clamav-milter in my opinion is not the best approach. I can image a event when smtp's client connects to server and send mail from/rcpt to and wait. Then connection to filter (clamav- milter) would be set but nothing will not load cpu. I would like to see the better way to limit the resources, workers from libmilter inform clamav-milter that they reach the MAX_WORKERS and clamav-milter sends: 451 4.3.2 AV system temporarily overloaded to smtp server. > Limit the number of threads isn't a good idea, unless the filter > (clamav-milter or other) can limit the amount of time allocated to each > task (e.g. message content scanning). If you don't do that, you create a > DoS vulnerability. So the only limit is to set the max number of connection? Best regards, Ernest Wypierowski _______________________________________________ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
