Closed Bug 1501631 Opened 6 years ago Closed 6 years ago

"you are logged now" IMAP problem in Poland with home.pl provider

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 344205

People

(Reporter: zbigniew, Unassigned)

Details

Attachments

(7 files)

YOU-ARE-LOGGED-NOW.png
31.35 KB, image/png
Details
IMAP LOG with "you are logged now"
29.40 KB, text/plain
Details
imap log without error (with proper login) - generated by starting and closing thunderbird)
18.27 KB, application/octet-stream
Details
wireshark.out -- IDLE response says "NO Please reconnect"
6.36 KB, text/plain
Details
login failed with y.a.l.n. message
42.12 KB, image/png
Details
TB just cannot show new messages until you restart it.
31.43 KB, image/png
Details
wireshark.out -- Connection attempts are RST by server for about 22 min.
25.46 KB, text/plain
Details
Attached image YOU-ARE-LOGGED-NOW.png — 
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0

Steps to reproduce:

Just leave Thunderbird open or sometimes just click an imap folder. It happens with any TB version 5x, 6x and so on.


Actual results:

Thunderbird stops refreshing imap folders or shows password window when you click INBOX on any account. Result is shown in activity monitor - "you are logged now" message. I am trying to solve this problem with HOME.PL provider (biggest in Poland) but without result. They also say ofc that their imap server goes along with RFC. So, about the bug - the idea is simple - i checked what is happening in the background (with port logger and ecryption disabled). When you click any folder - Thunderbird sometimes tries to send login and password to the server. This time (with home.pl) it receives the message "you are logged now" but instead interpreting it "properly" - it shows window asking for password. Seems that it is something new for Thunderbird and the client doesn't know what to do with that answer. If you leave Thunderbird open it probably refreshes the folder from time to time, but same thing happens. It logs in, receives "you are logged now" and generally stops refreshing the folder and showing new messages. These errors happen every day in hundereds of workstations in my client's PCs. You have to restart the app or click different folder and go back to inbox for example. After this trick, Thunderbird can login into the server properly so new messages can appear. Users generally hate Thunderbird when used with home.pl, what they see is that Thunderbird lags, of messages appear after many hours or they cannot handle the paswword window properly (i mean just close it and click different folder temporarily) and they just click ok making Thunderbird remember empty password that causes another problem.


Expected results:

I am no TB programmer and don't know TB internals, but generally when Thunderbird receives this message - it should behave in this situation just like when you click some different imap folder and go back to inbox for example. Or just like when you restart it completely. It should be able to handle this reply properly.
Dear Developers, this bug is BIG. I have IT friends that have many clients and they have the same problem. I wonder why in our country no one have found this bug yet.
If you could provide the network trace you obtained and/or a thunderbird IMAP log that records the activities when the problem occurs, that would be most helpful. You can find the information needed to record the IMAP log here:
https://wiki.mozilla.org/MailNews:Logging

Specifically do this if using Windows and tb 6x:

set MOZ_LOG=IMAP:5,timestamp
set MOZ_LOG_FILE=%USERPROFILE%\Desktop\imap.log
"%ProgramFiles(x86)%\Mozilla Thunderbird\thunderbird.exe"

Attach the resulting imap.log file with the "Attach File" link above with details of what you were doing while recording the log. No need to zip the file.

Note: Tb does not normally interpret the text that occurs in imap responses such as "you are logged" but instead just uses the parts of the response that is explicitly specified in the imap RFC such as OK, BAD, NO etc.
Part of the log file with "you are logged now reply" of the server. Name of the server changed because of privacy reasons.
Thanks for the logs. Is anything cut off or removed? I was expecting to see the imap ID command and its response to see what kind of server home.pl uses (Dovecot, Cyrus, something else).

Are you using security STARTTLS? The "BAD You are logged" response is coming in response to the imap command "STARTTLS". Is it possible to use SSL/TLS with home.pl? But I don't think that's the problem.

Looking at your first log, it appears that what triggers the re-send of STARTTLS is the response to a DONE. DONE should only be sent by tb when it is exiting IDLE state which will happen when you click on a folder or maybe doing nothing for 30 minutes. For some reason the server doesn't like DONE at that point and reports the problem to TB and this causes the STARTTLS to be sent that responds with "BAD I'm still logged in". This causes tb to be try to re-do the login process. Unfortunately, what was happening before DONE was sent by tb is not present in the log file so it would be good to see this. But, later in the first file "Senddata: DONE" occurs with no problem.

In the 2nd file (no errors) I only see the DONE sent near the end when you were shutting down and the server didn't complain.

Since the problem seems to be triggered by the DONE command, a workaround is to disable IDLE functionality in tb for this server. IDLE is enabled when the "Notify immediately when new mail arrives" checkbox in the server settings for the account. Restart tb to ensure it takes effect. You can reduce the time between new mail checks to compensate for lack of IDLE.

If you can attach a log that show more of what was happening before the bad DONE response it would be helpful. 

Another possibility is for you to provide me with a temporary "guest" account on the home.pl imap server. That way I could duplicate and debug the problem from here without requiring you to send me logs. Often logs don't show the whole picture.
Thanks for the account. I'm now setup and will take a look...
I think that best solution would be one that works without tweaking any TB client, because thousands of people won't do that for sure.

Yes, logs were cut, because i tried to extract the part when the bug occurs. I have many accounts on my PC and TB generates output from many accounts in same parts of the text. In order to generate full logs, I started logging on another PC with just one account. Will have logs with "you are logged now" tomorrow I think.

You've got also an account to test the bug on now. Credentials sent in priv email.
Just connect it and leave TB open for some time. You can also look at Activity Monitor for "y.a.l.n." error.

Good point on "DONE" command. It may be the reason. Thing is why TB acts so weird and other clients don't. Outlook doesn't bother with it, Bluemail on my phone either.
(In reply to gene smith from comment #5)
> Thanks for the account. I'm now setup and will take a look...

Great! :)))
Home.pl contacted and invited to join the bug.
No problems yet. Sent a test email to the account and it came almost immediately via IDLE. After about 10 minutes saw tb leave IDLE via DONE, check for new email and go back to IDLE as it should. Anything I can do to cause the problem, e.g., switch folders etc, or should I just wait?
(In reply to gene smith from comment #9)
> No problems yet. Sent a test email to the account and it came almost
> immediately via IDLE. After about 10 minutes saw tb leave IDLE via DONE,
> check for new email and go back to IDLE as it should. Anything I can do to
> cause the problem, e.g., switch folders etc, or should I just wait?

Hey, for now, just wait.
Sometimes it happens more often, sometimes less. I am observing TB on 2 PCs too and no errors yet.
I attached a trace that show what happened. 

I let tb run for a couple hours without looking and just noticed 3 items in the activities that say approximately: "operation failed for INBOX. Server bitback.pl responded: Please reconnect". This occurred at 3 consecutive 10m intervals (default check for new mail time). Looking at wireshark trace I see that at about 22:31 tb exited IDLE with DONE OK and checked for new mail and then issued IDLE but the server responded: NO Please reconnect. Tb does not parse the info after NO so it went ahead and assumed IDLE was not available at this time and went on. Then 10 minutes later tb checked for new mail again and again tried to reenter IDLE stat and received the "NO Please reconnect" response to the IDLE command. After the 3rd failed IDLE try the server then, about 10m later, did a disconnect (tcp FIN). In response to the FIN, tb then reconnects and re-SELECTs Inbox (not shown in the trace).

The question is why is the server refusing the IDLE? The IDLE rfc says nothing about the need to do a tcp reconnect when IDLE responds with a tagged NO. It should just mean IDLE is not available at this time and is not fatal for the session. Apparently the home.pl server has somehow run out of resources for the connection so it can't do IDLE?
I need to mention that there is an issue in released TB with the IDLE response when it is NO or BAD that has existed for a long time. See Bug 344205. The problem is that when an idle NO (or BAD) tagged response occurs, released tb *does* do a logout for the connection and then log back in. This is exactly what your server (home.pl) is wanting it seems. The fix for that bug (I am currently running the unreleased patch) is to treat the NO/BAD as IDLE not available but, when requested again, go ahead and try IDLE command again. So that's why in the trace attachment tb does not immediately reconnect (again, tb does not parse the "please reconnect" text).

I will remove the patch and try my test again. However, I suspect that the root problem is with the IdeaImapServer since, per your attached log, it is failing on the DONE command. This may also indicate the same resource problem in the server.

I will try again with my patch removed so I am testing more like the released tb.
Now I'm seeing your exact problem with the patch removed. It's also due to the IDLE response being NO. Without the patch, tb doesn't know that the connection never got to idle state so it sends the DONE. The server responds correctly with a BAD response to DONE. Then, as shown in Bug 344205 Comment 0, tb tries to login again (using login and not CRAM-MD5) and the server responds with "BAD You are logged". Tb then does a TCP FIN which is what the server IDLE response "NO Please reconnect" actually requested.

Here are the steps after the last good IDLE (c=tb, s=imap server):

c: 28 IDLE
s: + idling
c: DONE
s: 28 OK Completed
c: 29 noop
s: 29 OK Completed
c: 30 IDLE
s: 30 NO Please reconnect.
c: DONE
s: DONE BAD  command not understood
c: 32 login "would-be-my-username@bitback.pl" "would-be-my-password" (*)
s: 32 BAD You are logged now
<Tb then FINs the connection and establishes a new tcp/imap connection>

So it seems that with and without the patch, the connection gets re-established. With the patch, the server does the disconnect and without the patch, tb does the disconnect. But for both the result is the same, as far as I can tell: A new connection is created that replaces the one the server had problems with.

So I'm thinking that maybe the "You are logged now" is not really causing the problem for your users; maybe it is a "red herring". After it occurs I don't see any bad behavior in tb for the test account. I just sent another test message and it was immediately detected in Inbox via IDLE. Do you only start seeing problems after "You are logged now" occurs?

(*) Don't know why tb is using LOGIN authentication here and not PLAIN, but that is maybe another issue.
Look at that screenshot. TB failed many times in that situation asking for password and showing our error message.
Translating it... "Authenticating on the server XXXX with the username XXXX failed.". Then same repeated another time (another minor bug). Then second window: Current operation for folder XXXX failed. Server XXXX replied: You are logged now.
Component: Untriaged → Networking: IMAP
Product: Thunderbird → MailNews Core
> So I'm thinking that maybe the "You are logged now" is not really causing
> the problem for your users; maybe it is a "red herring". After it occurs I
> don't see any bad behavior in tb for the test account. I just sent another
> test message and it was immediately detected in Inbox via IDLE. Do you only
> start seeing problems after "You are logged now" occurs?

Well, I can describe the behaviour of TB. It sometimes (and that is weird, that not always) just starts to lag with one of folders on one or many accounts (ofc home.pl). Mostly INBOX. What you see then is when you click INBOX, it doesn't refresh. You can go to another folder, go back. Sometimes it refreshes and you see new messages, sometimes not and then you just have to restart TB.

Sometimes TB is not refreshing INBOX because it is strongly related to you are logged now error. You wonder why there are not emails, so you click INBOX. Like on my last screenshot - clicking INBOX makes TB show you password window and also window with y.a.l.n. message. You have to close the password window, go to another folder and go back to INBOX. This time it mostly refreshes properly... well, mostly, because sometimes it just lags and stops refreshing the folder for good. You have to restart TB.

The situation on last screenshot shows that TB doesn't go well with the response.
Please try to put some emails into this account and use it from time to time.

Also, well, sometimes there are days that people start to call me and ask why TB doesn't show any new messages but their phones work properly. Seems like the server has to do something with it. I think it may be influenced by the server... or maybe you'll be able to reproduce it any time.

Thing is... TB stops showing new emails, but phones (with Bluemail) show them properly.
Another issue is ofc with that asking for password when people click INBOX folders.
Component: Networking: IMAP → Untriaged
Product: MailNews Core → Thunderbird
Reporter: Do not change our component/product information, in cases of mid-aid collisions, just submit your comment and no other changes.

Gene: Is this related to bug 344205? Then I'll get to the review quicker. Also, you can do a try build based on TB 60.3 ESR for the reporter.
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: IMAP
Ever confirmed: true
Product: Thunderbird → MailNews Core
(In reply to Jorg K (GMT+2) from comment #17)
> 
> Gene: Is this related to bug 344205? Then I'll get to the review quicker.
> Also, you can do a try build based on TB 60.3 ESR for the reporter.

I didn't see a difference with or without the patch for bug 344205 in account behavior. I haven't seen the password request pop up yet either. So I need to try to duplicate that and the other problems the reporter is seeing. But with the patch in place, tb does not try to do the login but lets the server do the disconnect so, depending on timing, that may improve the situation. So I will do the try build.  

Zbigniew, Are you willing to try a test build? I assume a win32 build is what you need. I will go ahead and do the build and provide you a link. I will also try to duplicate the problem based on your latest descriptions.

When you say "ofc" not sure what that means. Do you mean "of course" (I googled it) or something else? 

Also, any word from the ISP as to why the IDLE errors occur?
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=19c595e464c47dc6ceb8229be8c88580b1230f60&selectedJob=208981240

Zbigniew-
This is a link to test build for tb v60.x which is the latest release but with my IDLE patch applied (it will claim to be a Daily build but it's not). It is optimized win32 but not localized Polish. (Don't see a way to do that with these test/try builds.)

On the treeherder page, click the "B" next to "Windows 2012 opt" so that it "lights up" and under Job Details along the bottom you will find a link to setup.exe. (Not sure if any of the other links might be useful, but possibly.)

With this patched version, when the server produces a NO response to IDLE you will not see the "You are logged" notification and tb will not attempt to re-login. You will see notifications about the NO idle response, probably "Please reconnect" since that is the text the server provides with the NO response. It seems that if this occurs and tb ignores it (like the patch does) the server does the disconnect after about 30 minutes. Not sure if this will improve the situation or not.

Still running the account here and will do more stress tests, like you suggest, to break it.
setup.exe? I thought it's target.installer.exe.
Thank you very much. I will install the build link and will provide info about it.
Ummm, I can't find the link. Should I be logged into Can you provide me with dropbox or google drive link?
https://drive.google.com/file/d/1b4oM9b17HWYqZgrMyD8JQkY0X9xfQhF6/view?usp=sharing

In case you still can't access the links, you get the installer file here. I also sent you the link via email (I think).
Still trying to see the reported problem (login screen pops up, slow/lagged response to new mail, etc) with the test account. No luck yet. Running without the IDLE patch. 

However, I think this might be related to or maybe the same as these bugs:

Bug 1493480
Bug 1428097 Comment 72 (This is initial discovery of bug 1493480)
Bug 693204  (Old bug)

I think the IDLE problem with the server may, in some situations, exacerbate the problem. Maybe not the actual cause of the problem.
Still can't duplicate the problem.  I assume your users that have the problem have "check for new messages every X minutes" enabled? If so, still at 10 mins (default)? Also, does check for new mail button cause Inbox to "refresh"?
Gene, i tested for 1-2 hours this build and stumbled on funny behaviour. TB registered "Please reconnect" message (which made him stop receiving new messages - yes, i sent an email to this account and push really stopped working). So i clicked INBOX and now, "Please reconnect" again... so i clicked "Sent" then went back to INBOX and again - no new messages, but "Please reconnect" in activity monitor. And again and again. So it started showing new messages after restarting. Same time, my phone worked well. I will attach screenshot in next post.
Still, I will be testing TB DAILY next few days and will send you full log.
What I learned today is:
1. TB daily stops refreshing some INBOX folders as normal build does.
2. You have to click another folder and go back to see new messages.
3. Sometimes even it fails and TB can't connect properly. You have to restart it.
12:40 was the time when i switched between folders trying to make TB (daily) reconnect. Didn't work out. It failed with "please reconnect" message.
Thanks for testing it. I tried last night to see the problem but no luck. Sounds like it happens quite often for you. Maybe I need more info.

1. Can you tell me the number of folders and the folder structure of you home.pl account that is failing. Also, approximately how many messages are in each folder. I don't need the real names for the folders, just how they are structured, e.g.,

Inbox  3000
Drafts 5
Sent   300
F1     10000
 f1subfolder  222
  f2subsubfolder 333
F2    444
:

2. Is there only one home.pl account. If more than one, need the structure and counts of those too.

3. How many not home.pl accounts?  Don't need their folder structures or message counts.

4. Any not default tb configuration or settings? 

5. Any add-ons or extensions? If so, what add on and have you tried safe mode (Help | Restart with add-ons disabled)?

6. When new emails are not detected, are they always delivered to Inbox? Are new mails ever delivered to other folders? (By "delivered" I mean which mailbox/folder that the server puts the new emails into.)

With this information maybe I can better duplicate the problem. Also, the imap log when the refresh stops will be helpful.
Saw something sort of interesting but not sure it is relevant. I was selected on another account and then selected on the Inbox of the test account. I noticed that the "spinning icon" remained present for longer than I expected. I looked at wireshark and noticed that tb had sent the DONE command (on selecting Inbox) and was waiting on the home.pl server to respond. It took the server 3 minutes to respond with OK but was fine after that. Could just be a network glitch but haven't noticed that before.

When you see the problem where new mail doesn't come in, do you see the spinning icon (indicating tb is busy) constantly?

More: Moved to Trash on test account and this time I saw DONE sent and the server immediately ACKd it. But there was no response from the server at all after that. I waited 10 minutes.

It appears there is something badly wrong with the "IdeaImapServer" idle processing. You mention phone apps not having a problem. Do you know for sure that the phone app uses imap IDLE or maybe it just poll?
Finally saw the login screen when click on Inbox. I think I was on another account before that. If you Cancel the login screen, tb seems to move on. It was in response to the login that tb does due to the error on IDLE. It won't do this, ofc, with the "try/daily" build you are testing. Didn't see a problem otherwise in that new mail was detected in Inbox after that.

Another thing I just saw is weird and may also be what is causing the "lag" delay in receiving new mail that you sometimes see. Again, TB tried to exit idle state by sending DONE and the server didn't respond and the server closed the tcp/ip connection. Then tb tried to reconnect with the standard tcp SYN, SYN/ACK, ACK handshake that worked fine. But the server never sent the imap "* OK ready" greeting but instead sent tcp RST that resets the connection and closes it. This happened on all 5 connections that tb makes to the server and tb kept trying again to connect only to receive the RST from the server. This lasted for about 22 minutes and then the server started responding correctly again. I will attach a wireshark trace that shows this activity so that your server vendor can see it.
Some explanation of the port number 131 is needed. Since my tb profile is mostly for test and development purposes, I connect to a localhost based stunnel server that handles the TLS/SSL stuff and forwards the transactions from local port 131 to to the standard imap/TLS remote port 993 at the home.pl server. This way I can have multiple accounts in my profile, each on a different local port, e.g., 131, 132 etc., and see the plaintext data in wireshark before it is encrypted by stunnel. I have never seen my set up cause any problems so I am sure that the problem shown in the attachment is caused by the home.pl server. The 22 minutes connection glitch is also somewhat consistent with the reporters "lag" description, but may not be the same thing.
(In reply to gene smith from comment #31)
> Thanks for testing it. I tried last night to see the problem but no luck.
> Sounds like it happens quite often for you. Maybe I need more info.
> 
> 1. Can you tell me the number of folders and the folder structure of you
> home.pl account that is failing. Also, approximately how many messages are
> in each folder. I don't need the real names for the folders, just how they
> are structured, e.g.,
> 
> Inbox  3000
> Drafts 5
> Sent   300
> F1     10000
>  f1subfolder  222
>   f2subsubfolder 333
> F2    444
> :
> 

Same happens in situation where inbox does have subfolders or doesn't. I use subfolders for inbox, sent and also for root folder. I sort emails carefully, so my inbox (on which the error occurs mostly - i think) has usually about 5-25 emails.


> 2. Is there only one home.pl account. If more than one, need the structure
> and counts of those too.

Same, inbox with couple subfolders, sent without, some folders hanging on root, so my boxes usually look like:
INBOX
  folder1
  folder2
SENT
  folder1
  folder2
Drafts(and rest of system folders)
MY-ARCHIVES
  some-folder1
    some-subfolder1
  some-folder2
    some-subfolder2

Like i said, most folders have not many emails (1-50). Couple have less than 1000.
I don't see any relation with the number of emails and the server failing or lagging.
I have account with zero items in inbox or sent. I will test your build on them, too - what I mean about that is - I will look for "please reconnect" message when clicking inbox or will look for lagging (server not responding, so the mouse icon has the wheel on it).



> 
> 3. How many not home.pl accounts?  Don't need their folder structures or
> message counts.

3 accounts that are not in home.pl. There was never anything bad happening with any of them. Only home.pl has problems.

> 
> 4. Any not default tb configuration or settings? 

I usually disable archives and nothing else. Never tweak any connection or whatever else may it be parameters.
One time I tried with check_all_folders_for_emails setting (i think that one) but I didn't like it. Same thing happened.

> 5. Any add-ons or extensions? If so, what add on and have you tried safe
> mode (Help | Restart with add-ons disabled)?

I use couple of addons on my PC (compact header, copy folder, edit email subject, lookout, thunderhtmledit) but same error happens on many PCs of my clients where mostly there are not any addons or even tweaks to default TB config.

> 
> 6. When new emails are not detected, are they always delivered to Inbox? Are
> new mails ever delivered to other folders? (By "delivered" I mean which
> mailbox/folder that the server puts the new emails into.)

No. Not in my situation. I use filtering on TB. The server doesn't put emails to other folders. I think that I tried to use the mechanism of "filtering" on the server (home.pl has this function) but even with check_all_folders_for_emails i think i had problems with TB not showing new emails for folders other than inbox. It was about a year ago, so I would have to try it with current TB version to say more about it.

> 
> With this information maybe I can better duplicate the problem. Also, the
> imap log when the refresh stops will be helpful.
(In reply to gene smith from comment #32)
> Saw something sort of interesting but not sure it is relevant. I was
> selected on another account and then selected on the Inbox of the test
> account. I noticed that the "spinning icon" remained present for longer than
> I expected. I looked at wireshark and noticed that tb had sent the DONE
> command (on selecting Inbox) and was waiting on the home.pl server to
> respond. It took the server 3 minutes to respond with OK but was fine after
> that. Could just be a network glitch but haven't noticed that before.

Exactly what I was talking about.

> When you see the problem where new mail doesn't come in, do you see the
> spinning icon (indicating tb is busy) constantly?

Yes! Exactly.

> 
> More: Moved to Trash on test account and this time I saw DONE sent and the
> server immediately ACKd it. But there was no response from the server at all
> after that. I waited 10 minutes.
> 
> It appears there is something badly wrong with the "IdeaImapServer" idle
> processing. You mention phone apps not having a problem. Do you know for
> sure that the phone app uses imap IDLE or maybe it just poll?

Same feeling from me. Home.pl has a problem with their server but they seem to not admit it nor have human resources to really test it like you did (great job, btw!) even after so many emails with explanations from me.

Phone app - Bluemail. I don't know anything "tech" about it. It just works.
Still, if IdeaImapServer fails "sometime" then it is possible that it also fails for phone app, but not the same time when it fails on TB, so my interpretation that phone app "always works" may be in reality bad. Phone app may just handle the error differently, but my intuition tells me that i may have problems, too. Same with Outlook on PC. I had many, many problems with home.pl and Outlook. Emails disappearing when uploading files from offline pst to imap server etc. But Outlook has it's own problems, too and I go around it whenever I can. TB is much more stable with keeping in sync what is really on the server and what's on offline cache files (mbox).
(In reply to gene smith from comment #33)
> Finally saw the login screen when click on Inbox. I think I was on another
> account before that. If you Cancel the login screen, tb seems to move on. It
> was in response to the login that tb does due to the error on IDLE. It won't
> do this, ofc, with the "try/daily" build you are testing. Didn't see a
> problem otherwise in that new mail was detected in Inbox after that.
> 
> Another thing I just saw is weird and may also be what is causing the "lag"
> delay in receiving new mail that you sometimes see. Again, TB tried to exit
> idle state by sending DONE and the server didn't respond and the server
> closed the tcp/ip connection. Then tb tried to reconnect with the standard
> tcp SYN, SYN/ACK, ACK handshake that worked fine. But the server never sent
> the imap "* OK ready" greeting but instead sent tcp RST that resets the
> connection and closes it. This happened on all 5 connections that tb makes
> to the server and tb kept trying again to connect only to receive the RST
> from the server. This lasted for about 22 minutes and then the server
> started responding correctly again. I will attach a wireshark trace that
> shows this activity so that your server vendor can see it.

100% accurate in my opinion! Exactly what I was talking about. Good job on explaining what really happens during the communication.
Well, at this point it looks like the only solution is to somehow have your users disable IDLE (i.e., server specific setting for immediate notification of new messages). I know you said that might be a problem. They could then set the time to check for new message down to a low value, i.e., 1 min (if default 10m is not quick enough) and tb will "poll" for new messages every minute.

I'm not sure about Bluemail either. I looked on their site and it talks about "push" but not sure that is the same as IDLE. I have bluemail on my phone too but not sure how to "sniff" what it is doing.
Thank you, Gene. I will go with 1 min myself and try how it works.

I contacted home.pl today again and they said that they will analyze the problem, too. They are aware that I contacted them in different ways. There is hope that someone competent will look into the case.

You did enormous job here, thanks again. Now we know what exactly is happening. You also explained my situations technically. As we see, these errors happen not every time and you have to watch the connection closely for many hours to find them or stumble upon them.

I hope they will adjust their server to work properly with default setting of Thunderbird.
I wanted to see exactly how Bluemail behaves so I opened external pc port 131 and was able to setup the test account on my phone, connecting bluemail at that port and see the data with wireshark on pc. What I see is that bluemail does use IDLE. However, every 15 minutes it initiates a tcp disconnect and creates a new connection. Tb keeps using the same connection until the server disconnects. The disconnect/reconnect that bluemail does probably keeps the home.pl imap server happy; resources are freed more often so the IDLE (and DONE) command doesn't return the NO error like we have been seeing with tb, and "please reconnect" IDLE responses are minimized or probably gone (I haven't seen them with bluemail).

Also, at any time, it appears that bluemail has a maximum of 2 connections while tb has default of 5. This also probably makes for a lighter load on the server. Of course, blue mail doesn't store the mail locally and doesn't even show the headers except for fairly recent emails: it uses a more exact fetch, using searches on date it seems, rather than pulling in everything like tb potentially does.

Another possible workaround in tb might be to reduce the number of "cached connection" (advanced server setting) from 5 down to 2 and increase the poll time for new message to 25 minutes or more and keep idle enabled (immediate notification server settings). This will reduce the load on the server; and Inbox and one other folder, if selected, will be in IDLE state rather then Inbox and possibly 4 other folders that never have mail delivered to them anyhow. Setting the poll time to 25m will tend to keep the same connection alive in case the server thinks the connection is inactive and decides to close it. I haven't seen home.pl actually close the inactive connection even after 1 hour, so you might set the poll time to 50 minutes or more and be OK.

Another thing that might help is to disable the global pref about check mail in all folders that you mentioned. Also, there is a right click option on each folder to check it for new email. I suggest disabling this for all folders since none have mail delivered to them (other than Inbox that is always enabled for new mail check). This should also reduce server load when the "get messages" button is clicked.

Also, after making any of these changes you should restart tb to make sure the changes get applied. Also, I suggest you try the workarounds with the release version; but if you want, you can continue to use the "try/daily" version.
Gene, wow, much more is explained now. Did you try the same with MS Outlook 2016? People using Outlook from 2010 to 2016 don't complain (probably all errors are hidden from the user). Outlook has its own BIG problems, but never asked for password like TB did. I wonder if Outllok works like Bluemail in terms of disconnecting every couple of minutes and creating new connection.
(In reply to gene smith from comment #26)
> However, I think this might be related to or maybe the same as these bugs:
> 
> Bug 1493480
> Bug 1428097 Comment 72 (This is initial discovery of bug 1493480)
> Bug 693204  (Old bug)
 
Looking closer, these are not related to this bug.

(In reply to Zbigniew Gralewski from comment #41)
> Did you try the same with MS Outlook
> 2016? People using Outlook from 2010 to 2016 don't complain (probably all
> errors are hidden from the user).Outlook has its own BIG problems, but
> never asked for password like TB did.

No, I haven't looked at what Outlook does. I don't actually have Outlook but only the M/S email program that comes with win7 home. Probably works very similar to Outlook. 
It's unlikely that Outlook would ask for a password since asking for password is a tb specific and incorrect response to a BAD/NO IDLE response caused by Bug 344205. I have found that if you just cancel the password prompt and don't retry or enter a  new password that tb goes on and works ok, at least so far for me.

In conclusion, I am going to close this bug as a duplicate of Bug 344205. Fixing that bug will eliminate the spurious prompt for new password. However, other observed problem must be fixed at the home.pl server or worked around with adjustments to the tb setup that we have discussed.

(In reply to Jorg K (GMT+2) from comment #17)
> Gene: Is this related to bug 344205? Then I'll get to the review quicker.

Jorg, Yes, I'm calling this a dup so if you can that would be great.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: