I'm having a problem with the IMAP control (latest version installed before you ask =;) ). My code attempts to connect up to a mailbox, browse through any folders looking for any mail items and then store them in a database. All working fine...until earlier this week.
On some folders for some users (not all users or even all folders for those users affected), the FetchSingleHeader routine comes back with null and an error is returned via the GetLastError method. Usually these are about the connection having been lost so I've already attempted to recreate the connection (which works)...but still the call to FetchSingleHeader returns null.
The error that gets returned via GetLastError is:
FetchSingleHeader: DllDate: May 8 2014 ChilkatVersion: 220.127.116.11 UnlockPrefix: CUBICIIMAPMAILQ Username: HARVESTER001:Administrator Architecture: Little Endian; 64-bit Language: .NET 4.0 / x64 VerboseLogging: 0 msgId: 1 bUid: 0 msgId: 1 isUid: 0 fetchSummary: fetchMultipleSummaries: getCompleteResponse2: getImapResponseLine: Socket connection closed. Failed to get next response line from IMAP server. --getCompleteResponse2 --fetchMultipleSummaries parseSummary failed. --fetchSummary fetchSummary failed. Failed. --FetchSingleHeader --ChilkatLog
What's annoying is that the call to GetMessageCount (which I use to work out if there's anything that needs processing) works fine and returns the correct count. Similarly if I try to retrieve the same email (which I've had sent on to me to investigate) from my own mailbox, it works fine.
The user is using Office365 and I'm using GMail. SSL is on for both but the fact that it picks up other emails from other folders has me scratching my head (even more so when I know that it's picked up other emails from the folder where the problem is happening).
My guess is that somehow the TCP connection is half-closed. (When I say "TCP connection", even if SSL/TLS there is still an underlying TCP socket connection..) My guess is that the server decided to close its end of the connection at an earlier point (or perhaps something in-between closed the connection). Your app then proceeded to call FetchSingleHeader,and sending the command was fine, but upon trying to read the response the disconnection was discovered.
Examine the verbose LastErrorText's for whatever activity just preceded this call. Also, is there anything external that could disrupt the connection? Could any of the prior activity have caused the server to decide to drop the connection?
answered Jan 30 '15 at 10:34
Got it! It wasn't the previous error as such (it was trying to create a sub-folder which was working) but even though I'd spotted that the connection had become 'invalid' and was reconnecting, I wasn't going back to the folder I was in when I hot the problem. The code was therefore trying to retrieve an email that didn't exist as it was in the wrong place in the IMAP structure =:S
So it looks as though the Office365 server will close the connection (almost when it feels like it given that the code happily works through several other folders before and afterwards) and the solution is to trap the error, and then re-establish the connection (making sure that you're not an idiot and remember to go back to the folder that you were originally in - d'oh).
Thanks for all your help guys - I'm sure I'll come up with plenty of other stupid questions in the future =;)
answered Jan 30 '15 at 11:17
The error log indicates that you are not quite on the latest version (18.104.22.168 instead of 22.214.171.124), so the first thing I'd do is test with the latest version just in case it's something that's already been addressed.
If this still doesn't help, try setting VerboseLogging = 1, run a test again, and then repost the LastErrorText in <pre> </pre> tags again (the log will have more information with VerboseLogging on).
answered Jan 29 '15 at 11:43
Curse the version numbers! =;) I'd downloaded the latest version onto my dev machine but the new DLL hadn't made it to the user's machine. With that little problem solved...still causing an error.
Using VerboseLogging switched to on I get the following error out:
FetchSingleHeader(16ms): DllDate: Jan 21 2015 ChilkatVersion: 126.96.36.199 UnlockPrefix: CUBICIIMAPMAILQ Username: HARVESTER001:Administrator Architecture: Little Endian; 64-bit Language: .NET 4.0 / x64 VerboseLogging: 1 msgId: 1 bUid: 0 msgId: 1 isUid: 0 fetchSummary(16ms): fetchMultipleSummaries(16ms): ImapCmdSent: aaax FETCH 1 (UID FLAGS RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER]) getCompleteResponse2(16ms): passiveClose(16ms): Passive socket closing complete. --passiveClose No longer connected. getImapResponseLine: Socket connection closed. Failed to get next response line from IMAP server. --getCompleteResponse2 --fetchMultipleSummaries parseSummary failed. --fetchSummary fetchSummary failed. Failed. --FetchSingleHeader --ChilkatLog
Hopefully that reveals something useful and someone's got some idea about how to get it working
answered Jan 30 '15 at 03:28