From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8) Gecko/20020208 BuildID: 20020311 This is for version 0.9.9 (20020311)... Hitting the "get msgs" button does *nothing*. Trying to send a message results in some data being sent about every 3 seconds or so for infinite time. Everything works fine with old version 0.9.8. (tried several times with both versions) Reproducible: Always Steps to Reproduce: Hit "get msgs" or try to send a mail. I don't know... Mail server type is POP3, server name is given as IP address. SMTP server name is given as an IP address as well.

Can't repo on 2002031104 (Win2K). POP3 incoming SMTP outgoing, hostnames not IP. Doesn't seem to be polling for new mail every X mins, but pressing 'get msgs' brings new ones down and writes Good Stuff (tm) in the status bar.

Dupe of 111102? pi

*** Bug 138555 has been marked as a duplicate of this bug. ***

I thought, maybe you do some sanity checks on the e-mail address and so it goes wrong. My data goes through a proxy and the e-mail address is of the form username#mailhost@proxy. Just a thought.

*** Bug 142713 has been marked as a duplicate of this bug. ***

Since this bug is, sadly, still not resolved for RC3 I investigated a bit further. I can now rule out that the problem is the connection though the proxy... I tried a _direct_ connection to my university (which is too expensive for me to use it normally) and getting/sending messages *still* did not work. However, I got the error: "Could not connect to server 'mailhost'; the connection was refused.", where 'mailhost' is the DNS name of my mail server. Surprisingly, by replacing the DNS name by it's IP address everything worked just fine! *Unfortunately* I cannot use the same trick if I connect via the proxy, where my Mozilla user name is 'username#mailhost' and the mail server name is the IP address of the proxy. Replacing 'mailhost' by the IP address gives the usual error after some time "Cound not connect to server 'proxy'; the connection was refused". Interestingly though, the proxy _is_ given as an IP address, and of course works. Note that all this worked and works fine till Mozilla version 0.9.8 and also works for any other email client. It started with version 0.9.9 that this doesn't work anymore, so I'd be *very* grateful to the one finding and fixing this bug. Thanks and bye, Michael Noisternig

michael.noisternig@sbg.ac.at: Are you still seeing this bug with recent builds? If yes: Which theme are you using when it happens? Does changing focus to the message pane *before* you click "get msgs" help? Also: Can you please try with a clean profile and tell if you see it with that one too.

I think I have tried *every* version without success starting from 0.9.9. This is no bug due to the theme (I use the standard modern theme). In fact "get msgs" *does* something - it sends some data out but it must do so to a *completely wrong* address, means Mozilla doesn't get any reply. It works exactly like this: I press "get msgs", then Mozilla sends some data out, waits for several seconds, gets no reply, and tries again and again... Remember: This worked just fine till 0.9.8 and works fine for *any other* email program. And yes, it also happens with a clean profile. It's such a helpless situation...

I have seen this occur on a colleague's machine, using Mozilla 1.0 and a post Mozilla 1.1a nightly build. His Get Msg button (and all equivalent invocations) simply stops working. The button is active, but has no effect whatsoever. I am therefore marking it as new. Several people in this office use Mozilla, but haven't had any problems. However, my colleague is the only one of us who uses POP3 to access his mail. The rest of us use IMAP. We are all connecting directly to the same server however. All platforms are Win NT or 2000 on Intel. This bug is not a duplicate of 111102. However, 140812 and 141151 look likely candidates for dupes. I think the critical priority attached to this bug is definitely justified. We are thinking of rolling a Mozilla or Netscape 7 browser to our users soon. However, we certainly couldn't consider it until this issue is resolved! I shall switch my mail config over to use POP in an attempt to see if I can reproduce it that way.

I can confirm this with 2002073008 on linux. POP3 account, no proxies. Going off/online does not help, only killing and restarting mozilla. When restarted and clicked on the button again, the first thing mozilla does is "Building summary file for Inbox".

We have started testing Mozilla/Netscape7 as a replacement for the now very aged Netscape 4. As a result, a lot of people in my office have started using Netscape 7 as their mail client. I appreciate that this is not strictly relevant here, but thought I'd give these comments to see if they were helpful. I shall do some testing with Mozilla 1.1 over the next few days. It seems that everyone who uses POP to access our mail server gets this problem. IMAP is completely immune. The client stops downloading new messages completely. Clicking get messages does nothing. In addition, there is often a permanent busy cursor when the inbox is selected. Restarting Netscape sometimes fixes this, but not always. However, closing down, deleting all index (.msf) files, and restarting the client does cure the problem. It's as if the index file has either become corrupted, or the mail client never finishes building it in the first place. I say this as, in some cases, this problem has appeared from the start. This is definitely a major bug. The mail client is unusable until it is fixed!

Just to confirm that this bug is present in Mozilla Build ID: 2002092304. I have also just changed our POP server from an old version of qpopper to uw imap (relaying POP3). This has made no difference; the problem shows identical symptoms with both servers. It seems that deleting the msf files is not a permanent fix either as the problem recurs. Given the critical severity of this bug, is anyone actually looking into it? Things seem awfully quiet around here!

Hi, I experience exactly the same problem as in comments #11 and #12. It happened with both Mozilla 1.0 and 1.1, running on Windows 2000.

Please go to bug 165832 and check if this here is a dupe or any of the bugs listed there is a dupe of this one. pi

Reporter: perhaps adding some keywords would help get some attention? ... 4xp, adt1.0.2, edt1.0.2, interop, mail4, mozilla1.0.2, mozilla1.2, mozilla1.3, nsbeta1, nsbranch, nsCatFood, nsenterprise, regression

some of those keywords don't apply, and none of them will have any effect unless there is something more concrete to work on. probably the most important thing is for someone to reproduce this with a recent nightly build of mozilla (I don't see anything more recent than September), using a standard theme and a clean profile. unless we can work out when this happens, it's pretty hard for anyone to fix it. someone should also take a look at the bug that Boris Piwinger mentioned and see if the other bugs there are duplicates or could add any info.

The problem persists even with the latest build of Mozilla 1.3a. I have tried with different versions of Windows without success and therefore it probably is an OS independent problem. What I get when I click on "Get Msgs" is "Could not connect to "proxy"; the connection was refused." Enabling debugging output for POP3 doesn't give any output in the logfile. None of the bugs listed in #165832 are dupes of this one.

reporter there's no way you can set up a test accnt for me to try? Do you know what type of mail server you are using? Maybe attach a protocol log: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop

Finally I have solved the problem by myself! Getting a packet sniffer and looking at what Mozilla _tries_ when clicking on "Get Msgs" I suddenly realized what was wrong all the time. Starting with version 0.9.9 Mozilla tries to get mail by using the SOCKS protocol when a proxy is enabled in the preferences menu. Now I really wonder why (1) Mozilla silently assumes that the same proxy is used for mail (2) Mozilla assumes that SOCKS works for this proxy (3) that it doesn't tell the user what it tries and WHY it fails!!! (4) this change (from 0.9.8 -> 0.9.9) was nowhere documented or mentioned (5) no developer here came up with what could be wrong by him-/herself??? (Even more that I have said from the beginning that I was using a proxy server.) Finally, by adding the proxy address to the "No proxy for" field in the preferences menu, mail works just fine now while using the proxy server to browse the internet. For the curious people I have attached Mozilla's stupid/lame attempt to get my mail by using the SOCKS protocol. Have fun, Michael Noisternig

I am encountering the same problem with mozilla 1.2.1 on linux, and I am not using a proxy of any kind. As near as I can tell, pressing the Get Msgs button does nothing at all for me; a tcpdump does not show any outbound packets at all. I also get the message pane hourglass symptom (the message list gets an hourglass cursor that doesn't go away until I exit mozilla and restart), and the index file rebuild on every startup. I tried creating a new profile, but that did not fix the problem. I can create a pop3 account for anyone who wants to try to reproduce this (I'm using cucipop). I can also work on fixing it myself, but if I'm going to do that, some pointers on where to start from someone who's familiar with the code would be very helpful.

Keith: Your build is rather old. Please try a more recent build: http://ftp.mozilla.org/pub/mozilla/nightly/latest/ (as always, be sure to delete your old Mozilla directory before installing the new one) PS You won't receive any replies if you're not on the CC list ;).

Okay, I tried with build 2003013015 and the problem still occurred. It works for a while after startup, but after a while it stops. The protocol debug log just shows successful connections until it stops, and then nothing.

Today (2003-02-10) I've updated my cvs tree and rebuilt mozilla. And my 'Get Msgs' button in Mail/News doesn't do anything. Since this bug is of critical severity, I wonder how mozilla could go from 1.3b to 1.3a. And as the bug is known since 2002-03-21 and it still persists, I assume developers have given up hope to fix this issue. I hope that one day I will find time to fix it myself. But presently I'm encountering bug after bug while getting acquainted with mozilla so I don't know when I will actually get to the stage to start fixing bugs.

maybe some people are running into bug 125885

dmitry - only drivers can set blocking+ flags. to nominate a bug, use the ? flag.

I am getting somewhat similar behavior for 1.3b build 2003021000 running Win98se. Initially the Get Msgs button works for a while, but then, at random times, it stops working, usually just for that account, and without the automatic periodic retrievals being affected, but sometimes it also blocks automatic retrieval, and sometimes it also fails for other accounts, or blocks automatic retrieval for all accounts. Closing the mail client and reopening it usually restores normal behavior, however. It does not seem to be directly connected to the xul.mfl file problem, but that is occuring as well.

I'm experiencing the same behavior as Jon Roland and Keith Reynolds on Mozilla 1.3 {build 2003030516} on Linux. It works for awhile, but then stops. It also doesn't work to hit the down arrow and click "Get all new messages" or to click the account name. The only way to retrieve further mail is to shut down Mozilla completely and relaunch it. I'm not running a mail proxy, I'm using the POP3 protocol, and absolutely no packets are captured with Ethereal.

OK, the Mozilla 1.3 GTK2 rpm install seems to have fixed it for me (I'm running Red Hat 8.0).

I spoke too soon. The behavior started back up again today. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 on Red Hat Linux 8.0, from the gtk2 rpm.

Any further progress on this one? It is still annoying.

Any further progress on this one? It is still not fixed on 1.4. A clue seems to be that it only affects one email account at a time. In my case, always the most active one first, that gets the most email. One thing that has changed since 1.3 is that previously the word "Done" appeared in the message bar, and now does not. I was able to use that "Done" as an indicator that the problem had set in, because most other processes that produced the word "Done" caused it to go away after a while. This made me suspect that some other process was failing to complete properly and unblock further retrieval. Does that sound plausible?

Am not having this issue with: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030718 Experienced it a little with 1.4, and possibly 1.3. I don't think this bug is the problem, though.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 For me, this bug happens consistently only after about 2 days of leaving Mozilla Mail on. After that, mail notification stops and GetMsgs doesn't do anything, although there is new mail. It happens with every major release I've tried since version 1.1 on Win XP Pro. - I use POP3 with notification. - Am on a office LAN. - I leave my PC on all the time with Mozilla Mail running.

I am also seeing this on a system with: multiple POP3 accounts, set up to automatically download messages every 10 minutes, left on for days at a time, with NO proxies, with the "message pane hourglass symptom"; When restarted, Mozilla spends a long time "Building summary file for Inbox". The only other thing I can think of is that the /home directory is on an NFS share. Also, it seemed to start happening after the ISP changed mail servers and now I have a joe+blow.com address instead of an @. It is version 1.4.1 from Fedora.

OS = XP Ver. 1.5 I too have the same problem. The "Get Mail" button does not work. There seems to be some type of corruption. Everything was working properly until Norton cleaned out a virus. Uninstalled and reinstalled with no sucess. I can only retrieve emails in 2 ways: First by invoking - emails are retrieved. Second, by double clicking on my inbox folder. This pops up a new window and retrieve works.

still see this problem?

RESO INCO due to lack of response to last question. If you feel this change was made in error, please respond to this bug with your reasons why.