On Thu, 06 May 2010 23:54:22 +0300 Stas Sușcov <[email protected]> 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. 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. > 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 :) ------------------------------------------------------------------------------ _______________________________________________ Dspam-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspam-user
