Hi Hugo,

I would be interesting in trying out your patches.


Hugo Monteiro wrote:
On 02/09/2010 04:50 AM, Philipp Kolloczek wrote:
Hello folks.

I have followed all of the messages which came in reply to Hugo's msg.
There are many interesting points of view and as I use qmail-ldap
myself here is another one. ;)

For some time now i've been wondering if there are any plans to enhance
Qmail-LDAP in a near future.
Hugo, I sign that.
It would be great to see a development of qmail-ldap in the future.
Equal to other I, or let better say we - the ISP I'm imeployed - use
qmail-ldap since years.

As you can imagine it is a heavy patched version to fit our needs.
It includes some patches which can be found in Hugo's site, some self
developed ones, some changed to fit needs and fit in code and so on.
Just to note feature like the big quota patch, a mailhost routing feature or
user based settings for spam/virus checking and attachment sizes.

In summary we use it actually in a HA Mail-Cluster based on two
Loadbalancer, a number of Sun T2000 and a NetAPP Storagesystem
for the main part (MTA / qmail-pop / 3rd Party IMAP).

In combination with qmail-queue-patch and Simscan we have include
a spam filtering/checking farm and also two different virus scanning
engines. Virus engine depends on customers choise.

With simscan and SpamAssassin tools like DCC and Razor are easy to
integrate, actually we use DCC. And based on Hugo's qenvscan patch
we actually are in the process of integrating a customer based
senderquota and also some kind of greylisting depending of
the amount of errors a sender IP/user is generation, like hammering
with massiv RCPT failures, relaying probes or ignoring the rctp count
limit.



Hello Philipp,

I too have some other patches that i have not yet published because i feel they need a little bit more testing. I can tell you though that i already have work done in the matter of per user message throttling, either based on number of messages or message size.

Another thing that i have implemented is the concept of SMTP (pre DATA) and EOM (end of message) protocol state, correlating both within a single SMTP session. That allows performing two sets of independent tests but maintaining a relation between the two. That will allow the use of SMTP policy servers such as Cluebringer (policyd v2).

I could arrange publication of that work if anyone is interested.

I also wonder what are the feelings of both the authors and users about turning Qmail-LDAP into a community driven project. In the event that the original authors are not available to continue to work on Qmail-LDAP, i wonder what are the feelings regarding a possible fork of the project.

Best regards,

Hugo Monteiro.

Reply via email to