Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!howland.erols.net!news-peer.gsl.net!news.gsl.net!EU.net!Ireland.EU.net!Ireland.EU.net!not-for-mail From: nick@eunet.ie (Nick Hilliard) Newsgroups: comp.mail.sendmail,comp.mail.smail,comp.unix.bsd.freebsd.misc Subject: Re: Sendmail vs. Smail... Followup-To: comp.mail.sendmail,comp.mail.smail,comp.unix.bsd.freebsd.misc Date: 18 Dec 1996 14:09:58 -0000 Organization: EUnet Ireland Network Operations Lines: 64 Message-ID: <598tvm$t0h@ezekiel.eunet.ie> 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> <1996Dec1721.54.58.11342@koobera.math.uic.edu> NNTP-Posting-Host: news.ieunet.ie X-Newsreader: TIN [version 1.2 PL2] Xref: euryale.cc.adfa.oz.au comp.mail.sendmail:35315 comp.mail.smail:2735 comp.unix.bsd.freebsd.misc:32743 D. J. Bernstein (djb@koobera.math.uic.edu) said: : The most common reason for very slow RCPTs in practice is very slow TCP : RTTs. This is not always the case. If the remote host has DNS checking of RCPT's enabled, then this can (and generally will) clock up considerably more latency than TCP round-trips. Not only do you have to shoot out UDP packets and get them back (similar rtt to TCP acking), but the time delay goes up by much more if you drop packets or if there is a delay at the remote nameserver. There are more variables involved and hence more scope for delay. : 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, you're really getting hung up on this particular Taiwan example. For the record, let me state some opinions and observations: a) (opinion) If the remote host can't cope with 10 RCPT's due to timeouts of some form, and the timeouts are due to poor provisioning or poor systems management, then that's really not my problem. The remote sys-admin should provision more bandwidth, disable DNS authentication in sendmail or arrange some local MX backup if he's having trouble receiving mail. If you disagree with this view, then fine b) (observation) Route flap is not the major cause of delayed mail. I don't know where you pulled this one from, but it really isn't much of a factor. The main factors for delayed/long-term queued mail are 1) host outages and 2) incorrect addressing to hosts behind firewalls. Unreachability due to transient route outages happens but is not a major contributing cause of delayed mail. c) (observation) If a route flaps like this, flap dampening comes into effect on most major Internet backbones and the route is blocked for quite often 20 minutes or more. For this reason, the situation you invented above sounds unlikely or at least rare. d) (opinion) If your routes flap persistently like this, you get what unreachability you deserve - flapping is harmful on the Internet. Like almost everything else, it can be controlled to a huge extent by careful management. e) (observation) The vast proportion of email which originates from the system I run (with the exception of ftpmail) is not addressed to remote, badly connected sites at the other end of the world which can't cope with 10 RCPT's. A considerable percentage are office memos addressed to multiple people on the same sites. When they start attaching 5 megs speadsheets and 10 meg autocad drawings, you really don't want to deliver these separately. Correction: I don't want separate delivery. You may disagree. Also, why did qmail originally do separate delivery of the same message to multiple sites? Was this feature in the initial design or was it an intentional or semi-unintentional by-product of qmail's queueing strategy? Nick