Bug 2726 - IMAP inactivity disconnect misinterpreted as parse error
Summary: IMAP inactivity disconnect misinterpreted as parse error
Status: REOPENED
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Folders/IMAP (show other bugs)
Version: 3.7.6
Hardware: PC Linux
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2012-08-24 10:22 UTC by Kai Henningsen
Modified: 2014-10-21 23:01 UTC (History)
1 user (show)

See Also:


Attachments

Description Kai Henningsen 2012-08-24 10:22:26 UTC
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.
Comment 1 Colin Leroy 2012-08-29 13:38:48 UTC
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.
Comment 2 Kai Henningsen 2012-08-31 15:06:24 UTC
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
Comment 3 Colin Leroy 2012-09-13 12:02:40 UTC
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?
Comment 4 Ricardo Mones 2012-09-13 12:13:46 UTC
Well, already done: https://github.com/dinhviethoa/libetpan/issues/42

;-)
Comment 5 Colin Leroy 2013-01-23 09:58:07 UTC
Putting priority to "enhancement" as we now issue keepalives more aggressively.
Comment 6 Ricardo Mones 2014-10-21 23:01:28 UTC
JFYI: a fix for this has been comitted on libetpan's git:

https://github.com/dinhviethoa/libetpan/commit/cba71ca522dd907e2acf71ee9c3c430e5748fed3

Note You need to log in before you can comment on or make changes to this bug.