Version: 4.7 (using KDE 4.7.1) OS: Linux In older kmail it was possible to manually configure the namespaces for which the imap mailserver was to be inquired. This allowed for a workaround in configuring old (buggy?) servers like the UW imapd which by default serve up the whole user home directory upon a LISTDIR request with default configurations. The workaround was to manually specify a subdirectory in user's home directory to selectively be checked for (imap) mailboxes. The latest akonadi version does not provide this configuration option anymore. This can render kmail unusable in some situations. More precisely, when first configuring an account for a faulty imap server (as described above), the potentially huge data transfer required bogs down the akonadi server and makes it seem to be frozen (this includes other ressources fetching and even the GUI of akonadi clients like kmail). Expected solution: Provide a configuration option for indicating the path in which mailboxes to be searched on the server (eventually displayed only for known faulty server versions). Reproducible: Always Steps to Reproduce: Configure an account for an UW imapd server with default configuration (maildir == ~) and with a few GB of non-mailbox data stored in the user account on the imap server. Actual Results: Akonadi freezes. Restart is required and it only temporarily stores functioning. It will freeze again after a few minutes. Faulty account doesn't appear in kmail. The faulty ressource appears as in "Connection established" state in "Akonadi Configuration" and it never goes to synching or to "Ready". Expected Results: Akonadi doesn't freeze. Ressource finishes synching and becomes "Ready".
I see. We're supposed to do the namespaces sensing automatically (hence why the option is not there anymore). I'd be interested in getting access to an account on that server if that's possible to check how it behaves and see if we could have a simple workaround. If I can't get access, or can't find a workaround then we'll indeed have to reintroduce that option somehow.
Unfortunately that server is behind a firewall I don't have control of. On the other side, that server is the standard version that shipped with many versions of Linux for many years. If my understanding of the documentation is correct, there is no way of working around this flaw in design. This server in particular (but perhaps a few others) was designed to push $HOME by default. It is only by changing the source code of the server that this can be corrected, but then the server doesn't advertise what directory it is configured to serve up, so there is no way of telling if it was "fixed" or not. Equally, on some situations (i.e. dedicated mail servers), serving up the whole $HOME is "OK", because $HOME contains _only_ mailboxes. This makes the automatic detection impossible and the whole situation very frustrating indeed. I believe the manual option is necessary (perhaps hidden behind a push button -- like for "serverside subscription"). Thanks a lot for your help. It is greatly appreciated.
Any chance you could at least telnet the server and give me the output of the NAMESPACE command? The "script" would be connecting using telnet then: A LOGIN username password B NAMESPACE I'm interested in the output of B. Optionnally that would be nice if you could also give me the output of: C LIST "" * D LSUB "" * That said those two will likely contain private data, feel free to change folders names if needed but not anything else.
Sorry for writing to your directly, Kevin. Unfortunately, I was forced to realize that the bug I reported was the least of my problems with this version of KMail. Once I worked around the first configuration blocking (by using serverside subscription), I discovered that: - the akonadi ressource for this server was unuseably slow (takes 15 to 20 minutes to upgrade a 12 message folder) - while updating this ressource, akonadi blocks completely; - it seems to block even the "Local folders ressource"; - messages deleted reappear in the folder after restart - often deleting is not possible (move to trash is grayed out) - the "Del" shortcut gets confused _after a while_ and refuses to act, with a popup message that says all of a sudden that it is confused because double assignment (this despite me not doing anything at all with the computer in the last 2 hours) - worst of all, if this ressource is active in akonadi, no other imap client can access the corresponding imap server other than read-only. These widespread failures seem to manifest only As I depend on my e-mail for 80% of my daily activity, and since I only have one machine to work with, and since I can't stand thunderbird, I will be forced for now to go back to kmail1, which works marvelously. Sorry for this. I will add anyways the information you required to the bugreport. Thanks a lot for your attention. On September 19, 2011 05:45:48 Kevin Ottens wrote: > https://bugs.kde.org/show_bug.cgi?id=282245 > > > > > > --- Comment #3 from Kevin Ottens <ervin kde org> 2011-09-19 05:45:48 --- > Any chance you could at least telnet the server and give me the output of > the NAMESPACE command? > > The "script" would be connecting using telnet then: > A LOGIN username password > B NAMESPACE > > I'm interested in the output of B. > Optionnally that would be nice if you could also give me the output of: > C LIST "" * > D LSUB "" * > > That said those two will likely contain private data, feel free to change > folders names if needed but not anything else.
openssl s_client -connect @@@:# -quiet * OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS AUTH=PLAIN AUTH=LOGIN] merlin.giref.ulaval.ca IMAP4rev1 2004.357 at Mon, 19 Sep 2011 20:12:38 -0400 (EDT) A LOGIN ctibirna ** A OK [CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User ctibirna authenticated B NAMESPACE * NAMESPACE (("" "/")("#mhinbox" NIL)("#mh/" "/")) (("~" "/")) (("#shared/" "/")("#ftp/" "/")("#news." ".")("#public/" "/")) B OK NAMESPACE completed The LIST command returned the full list of all files contained in my user home directory, including all hidden files and contents of hidden (dot) directories. This is absolutely huge, 80K lines, it can take anywhere from 15s to receive on local (fast) network, and up to many minutes, depending on server load. This is why I don't paste that here. The format returned is absolutely standard. For example: - for directories: * LIST (\NoSelect) "/" imap-mail/WORK/ATTIC - for files: * LIST (\NoInferiors \UnMarked) "/" imap-mail/WORK/ATTIC/fvwm At the end, as expected: C OK LIST completed The LSUB command returns whatever filename I had put in ~/.mailboxlist on the server in order to try to work around the issue. E.g.: D LSUB "" * * LSUB () "/" imap-mail/WORK/ATTIC/fvwm D OK LSUB completed Worthy notices: - as you can see, this is a rather old (and presumably very well known) server software. It is the UW imapd, which was the "de facto" testing implementation for the imap protocol, I guess. - this exactly same server works perfectly with kmail1 - once one worked around this particular problem, many many other issues appear: - unuseable slowliness, - akonadi full blocking, - server-side access locking (probably throught DoS; no other clients can access the mailboxes other than read-only) - deleted messages reappear at next kmail2 restart etc. Thanks for your attention.
OK, so now, could you try to issue a LIST command for each of the namespaces, like: A LIST "" "#mhinbox" B LIST "" "#mh/"" ... And so on, just skipping the first one (the empty namespace). Would that give you a more proper list of mailboxes? If not, please point me out which namespaces didn't give you adequate results.
Sorry, pressed send to fast and spotted a typo. B LIST "" "#mh/"" should be instead: B LIST "" "#mh/"
B NAMESPACE * NAMESPACE (("" "/")("#mhinbox" NIL)("#mh/" "/")) (("~" "/")) (("#shared/" "/")("#ftp/" "/")("#news." ".")("#public/" "/")) B OK NAMESPACE completed C LIST "" "#mhinbox" * NO /users/ctibirna/.mh_profile not found, mh format names disabled C OK LIST completed D LIST "" "#mh/" D OK LIST completed E LIST "" "#shared/" E OK LIST completed F LIST "" "#ftp/" * LIST (\NoSelect) "/" #ftp/ F OK LIST completed G LIST "" "#news." G OK LIST completed H LIST "" "#public/" H OK LIST completed I LIST "" "~" I OK LIST completed Nothing there, as I said. This server software is programmed (hardwired) to serve up the home user. The other namespaces have little utility.
Indeed... I see no way out... For reference and make my job easier when I'll be able to work on a fix for your issue, any chance you could attach me a screenshot of the namespace settings you had in kmail1? I'll probably make something more generic, but I want to make sure I don't make it useless for you in the process.
Created attachment 64071 [details] kmail1 imap namespace config The green "reload" icon next to "Namespaces:" allowed for reloading the defaults offered by the server.
I have a similar problem, although in my case, the instructions for accessing our server state: set the personal namespace to "" and IMAP server directory to "~/Mail". I opened a separate bug to request an option for setting IMAP server directory (#292285), but I'm mentioning it here in case there is a workaround using namespaces or vice versa. Here is the output of my server greeting and namespaces, in case it helps. * OK [CAPABILITY IMAP4REV1 I18NLEVEL=1 LITERAL+ SASL-IR LOGIN-REFERRALS AUTH=PLAIN AUTH=LOGIN] imap.cs.ubc.ca IMAP4rev1 2007f.404 at Mon, 23 Jan 2012 11:44:02 -0800 (PST) A LOGIN xxx *** A OK [CAPABILITY IMAP4REV1 I18NLEVEL=1 LITERAL+ IDLE UIDPLUS NAMESPACE CHILDREN MAILBOX-REFERRALS BINARY UNSELECT ESEARCH WITHIN SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User xxx authenticated B NAMESPACE * NAMESPACE (("" "/")("#mhinbox" NIL)("#mh/" "/")) (("~" "/")) (("#shared/" "/")("#ftp/" "/")("#news." ".")("#public/" "/")) B OK NAMESPACE completed C LIST "" "#mh/" C OK LIST completed D LIST "" "#mhinbox" * LIST (\NoInferiors) NIL #mhinbox D OK LIST completed
The IMAP resource has a new maintainer, reassigning to him.
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present? If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
We(In reply to Denis Kurz from comment #13) > This bug has only been reported for versions older than KDEPIM 4.14 (at most > akonadi-1.3). Can anyone tell if this bug still present? Well, I don't have access to that UW imapd server anymore (we replaced it with dovecot some time ago) but I would guess that, as the discussion above clearly states, as long as that server is still in use, a manual configuration for Namespaces would be needed still. > If noone confirms this bug for a recent version of akonadi (part of KDE > Applications 15.08 or later), it gets closed in about three months. Well, it would be a negative resolution for this report, but I guess, yeah, the world evolves and some issues just go away by themselves. I'd say, go ahead and close it. If someone finds the error again, most likely they will also find this report too, even if marked closed.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.