Am 07.05.2010 17:14, schrieb Stevan Bajić: > On Fri, 7 May 2010 16:55:12 +0200 > "imposit.com - Webmaster"<[email protected]> wrote: > > >>> [...] >>> >>>> 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 >> >> >> > Look. I am not the one against everything in a db. For me DB is fine. The > only thing that is bothering me is that so far no one has done serious work > on DSPAM in the last months beside me. Every one keeps talking, talking, > promissing, talking and at the end everything is hitting me. > Remember the PHP WebUI talk? Doing a WebUI should be a no issue but even that > small development is never happening. offtopic, but even the imposit.com site is not finished and under construction.
> At the end every one is waiting for the other to do something. And the only > idiot investing a lot of time is me. Funny. If you guys are all so horny on > that DB stuff, then why is now one helping to get that implemented in DSPAM? > Why? Is it because of me? Am I the show stopper? > > > >> >> PS do you think google saves their images on a filesystem or in a database >> .... hmm guess :-) >> >> > They save it for sure on the filesystem. Now you can go on and tell me that > it is saved in a database but that database is for sure saved on a > filesystem. :) :) :) : > > >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Dspam-user mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/dspam-user >> >> > ------------------------------------------------------------------------------ > > _______________________________________________ > Dspam-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspam-user > > ------------------------------------------------------------------------------ _______________________________________________ Dspam-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspam-user
