Stefan Foerster:
> * Wietse Venema <[email protected]>:
> > 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
