On Fri, 07 May 2010 01:18:25 +0300 Stas Sușcov <s...@nerd.ro> wrote:
> În data de Jo, 06-05-2010 la 23:50 +0200, Stevan Bajić a scris: > > On Thu, 06 May 2010 23:54:22 +0300 > > Stas Sușcov <s...@nerd.ro> wrote: > > > > > Sorry, didn't mean to look like something explosive :) > > > > > Easy. > > > > > > > Yep, exactly. We got MySQL and LDAP on main server A. B is in the same > > > network and C is in another city. > > > > > Hmm... so that whole setup is very dependend on server A. If server A goes > > down then MySQL and LDAP are gone and server B and maybe server C can not > > use MySQL/LDAP services. Right? If this is not an issue for you then you > > could install DSPAM on server B and configure it to use the MySQL instance > > on server A. Just a normal setup of DSPAM but instead of using the local > > socket or 127.0.0.1:3306 you would use 1.2.3.4:3306. Another possibility > > would be to setup MySQL on server B and use MySQL replication in master <-> > > master replication mode. Regardless which of the two above you would use, > > you would probably need to share DSPAM_HOME in some way between server A > > and server B. Something like NFS would work. I for example use GlusterFS to > > share DSPAM_HOME between the various DSPAM instances/nodes. > > > > If this is not an option then extending DSPAM to use the connecting/remote > > client as DeliveryHost could be an option. The only problem I currently see > > in that approach is that DSPAM right now already has this domain dependend > > delivery option. Enabling a connection back to the connecting client would > > either need to fit into the current domain delivery model or we need to > > find a way how the both can coexist without disturbing each other. > > > > Maybe something like this here would be an option: > > > > Normal domain dependend delivery: > > DeliveryHost.domain.com 1.2.3.4 > > DeliveryPort.domain.com 10024 > > > > Normal delivery (IP based): > > DeliveryHost 1.2.3.4 > > DeliveryPort 10024 > > > > Normal delivery (socket based): > > DeliveryHost /var/run/dspam.sock > > DeliveryPort > > > > Delivery back to connecting client (IP based): > > DeliveryHost *remote_addr* > > DeliveryPort 10024 > > [OR] > > DeliveryHost.domain.com *remote_addr* > > DeliveryPort.domain.com 10024 > > > > > > The above used "*remote_addr*" value would then instruct DSPAM to use the > > remote address of the connecting client as DeliveryHost. > > > > 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! > > Another approach could be to extend the DSPAM proprietary DLMTP server mode > > and allow to pass a value to the DSPAM server telling where to deliver that > > message back. This would however require the use of "dspamc" binary or > > "dspam --client". > > > > Or maybe it's time to implement what Julien Valroff asked long time ago: > > http://sourceforge.net/tracker/?func=detail&aid=2838073&group_id=250683&atid=1126468 > > > > Or maybe mix Julien's and your requirements? Aka: Adding that *remote_addr* > > to DeliveryHost/DeliveryPort AND allow profiles for > > TrustedDeliveryAgent/UntrustedDeliveryAgent. > > > > Currently we only have storage profiles. But it would be not such a ultra > > big coding challenge to add delivery profiles. However... in case we > > (probably me. who else?) add that delivery profile option to dspam/dspamc > > then IMHO they should overwrite/have higher priority than normal delivery > > or domain based delivery. > > > > 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. > 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? > Just my two cents. Thanks for bringing this up. > > > > > > Btw, I'm stas on irc in #dspam. Lurking most of the time, maybe I should > > > ask there if somebody hangs on irc? > > > > > Ion-Mihai is hanging there. And he is sure already sharpening his Release > > Manager knife to kill me because I am purposing changes for DSPAM :) > > Yep, had a chat this afternoon with ITetcu, he encouraged me to ask on > mailing list :) > Mailing list is often better because your question gets exposed to more users at once. And beside that the communication on the mailing list is mirrored and saved at many places. > Thanks for support. > > -- > () 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
