Conrad <[EMAIL PROTECTED]> writes: > We looked at using it on our production servers a few years back. At > the time it was missing a lot of robust code, ssl extensions, and > didnt scale as well as we expected. After lots of testing, we went > with a different solution:
I inquired about this because I'm actually considering starting work on a similar project. Lately I've come to the conclusion that a layered approach like this is where it's at. MTAs have tried to get into the business of spam-blocking, but haven't done a great job. Even when they have, each MTA does the same thing differently, so between MTAs there is no consistency. It seems like a good idea to use a primary layer to reject spam, and let the MTA underneath it do what it was designed to do - transfer and deliver mail. I was thinking the other day that this is the only reason I dropped qmail for Postfix a few years ago. Because qmail has no spam defenses, and Postfix does. But if that were not an issue, I'd still prefer qmail, which is easy to understand, has a simple and clear configuration, is secure, has a great local delivery agent, cool .qmail interface, great virtual domain interface, qmail-inject, etc. Much of this I've never been able to replicate with Postfix. qpsmtpd seems to be the only open source SMTP proxy I've found that's of any significance. But it's written in Perl, which means you have to write yucky Perl code to add plugins or modify/understand current ones, and the scalability is questionable. I think it needs some competition, and I see this type of product as something that is badly needed for the aforementioned reasons. I'd love to be able to switch back to qmail with a dead simple configuration, and leave all the spamblocking (SPF, black/white/greylisting, tarpitting, content filtering, RFC compliance, DSBLs, virus scanning, Bayesian analysis, etc) to some other tool. So I'm thinking of writing my own SMTP proxy, using some of the techniques I've learned over the past few years working on a terascale message passing library at my day job, for example -- - Concurrency, using very lightweight (non-OS) threads, and where processes communicate using asynchronous message passing without sharing memory. This would allow for great scalability out of the box on a single server, and optionally a distributed configuration where you could run the software on multiple servers, or "nodes", and the workload would be distributed amongst them transparently. - First class fault tolerance, using process monitoring, and in a distributed installation where processes would fail-over to other nodes and then automatically migrate back to recovered nodes. - Incremental code loading and "hot swapping" so that the software never needs to be HUP'd, stopped or restarted. Configurations can be changed, new plugins removed or inserted, and even the software itself upgraded to a new version without stopping it. It'll be designed to "run forever", except for hardware or electrical failures. Now the question is whether I'll ever have the time to start such a beast. :-) _________________________________________________ tmda-workers mailing list ([email protected]) http://tmda.net/lists/listinfo/tmda-workers
