Bug 395249 - Akonadi 5.8.2 breaks existing IMAP/STARTTLS account
Summary: Akonadi 5.8.2 breaks existing IMAP/STARTTLS account
Status: RESOLVED FIXED
Alias: None
Product: kimap
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Daniel Vrátil
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-11 13:57 UTC by kramski
Modified: 2018-07-05 10:14 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.8.3


Attachments
Hacky fix (1.68 KB, patch)
2018-06-12 09:50 UTC, Allan Sandfeld
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kramski 2018-06-11 13:57:46 UTC
After upgrading to Kmail/Akonadi 5.8.2, I can no longer connect to my IMAP server at work which is defined as:
   IMAP
   Port 55### (may be this unusual high, non-standard port became a problem?)
   Encryption: STARTTLS
   Auth: PLAIN

Status of the account in Kmail is shown as "Could not connect to the IMAP-server ####. Could not read the password: user rejected wallet access."

The error message seems misleading: I did not reject access to kwallet, and the IMAP ressource is happily able to recreate a new, correct password entry if I rename or delete the existing one.

The journal shows at the same time:

"Jun 11 15:41:49 #### akonadi_imap_resource[8655]: org.kde.pim.kimap: STARTTLS not supported by server!"

Other IMAP clients still work with the above settings.
Comment 1 tromzy 2018-06-12 07:28:38 UTC
I can confirm, I have the same issue since latest Akonadi / Kmail update (or maybe Frameworks 5.47) : I cannot connect to my IMAP account anymore. I get the same error as kramski@web.de. If I type the password again, it does nothing. Thunderbird still works fine.
Comment 2 Allan Sandfeld 2018-06-12 07:30:07 UTC
I see the same. Though not with all IMAP servers with at least with outlook 365
Comment 3 Allan Sandfeld 2018-06-12 09:10:09 UTC
It appears outlook doesn't return a response.responseCode == "STARTTLS". Instead the only response code it sends is a base64 unicode16 string that ends in OUTLOOK.com :/
Comment 4 Allan Sandfeld 2018-06-12 09:50:21 UTC
Created attachment 113224 [details]
Hacky fix

This patch fixes it for outlook 365, but more generally I think it is probably a mistake not to try starttls unconditionaly if the mailtransport was configured to use starttls.
Comment 5 kramski 2018-06-12 10:31:50 UTC
In my case server is Oracle Beehive, running behind an NGINX reverse proxy.

I was able to successfully use the workaround from https://www.reddit.com/r/kde/comments/8p9rtz/kde_ships_kde_applications_18042/e0b9f4t and reconfigured the connection as TLS/SSL with AUTH="clear text" and another (user defined, high) port.
Comment 6 Allan Sandfeld 2018-06-12 11:45:01 UTC
It probably also doesn't advertise STARTTLS support.
Comment 7 Martin Ottmar 2018-06-19 11:35:52 UTC
I have probably the same problem since the last update to akonadi 18.04/5.8.2 on friday 9th (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, 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. :-/
But in my case, changing to other configurations (insecure connection or SSL/993) doesn't work too.
Actually, there is another annoying behaviour of akonadi, which leads into state, when I'm most probably blocked on the server as a spammer (Because I'm unable to logging from my phone via the k9-mail anymore - 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 for more than one second with terrible window blinking.

And even if the account gets blocked in akonadi after a 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).

In akonadi, I have next three IMAP accounts with TLS configured and it seems that they work correctly.
Comment 8 Daniel Vrátil 2018-07-05 10:12:48 UTC
Git commit 7c4570b17a3bdc94c32ee4ac17e822b25ffb9755 by Daniel Vrátil.
Committed on 05/07/2018 at 10:06.
Pushed by dvratil into branch 'Applications/18.04'.

Fix STARTTLS support detection

Don't assume that IMAP servers announce capabilities in initial greeting,
the RFC does not require that at all. This assumption caused LoginJob
to fail if user configured STARTTLS but the server did not announce any
capabilities in the greeting.

Now we explicitly ask for capabilities before sending the STARTTLS command
to make sure that STARTTLS is supported.
FIXED-IN: 5.8.3

M  +18   -11   src/loginjob.cpp
M  +0    -5    src/session.cpp
M  +0    -6    src/session_p.h

https://commits.kde.org/kimap/7c4570b17a3bdc94c32ee4ac17e822b25ffb9755