Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!caen!uwm.edu!ogicse!littlei!trim!adams
From: adams@trim.intel.com (Robert Adams)
Newsgroups: comp.unix.sysv386
Subject: Re: SVR4 - broken Yellow Pages, slow smtp, no monitor
Message-ID: <1767@gandalf.UUCP>
Date: 31 May 91 17:51:26 GMT
References: <1991May30.115102.29590@qut.edu.au> <1991May30.045643.26262@csrd.uiuc.edu>
Sender: news@gandalf.UUCP
Reply-To: adams@trim.intel.com (Robert Adams)
Organization: Intel Corporation; Hillsboro, OR  USA
Lines: 21
Nntp-Posting-Host: trim

In article <1991May30.045643.26262@csrd.uiuc.edu>, pwolfe@kai.com (Patrick Wolfe) writes:
|> Now, can anyone tell me why SVR4 always takes at least five minutes to deliver
|> an email message to another system via SMTP?  What the heck is taking so long?

The problem is that the smtp transport daemon is trying to resolve the
route by searching for MX records (broadcast resolution request, wait,
timeout, broadcast resolution request, wait, timeout...). An un-
successful search will take 3 to 5 minutes.

For SVR4 version 3, USL added a "-N" parameter to the smtpqer invocation
to tell him not to do the MX record resolution (invocation in
/etc/mail/mailsurr).

For version 2, a workaround is to turn on the dynamic name resolution
stuff (edit /etc/resolv.conf, etc) so that the smtp system has a quick
way of resolving names.

        -- Robert Adams         adams@littlei.intel.com
                                ...!uunet!littlei!adams
Disclaimer: Any opinions expressed here are my own and are not
     representative of Intel Corporation.