[TriLUG] Re: help, fetchmail is downloading incredibly slooooooooowly
jonc at nc.rr.com
Fri Apr 13 10:46:19 EDT 2001
As I was reading your message, I thought: "That's gotta be a DNS problem!"
The description is perfect...
But it could also be a piece of crap "mail" on the server. Mindspring
recently spammed a bunch of folks with a malformed email. Fetchmail may be
chocking on that piece of mail and then moving on.
Try telnetting into the pop server and see the problem first hand:
telnet mail.mindspring.com 110
Minimal POP3 Commands:
USER name valid in the AUTHORIZATION state
STAT valid in the TRANSACTION state
QUIT valid in the UPDATE state
Optional POP3 Commands:
APOP name digest valid in the AUTHORIZATION state
TOP msg n valid in the TRANSACTION state
Note that with the exception of the STAT, LIST, and UIDL commands, the reply
given by the POP3 server to any command is significant only to "+OK" and
"-ERR". Any text occurring after this reply may be ignored by the client.
On Friday 13 April 2001 08:01, rpjday wrote:
> i'm baffled by a problem i've had once before that i thought
> i solved, but now it's back. from home, after i bring up PPP
> with "ifup ppp0" to connect to mindspring, and start to download
> mail with "fetchmail", each of the messages (average 2-3 K) download
> unbelievably slowly -- each message starts to download, then hangs
> in the middle for 30-45 seconds, gets flushed, then fetchmail goes
> on to the mext message. occasionally, fetchmail simply aborts,
> probably because of some timeout.
> i remember having this once before, and got so frustrated i called
> mindspring tech support, who couldn't help. it eventually dawned on
> me that, if i'm getting timeouts with network-related stuff, DNS might
> be a good place to start. sure enough, i had just returned from a
> client where i'd put my laptop on their internal network, and i still
> had *their* DNS server addresses in /etc/resolv.conf. slap forehead.
> duh. fixed that, and we were off to the races.
> i never thought i'd see that problem again, but once again, just got
> back from a client, having been on their internal network, and yup,
> painfully slow fetchmail. this time, i've looked everywhere for a
> DNS-related problem and can't find one. all the config files look good,
> /etc/hosts, /etc/host.conf, /etc/resolv.conf, etc. sending mail works
> just fine, browsing is fine, it's just fetchmail that's a real dog.
> any suggestions? i'm more than willing to be embarrassed if someone
> can tell me how to fix it. ack.
> p.s. is there an obvious way to tell if DNS is timing out, or something
> to that effect? there's no indication in /var/log/messages, is there
> another log file for that? thanks again.
More information about the TriLUG