understanding the why and the wherefore of postscreen

[Daniel Bromberg]

With an emphasis towards handling larger loads in the future, I am 
trying to get a grip on the advantages provided by postscreen as opposed 
to letting smtpd do the filtering "in situ."

My skeptical side says that the same logic must be implemented to reject 
a client regardless of the process context, and postscreen creates 
additional process structure overhead (space) and additional 
interprocess communication overhead (time), and is therefore a net loss 
to system performance.

My separation-of-duty side says that regardless, this overhead is small 
and the design is cleaner, allowing for more screening complexity with 
interesting rules that reject earlier in the SMTP conversation. My 
skeptical side replies that these rules could still exist in the smtpd 
configuration grammar.

My optimization side says that parallelism can still be leveraged both 
on a hardware basis, as postscreen is doing logic on a new cluster of 
connections while smtpd is doing logic on an existing cluster, and on an 
I/O blocking basis, as postscreen can be waiting for (multiple, 
differently speeded) smtp client introductions while smtpd can focus on 
I/O heavy DATA transmission.

My skeptical side again replies, this time arguing parallelism is 
relatively low given that network speeds are much slower than CPU 
processing speeds, and that smtpd can do select() multi-plexing rather 
than using additional processes to avoid blocking on any one socket.

Finally, my DDAUIB (don't do anything until it's broken) side says, what 
metrics can I measure easily to know smtpd is getting overwhelmed and 
it's time for Postscreen? Is there an internal connection queue length 
that can get too long?

Without signing up for a Postfix developer course, can anyone help 
straighten me out, ideally in a more concise manner than my usual wordy 
posts.

Thank you,
-Daniel