Closed Bug 1324077 Opened 8 years ago Closed 7 years ago

Thunderbird inbox message refresh takes hours(because mobile.charter.net doesn't quote space contained in mailbox of STATUS response, Tb can not fetch Flags, header for new or Unseen messages)

Categories

(MailNews Core :: Networking: IMAP, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: jackkistler, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

Sent test messages to myself
Had someone else send test messages to me

This is on all Thunderbird versions since I changed my ISP to charter.net about 6 months ago. I am currently on version 45.5.1. This is the first time I have been on an ISP that uses the IMAP protocal, but I don't know whether it is IMAP1, 2, or other. The Charter support techs claim that the problem is with Thunderbird.

I also opened the mail client on the charter user page via FireFox. The test messages show up there within seconds of being sent.


Actual results:

Test messages took hours to show up in my inbox. 


Expected results:

I have the refresh rate set a 5 minutes, so I should have seen the test messages within 5 minutes of when they showed up in charter's web browser support.
OS: Unspecified → Windows 8.1
Hardware: Unspecified → x86_64
In the process of trying to find out what is causing this problem I have been searching the web for possibilities. One hit suggested changing some of the account settings so I tried them. When they didn't help I started setting them back to what they were. The last changes I made were to the actions taken when a message in the inbox is deleted. When I did this a strange window that said something about indexes (huh?) came up. Could this have anything to do with my problem?
Be advised, charter has had a multitude of issues in recent months.

(In reply to Jack Kistler from comment #1)
> In the process of trying to find out what is causing this problem I have
> been searching the web for possibilities. One hit suggested changing some of
> the account settings so I tried them. When they didn't help I started
> setting them back to what they were. The last changes I made were to the
> actions taken when a message in the inbox is deleted. When I did this a
> strange window that said something about indexes (huh?) came up. Could this
> have anything to do with my problem?

hey, like a screen shot or copy paste would be most helpful, perhaps, please, so we know what you are talking about. :)

Also, first stab, start *Windows'* safe mode with networking enabled
- win8 https://support.microsoft.com/en-us/help/17076/windows-8-startup-settings-safe-mode

Still In Windows safe mode, start thunderbird in safe mode
- https://support.mozilla.org/kb/safe-mode-thunderbird

Does problem go away?
Please don't spam comments here with unrelated logs. All the CSS errors/warnings you pasted are completely irrelevant. If anything, please attach a text file.

This is a support problem, not a software issue. Try to get support here:
https://support.mozilla.org/en-US/products/thunderbird

We have no resources to debug individual users' problems. We get many problems of this sort like "can't sent" or "can't receive", and all those bugs are closed as invalid in the end.

Note that the provider's (mostly incompetent) Level 1 support always blames the problem on Thunderbird, see another "cannot send" example here: Bug 1322702.

If you feel that TB is indeed at fault, please provide an IMAP log (attached not pasted):
https://wiki.mozilla.org/MailNews:Logging

TB generally downloads messages as soon as they are available in the inbox on the server via IMAP.

WADA, would you be able to help this user further?
Flags: needinfo?(m-wada)
I can't guess about "inbox message refresh" and "takes hours” in bug summary of ”inbox message refresh takes hours”.

It sound for me that phenomenon is following.
 When a mail is sent to a mail address,
  Web mail for the mail address : the mail can be viewd quickly after the mail send.
  Relevant imap account in Thunderbird : ???

I can't know about that the mail was sent from what mailer on which PC including relevant Thunderbird instance, or sent from the relevant Web mail, or sent from other Web mail.

I guess "???" is that "unread mail count of Inbox" is not automatically updated after the mail was sent by someone.
But I'm not sure, because I can't found statements for guessuing.

Possible phenomenon:
 1. IDLE is supported by server and is used by Thunderbird.
 2. Connection loss while IDLE, due to server kills connection while IDLE, or due to network error.
 3. User did do nothing on Inbox of the imap account in Thunderbird.
 4. Because Thundserbird can do nothing on "connection loss while IDLE" currently,
    new mail in Inbox can not be detected for long time.
    This may occur upon automatic "new mail check every 5 minutes".
 5. When user did some actions on Inbox of the imap account, server access was done, and new mail was detected.

But I can't know what was done before the "takes hours” and while the "takes hours” and after the "takes hours”.
I can't know what ocurred before the "takes hours” and while the "takes hours” and after the "takes hours”
So, I can say nothing.
Flags: needinfo?(m-wada)
By the way, Jorg K, why you need to look into this king of "bug" report in B.M.O?
This is Wayne's field. If you have time, please comment in actual bug reports which I'm pretty interested in :-)
I ran the diagnostic Jorg K gave me and have posted it on my drop box at https://www.dropbox.com/s/8ymtkidu7i0mreh/imap.log?dl=0.
I also had another conversation with Charter support. They claim to have NO level 2 support people and continued to refer me back to Thunderbird support. It sounded to me like they were trying to deny that they even allow third party email clients to access their servers, which to me is beginning to sound like an anti-trust situation. I have posted the chat on by drop box at https://www.dropbox.com/s/mbldwgqo6rl7msf/Thunderbird%20inbox%20refresh%20chat%20with%20charter%20support.docx?dl=0. 

I feel very much in the middle with this problem and wish that the two end points could get together and work this all out between them.

While dealing with this problem I am beginning to wonder if gmail, ATT, and Charter all use the same server and client code, perhaps obtained from the same producer, but that while gmail and ATT have upgraded or downgraded to a level that does not have the problem but Charter has not.
I see in the Thunderbird settings that there is an option for remote diagnostics. Would it be possible for a Thunderbird programmer or support person to get in touch with me at jackkistler@charter.net to arrange for a remote session?
I am trying some variations of use while using the logging procedure, and am noticing something that I am wondering is associated with the inbox refresh problem I am having. 

1) I create a message to myself and send it. There is no refresh of the inbox.
2) I close Thunderbird and check the log that was created. Examining the log shows the refresh failing, just like in the log I posted to my dropbox as stated above.
3) I run the bat file as admin again. The test message appears in the inbox as soon as Thunderbird opens.
4) I delete the test message. It goes from the inbox to the trash folder, disappears from the inbox and appears in the trash folder.
5) I close Thunderbird and examine the log file. AAArrrggg. Is there a way to cause this logging trick to append new log information to the existing log? 

I had more steps in mind, but first I have to start all over and manually append the log files.
Tried again. Annotated my actions within the combined log file and moved it to my Dropbox at https://www.dropbox.com/s/351wpimr9ze8530/imap.logb.txt?dl=0
(In reply to Jack Kistler from comment #10)
> Tried again. Annotated my actions within the combined log file and moved it
> to my Dropbox at https://www.dropbox.com/s/351wpimr9ze8530/imap.logb.txt?dl=0

It's server bug.
> 2016-12-17 20:52:35.227000  S-Trash:SendData: 13 STATUS "INBOX/AARP" (UIDNEXT MESSAGES UNSEEN RECENT)
> 2016-12-17 20:52:35.336000  S-Trash:CreateNewLineFromSocket: * STATUS INBOX/AARP (MESSAGES 2 RECENT 0 UNSEEN 0 UIDNEXT 1002)
> 2016-12-17 20:52:35.336000  S-Trash:CreateNewLineFromSocket: 13 OK STATUS completed
> 
> 2016-12-17 20:52:35.633000  S-Trash:SendData: 14 STATUS "INBOX/account registrations or membership ids" (UIDNEXT MESSAGES UNSEEN RECENT)
> 2016-12-17 20:52:35.742000  S-Trash:CreateNewLineFromSocket: * STATUS INBOX/account registrations or membership ids (MESSAGES 1 RECENT 0 UNSEEN 0 UIDNEXT 1001)
> 2016-12-17 20:52:35.742000  S-Trash:PARSER:Internal Syntax Error on line: %s: * STATUS INBOX/account registrations or membership ids (MESSAGES 1 RECENT 0 UNSEEN 0 UIDNEXT 1001)
> 2016-12-17 20:52:35.742000  S-Trash:SendData: 15 logout
> 2016-12-17 20:52:35.742000  S-Trash:CreateNewLineFromSocket: 14 OK STATUS completed

As seen in "14 STATUS ..." issued by Thunderbird, at least when mboxname contains space, mboxname should be quoted by double-quote in imap command/response.
This is defined rule in protocol named imap.
Server bug may be STATUS command response only bug.

If "INBOX/account registrations or membership ids" or something(which has space ( ) \ " etc.) is selected at folder pane of  Thunderbird, and if the mbox is selected at a cached connection upon new mail check, Thunderbird can not use STATUS command, and uses "uid fetch HighestUID:* Flags" for new mail check.
So, server bug is not exposed.

IDLE is not seen in log, so your server perhaps doesn't support IDLE.

Quickest/simplest/easiest wiorkaround of the server bug:
  Don't use at least space in your imap folder name of the server.
  Or, if server won't violate RFC when ( or ) or ", ... is used,
  use such special character too when you want to use space in imap folder name of the server.
For visibility and similar name, change like " "(space) -> "_"(underscore) may be a practical workaround of your server's bug.
To Jack Kistler(bug opener), because you use MS Windows, you can use DebugView when you get NSPR log. (Do Google search for DebugView by yourself, please)
  SET NSPR_LOG_FILE=WinDebug
  SET NSPR_LOG_MODULES=imap:5 (because timestamp is added to log by DebugView, remove timestamp parameter)
Hooking by DebugView can be controled, so "saving partial log only" is pretty easy.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
This bug is NOT resolved. 

I have changed all of the folder names that contained imbeded blanks to replace the blanks to "_" (underscores) as you have suggested. While this did indeed get rid of the parsing error TB was experiencing, the basic symptom was not solved. 

I notice that the charter server is returning "IMAP4". If they are using IMAP4rev1, what would the server return? 

I just had another conversation (via chat) with Charter support, and they still deny any problems with their email servers. 

Here is another question? Is there some difference between support given by a server for a "mobile" device and a "desktop" device. As I have said before, the directions on the charter site for a "desktop" device DO NOT WORK. I can't even get a connection. I was once told that I had to coordinate this with Mozilla support to get it to work. Have you ever heard anything about this?
And I have a new activity log in my Dropbox of this at: https://www.dropbox.com/s/vooz5w8gsyiomnv/imapc.log?dl=0
And I have saved my chat with Charter support and uploaded it to my Dropbox at: https://www.dropbox.com/s/1hqfeghaigrc1t1/another%20conversation%20with%20Charter%20about%20inbox%20refresh.txt?dl=0
(In reply to Jack Kistler from comment #14)
> And I have a new activity log in my Dropbox of this at:
> https://www.dropbox.com/s/vooz5w8gsyiomnv/imapc.log?dl=0

Following is seen.
> 2016-12-17 23:56:02.507000 mobile.charter.net:A:SendData: 34 STATUS "Junk Mail" (UIDNEXT MESSAGES UNSEEN RECENT)
> 2016-12-17 23:56:02.616000 mobile.charter.net:A:CreateNewLineFromSocket: * STATUS Junk Mail (MESSAGES 0 RECENT 0 UNSEEN 0 UIDNEXT 1000)
> 2016-12-17 23:56:02.616000 mobile.charter.net:A:PARSER:Internal Syntax Error on line: %s: * STATUS Junk Mail (MESSAGES 0 RECENT 0 UNSEEN 0 UIDNEXT 1000)
> 2016-12-17 23:56:02.616000 mobile.charter.net:A:SendData: 35 logout
> 2016-12-17 23:56:02.616000 mobile.charter.net:A:CreateNewLineFromSocket: 34 OK STATUS completed

Even if you are not familiar with IMAP, I already referred lines in your log data and I already wrote about "STAT" like one.
Above lines can be pretty easily found merely by "Search stat" using popular Text Editor.
Can you do such job by yourself?

Which mail/new mail in which mbox is not detected by Thunderbird as expected?
Any mail in any mbox which is not quoted by double-quote in STAT response?
("Order Received" column value is UID when imap folder in Thunderbird.)
Even if so, what happens when you did manual new mail check?
What happens when you click relevant imap folder at folder pane and explicitly opened the folder?

Thunderbird may not be tolerant with the server's RFC violation. Rule may be "mboxname in command response should be quoted when / is contained or always". Sorry but I don't know well.
If so, following may occur.
- When mbox is opened by click at folder pane, new mail is detected. (uid fetch 1:* Flags is issued)
- When new mail check by STAT command, new mail is not fetched by Tb, because mboxname in STAT command response is RFC violation.
- If other mailers don't care about RFC violation, they may accept such RFC violation.
  (mailer of mobile device perhaps doesn't use STAT command, and RFC violation is perhaps in STAT response only.)

> I just had another conversation (via chat) with Charter support, and they still deny any problems with their email servers.

It's pretty normal. It's ordinal response, as suspect always says "I didn't do it" even after arrested :-)
FYI.

Following is "header fetch from Sent" after copy of sent mail was saved in Sent("append" command is used for save==upload in imap).
> 2016-12-17 23:56:04.085000 mobile.charter.net:S-Sent:SendData: 8 UID fetch 1144:1145 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type Reply-To)])
> 2016-12-17 23:56:04.226000 mobile.charter.net:S-Sent:CreateNewLineFromSocket: * 29 FETCH (UID 1144 RFC822.SIZE 419 FLAGS (\Recent \Seen) BODY[HEADER.FIELDS (FROM TO CC BCC SUBJECT DATE MESSAGE-ID PRIORITY X-PRIORITY REFERENCES NEWSGROUPS IN-REPLY-TO CONTENT-TYPE REPLY-TO)] {268}
> 2016-12-17 23:56:04.226000 mobile.charter.net:S-Sent:STREAM:OPEN Size: 419: Begin Message Download Stream
> 2016-12-17 23:56:04.226000 mobile.charter.net:S-Sent:CreateNewLineFromSocket: To: Jack Kistler <jackkistler@charter.net>
> (snip)

Because mboxname is correctly quoted in LIST response/LSUB response by your server, any imap client can access the mbox normally, including Thunderbird. Problem is in "STATUS command response".
In response to WADA from comment #16

Interesting. "Junk mail"??? I had seen that before and deleted that folder, at least I remember doing so. Can you think of anything automated that would bring that folder back? 

Anyway, I deleted that folder again and closed TB. Then I ran it from the bat file as admin and got the following log: https://www.dropbox.com/s/r40u1d0bh7sv90s/imapd.log?dl=0

In this run I built a test message to myself, checked that the folder "junk mail" did not reappear, opened the "trash" folder  and deleted some files that were deleted from the inbox, clicked on the inbox folder name (no response, not even the progress bar at the bottom of the screen), clicked on the "get messages" button (again, no response), and closed TB. I think I have changed or eliminated all folder names with blanks at this point. 

I had noticed a day or two that sometimes when I move a note from the inbox to subfolder that the note does not show up, but thought this was part of the same problem. After renaming folders that had blanks in their name I did click on some of them and saw that the progress bar showed at the bottom of the screen and that the contents of the subfolder appeared, 

Is there a setting that will cause TB to refresh only the folder clicked??
I thought I would try another run to see what happened with clicking the "Trash" folder, which seems to refresh message lists fine. Then I clicked the "empty trash" option and that also seemed to work properly.

The trace log is at; https://www.dropbox.com/s/dap477bo7elacxh/imape.log?dl=0
Also, it looks like this last run answers my question in the last line of comment 18. Yes, clicking the folder name when viewing the list for a different folder or subfolder does refresh only that one folder.
After thought to comment 20

Or does it?
(In reply to Jack Kistler from comment #18)
> Is there a setting that will cause TB to refresh only the folder clicked??

"Non-quoted mboxname in STAT response by your server" is a kind of such setting.

There is no correct interpretation of imap command response when the command response violates RFC(i.e. broken), so an imap client, Thunderbird, can't receive data of "new mail is available in an imap mailbox" when Thunderbird issued STAT command for checking new mail in the imap milbox. So, Thunderbird doesn't(rather, can not) request fetch of new mail data in the imap mailbox.

As seen in your imap log, LIST response/LSUB response is correct, so Thunderbird can know existent mboxname. Because mboxname is correctly passed from your server, Thunderbird can request 'SELECT "Inbox/XXX"', 'uid fetch 1:* Flags()', 'uid fetch HighestUID:* ..." and so on. And, server response to it is correct, Thunderbird can detect new mails in mbox and can fetch(download) mail data.

Jack Kistler, if you want to report your server's bug, get imap log with minimum configuration, with minimum operations.

1. create new Tb profile(call "ProfX"), define the problematic account only.
2. In Tb's setting, disable any setting which interfere your problem analysis.
   Server settings/Junk Settings : disable any automatic actions,
   Synchronization&Disk Space : kill synchronization, and so on.
   Tools/Options : Disable Global Indexer and search, etxc.
   Folder Properties : Never include any folder in new mail check.
3. At Server Settings/Advanced, set max cached connections=1 for ease of getting/viewinglog, restart Tb.
4. Restart Tb with imap logging enabled. Access Inbox, Inbox/AAA only. See imap log.
   You can see logs for login, CAPABILITY command/response, LIST, LSUB etc.
   These are logged upon each Thnderbird restart/login etc.
   So you can skip these logs easily at imap log check in subsequent tests.
   And you can see logs for normal access to Inbox, Inbox/AAA, so you can understand log in subsequent tests.
5. At Server Settings/Advanced, set max cached connections=more than 1. 2 or 3 may be adequate.
   At folder properties of Inbox/AAA, include it in new mail check.
   At Server Settings, enable new mail check at startup, new mail check every 1 minutes. (1 minute for testing)
6. Restart Thunderbird with logging enabled. use thunderbird.exe -no-remote -p "ProfX"
   By -no-remote, you can run two Thunderbird instances at same time.
7. At your daily use Thunderbird, or by Web mail, copy an Unread mail to Inbox and Inbox/AAA.
8. For Thunderbird with -no-remote, the copied mail is absolutely new mail.
   After a while, terminate Thunderbird with -no-remote, and see imap log.
   You probably see "No mail data fetch(download) after STAT/STAT response which indicates new mail).
9. Do same steps as 6 to 8, with clicking INBOX/BBB, Inbox/CCC, Inbox/DDD, then click Inbox/AAA.
   Because max cached connections=3, "selected state of Inbox/AAA" removed by other folders,
   so when Inbox/AAA is clicked again, following is done by Tb.
   SELECT "Inbox/AAA", uid fetch 1:* Flags(). Because UID of new mail in Inbox/AAA is returned,
   Thunderbird fetches(download) header data(uid fetch mm:nn body.peek[Herader.Field ... like one).
   When you view the mail, entire mail data is downloaded(uid fetch NN body[] where NN=UID of the mail).
10. Terminate Thunderbird with -no-remote, and see imap log.

When explained in statements, it's long, but what is needed, required operations etc. is simple/easy.

Log of STAT command/STAT response is sufficient for accusation of your server.
But, as I said, suspect always says "I didn't do it, or I'm not bad you are bad" even after arrested.
So you need to keep log(evidence of RFC violation) for step 9 and you need to know what occurred in step 9.
(In addition to previous command)
1. When you show evidence, show example of "no quote for Inbox/AAA" only first.
2. Suspect perhaps says "I'm not bad, you are bad".
3. Then, show evidence of "no quote for Inbox/ABC DEF GHI". Suspect can't say "I'm not bad" any more :-)
As I learn more about the activity shown in these logs I think I have discovered something that may help get us past the knee jerk "I'm not bad" from Charter. Looking in imapc.log (at https://www.dropbox.com/s/vooz5w8gsyiomnv/imapc.log?dl=0
) I see a "capability" response:
------------
2016-12-17 23:55:14.908000 UTC - 7744[15bc0970]: 163ad800:mobile.charter.net:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 UIDPLUS NAMESPACE QUOTA SORT ID
-------------
which says it recognized "IAMP4rev1" protocol (the RFC 3501 that someone mentioned,either here or in another TB bug report). I find this RFC difficult to follow without the training and experience I am sure you have, but I am unable to find where it says anything about folder names with blanks in them requiring quotes around them. As a retired programmer, however, I know how important protocols for being able to parse strings with blanks in them can be, and my assumption is that it has to be stated in there somewhere.
And in an "ID" response (am I correct that this is a server response?) at this line: 
----------
2016-12-17 23:55:15.252000 UTC - 7744[15bc0970]: 163ad800:mobile.charter.net:A:CreateNewLineFromSocket: * ID ("name" "Email Mx" "version" "M.9.00.023.01 201-2473-194" "vendor" "Openwave Messaging" "support-url" "http://support.openwave.com" "date" "Mon Apr  4 21:15:22 PDT 2016")
---------------
I see 
------------
"vendor" "Openwave Messaging", "version" "M.9.00.023.01 ..." and "support-url" "http://support.openwave.com". 
----------------
I thought maybe this would point to the people we should be talking to instead of Charter, since the ID line implies someone called "openwave" owns the code Charter has on its email server. Unfortunately when I tried the address "support.openwave.com" I got "server not found."

I tried www.openwave.com and got a home page for a company called "openwave mobility", but I was unable to find out what products they produce or if they build server code for the IMAP4rev1 protocol. 

When I did a search on "openwave messaging" I got a hit that suggested "https://www.linkedin.com/company/openwave-messaging-inc-", which I was unable to figure out how to get to any useful information from this site. 

This leaves me with the following thoughts: 
So what gives? Is the maker of the code Charter is using gone, or just trying to stay hidden from the rest of the world. Is this why Charter support is so adamant that the problem is not theirs? Obviously if they don't have access to the source code for the IMAP application they are running on their email servers then they can't fix ANY problems they may have with it. 

We really need someone other than Charter to talk to, and I have exhausted my ability to find someone.
In trying to learn more about this I have examined what I could find in RFC 3051 at https://tools.ietf.org/html/rfc3501#ref-IMAP-IMPLEMENTATION
RFC 2683 at: https://tools.ietf.org/html/rfc2683
and RFC 2060 at https://tools.ietf.org/html/rfc2060

I was specifically looking for specification of how mailbox names were to be returned by the server. There were many examples in these documents showing server responses that included mailbox names, but none of the example responses showed quotes around the name. Of course, none of the responses had spaces in mailbox names, so it doesn't look like these RFCs considered such names. 

I admit that I do not know what other RFCs I should have examined. Please let me know if I missed one that is pertinent. 

Otherwise:
As I see it, without anything specific that shows how a server must handle mailbox names with spaces, then Thunderbird should be changed to refuse mailbox names, including in hierarchical structures, with spaces in them, and should prompt users to correct any such names that currently have spaces in them to rename them.
(In reply to Jack Kistler from comment #25)
> I could find in RFC 3051 (snip)

Oh, sorry, I should have pointed RFC 3501 for you.

> I was specifically looking for specification of how mailbox names were to be returned by the server.

I also tried to find specification about it. But I can't find clear explanation on it.

Mboxname itself doesn't contain "quoting by double-quote". However it's a parameter of command or command response. And, if not top level mbox, "hierarchy delimiter" is contained in string.
I guess that parameter in command/response for mboxname is quoted string, or quoting is needed when delimiter(usually dot/period or slash) is contained, although I don't understand BNF syntax description yet.

At least "no quote when mboxname contains space" is apparently/obviously server's bug. No one can say "server is RFC compliant".
As both of you and me are not sure about "after change from space to underscore" case, you may be better to show evidence of "no quote when space is contained" only. They never can say "it's correct" for it :-)

> Otherwise:
> As I see it, without anything specific that shows how a server must handle mailbox names with spaces,
> then Thunderbird should be changed to refuse mailbox names, including in hierarchical structures,
> with spaces in them, and should prompt users to correct any such names that currently have spaces in them to rename them.

I agree on that Tb is better to report about error state to user instead of "error log in imap log" only.
However, as I wrote before, there is no correct interpretation of broken response, so there is no way to inform you "server doesn't quote mboxname with space".
We can open bug for good report for server's RFC violation, but developers, who are volunteers, are pretty busy to fix important bugs.
I believe server's bug should be reported to ISP instead of bugzilla.mozilla.org, and I believe request for improvement should be requested to ISP instead of Thunderbird developers.
I looked charter.net site, and met following statement.
> Charter Communications, Time Warner Cable and Bright House Networks are now one company.
How about request to "Time Warner" instead of Charter Communications?
"Time Warner" is parent or Grandpa company, so they can not reject request, even if they reject your request.
I have found what looks like a news article showing that "Openwave Messaging" had been bought by "Synchronoss Technology" at "http://finance.yahoo.com/news/synchronoss-technologies-acquire-openwave-messaging-213000212.html" -- 

I have also found that the author of the RFC 3501 specifications (the IMAP4rev1 protocol) is:
 Mark R. Crispin
   Networks and Distributed Computing
   University of Washington
   4545 15th Avenue NE
   Seattle, WA  98105-4527

   Phone: (206) 543-5762

   EMail: MRC@CAC.Washington.EDU

It still looks to me that the IMAP4rev1 are incomplete and ambiguous about the handling of mailbox names with embedded blanks. I would think that the best source for resolving this confusion would be Mark R. Crispin. 

----
Having replaced the blanks in all of my mailbox names with underscores, I am no longer getting the failure that was the direct results of blanks in mailbox names. Since I am still getting the external symptom of "notification of new mail takes hours", I will open a new bug report and allow this one to be closed as a work around is available.
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---
Summary: Thunderbird inbox message refresh takes hours → Thunderbird inbox message refresh takes hours(when server doesn't quote mboxname in STATUS response, Tb doesn't fetch Flags, header for new or Unseen messages)
Component: Untriaged → Networking: IMAP
Product: Thunderbird → MailNews Core
Version: unspecified → 45
Jack Kistler, "space in mboxname" case is obvious RFC violation by server, because mboxname can't be extracted from STATUS response unless quoted(escaping may be allowed). RFC defines use of quoted-string in such case.
Problem is only in "after change space to underscore" case.
Even if RFC allows "no quoting of mboxname in STATUS response if no space in mboxname", or if RFC is ambigous about quoting of mboxname in STATUS response or all imap command response when no space in mboxname, "space in mboxname" case is apparent/obvious fault of your imap server. I believe no one can say "your server's behavior is correct" for "space in mboxname" case.
OS: Windows 8.1 → All
Hardware: x86_64 → All
Jack Kistler, please check following in STAT response from your server is correct or not.
> "(MESSAGES 1 RECENT 0 UNSEEN 0 UIDNEXT 1001)"

If value of each feild returned from server is incorrect, even when Tb interprets non-quoted mboxname part as mboxname, "imap client including Tb who uses STAT" doesn't try to fetch data for new mail, because "new mail exists or not" is determined from values returned from server.
Because I can't know about "what value is correct value" by your report, explanation only, I'm impossible to know about correctness of values in your imap log.
See Also: → 1325192
Oh you opened bug 1325192. Closing as INVALID because original report was for "space in mboxname" case and because keeping two bugs is useless.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → INVALID
Summary: Thunderbird inbox message refresh takes hours(when server doesn't quote mboxname in STATUS response, Tb doesn't fetch Flags, header for new or Unseen messages) → Thunderbird inbox message refresh takes hours(because server doesn't quote space contained mboxname in STATUS response, so Tb can not fetch Flags, header for new or Unseen messages)
Response to WADA comment #29. 
""space in mboxname" case is obvious RFC violation by server, because mboxname can't be extracted from STATUS response unless quoted(escaping may be allowed). RFC defines use of quoted-string in such case."

Is there some other RFC where the use of quoted-string is spelled out? I can not find any place within RFC 3501 where there is any mention of a quoted-string requirement for a mailbox name in a STATUS response from a server. Did I miss it? A find request for "quoted-string" in RFC 3501 responds with none found within the entire document. 

RE: RFC 3501 - We can't legitimately claim that the server is violating the protocol unless we can point specifically to a spot within the protocol document where it is specified what the behavior must be. If the protocol is ambiguous about something that is causing problems between a client and a server then the protocol must be changed to clarify the requirement. In this case, the RFC must specify either that the STATUS response from the server must always enclose the mailbox name in a quoted-string or that spaces in mailbox names are not supported and the client is responsible for denying any attempts to create a folder name with blanks in it. If the RFC is changed to require mailbox names in quoted-strings then all examples in the RFC document must also be changed to comply, since non-compliant examples in a defining document are so often a source of confusion and/or non-compliance.
> mailbox         = "INBOX" / astring
>                     ; INBOX is case-insensitive.  All case variants of
>                     ; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
>                     ; not as an astring.  An astring which consists of
>                     ; the case-insensitive sequence "I" "N" "B" "O" "X"
>                     ; is considered to be INBOX and not an astring.
>                     ;  Refer to section 5.1 for further
>                     ; semantic details of mailbox names.
> 
> astring         = 1*ASTRING-CHAR / string
> 
> ASTRING-CHAR   = ATOM-CHAR / resp-specials
> 
> ATOM-CHAR       = <any CHAR except atom-specials>
> 
> atom-specials   = "(" / ")" / "{" / SP / CTL / list-wildcards /
>                   quoted-specials / resp-specials
> 
> list-wildcards  = "%" / "*"
> 
> quoted-specials = DQUOTE / "\"
> 
> resp-specials   = "]"
> 
> string          = quoted / literal
> 
> quoted          = DQUOTE *QUOTED-CHAR DQUOTE
> 
> QUOTED-CHAR     = <any TEXT-CHAR except quoted-specials> /
>                   "\" quoted-specials
> 
> TEXT-CHAR       = <any CHAR except CR and LF>
> 
> 
> literal         = "{" number "}" CRLF *CHAR8
>                     ; Number represents the number of CHAR8s
> 
> CHAR8           = %x01-ff
>                     ; any OCTET except NUL, %x00

If SP is contained in mailbox, it should be string = quoted / literal.

I thought "/" is a special character in mailbox(not mbox name, mailbox parameter).
But it seems "/" is allowed.
And, in example of RFC3501, "mailbox without quote" is seen.

If so, Thunderbird may accept "mailbox without quote" in STATUS response in your case.
After change from space to underscore, problem may be number in STATUS responce by your server.
So I wrote comment #31 for you.
Summary: Thunderbird inbox message refresh takes hours(because server doesn't quote space contained mboxname in STATUS response, so Tb can not fetch Flags, header for new or Unseen messages) → Thunderbird inbox message refresh takes hours(because server doesn't quote space contained mailbox in STAT response, Tb can not fetch Flags, header for new or Unseen messages)
Summary: Thunderbird inbox message refresh takes hours(because server doesn't quote space contained mailbox in STAT response, Tb can not fetch Flags, header for new or Unseen messages) → Thunderbird inbox message refresh takes hours(because mobile.charter.net doesn't quote space contained in mailbox of STATUS response, Tb can not fetch Flags, header for new or Unseen messages)
You need to log in before you can comment on or make changes to this bug.