gg> Okay it happened again. Attempting to reply to an email through VM gg> & got the unknown host error. This time I had some things ready. gg> and sure enough this paused Emacs for a while and then spit out gg> the "unknown host" message in the minibuffer. On restarting Emacs gg> and running this again, it made the connection just fine and the gg> SMTP greetings line showed up in my scratch buffer. I have seen similar problems (on my laptop running RedHat Linux). I don't have a good solution, but the workaround you came across (restarting emacs) is what I do. Here is my wild speculation about what is going on. Like most UNIX applications, the first time you need to resolve a domain name emacs calls the resolver library. The resolver library reads /etc/resolv.conf to get the IP addresses of the DNS servers you use. It then remembers those IP addresses for next time (ie, it doesn't re-read /etc/resolv.conf). When you connect to your ISP, your PPP daemon is probably creating a new /etc/resolv.conf with the "right" DNS servers. Ditto for using DHCP to get an IP address on the local LAN. Although your ISP DNS servers may or may not be visible in the Internet at large, it is reasonably likely that your LAN DNS servers are behind some firewall and not visible outside. So, the steps to calamity (for me, and perhaps for you) are: 1. Get IP address and DNS server info via DHCP on LAN. 2. Run emacs and read resolv.conf. 3. Wander away, and connect to ISP via PPP. 4. Anything DNS-ish makes emacs hang for a good while. You are less likely to notice this with other applications since they don't have the long life of emacs. That's why ping and telnet worked for you. They were freshly started processes and each read the current /etc/resolv.conf. Here are some possible and partial solutions: 1. Just live with it. Restart emacs as necessary to pick up new DNS info, or run two copies of emacs (one for LAN, one for ISP). Ick. 2. Run a local DNS server. Configure your DHCP and PPP to not overwrite /etc/resolv.conf (which now points at your local machine). 3. It sounds like the resolver is ignoring whatever you put in /etc/hosts. You may be able to alter it's behavior by messing with /etc/host.conf (on Linux, various other places on other UNIX variants). That will be OK for a small number of hosts, but there is a reason people use DNS instead of /etc/hosts, so don't overdo it. 4. Fill /etc/resolv.conf with DNS servers that are visible in both cases (ISP and LAN). Configure your DHCP and PPP to not overwrite /etc/resolv.conf. (You may have trouble finding DNS servers that fit this constraint, depending on firewalls and various things you can't control, but it's a good solution if you can find them.) 5. Petition someone who is willing and able to do something about this in emacs source code. Granted, other apps don't have DNS hacks in them, but they don't run for months at a time either. I believe there are C calls that can be made to re-initialize the resolver to have it re-read /etc/resolv.conf. emacs would just have to keep track of the timestamp on /etc/resolv.conf and Do The Right Thing. Given all the stat() and fstat() calls that emacs is doing, it shouldn't be much of a performance burden to check before most/all resolver calls. (It would be even cooler if there were a resolver option to do this internally on behalf of an application, but I don't think there is.) -- bill(a)carpenter.ORG (WJCarpenter) PGP bill(a)bubblegum.net 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3

WJCarpenter writes: Note that on Solaris and most Linux distributions you can set up /etc/nsswitch.conf (I think the name means "Name Service Switch") which will instruct the resolver whether to use /etc/hosts, DNS, or some other methods like NIS to resolve hostnames to IP addresses. You can specify more than one method, and specify the order in which they are searched. Putting "files" first causes the /etc/hosts file to be consulted before sending any DNS requests. Read the manpage for nsswitch.conf for more info.