IMAP Disconnection

Question

Frequently we are receiving disconnection from Imap Servers. The debug log shows these disconnections occur always after a TLS Alert. Any help to solve the question is welcome.

Follows the log:

2015-02-09 20:21:52.353 INFO MyImap(3)[27] Command: R00050 SELECT "INBOX/BOM DIA"
2015-02-09 20:21:52.353 DEBUG MyImap(3)[27] Info: State changed from 'Sending' to 'Reading'.
2015-02-09 20:21:52.534 INFO MyImap(3)[27] Response: * 159 EXISTS
2015-02-09 20:21:52.534 INFO MyImap(3)[27] Response: * 0 RECENT
2015-02-09 20:21:52.534 INFO MyImap(3)[27] Response: * OK [UNSEEN 7] mailbox contains unseen messages
2015-02-09 20:21:52.534 INFO MyImap(3)[27] Response: * OK [UIDVALIDITY 60516] UIDs are valid for this mailbox
2015-02-09 20:21:52.534 INFO MyImap(3)[27] Response: * OK [UIDNEXT 48336] next expected UID is 48336
2015-02-09 20:21:52.534 INFO MyImap(3)[27] Response: * FLAGS (\Answered \Deleted \Draft \Flagged \Seen $Forwarded $MDNSent Forwarded $Junk $NotJunk Junk JunkRecorded NonJunk NotJunk)
2015-02-09 20:21:52.534 INFO MyImap(3)[27] Response: * OK [PERMANENTFLAGS (\Answered \Deleted \Draft \Flagged \Seen $Forwarded $MDNSent Forwarded \*)] junk-related flags are not permanent
2015-02-09 20:21:52.534 INFO MyImap(3)[27] Response: * OK [HIGHESTMODSEQ 152320] modseq tracked on this mailbox
2015-02-09 20:21:52.534 INFO MyImap(3)[27] Response: R00050 OK [READ-WRITE] SELECT completed
2015-02-09 20:21:52.534 DEBUG MyImap(3)[27] Info: State changed from 'Reading' to 'Ready'.
2015-02-09 20:21:52.535 DEBUG MyImap(3)[27] Info: State changed from 'Ready' to 'Sending'.
2015-02-09 20:21:52.535 INFO MyImap(3)[27] Command: R00051 UID FETCH 32599 (UID BODY[])
2015-02-09 20:21:52.535 DEBUG MyImap(3)[27] Info: State changed from 'Sending' to 'Reading'.
2015-02-09 20:21:54.769 INFO MyImap(3)[27] Response: * 109 FETCH (UID 32599 BODY[] {720663}
2015-02-09 20:21:54.953 INFO MyImap(3)[27] TLS: Alert Alert:Alert was received.
2015-02-09 20:21:54.953 INFO MyImap(3)[27] TLS: Alert Alert:Alert was sent.
2015-02-09 20:21:54.953 INFO MyImap(3)[27] TLS: State StateChange:Closed
2015-02-09 20:21:54.953 DEBUG MyImap(3)[27] Info: Connection closed.
2015-02-09 20:21:54.960 ERROR MyImap(3)[27] Info: Rebex.Net.ImapException: The server has closed the connection.
   at Rebex.Net.WM.JB(Byte[] A, Int32 B, Int32 C)
   at Rebex.Net.WM.HB(Byte[] A, Int32 B, Int32 C)
   at Rebex.Net.Imap.FU(String A, ArrayList B)
   at Rebex.Net.Imap.CM(String A, VM B, String C, Boolean D)
   at Rebex.Net.Imap.LU(ImapMessageSet A, Int32 B, UInt32 C, Boolean D, String E)
   at Rebex.Net.Imap.MU(ImapMessageCollection A, ImapMessageSet B, Int32 C, UInt32 D, Boolean E, String H, Int64 I)
   at Rebex.Net.Imap.LV(ImapMessageSet A, Int32 B, Boolean C, Int64 D, Int32 E)
2015-02-09 20:23:38.078 DEBUG MyImap(3)[27] TLS: Closing TLS socket.
2015-02-09 20:23:38.078 DEBUG MyImap(3)[27] Info: State changed from 'Reading' to 'Disconnected'.

Answer 1

The TLS/SSL Alert packet received from the server is not actually the cause of the issue, it's a symptom. TLS/SSL Alert packets are used to inform the other side of the connection that it's about to be closed. Unfortunately, it's not possible to determine the reason for the disconnection from these packets.

In any case, something like this should not normally occur. The most likely explanation is that a fatal server-side error that caused the session to be closed. For example, the server might have been unable to read the actual content of the message for some reason (such as a disk failure), and since it already announced to the client that 720663 bytes are to be transferred, it had no choice but to close the session at this point. A server log should contain more information about this.

From the client's side, there is not much you can do. If you are able to retrieve other messages and only a single one is causing the error, try copying it into another folder or accessing it through the server's web interface (if it has one) and delete it afterwards to work around the issue.

Comments

Perfect . We will investigate the server side.
Thank you for the ready reply