Created attachment 113968 [details] annoying windows I have a problem since the akonadi 18.04/5.8.2 (installed on friday 9th of June (archlinux)). One of my IMAP accounts (volny.cz) stopped working in kmail just after the update. The original settings was STARTTLS/143. But as I verified later from server support, the server volny.cz doesn't support STARTTLS for IMAP at all. So, it seems that for many years I was connected insecure from k9-mail and from kmail (Is it possible to notify the user about this fallback?). :-/ Actually, there is another annoying behaviour of akonadi, which leads into state, when I'm blocked on the server for next one day as a spammer (Because I'm unable to logging from my phone via the k9-mail anymore within this time period - without changing anything there). There is a strange window (Please excuse my free translation fom Czech language and my poor English): Unable to verify - Volny.cz type E-mail IMAP server Server for account "Volny.cz" refused given username and password. Authentication method failed, server answered: A000002 NO Bad username or password [ AUTHENTICATIONFAILED ] I keep getting these windows. Sometimes I have more than 30 instances of these windows appeared at the same time, sometimes, a previous instance get immediately closed automatically. But they are steeling mouse focus (focus follow mouse settings) for more than three seconds with terrible window blinking. Sometimes I'm even unable to turn akonadi off from KDE at all. This comes together with permanent network traffic (about 170kbps). And even if the account gets blocked in akonadi after some while with strange message (which is not true anyway): "Unable to read password: User refused access to wallet", I'm probably still keep getting these windows even they are not visible (periodically loosing focus until I stop akonadi completely). I have next three IMAP accounts with TLS configured in akonadi. And it seems that they work correctly. Fix of the KDE bug #395249 doesn't have any possitive effect. It is still broken the same way with akonadi 5.8.3. Maybe it is worst, because akonadi won't disable the account automatically anymore, I think. I'm unable to disable checking of this broken account without deleting it from akonadi. When I press LMB on an Inbox folder of any other account, this hell will start again immediately, even if the volny.cz account is not visible in kmail and removed from manual or automatic email checking. The problem is, that explicit change to other configurations (insecure connection or SSL/993) doesn't change anything, too. The only found "solution" is to turn akonadi off. :-/
Created attachment 113969 [details] network traffic generated when akonadi is running
I'm unable to find anything about this broken IMAP resource logged in akonadi console logs. There are plenty of messages from other IMAP resources and from CALDAV resource.
Almost two months without my favorite IMAP account. :-O Akonadi has been "fixed" by adding iptables permanent DROP rule for OUTPUT packets to the broken IMAP server. It "fixes" everything strange meant above, except the IMAP account itself, of course, which behaves as disconnected now. So, akonadi and the KDE workspace are usable together again.
Volny.cz does support STARTTLS, so your communication was secured the whole time :) But it looks like volny.cz only supports PLAIN authentication method, while it looks like we are trying to log in with LOGIN authentication method (or at least I assume that "Metoda 'Příhlášení' selhala" is just a bad translation for the "LOGIN" method). Please check in the IMAP account's settings (in the Advanced) tab whether the "Authentication" method selected is "PLAIN" (I hope this is not localized :)).
I'm pretty sure, I've tried all three interesting methods ("Čistý text", "PLAIN" and "LOGIN") for all encryption methods (None, SSL/TLS and STARTTLS). And the PLAIN method was the preferred one. No any combination is working now, with the new akonadi 18.08/5.9.0 (Good news everyone, the google account is broken now! :-D ). I looks like any combination I choose is ignored completely, and it uses the same default with the same result. BTW: What is the difference between methods "Čistý text" and "PLAIN", if any? If I try to set STARTTLS/PLAIN (None/PLAIN / STARTTLS/PLAIN) and then I drop the mentioned iptables output rule, and to renew the incoming manually, the follow mouse policy method makes the desktop unusable, and the network traffic skyrockets immediately. Sometimes, within this hell, I'm able to see the strange window mentioned above for a moment, but it disappears immediately. The following is from the akonadi console: Job ID Created Wait Time Job Duration Job Type State Info akonadi_imap_resource_1 19538 15:20:25 CEST.935 00:00:00.014 Custom-startConnect Running 19541 15:20:25 CEST.964 00:00:00.007 Custom-startConnect Running 19544 15:20:25 CEST.987 00:00:00.009 Custom-startConnect Running 19547 15:20:26 CEST.009 00:00:00.008 Custom-startConnect Running 19550 15:20:26 CEST.031 00:00:00.010 Custom-startConnect Running 19553 15:20:26 CEST.054 00:00:00.009 Custom-startConnect Running 19556 15:20:26 CEST.076 00:00:00.011 Custom-startConnect Running 19559 15:20:26 CEST.100 00:00:00.011 Custom-startConnect Running 19562 15:20:26 CEST.123 00:00:00.009 Custom-startConnect Running 19565 15:20:26 CEST.144 00:00:00.014 Custom-startConnect Running 19568 15:20:26 CEST.172 00:00:00.009 Custom-startConnect Running 19571 15:20:26 CEST.197 00:00:00.012 Custom-startConnect Running 19574 15:20:26 CEST.222 00:00:00.009 Custom-startConnect Running 19577 15:20:26 CEST.244 00:00:00.010 Custom-startConnect Running 19580 15:20:26 CEST.267 00:00:00.011 Custom-startConnect Running 19583 15:20:26 CEST.291 00:00:00.012 Custom-startConnect Running 19586 15:20:26 CEST.316 00:00:00.009 Custom-startConnect Running 19589 15:20:26 CEST.338 00:00:00.010 Custom-startConnect Running 19592 15:20:26 CEST.364 00:00:00.011 Custom-startConnect Running 19595 15:20:26 CEST.389 00:00:00.009 Custom-startConnect Running 19598 15:20:26 CEST.411 00:00:00.009 Custom-startConnect Running 19601 15:20:26 CEST.432 00:00:00.009 Custom-startConnect Running 19604 15:20:26 CEST.454 00:00:00.012 Custom-startConnect Running 19607 15:20:26 CEST.479 00:00:00.012 Custom-startConnect Running 19610 15:20:26 CEST.505 00:00:00.010 Custom-startConnect Running 19613 15:20:26 CEST.528 00:00:00.011 Custom-startConnect Running 19616 15:20:26 CEST.558 00:00:00.012 Custom-startConnect Running 19619 15:20:26 CEST.590 00:00:00.012 Custom-startConnect Running 19622 15:20:26 CEST.620 00:00:00.009 Custom-startConnect Running 19625 15:20:26 CEST.646 00:00:00.010 Custom-startConnect Running 19628 15:20:26 CEST.673 00:00:00.009 Custom-startConnect Running 19631 15:20:26 CEST.695 00:00:00.012 Custom-startConnect Running 19634 15:20:26 CEST.725 00:00:00.012 Custom-startConnect Running 19637 15:20:26 CEST.751 00:00:00.014 Custom-startConnect Running 19640 15:20:26 CEST.778 00:00:00.009 Custom-startConnect Running 19643 15:20:26 CEST.801 00:00:00.009 Custom-startConnect Running 19646 15:20:26 CEST.822 00:00:00.009 Custom-startConnect Running 19649 15:20:26 CEST.844 00:00:00.011 Custom-startConnect Running 19652 15:20:26 CEST.870 00:00:00.011 Custom-startConnect Running 19655 15:20:26 CEST.893 00:00:00.011 Custom-startConnect Running 19658 15:20:26 CEST.917 00:00:00.009 Custom-startConnect Running 19661 15:20:26 CEST.939 00:00:00.010 Custom-startConnect Running 19664 15:20:26 CEST.962 00:00:00.009 Custom-startConnect Running 19667 15:20:26 CEST.985 00:00:00.009 Custom-startConnect Running
I'm suddenly seeing a similar thing with a bunch of "Custom-startConnect" tasks running and all my IMAP resources failing to connect, although they cause high CPU load on themselves and the session dbus instance. This affects two servers that did not change configuration. The resources show "online, idle" with status message "ready" in akonadiconsole but flash to some other state too quickly to see ("offline" maybe). There is zero useful information anywhere, `akonadictl --verbose start` prints a lot of garbage but nothing pointing toward a problem, and akonadiconsole isn't helping either.
me to i got probleme with kmail and others services since laste update: -probleme imap but not smtp - all services about wich depends on plasma-discover do not work because of https://autoconfig.kde.org/ocs/providers.xml file missing - cannot re-create googledrive account (online account) - kio error for kontact (not sure it's related on) config: debian-kde plasma 5.13.5 / kde frameworks 5.49.0 / QT 5.11.1 kernel 4.18.0-1 repo buster/testing
(In reply to Cherkah from comment #7) > me to i got probleme with kmail and others services since laste update: > -probleme imap but not smtp > - all services about wich depends on plasma-discover do not work because of > https://autoconfig.kde.org/ocs/providers.xml file missing > - cannot re-create googledrive account (online account) > - kio error for kontact (not sure it's related on) > > > config: > debian-kde plasma 5.13.5 / kde frameworks 5.49.0 / QT 5.11.1 > kernel 4.18.0-1 > repo buster/testing the last update has resolved my probleme thx
Just sixt months (from the first report) without my favorite email account on my desktop. Currently there is akonadi 18.12.1/5.10.1 installed. All problems reported within this ticket are still here. I don't see much progress even in other reported bugs. Is akonadi dead?
I'm sorry. This has been probably fixed yet in 2019, but I've forgotten to close this. Reading IMAP accounts works fine now (still last versions with archlinux), maybe exept the unpleasant long pause after network re-connection (manual refresh doesn't work too until some timeout - expected automatic pull immediately after network re-connection).