APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Debugging a failing pop mail connection

© January 2004 Tony Lawrence

A user at the remote site of a dedicated T1 connection complained that intermittently he could not send or receive mail. The machine was current with Microsoft patches and his connection to the main office otherwise worked, but mail was often a problem. This was usually blamed on Internet connectivity problems, but when we put in a SME Server at the main office and he still had the problem, it was obvious that something else was wrong.

I began by getting him to a command prompt and asking him to "ping mailserver". He got responses with no packet loss. I checked from the server side that I could ping him also. I then had him "telnet mailserver 110". This did not work, but it wasn't refused: he just could not connect. My suspicion was that he was being blocked at his end, so to confirm it I obtained his IP address and did

arp -d

to delete him from the arp cache. I then had him try the "telnet mailserver 110" again and noted that his machine did NOT appear in the arp cache (arp -an) . That means that the telnet was definitely blocked. As I said, I suspected his end, so I asked him to disable Norton Anti-Virus entirely and reboot. That instantly fixed it.

Turns out that NAV had expired. Whether that caused the problem or not I don't know, but I left him with the promise that he would download a new NAV. He also had very little memory (128 MB running Win2K), so I suggested that be increased also.

Arp can be very helpful in debugging problems like this.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Debugging a failing pop mail connection

Inexpensive and informative Apple related e-books:

Take Control of Preview

Take control of Apple TV, Second Edition

Digital Sharing Crash Course

iOS 8: A Take Control Crash Course

Take Control of Upgrading to El Capitan

More Articles by © Tony Lawrence

"Arp can be very helpful in debugging problems like this."

Yes it can. arp can also be useful in "fixing" DHCP problems caused when machine A, which previously acquired an IP address from the local DHCP server, disappears from sight, and shortly thereafter, machine B goes on-line and gets assigned the same IP address that previously identified machine A. This condition can occur when the arp cache persistence is set very long and the lease time on IP addresses is set very short.

The ultimate problem, of course, is that the MAC address associated with the DHCP-assigned IP address actually belongs to machine A, not B. So even though everything appears to be okay, the IP address is a dead-end. An arp -d of the offending IP address is all that is required to get the kernel to correctly relate to machine B's MAC address.


Actually, that was my very first thought. But since he could ping, that couldn't have been it.


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

Whenever the literary German dives into a sentence, that is the last you are going to see of him till he emerges on the other side of his Atlantic with his verb in his mouth. (Mark Twain)

Linux posts

Troubleshooting posts

This post tagged:



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode