[spambayes-dev] SpamBayes server compliant w/ spamassassin
tdickenson at geminidataloggers.com
Sun Apr 25 13:21:32 EDT 2004
On Sunday 25 April 2004 13:50, Jkx at Pythonfr wrote:
> > jkx> Do you really want to open one UnixDomain socket per user ?????
> > Sure, why not? Unix domain sockets are pretty cheap.
> Simply because this is not realist ... this will eat a bunch of socket for
> nothing .. Have you ever heard that OS has max open file descriptor
> limit ? ?
There is an engineering compromise here split around having one big process
and one big socket covering all users, compared to having per-user processes
and sockets. You are right that it doesnt make sense to have one big global
process listening on 100's of sockets.
Disadvantages of having one big process include:
1. security. This big process has to be priveliged enough to read a .hammiedb
from every users home directory. In practice I guess you run it as root. The
spambayes development team doesnt have the culture to justify that kind of
trust IMO. (also IMO, nor should it)
2. functionality. spambayes assumes a per-user operational model. For example,
I think sb_global_server currently doesnt handle per-user ~/.spambayesrc.
> I think you should look closer at how mail delivery works !
> Have you ever think that you can deliver a bunch of mails at the same time
> ? So you don't have only a one 'exec python' but you will have one per user
> for simultanous incomming mail.. For example filtering done thought
> maildrop can get (by default) 100 simultanus filter.. so do you really
> think that 100 * exec python is the same as 100 * spamc ??? (cause spamc
> eat ~500 Kb and python ~ 4.5 Mb )
Yes, using python for sb_bnfilter is a short-term measure. Its a prototype. C
version is in progress
> my code try to face this problems:
> - spawning a python at each incomming mail (spamc)
> - having one deamon (or more) per user .
I agree the first of those is a problem, and needs to be fixed in sb_bn*.
(reusing the lightweight s.a. code here is a good trick btw.)
I'm unconvinced so far that the overhead of having one deamon per user is a
bigger problem than having spambayes run in a shared deamon with higher
priveliges than a normal user.
More information about the spambayes-dev