a bug or dots not supported in folder names ?

[sam]

I just came across this very bad issue in ox6.16.1.0-3_3.1 installation (i would say, it worked in 6.14):

I'm having user login names with a dot in form "first.last". This works nicely.
But if I try to setup shared folders, these would not work at all.
Everything seems ok in dovecot imap with thunderbird client but ox web interface
would not show the shared folders in the folder tree. I can set the permissions to allow
the other user to see a particular folder. The other user can even see that
folder within the subscription dialogue. But it wont appear in the email folder tree.
If I try the same with a non-dot test user, everything works like expected.

I further tried to use dot-containing folder names in general - neither that works correctly,
totally broken behavior. Even if my dovecot configuration supports dots in foldernames
and egain everything ok with Thunderbird.

[Martin Heiland]

Hi,

i suspect you mean IMAP folders? IMAP servers uses special characters (like dot or slash) internally for folder separation. If such characters are used within folder names, the IMAP server might respond unexpected - for example creating two subfolders or not showing anything. You might solve it by changing the folder separation character at the IMAP server to "/". IMHO this is not a broken behavior but simply caused by the IMAP servers configuration. Other folder types (calendar, contacts, tasks, infostore etc.) work fine for me since they are fully managed by OX. If you still feel that this is a bug, you might open a bug report over at http://bugs.open-xchange.com/.

Greetings

[sam]

Hi Martin,

yes, I mean IMAP folders. My dovecot server fully supports dots in folder names (using listescape plugin + "/" separator in namespaces). As I've written above, it works
perfectly with other clients as e.g thunderbird. So it must be an ox bug. I even feel like it worked in 6.14.

Could you please point me to the right ox source files I have to look ? I've setup the environment + full sources and I'd prefer to do little debugging on my own before filling a bug.

regards,

Sam

[Martin Heiland]

Hi,

i don't know the exact code, but it might be somewhere at the com.openexchange.imap bundle.

Bug reports go here: https://bugs.open-xchange.com/

Thanks.

[sam]

So, i'm back again and I hope to give some useful infos for the others reading here:

It is not an ox bug, it is just the very distinct way ox webclient is using the \HasNoChildren flag and the LSUB command. Thunderbird is relying on LIST command, therefore, everything looks ok there. The real bug is in dovecot listescape plugin. Actually, in v1.2.x there are multiple issues there, better to say a can full of bugs , if listescape is used along with acl plugin, so beware of using listescape in v1.2 !

Timo made few fixes on dovecot v2.0 trunk right now. However, there are 2 more issues remaining to be solved. For v1.2.x no fix is expected anymore.

For those others wanting to try v2.0 now: please note, ox has broken imap capability implementation (interpreting the restricted capabilities set given before login...) and dovecot v2.0 conforms strictly to standard now. Therefore, to get ACLs working, you have to explicitly place the imap_capability command in dovecot config.
See e.g. http://dovecot.org/list/dovecot/2010-April/048147.html
There seems to be an bug report #16640 on this, but unfortunately it is not public.
Further, you have to restart gropware after this change, since it is caching the capabilities from the 1st login session. Thats actually a nasty bug. A sideeffect of this is probably that ACLs work only on the primary account.

So, thats all for now, I'm going to dive back to java code to find out warum zum Teufel
are ACL groups grayed out even if the groups exist and imap server supports ACL groups...

[Martin Heiland]

Hi,

thanks for digging into this. We already have had a conversation with the Dovecot guys regarding 2.0 and the new CAPA handling. See: http://www.dovecot.org/list/dovecot/...st/051280.html
An earlier RFC stated clearly, that the CAPA must be fully shown before login. With RFC3501 this specific wording has been changed to allow user-specific CAPA strings and so on. We already have a Dovecot 2.0 installation up and running for testing.

The bug should be public now. Essentially we decided to work on this as an enhancement for a upcoming version. The bug reporter also described a possible workaround.

Greetings