Stefan Foerster: > * Wietse Venema <wie...@porcupine.org>: > > Stefan Foerster: > > > One of the greatest improvements in the 2.7 tree is the ability to > > > defer transmission of received messages to a SMTP proxy until the > > > message receiption completes (smtpd_proxy_options = speed_adjust). > > > > Can you be more specific about the benefits? > > Number of filters is down by more than 40%. Comparing a typical day > before and after we deployed that feature: > > http://www.incertum.net/~cite/speed_adjust.png
As with the first public release release, Postfix avoids the need for a forklist upgrade (that was geek talk for having to install more powerful hardware). Now I can claim it as a "green" option. > Other sites might not notice such a large impact: Our setup includes a > large number of clients connected via lines with little bandwidth > (2MBit/s) which is typically used for other purposes besides sending > mail. If the time a mail transmission takes is negligible, I expect > the results to be vastly different. It also depends on how far away the clients are: each round-trip time adds to the duration of a session (from this location near New York I measure some 90ms RTT to europe and 175ms to Japan). > Furthermore (I'm not 100% sure about this, would be glad if you could > confirm this) it's much harder to DoS a Postfix server with that > patch: Previously, all you had to do was opening a number of > connections equal to the number of pre-queue content filter processes, > go through the initial (E)SMTP steps and then send a mail very slowly. As long as the number of SMTP server slots is finite, there will always be saturation effects. The main trick of speed-adjust is that you can run more SMTP server processes than filters, and thereby reduce the impact of slow or non-cooperative clients. Of course the system still saturates immediately when the PEAK email volume exceeds the filter capacity. With after-queue filters, saturation happens when the AVERAGE volume exceeds filter capacity. > With "smtpd_proxy_options=speed_adjust", you'd have to DoS the Postfix > SMTP server itself, and between postscreen guarding it, high process > limits, access control and the stress adaptive server personality, > this one is well able to take care of itself. I have been looking for incremental steps to improve Postfix's handling of non-cooperating clients, and speed-adjust is part of those steps. Postscreen greylisting support should also help a lot, but that will probably not be in Postfix 2.7. Of course all these things do is increase the threshold. No system except a wire cutter can deal with unlimited amounts of traffic. Wietse