[spambayes-dev] SpamBayes server compliant w/ spamassassin

[Jkx at Pythonfr]

On Sunday 25 April 2004 19:21, Toby Dickenson wrote:
> On Sunday 25 April 2004 13:50, Jkx at Pythonfr wrote:


> 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)

In fact, if you look deeper in the code, you will see that i use this 
on virtual mail domain. with hierarchie looking as:
/var/lib/vmail/domain/user
for example /var/lib/vmail/example.com/contact. 
So i don't really get trouble w/ the right since this all virtual domains
are only owned by one user 'vmail'. 

But anyway in a normal setup you can:
- run the deamon as root (as done w/ spamassassin .. i don't think
  this is really risky, because by default the the socket is binded to 
  localhost .. etc etc ..)
- And you can easily imagine to run this as another user, and tweak
  the self.dbname according to your needs..  (for example put all 
  the db in a unique folder .. which only one account can access. 
  this is a common way to do stuff for large system) 



> 2. functionality. spambayes assumes a per-user operational model. For
> example, I think sb_global_server currently doesnt handle per-user
> ~/.spambayesrc.

Yeah that's true .. but again i think this is only a matter on implementation.
As the filter is done at each request .. i can imagine parsing this 
configuration file too. 

It's my first hack w/ spambayes. I just discovered the code yersterday .. 
so i think i really miss some points. And that why i'm asking for support 
here. 


> > 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

Please look at spamc code, because it try to cover a large amount of 
issue (by alowing the change of username for example .. which is 
really usefull in my approach, or round-robin filtering too .. )

> > 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.)

Fine :) 

> 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.

I'm quite agree w/ you but keep in mind my example, my approach 
isn't so much different. I run only one process for all user.  and i think i 
can do that w/ sb_bn* but the sb_bn* doesn't support the 'user' setting. 

I really think that allowing users (in a large system) to spwan process
is a bad idea. not for a workstation of course but of a filtering server with
1000 mail accounts. My approach is exactly the same as used by things
like virus scanner .. Do you think hosting company will allow people to
install there own virus scrambler on there account ? They don't .. why :
Just because this will be to painfull to administer and spawn a bunch of 
process for nothing. My approach is the same. 


I really like spambayes, but i can't use on large system not because 
it isn't stable enought or doesn't feet w/ the goal but simply because 
it doesn't provide a nice way to administer a large number of accounts. 



Many thanks Toby .. this is kool to heard something different than 
look at sb_bn*. 


Bye Bye ..