1260724 - TB 38 will not download new messages from GoDaddy via IMAP

Status: RESOLVED INVALID

(MailNews Core :: Networking: IMAP, defect)

Description

[grebhan]

Attachment: imap1.log

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36

Steps to reproduce:

Start TB.  New mail is downloaded from GoDaddy via IMAP.  Send a message to myself (or have someone send to me).

Using latest release version on both Mac and Windows.  Many others are reporting similar issues:

https://support.mozilla.org/en-US/questions/1116177
https://support.mozilla.org/en-US/questions/1116139
https://support.mozilla.org/en-US/questions/1116025
https://support.mozilla.org/en-US/questions/1116133



Actual results:

The new message never appears in TB.  No new messages are downloaded.


Expected results:

New messages should be downloaded either automatically, or at least when I hit Get Messages.  However, new messages are not downloaded *unless*,

I quit and restart TB, or
I delete a message.

FYI - if I change the 'read' status of a message in TB, it does update in my GoDaddy account (I can see the status change in GoDaddy Webmail).  This does not trigger new messages to be downloaded.

My imap log file is attached - the downloaded emails only appeared if I restarted TB, or deleted existing messages.

I'm willing to help troubleshoot - including provide a test email address from our domain on GoDaddy...

Comment 1

[Matt]

I have cut the following bit out of the log (The end really)  and I am left with a fairly obvious question.

The server name suddenly changes from imap.secureserver.net to  outlook.office365.com.  Can you please confirm you do not have an office365 mail account in Thunderbird.

I noticed the godaddy are now offering office365 bundles, including hosted email. This is in addition to what they call Workspace Email.  

I am wondering if there is an issue with their setup that changes from one to the other when the idle command is issued. 

Does the issue improve if DIle is disabled in the advanced dialog from server settings?

2016-03-30 13:23:36.843000 UTC - 8336[be39a30]: cc02800:imap.secureserver.net:S-INBOX:CreateNewLineFromSocket: 9 OK FETCH completed.

2016-03-30 13:23:36.866000 UTC - 8336[be39a30]: cc02800:imap.secureserver.net:S-INBOX:SendData: 10 IDLE

2016-03-30 13:23:36.916000 UTC - 8336[be39a30]: ReadNextLine [stream=b7927e0 nb=10 needmore=0]
2016-03-30 13:23:36.916000 UTC - 8336[be39a30]: cc02800:imap.secureserver.net:S-INBOX:CreateNewLineFromSocket: + idling

2016-03-30 13:23:43.022000 UTC - 12844[be3ac90]: be60000:imap.secureserver.net:S-LVInfo:SendData: DONE

2016-03-30 13:23:43.022000 UTC - 8908[18a39790]: 19448000:outlook.office365.com:S-INBOX:SendData: DONE

2016-03-30 13:23:43.022000 UTC - 12988[be3ab40]: be6a800:outlook.office365.com:S-Sent:SendData: DONE

2016-03-30 13:23:43.022000 UTC - 2836[be3b1d0]: be61000:imap.secureserver.net:S-Travel:SendData: DONE

2016-03-30 13:23:43.022000 UTC - 12672[be3b470]: c3bd800:imap.secureserver.net:S-Sent:SendData: DONE

2016-03-30 13:23:43.022000 UTC - 13116[15cd9a70]: c061000:imap.secureserver.net:A:SendData: 40 logout

2016-03-30 13:23:43.022000 UTC - 12844[be3ac90]: be60000:imap.secureserver.net:S-LVInfo:SendData: 7 close

2016-03-30 13:23:43.022000 UTC - 12816[be3a0c0]: bb35000:outlook.office365.com:A:SendData: 13 logout

2016-03-30 13:23:43.022000 UTC - 8336[be39a30]: cc02800:imap.secureserver.net:S-INBOX:SendData: DONE

2016-03-30 13:23:43.023000 UTC - 12988[be3ab40]: be6a800:outlook.office365.com:S-Sent:SendData: 8 close

2016-03-30 13:23:43.023000 UTC - 12988[be3ab40]: be6a800:outlook.office365.com:S-Sent:SendData: 9 logout

2016-03-30 13:23:43.023000 UTC - 2836[be3b1d0]: be61000:imap.secureserver.net:S-Travel:SendData: 7 close

2016-03-30 13:23:43.023000 UTC - 12844[be3ac90]: be60000:imap.secureserver.net:S-LVInfo:SendData: 8 logout

2016-03-30 13:23:43.023000 UTC - 12672[be3b470]: c3bd800:imap.secureserver.net:S-Sent:SendData: 20 close

2016-03-30 13:23:43.023000 UTC - 2836[be3b1d0]: be61000:imap.secureserver.net:S-Travel:SendData: 8 logout

2016-03-30 13:23:43.023000 UTC - 12672[be3b470]: c3bd800:imap.secureserver.net:S-Sent:SendData: 21 logout

2016-03-30 13:23:43.023000 UTC - 8908[18a39790]: 19448000:outlook.office365.com:S-INBOX:SendData: 26 close

2016-03-30 13:23:43.023000 UTC - 8336[be39a30]: cc02800:imap.secureserver.net:S-INBOX:SendData: 11 close

2016-03-30 13:23:43.023000 UTC - 8908[18a39790]: 19448000:outlook.office365.com:S-INBOX:SendData: 27 logout

2016-03-30 13:23:43.023000 UTC - 8336[be39a30]: cc02800:imap.secureserver.net:S-INBOX:SendData: 12 logout

2016-03-30 13:23:43.076000 UTC - 12816[be3a0c0]: bb35000:outlook.office365.com:A:TellThreadToDie: close socket connection
2016-03-30 13:23:43.076000 UTC - 12816[be3a0c0]: ImapThreadMainLoop leaving [this=bb35000]
2016-03-30 13:23:43.076000 UTC - 12988[be3ab40]: be6a800:outlook.office365.com:S-Sent:TellThreadToDie: close socket connection
2016-03-30 13:23:43.076000 UTC - 13116[15cd9a70]: c061000:imap.secureserver.net:A:TellThreadToDie: close socket connection
2016-03-30 13:23:43.076000 UTC - 12988[be3ab40]: ImapThreadMainLoop leaving [this=be6a800]
2016-03-30 13:23:43.076000 UTC - 13116[15cd9a70]: ImapThreadMainLoop leaving [this=c061000]
2016-03-30 13:23:43.076000 UTC - 12844[be3ac90]: be60000:imap.secureserver.net:S-LVInfo:TellThreadToDie: close socket connection
2016-03-30 13:23:43.076000 UTC - 12844[be3ac90]: ImapThreadMainLoop leaving [this=be60000]
2016-03-30 13:23:43.076000 UTC - 12672[be3b470]: c3bd800:imap.secureserver.net:S-Sent:TellThreadToDie: close socket connection
2016-03-30 13:23:43.076000 UTC - 12672[be3b470]: ImapThreadMainLoop leaving [this=c3bd800]
2016-03-30 13:23:43.076000 UTC - 2836[be3b1d0]: be61000:imap.secureserver.net:S-Travel:TellThreadToDie: close socket connection
2016-03-30 13:23:43.076000 UTC - 2836[be3b1d0]: ImapThreadMainLoop leaving [this=be61000]
2016-03-30 13:23:43.076000 UTC - 8908[18a39790]: 19448000:outlook.office365.com:S-INBOX:TellThreadToDie: close socket connection
2016-03-30 13:23:43.076000 UTC - 8908[18a39790]: ImapThreadMainLoop leaving [this=19448000]
2016-03-30 13:23:43.076000 UTC - 8336[be39a30]: cc02800:imap.secureserver.net:S-INBOX:TellThreadToDie: close socket connection
2016-03-30 13:23:43.076000 UTC - 8336[be39a30]: ImapThreadMainLoop leaving [this=cc02800]

Comment 2

[grebhan]

Hi Matt - I have 2 accounts at GoDaddy - one uses their 'webmail' system (that one is NOT working). And one uses their Outlook365 system - that one is working.  They are different domains.  So I think it is simply attempting to fetch email for two different accounts.

I am happy to try whatever you like, but I don't know what this means, can you give me more info? "Does the issue improve if DIle is disabled in the advanced dialog from server settings?"

Comment 3

[Matt]

Right click the account in the folder pane and select settings. 
Select settings then the server settings in the dialog that opens.  
Click the advanced button.  
There is an option there to turn IDLE on and off.  (typo the first time)
In the server settings, make sure the "check for new messages is selected and the frequency is set to 10 or more minutes (less probably works,  but 10 or more makes sure there is no overlap in attempts)

Also,  as you using the SSL or non SSL settings?  Try changing the account settings to use the NON SSL settings provided by godaddy.  Others tell me there are no Cypher errors in the error console.  Nor should there be as the initial download works.  But with and without SSL is another option to explorer

Comment 4

[grebhan]

Hi Matt -
We have tried IDLE both ways before on someone's suggestion - no apparent difference.
The check message duration has always been at 10 minutes.
We have tried both SSL and nonSSL - no apparent change.

We have used TB with our GoDaddy account for over 4 years.  This issue began last Monday and as I am sure you are aware, many users with similar configs (IMAP/GoDaddy/TB) are experiencing the issue.  If you need to debug, I can set up an email for you on our domain - just let me know how to get the details to you in a private manner...
Thanks,
George

Comment 5

[[e-mail]]

Same problem here, with one difference: rebooting TB will get email once, but not subsequently.

TB38 won't download any of my GoDaddy emails, on multiple PCs. Email hosted elsewhere (1&1, gmail) is fine on the same TB. 
I turned off IDLE, but that made no difference.
Safemode made no difference either.

Thank you for any help.

Comment 6

[Kent James (:rkent)]

In forums I keep seeing reference to downgrading to Thunderbird version 37 or 36, but those are not real versions. If this happened suddenly and recently, and it was caused by Thunderbird, then it would have been caused by upgrade to a recent point release of TB 38. So the test that people need to do is to downgrade to a previous point release of Thunderbird 38. So please test with the previous point release of Thunderbird, 38.6.0, that is available here:

https://archive.mozilla.org/pub/thunderbird/releases/38.6.0/

Comment 7

[Kent James (:rkent)]

If someone could provide to me a test account that shows this issue, that would be helpful.

Comment 8

[grebhan]

Hi Kent - I sent you an email directly with your credentials for our domain - please let me know if you did not receive them.

Comment 9

[grebhan]

Tested 38.6.0 on Mac - same issue.

Comment 10

[Kent James (:rkent)]

What I am seeing is the following issue from godaddy IMAP. On initial startup, all messages are read. But when I send a message to an account that is received after the initial listing of messages, godaddy falsely reports there are no messages there.

So in a godaddy test account, I send a message to the account that should be received with UID 4 while godaddy IMAP is in IDLE. godaddy wakes up and reports a message exists, but when we request a list of the new messages with fetch 4:*, it does not report them. Here are Wireshark captures of network data:

+ idling
* 4 EXISTS
DONE
10 OK IDLE completed
11 noop
11 OK NOOP completed
12 UID fetch 4:* (FLAGS)
12 OK FETCH completed.
13 IDLE
+ idling

If I restart Thunderbird, Thunderbird on startup asks for all messages, and this time Godaddy reports back correctly with the new message with UID 4, and a download starts:

8 select "INBOX"
* FLAGS (\Draft \Answered \Flagged \Deleted \Seen)
* OK [PERMANENTFLAGS (\Draft \Answered \Flagged \Deleted \Seen)] Limited
* 4 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1] Ok
* OK [UIDNEXT 5] Predicted next UID
8 OK [READ-WRITE] SELECT completed.
9 UID fetch 1:* (FLAGS)
* 1 FETCH (UID 1 FLAGS (\Seen))
* 2 FETCH (UID 2 FLAGS ())
* 3 FETCH (UID 3 FLAGS ())
* 4 FETCH (UID 4 FLAGS ())
9 OK FETCH completed.
10 UID fetch 4 (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)])
* 4 FETCH (UID 4 RFC822.SIZE 2312 FLAGS () BODY[HEADER.FIELDS ("From" "To" "Cc" "Bcc" "Subject" "Date" "Message-ID" "Priority" "X-Priority" "References" "Newsgroups" "In-Reply-To" "Content-Type" "Reply-To")] {268}
Content-Type: multipart/alternative; boundary="----M91644PB16A9CEL9FAJYII9LSB66R4"
Subject: Godaddy 3
From: Kent James <[e-mail]>

So this is the failure point. I do not have any relationship with GoDaddy, so those who are their customers need to report the issue to GoDaddy and get them to respond. I am happy to do further communications, but this is a GoDaddy problem and they need to engage with it.

Comment 11

[Matt]

This support topic indicates godaddy may have fixed the issue.
https://support.mozilla.org/en-US/questions/1116720#answer-863592

Can anyone else confirm that?

Comment 12

[Kent James (:rkent)]

Using the godaddy test account that we provided to me, it is now working correctly.

Comment 15

[Jorg K (CEST = GMT+2)]

Nothing to fix here. GoDaddy fixed it.

Comment 16

[Wayne Mery (:wsmwk)]

actually, invalid = not a bug