Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!spool.mu.edu!newspump.sol.net!howland.erols.net!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!uunet!in2.uu.net!128.248.178.247!koobera.math.uic.edu!djb From: djb@koobera.math.uic.edu (D. J. Bernstein) Message-ID: <1996Dec1721.54.58.11342@koobera.math.uic.edu> Date: 17 Dec 1996 21:54:58 GMT Newsgroups: comp.mail.sendmail,comp.mail.smail,comp.unix.bsd.freebsd.misc Subject: Re: Sendmail vs. Smail... References: <57tf61$gq7@raven.eva.net> <58rvbf$r6t@news.fsu.edu> <1996Dec1510.41.00.4656@koobera.math.uic.edu> <1996Dec16.152941.1706@isac.hces.com> Organization: IR Lines: 22 Xref: euryale.cc.adfa.oz.au comp.mail.sendmail:35286 comp.mail.smail:2730 comp.unix.bsd.freebsd.misc:32725 Simon Casady <cap@hces.com> wrote: > So tell us, please, why does the RCPT cost so much time? The first thing to understand is that the client has to wait for the RCPT response before it can send another command. The time between sending RCPT and receiving the response is added to the delay in every recipient's mail. If the time is high enough, the client will time out, deferring the message for many minutes. Even if the time isn't that high, several slow RCPTs can add up to a huge delay for every recipient. The most common reason for very slow RCPTs in practice is very slow TCP RTTs. If routes are flapping, for example, then packets will usually shoot off into nothingness, but there will be occasional short bursts where the routes are correct and the client can talk just fine to the server. An SMTP conversation short enough to fit into one burst will have an average delay of half the flap period. Add one extra round trip and suddenly the average delay jumps to 1.5 times the flap period. There are many more contributing factors; this isn't a simple issue. ---Dan Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html