Ahm, Just a Question :-) From my Point of View there should be no Problem with using the same DB - i mean why should be .. since it should make absolute no difference ifo ne or more applications write to the same tablespace So the only 2 things are more Problematic are 1. user and group administration 2. quarantineboxes
So in theory - if everything is stored in the database and nothing is stored on the filesystem it should easily work in a cloud. (Which brings me again to the point - all quarantines in the database thing :-) So the question : i am right about that ? În data de Jo, 06-05-2010 la 21:03 -0500, Kenneth Marshall a scris: > On Fri, May 07, 2010 at 02:05:57AM +0300, Stas Su??cov wrote: > > ??n data de Vi, 07-05-2010 la 00:32 +0200, Stevan Baji?? a scris: > > > On Fri, 07 May 2010 01:18:25 +0300 > > > Stas Su??cov <s...@nerd.ro> wrote: > > > > > > Thanks a lot for these tips, I'll try some of them and come back with > > > > results. Hope I'll have something interesting to report. > > > > > > > THEY DON'T WORK NOW! I only purposed that DSPAM source could be changed > > > to allow something like that. I mean that "*remote_addr*" part is NOT > > > IMPLEMENTED! > > > > > > > > > > Huh, looks like I missed that "could be" part. > > Though I will still consider the MySQL replication idea. > > > > > > Reading all the above it's pretty clear for me that dspam wasn't > > > > designed as a tool to be used in cloud. I would think about it since all > > > > the software is trending into that direction. > > > > > > > DSPAM can and does work in a cloud. The only point is that DSPAM does not > > > have a complex trasport mechanism. Normally people use MTAs for that and > > > not a Anti-Spam application. > > > > > > > > > > I think Internet evolves into something where a single MTA is just not > > enough, though a single AntiSpam server will still be enough. That was > > my main thought. > > > > > > This is a classic setup of a client server situation, and as long as it > > > > doesn't have a simple solution, it leaves space for improvements. > > > > > > > Look it from that point: Something like ClamAV is able to work in > > > client/server mode. You can open a socket to the ClamAV daemon and send > > > stuff to it and it will respond if the message is OK or not. DSPAM offers > > > the same. It is capable to tell you if a message is SPAM or not. > > > You on the other hand want more. You don't want just the Anti-Spam engine > > > to tell you if it is Spam or not (which btw DSPAM already is capable of). > > > You want to pass the whole message to DSPAM and then let DSPAM do the > > > evaluation and then DELIVER the message to another place. This is more > > > then just simple/classical clinet/server operation. > > > > > > Just out of curiosity: Does any of the other F/OSS Anti-Spam solutions in > > > the wild allows complex transport logic? Which one? > > > > > > > Sorry, you're right, it is not that simple/classic. I'll try to be more > > precise. > > > > I also don't know about anything similar I described as an Anti-Spam > > solution. > > > > This sounds like something that can easily be addressed by running multiple > DSPAM instances on the anti-spam server, one for each MX. They can use the > same DB backend. Then each MX would need to deliver to the appropriate > DSPAM instance, a pretty trivial configuration. There won't be problems using the same db? Or those are minor and can be skipped? -- () Campania Panglicii în ASCII /\ http://www.asciiribbon.org/ ------------------------------------------------------------------------------ _______________________________________________ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user !DSPAM:1005,4be3ed30230047224784171! ------------------------------------------------------------------------------ _______________________________________________ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
