> > [...] > > Well, both, though you are right, my first thoughts were for the use of suExec for the > > WebGUI. > > > The WebGUI is actually doing two things: > 1) reading data from DSPAM_HOME > 2) executing the dspam binary > > To avoid suExec for (1) you need to have ALL data in the database. Not only quarantine. > To avoid suExec for (2) you could add the web server user to be a trusted user. > > The WebGUI however would need to be much more complex if everything is in a database. The UI would need to implement direct access logic to the database. Right now the WebGUI is storage backend unaware. >
Both solutions doest feel right :-) Why not everything in the database? Ok maybe not possible to run every currently support DB Backend. But again , DSPAM is Design as an Enterprisesystem not as an Clientsystem where i have to drive lowcost BTW Big Quarantines would be processed much faster if everything is in the DB. YOu do not have to parse a hole 200MB file And i CANNOT agree thats much more complex fort he webui - i tell you its defenetly easier since you do not have to parse the files and bother with all those problems comes with it. And more... you can split the mails on different tables (attachment/subject/content) this should be done by dspam TO Read you do not have to parse and filter (where always can go something wrong o rat least tage ages) You simply request the needed information For example: to show the whole list of messages stored in a mysql DB its one sql is 5 rows of code (in the very simply variant :-) Where the problem with direct DB access? Perl/php/java have it all built in And you do not need anything. You can run in jail or whatever you want (another thing i dont like apache being not jailed) no suexec or another thing with users and rights Simply DSPAM gets a message / decide to quarantine it / split and write it to the DB >From there simply fetch it and show it. You do not need additional utilitys to delete very old quarantines - one statement is good for it The Filesystem version isnt simplier - its much more complicated - we nee down atmic here (locks and co) We need to parse and bother with charset We need to bother with user UIDs, setuids, and so on We need third party tools to clean We do not have a real overview how those files grow User cannot set their own groups We cannot autoassign by vertain rules since that would be more complicated And so on ..... There are so many things possible to do much easier / or even possible to do by storing everything in the DB backend PS do you think google saves their images on a filesystem or in a database ... hmm guess :-) ------------------------------------------------------------------------------ _______________________________________________ Dspam-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspam-user
