Files outside of imap root exposed despite setting imap_ns_* options

[rcubetrac]

Reported by cepheid on 18 Jun 2013 00:42 UTC as Trac ticket #1489181

I don't know if this counts as a bug or not, but I couldn't find any solutions for it and it feels like a bug. On my new install (RC 0.9.2 on CentOS 5.8, php 5.2.17, using sqlite3 DB, with uw-imap 2007b Pro Control Panel version), RC is exposing all files in a user's home directory despite the namespace override options being set in main.config.inc.

All of the user mail folders are in ~/mail ... The ancient imapd that my server must run does not support namespaces but, for example, SquirrelMail allows setting of the "default mail folder" to artificially restrict the client to only the mail folder (so setting it to "mail/" shows only the files in that directory, and nothing else). I saw that RC used to have an imap_root config option, but this does not seem to be supported any longer -- at least, it's not present in the main.config.inc. I did set all of the imap_ns_* options (imap_ns_personal, imap_ns_shared, imap_ns_other) to "mail/" but this did not help...

Specifically, while setting the imap_ns_* options DID clean up the folder display on the main page (i.e. it no longer showed the mail/ directory itself, just the folders within it), the folder subscription page (Settings -> Folders) still exposes everything in the user's home directory (the mail directory itself, public_html, etc.).

Shouldn't the imap_ns_* options restrict RC from showing things outside of these directories?

How can I get RC to show only those folders in the mail directory, and nothing else? Is imap_root still supported, or is there some other option I'm missing? Or is this a bug and the imap_ns_* options are not working fully correctly?

I am happy to post screenshots, logs, whatever is needed. Please provide instructions if you need logs with debugging info. Thanks.

Migrated-From: http://trac.roundcube.net/ticket/1489181

[rcubetrac]

Comment by @alecpl on 18 Jun 2013 06:19 UTC

This is not an intention of imap_ns_* options. There's no option to hide some of folders. And of course this is a bug of IMAP server. I'm not closing this in case someone would like to implement such feature.

[rcubetrac]

Comment by cepheid on 18 Jun 2013 06:23 UTC

The lack of namespace support is certainly a missing feature of the IMAP server... I won't say it's exactly a bug. Didn't RC used to support an "imap_root" config option, that would accomplish essentially this same thing? (As previously mentioned, SQmail seems to have a specific workaround for this issue... it has a setting for the IMAP server type, and a setting for the default folder prefix, i.e. forced namespace.)

Hopefully this report makes sense -- it's not that I'm looking to hide some of the folders, it's that I'm looking to force the namespace since the IMAP server won't do it for me, similar to how SQmail does it. I thought this used to be an option with imap_root but I guess maybe I misinterpreted...

[rcubetrac]

Comment by @alecpl on 18 Jun 2013 09:56 UTC

But this is your IMAP server responding with a list of all folders, while it should respond with only folders relevant to IMAP. Are you IMAP folders prefixes with INBOX/ or sth? If not, I don't see a way to implement an option to hide others.

[rcubetrac]

Comment by cepheid on 18 Jun 2013 17:10 UTC

They are in a mail/ subdirectory, so they are prefixed with mail/ ... this is why specifying imap_ns_personal = "mail/" cleaned up the display of the folders in the left sidebar, even though it did not fix the available subscription list.

In pine, for example, I can specify the default folder as "mail" and pine will not look anywhere but that folder. The same is true for Apple Mail and the iPhone/iPad mail client -- specifying the "folder path" will cause those clients to look only in the specified path (in this case, folder path = "mail/"). Same for SQmail, too.

This path restriction (basically an IMAP root) appears to be common to IMAP clients, so that even if the IMAP server doesn't support namespace restriction, the client can do so.

[rcubetrac]

Comment by steve on 26 Aug 2013 22:15 UTC

I created an account just to say that I just spent two hours trying to figure this out before finding this ticket. For another example, OpenWebMail uses ~/mail/sent-mail and similar filenames. For iPhone/iPad, Becky!, and other IMAP clients I can set an "IMAP Path Prefix" setting of "mail" that will limit the list of folders when pairing "Sent Mailbox" on iOS with "mail/sent-mail", so they share those same files (see https://www.google.com/search?q=outlook+imap+path+prefix for a long list). Using the same set of filenames would make it easy to switch to Roundcube, but otherwise it seems like I would have to create /home/user/.mailboxlist for each user to subscribe the default folders, and/or perhaps add symlinks for each user in order to use "Sent" instead of "sent-mail".

BTW, when creating my user account Trac defaulted to an unknown email address that I will obscure slightly as "othername.steve at yahoo.com". Not sure if it gave me another account, found any old email address with "steve" in it, or what.

[rcubetrac]

Comment by preon on 30 Sep 2013 17:15 UTC

I reported what turned out to be the same issue in #1489362

I don't handle the mail end of things and didn't realize which solution we were using but after investigating it turns out we're running UW-IMAP as well.

By default UW-IMAP does not enforce any namespaces and makes ~ available to the user. UW-IMAP is capable of this but since it doesn't support runtime configuration, this involves setting the appropriate configuration variables in env_unix.c before compiling the daemon. Most mail clients have some way to choose their own root directory for either organization purposes or to get around pitfalls like this. It seems that RC currently does not.

If you're unable to recompile UW-IMAP, it is capable of parsing an "unsupported" runtime configuration file.

/etc/c-client.cf:

I accept the risk
set mail-subdirectory mail

The file must start with the phrase "I accept the risk" or UW-IMAP won't parse it, as runtime configuration is not officially supported.

Any pre-existing mail folders will need to be moved accordingly, or mail clients reconfigured if they were previously setting their own mail directory.

[rcubetrac]

Comment by cepheid on 30 Sep 2013 20:17 UTC

Replying to preon:

If you're unable to recompile UW-IMAP, it is capable of parsing an "unsupported" runtime configuration file.

Indeed, uw-imap does provide a workaround... however, there are likely to be cases where the user who is installing RoundCube has no ability to change the IMAP server settings, whether via runtime config or recompiling. For example, the IMAP server may be a completely different server, under someone else's control, than the server on which RoundCube is installed.

The MUA (mail user agent) should also be able to "artificially" restrict namespace access. The prime examples of this would be SquirrelMail or the iOS web client, both of which have a setting for "mail folder prefix," so that the MUA then looks only at folders within this prefix directory and ignores everything else. What I am requesting is that RoundCube implement a similar setting, which would allow "forcing" of namespaces regardless of the IMAP server software and/or ability of the RoundCube admin to modify the IMAP server settings.

[rcubetrac]

Comment by hsleisink on 27 Nov 2013 15:18 UTC

I have a simple patch for this:

Add the following line to config/main.inc.php:
$rcmail_config['imap_root'] = 'mail';

In program/steps/settings/folders.inc change line 212 and 213 to:

$a_unsubscribed = $STORAGE->list_folders($RCMAIL->config->get('imap_root'));
$a_subscribed   = $STORAGE->list_folders_subscribed($RCMAIL->config->get('imap_root'), '*', null, null, true); // unsorted```

[rcubetrac]

Comment by cepheid on 27 Feb 2014 19:18 UTC

Replying to hsleisink:

I have a simple patch for this:
Thanks, I'll give this a shot. But, it looks like your patch cleans up the Folder Subscription page, but may not clean up the display... that is, it seems like I might still need to set the imap_ns_* options in addition. Is that correct? If so, a more comprehensive patch that incorporates imap_root into imap_ns_* would be recommended. (However, imap_ns_* might not even be needed if imap_root exists, since I think the idea behind them is basically the same...)

[alecpl]

With the above commit following configuration can be used to achieve the requested behavior:

$config['imap_ns_personal'] = 'mail/';
$config['imap_ns_other'] = null;
$config['imap_ns_shared'] = null;