As you can see in this log snippet: [11:30:49] IMAP4< [FETCH data - 5792 bytes] [11:30:49] IMAP4< [FETCH data - 8192 bytes] [11:30:49] IMAP4< [FETCH data - 5467 bytes] [12:03:39] IMAP4> 1911 NOOP [12:03:39] IMAP4< * BYE Disconnected for inactivity. ** IMAP Fehler auf 10.0.2.5: parse error (sehr wahrscheinlich ein nicht RFC-konformer Server) ** IMAP4-Verbindung unterbrochen [12:03:39] IMAP4< * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready. Copyright 1998-2010 Double Precision, Inc. See COPYING for distribution information. This is rather irritating, as it always produces the connection problem icon in the lower left corner.
This is a server problem, for me. It replies with an untagged data (* BYE Disconnected for inactivity.) but it should after that send an "OK" or "BAD" response before disconnecting.
You are wrong. RFC 3501, 7.1.5 clearly states that for an idle disconnect (case 3), the connection is closed immediately after the BYE: 7.1.5. BYE Response Contents: OPTIONAL response code human-readable text The BYE response is always untagged, and indicates that the server is about to close the connection. The human-readable text MAY be displayed to the user in a status report by the client. The BYE response is sent under one of four conditions: 1) as part of a normal logout sequence. The server will close the connection after sending the tagged OK response to the LOGOUT command. 2) as a panic shutdown announcement. The server closes the connection immediately. 3) as an announcement of an inactivity autologout. The server closes the connection immediately. 4) as one of three possible greetings at connection startup, indicating that the server is not willing to accept a connection from this client. The server closes the connection immediately. Crispin Standards Track [Page 67] RFC 3501 IMAPv4 March 2003 The difference between a BYE that occurs as part of a normal LOGOUT sequence (the first case) and a BYE that occurs because of a failure (the other three cases) is that the connection closes immediately in the failure case. In all cases the client SHOULD continue to read response data from the server until the connection is closed; this will ensure that any pending untagged or completion responses are read and processed. Example: S: * BYE Autologout; idle for too long
Indeed, I was mistaken. Then it seems libetpan should send us a different return code than parse error. Would you want to file a bug to libetpan?
Well, already done: https://github.com/dinhviethoa/libetpan/issues/42 ;-)
Putting priority to "enhancement" as we now issue keepalives more aggressively.
JFYI: a fix for this has been comitted on libetpan's git: https://github.com/dinhviethoa/libetpan/commit/cba71ca522dd907e2acf71ee9c3c430e5748fed3