Wietse Venema wrote: > [thundering herd problem] > > When the sender exceeds the smtpd_client_connection_count_limit, > > they will get a 4xx deferral. When they retry delivery is out of > > your control -- some may retry in a few minutes, other hours, a few > > never (although not retrying is non-RFC compliant and seldom seen > > with legit servers). So it can result in severe mail delays and > > possible loss of mail.
In this case it is Exim and I don't think it will lose email. There might be delays though. I could see it pushing mail off into a long term deferred queue instead of delivering it through the currently active connections. Thanks for the description. > > The bigger problem is that one or two connections from a > > well-connected client will still overwhelm your bandwidth. The real > > solution is traffic shaping or QoS to limit the bandwidth used by > > SMTP. Your firewall software or your router may already have this > > feature, just waiting for configuration. > > Many TCP/IP stacks will let you shape traffic. First, I have a very imperfect understanding of traffic shaping. But I was under the understanding that traffic shaping really only worked well on the outgoing side. Because on the incoming side by the time the netfilter can decide what to do about it the packet has already been received. This makes rate limiting the number of connections easy, basically the same as smtpd_client_connection_count_limit, but limiting the data bandwidth rate difficult. But again I know little of traffic shaping. BTW... I am using the Linux kernel. > Otherwise, you can set the Postfix tcp_windowsize to a non-zero > value to slow down email. I have used a value as low as 512 to keep > a low-speed backup connection usable. For this a simple "postfix > reload" is not sufficient. For details see: > > http://www.postfix.org/postconf.5.html#tcp_windowsize This looks interesting. I will investigate and try it. Thanks! Bob
