Stefan Foerster:
[ Charset UTF-8 unsupported, converting... ]
> * 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.
In the posting that you are replying to, I discussed the constraints
for out-sourcing postscreen tests to helper programs, using DNS,
TLS and policy delegation as examples.
- The most practical option is a pool of helper programs that can
have implement non-trivial functionality and that can die on errors.
- The least practical option is to implement non-trivial functionality
in a single program that handles thousands of overlapping requests.
Either way, it will be a challenge to make sure that postscreen
will never make performance worse.
Wietse
