* Wietse Venema <wie...@porcupine.org>: > I created postscreen because it is becoming too expensive to spend > one server process per zombie connection. Instead, one postscreen > process manages up to thousands of inbound connections simultaneously, > and drops the majority of them before they can affect Postfix's > availability for legitimate clients.
I've got a terrible headache right now, preventing me from thinking this through properly, but I guess that this paragraph actually outlines two problems, not one. The first seems to be the fact that Postfix is handling incoming connections synchronously, spawning an smtpd process per client. The solution to this is asynchronous programming, but it seems you decided that you'd rather implement this in a new helper program instead of performing substantial changes to the way incoming connections are handled in the existing code base. Can't say I blame you - during university, while doing a project with Gröbner bases, I had the opportunity to experience the unique problems and challenges one faces when dealing with asynchronous frameworks first hand. FWIW, I think that the design decision to create a new program was the right one to make. With the passing of file descriptors, it's even an elaborate one :-) The second point you mentioned is that you are planning on rejecting the majority of zombies with a set of - possibly fixed - tests within a single process. That means those tests do not only have to be effective, but also efficient (I might confuse those two, sorry, headache). The efficiency of such a test is something that can ideally be proved mathematically - or just deducted by common sense. It's effectiveness, OTOH, is something that can only be testimonied by intensive data gathering and accurate statistical analysis. In other words, you seem to think that the tests you implemented until now - PREGREET, HANGUP, DNSBL - are both, effective and efficient, and therefore sufficient to reach the goals you wanted to reach with the creation of postscreen. So, thinking about my initial posting again and reading the cited paragraph as well as the remainder of your reply, comparing complexity with gain, I'd like to withdraw my feature request. Stefan
