Yes, I proved this empirically. After I applied qmail-ldap-control patch I had to increase the softlimit memory size of the qmail-smtpd process from 2.000.000 bytes to 20.000.000 (Actually, I've tested untill 7.000.000 and it still needed more memory, then i got mad and increased it to 20.000.000 definitely)We have thought about qmail-ldap-control for a long time now and have drawn up our plans how we want to implement that. The existing control implementation is pretty inefficient and totally breaks down if the LDAP server gets lost.
Also I'm having other problems with this patch and I can't get help from anybody. This patch is not working as its documentation says, and i can't contact Turbo Fredriksson to report this to him.
Our solution will continue to accept mail and everything but delivering mails to mailboxes.
Good idea.
Ok Andre, just trying to give you some more motivation, I'd like to remember you that, the more qmail-ldap fits smoothly for large-scale enterprise situation, more it gonna be used by big companys. And the smooth support for clusters (and virtualdomains too) is the essential point for large-scale environments.Why isn't that implemented yet you ask? Two reasons; We haven't found enough (spare) time to do it and/or nobody has yet stepped forward to fund this it so we can work on it during business hours. Maybe this will change it, we never know. ;)
I really like all the features qmail-ldap has, like spam blocking and smtp/qmqp traffic compression, but I was compelled to use it since it provides a clean way to split a domain through remote mailservers. If I had only one domain to take account, qmail-ldap would be just perfect. But when it comes to add/remove virtual domains in a cluster of remote mailservers, qmail-ldap is still missing some facilities.
So i reinforce my vote that you implement qmail-ldap-control into qmail-ldap. Surely you gonna built a great product that I and a lot of people in the world will love(and need) to use. :-)
Best regards,
bruno negrão
