Version: 1.5.0 (using Devel) OS: Linux After a while (about an hour or so), the IMAP agent connected to my Microsoft Exchange IMAP server stops synchronising. Pressing F5 on any folder from this IMAP server or using Ctrl+L or any method of synchronisation results in absolutely nothing happening. This includes using Akonadi Console (RMB > Synchronize > Synchronize All). The only solution to getting synchronisation back is to use the Akonadi Console, right click on the agent and select Restart Agent. Sometimes, it requires restarting more than once. This could be related to the KWallet password caching, but I have not been able to determine if this is connected to the wallet closing. I have changed my KWallet settings before to see if it made a difference and I could not make it work. I should also point out that the Exchange Server IMAP is notorious for being broken. It disconnects the IDLE connection far too soon (simply drops the connection, with no IMAP commands) and it sometimes replies with BAD at unexpected times. Reproducible: Sometimes Steps to Reproduce: 1. Make sure that the agent is synchronising with Exchange 2. Wait some time (an hour or so, maybe more, maybe less, no clue what the real reason is) 3. Synchronise again (Ctrl+L, F5, Akonadi Console) Actual Results: *NOTHING* happens. No synchronisation is done. No IMAP traffic happens -- the agent is disconnected from the server (no TCP/IP connection established) and it doesn't try to connect. Expected Results: The agent should reconnect to the server and synchronise. OS: Linux (i686) release 2.6.36.2-server-1mnb Compiler: gcc This account is configured for 15-minute interval checking.
Toggling online and offline does not help. The agent must be restarted.
adding as a showstopper
I should point out that once this starts happening, the agent *will* connect to the server, but it sends a NAMESPACE and CAPABILITY command only. It does not even try to log in.
akonadi_imap_resource_0(12784)/kdeui (Wallet) KWallet::Wallet::openWallet: Pass a valid window to KWallet::Wallet::openWallet(). akonadi_imap_resource_0(12784)/kdepimlibs (kimap) KIMAP::SessionThread::sslConnected: TLS negotiation done. akonadi_imap_resource_0(12784)/kdepimlibs (kimap) KIMAP::LoginJob::handleResponse: Capabilities after STARTTLS: ("IMAP4", "IMAP4rev1", "AUTH=NTLM", "AUTH=GSSAPI", "AUTH=PLAIN", "CHILDREN", "IDLE", "NAMESPACE", "LITERAL+")
The build I've just started running seems to have stopped having the problem. If it returns, I'll let you know in this bug. But I really think this is a showstopper that needs to be fixed.
3 days running without restarting the agent and counting.
Still counting on this machine. However, another one with the exact same build of Akonadi and KMail required the agent to be restarted twice today. I'll restart the agent on this machine now and see if the problem returns. I'm proposing marking it as a blocker again, since the only way to get email flowing again is with Akonadi Console (which is a debug tool). Normal users will not know how to fix it, short of logging out and back in.
Restarting the agent did not bring the problems back. Restarting the Akonadi server did.
Does this one still applies? I still have this issue of not being able to reproduce exchange related bugs.
I didn't have access to an Exchange server for several months. I do now. I'll pay attention during the week.
I could not reproduce the problem with Intel's Exchange 2010 server. That doesn't mean the problem is solved, since it's a different server with very different account configurations. I should also note that unlike the Nokia installation, this one does not disconnect me all of the time due to the load-balancer losing contact with the backend. So I recommend moving it to WORKSFORME for now.
I might be able to offer some more insight: this problem is related to authentication. It happens when the IMAP server rejects the AUTH command. The way that IMAP on Exchange works, the IMAP front-end and the Exchange back-end might be different servers. If the two stop talking to each other for whatever reason, like a network problem, the IMAP front-end will be unable to authenticate and will reply with NO. This happened quite often at Nokia due to the load balancing. It doesn't happen often at all at Intel, but it happened yesterday due to network outage. I didn't notice that the connection was stuck in "Connection established" state until this morning.