Version: unspecified (using KDE 4.5.80) OS: Linux Using an existing IMAP-Account with a password which contains a "%" (followed by two digits, if that further matters) gives an error: "A000003 BAD expected end of data instead of %(here are the two digits)" ...making the IMAP account in fact inaccessible for the user. Reproducible: Always Steps to Reproduce: Happens both when migrating from old KDE 4.5-style and when trying to set up a new account in Akonadi.
What IMAP server (make/model) is that, and could you post a log of the IMAP command/responces? export KIMAP_LOGFILE="filename"; akonadictl restart filename should now contain a log of all IMAP traffic so please post that after some cleaning.
I only get logfiles with length "0" using the command you propose?! The IMAP server (German provider "web.de") works flawless with all other clients and all other OSes, including KMail up to th version included with KDE 4.5.x. Maybe the "%" followed by a number is considered as some "escape code"?
Somehow because of this error Akonadi for my case is stuck in the migration process from the old-style KMail accounts - it endlessly tries to migrate with every new start. However, also a strange message appears in the migration window: "User denied password access" or something like that, indicating Kwallet problems (which definitely should not exist as Kwallet gives Akonadi full access, and the other error message rather hints at problems with the IMAP server).
I had to completely re-setup Akonadi and KMail (the failed migration messed everything up more and more). However, I still can't access my IMAP server, the error persists with the error message as given in #1. In KMail's account, however, the exact error message is "Could not connect to the IMAP server. Could not read the password: User rejected wallet access." Accessing the mail provider via POP3 (same password, also stored in KWallet) works flawlessly, however. I still have no idea how to turn on a meaningfull logging.
Strange, but I just saw that that logger strips all login credentials so it would not work anyway :( My guess would also be that the server interprets the %XX as a escape code that transforms the "%XX" into another character. The question (I think) is if the escaping from kimap is wrong or if the server is wrong in it's interpretation. Hence it would be good if we could see what was sent to the server. Wireshark dump?
I think I have found the solution to the problem. With this IMAP-Server, Akonadi wrongly chooses STARTTLS as crypto method, and PLAIN instead of LOGIN. Manually switching the autodected values to SSL/TLS and LOGIN solves the problem. So maybe it's rather a problem with the autodection of the IMAP server?
That would depend on what the IMAP server replies to the CAPABILITIES command.
As at least for my configuration the problem is fixed and seems to be more of a problem between the auto detection of features and the IMAP server, I close my report.