If you're familiar with wireshark (or another packet analyzer) I'd be interested in seeing where the delay actually is coming from.
J. Rutkowski On Thu, Jul 23, 2015, at 06:27 PM, walt wrote: > On Thu, 23 Jul 2015 21:49:50 +0100 > Mick <michaelkintz...@gmail.com> wrote: > > > On Thursday 23 Jul 2015 06:47:07 Nikos Chantziaras wrote: > > > On 23/07/2015 05:49 πμ, walt wrote: > > > > Nope. Wrong. I just changed my resolv.conf back to the IP > > > > address of the router that ATT forced me to "upgrade" to and the > > > > delay is *gone*. > > > > > > > > The delay I was seeing was apparently caused by something very > > > > local to me, and suddenly vanished after two days. > > > > > > > > The interwebz is a scary place :( > > > > > > A friend of mine had a problem where half the time he tried to > > > browse to a URL, he would end up on a porn site. I thought it was > > > some Windows malware. But when booting from a USB stick with > > > SysRescueCd on it, even "ping google.com" would ping a porn site at > > > first. > > > > > > His modem/router combo device was infected with something that > > > hijacked the DNS setting. He was using a DSL-Modem/router from 2003. > > > > > > It *is* a scary place. > > > > Walt's previous test indicates that his ISP's DNS repeaters were > > congested, or under DoS attack. Setting temporarily a higher level > > peer could prove the point. Some top level DNS resolvers shared here > > (from a previous post in this list): > > > > http://www.circleid.com/posts/20110407_top_public_dns_resolvers_compared/ > > The most interesting thing I've learned from this thread is that a > whole bunch of other people are just as paranoid as I am. I just > assumed that google had "done something" to produce this problem, but > now I know what really caused it: > > I recently switched from thunderbird to claws-mail, mostly as an > experiment because I'm not sure how committed mozilla.org is to > maintaining thunderbird. > > I really like claws-mail in general, but this "google" problem was > actually caused by some very dysfunctional behavior in claws-mail. > (I've been building from the latest git sources, so I gotta expect > some buggy behavior...) > > Anyway, claws-mail (for normal behavior) apparently *requires* me to > switch email accounts from a drop-down menu (Configuration::Change- > current-account) before trying to read or send email. > > If I fail to change the email account then claws-mail produces these > very long and variable delays. I have no idea what it's doing while it > waits, but it does connect eventually. > > Curiously, I don't see the same problem with nntp servers, just email > servers (smtp and imap, I haven't tried pop3). > > >