[kmail2] [Bug 321509] New: Connections between kmail2 and courier-imap-ssl unstable

[Freek de Kruijf]

https://bugs.kde.org/show_bug.cgi?id=321509

            Bug ID: 321509
           Summary: Connections between kmail2 and courier-imap-ssl
                    unstable
    Classification: Unclassified
           Product: kmail2
           Version: 4.10.3
          Platform: openSUSE RPMs
                OS: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: NOR
         Component: general
          Assignee: kdepim-bugs at kde.org
          Reporter: f.de.kruijf at gmail.com

Created attachment 80721
  --> https://bugs.kde.org/attachment.cgi?id=80721&action=edit
compressed tar archive of courier-imap-ssl log file and wireshark capture file

Most likely since I installed 4.10.2 I see a runaway connection between kmail2
imap client and a remote server running on openSUSE with a courier-imap-ssl
IMAP-server. I see this problem with two of these servers, one running on a
server with openSUSE 11.4 courier-imap version 4.8.1-2.4 and the other on
openSUSE 12.3 (armv5tel) courier-imap version 4.12.0-1.1. The first one uses an
IPv4 connection and the second an IPv6 connection.
At a certain moment the client or the server disconnects and after that the
client starts new connections which are almost immediately disconnected at a
rate of about 4 per second. This only stops after restarting the IMAP server of
stopping Kontact. But at one occasion it looks as if after stopping Kontact the
IMAP agent still went on and only after ending the KDE session the runaway
process stopped.
I have a wireshark capture file for a session between the client and the server
on IPv6 which I will attach. The capture started at 18:14:16. At 18:44:23 the
runaway processing started. I just send the first 500 packets.
The second file shows the log of the courier-imap-ssl server starting at the
same time. At that time I started Kontact. There are two IMAP-SSL connections
for two different users on the server which are shown in this log all coming
from the 1:37 system. Only one is reflected in the capture file because the
server has two IPv6 addresses.
I made a compressed tar archive with these tow files in it.

-- 
You are receiving this mail because:
You are the assignee for the bug.