Debugging a failing pop mail connection
I've removed advertising from most of this site and will eventually clean up the few pages where it remains.
While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.
If you found something useful today, please consider a small donation.
Some material is very old and may be incorrect today
© 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 10.1.1.92
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.
If you found something useful today, please consider a small donation.
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 © 2012-07-14 Tony Lawrence
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)
This post tagged:
Skills Tests
Unix/Linux Book Reviews
My Unix/Linux Troubleshooting Book
This site runs on Linode
"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.
--BigDumbDinosaur
Actually, that was my very first thought. But since he could ping, that couldn't have been it.
--TonyLawrence
Printer Friendly Version
Debugging a failing pop mail connection Copyright © January 2004 Tony Lawrence
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