[TriLUG] Re: help, fetchmail is downloading incredibly slooooooooowly
Jon Carnes
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
user ur_username
pass ur_password
...
Minimal POP3 Commands:
USER name valid in the AUTHORIZATION state
PASS string
QUIT
STAT valid in the TRANSACTION state
LIST [msg]
RETR msg
DELE msg
NOOP
RSET
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
UIDL [msg]
POP3 Replies:
+OK
-ERR
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.
http://freesoft.org/CIE/RFC/1725/
===
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.
>
> rday
>
> 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
mailing list