On 6/6/2012 8:45 AM, Wietse Venema wrote:
Curtis:
smtp_discard_ehlo_keywords = pipelining,silent-discard
(Again, this time without the d.) Aside from a little extra bandwidth,
would this cause outbound deliveries to go horrendously slower on a busy
mail server?
The issue is NOT bandwidth (i.e. the width of a pipe). It's latency
Yeah, I realized that the bandwidth impact would be minimal. (Someone
else noted in another thread a slight increase of bandwidth due to the
extra TCP round-trips.)
(i.e. the distance between pipe endpoints). You can increase the
former, but you can't break the speed-of-light limit.
Pipelining reduces the number of TCP round-trip times, At a minimum
there will be 5 round-trip times (SYN-SYNACK, ACK-220, EHLO-EHLOREPLY,
DATA-DATAREPLY, ENDOFDATA-ENDOFDATAREPLY; the SMTP client does not
wait for final handshake completion). Disabling pipelining adds one
round-trip time for each MAIL FROM and for each RCPT TO command,
from 5 to 7 or more. Your SMTP server may spend 40% more time
delivering mail, depending on the number of messages per destination
(which reduces impact of DNS lookups), and on the number of recipients
per message.
Yeah, I figured it would be a pretty significant slow down for hosts
that support it... I just wasn't sure what percentage of hosts support
pipelining. If only 10% of hosts were using it in the first place, the
40% extra delivery time lost on those hosts might be managable... but,
if you're saying that the majority of hosts do have pipelining enabled
(it makes sense that they would), then a 40% slow down would probably be
too expensive.
Postfix has bug workarounds for CISCO PIX that are enabled automatically
when mail has been queued for 500s ore more. Maybe some of the
optimizations such as command pipelining could also be made
time-dependent.
That would be awesome. I will stay tuned for that. In the mean time,
it sounds like we'll have to stick with the
smtp_discard_ehlo_keyword_address_maps solution. We'll just have to set
up something to monitor the logs and automatically add problem hosts. I
love how there's almost always multiple ways to solve a problem with
Postfix.
Postfix rocks! :-)
Curtis
Wietse
