So with further simplicity in mind, I would even suggest removing the option to sync unsubscribed folders in IMAP @vanmeeuwen

Hello @greve - nice to (informally meet you, Sir)

In T1244#22244, @hsmith wrote:

For simplicity sakes, it may even be worth considering removing the option for folder syncing altogether.

Yes @vanmeeuwen I understand point you make - the user appears to be frustrated that that the default behaviour for Activesync is that when a new folder is created on Activesync, it doesn't force all other Activesync devices to subscribe it.

For simplicity sakes, it may even be worth considering removing the option for folder syncing altogether.

I don't get it. Resource is not a location. Even assuming some resources can have location specified (where in LDAP?) this could be somewhat confusing. What if the location was filled as you describe and then you edit the event changing the resource, should we then modify the location?

Assuming that this is for the KE14 webclient.

Assuming that this is for the KE14 webclient.

Assuming that this is for the webclient and KE14.

Yes. The "send a document as email" function should open roundcube webmail and creates an empty mail with the attached document.

As I understand when you send a document from LibreOffice it will attach the document to the email message, right?

In T1244#20657, @vanmeeuwen wrote:

I agree with the suggested options by @machniak, since they combine in to the following combinations of bitflips for the underlying Syncroton:

1. Selected folders only (0),
2. All subscribed folders (1+4+16),
3. All folders (2+8+32)

With the above in mind @machniak @petersen @vanmeeuwen,

Yes @machniak you're certainly right - it's about the former indeed.

Enabling syncing of all (selected) folders is one thing and disabling "flat mode" is another. I think this ticket is about the former.

What would be even better is if the server could detect when an Outlook connection is initiated via Outlook, and automatically set Option 2 outlined by @vanmeeuwen (flags 1, 14, 16).

This so good to see!

Mr Roundcube @bruederli might be the man for this Task, given that Roundcube Next, and hopefully Kube will be JMAP-certified clients :)

First time poster, but a very happy Kolab Now customer :)

I would include the following key aspects;

Alec, can you do that?

This is a wontfix

Still missing a few points:

Cherry-picked in 194690f59b

https://github.com/roundcube/roundcubemail/commit/f6861cc89689f92d44c6b36d6a4d2520cca4b17b needs to go in to release-1.1 as well.

Great to see! This will definitely go a way to enriching the experience of both users on Outlook, and also on mobile devices too.

The proposed solution for enabling CRAM-MD5 and DIGEST-MD5 based authentication is documented here: https://docs.kolab.org/administrator-guide/md5-sasl-mechs.html

I agree with the suggested options by @machniak, since they combine in to the following combinations of bitflips for the underlying Syncroton:

Changed documentation points to "Sievefilters" here:

differential for "Settings":
https://git.kolab.org/D177

I can only support the need for a (fully) functional way to use Outlook as a client. Many of our (potential) clients use Outlook and are not willing to switch to something else. (even if I don't like it, it's just the way it is unfortunately).

We will take under consideration, the need to support an existing desktop client already configured with CRAM-MD5 -- all implications included.

I didn't say the last but the easiest.
The options we thought about:

We are fully aware of the fact, that kolab-saslauthd is not a full https://tools.ietf.org/html/rfc4422 implementation but based on this RFC our request is just to get kolab-saslauthd closer to this.
And based on the https://en.wikipedia.org/wiki/CRAM-MD5 second point of weeknesses explaination, based on RFC 2104, it could be possible to add some security too.

The suggested solution (to support CRAM-MD5 or DIGEST-MD5 in kolab-saslauthd) is very likely not the most efficient solution.

OTRS 1100055

Downvoted.

Syncroton already has a similar option, however it is not user configurable.

// When a device is reqistered, by default a set of folders are
// subscribed for syncronization, i.e. INBOX and personal folders with
// defined folder type:
//     mail.drafts, mail.wastebasket, mail.sentitems, mail.outbox,
//     event, event.default,
//     contact, contact.default,
//     task, task.default
// This default set can be extended by adding following values:
//     1 - all subscribed folders in personal namespace
//     2 - all folders in personal namespace
//     4 - all subscribed folders in other users namespace
//     8 - all folders in other users namespace
//    16 - all subscribed folders in shared namespace
//    32 - all folders in shared namespace
$config['activesync_init_subscriptions'] = 0;

machniak@kolabsys.com:
As this behaviour would need to be optional and manageable by the user, I see this as a user Preference, e.g. a checkbox "Enable ActiveSync on newly created folders" in Preferences > Server Settings > Main Options.

thanks - going to have a look at it tonight

https://git.kolab.org/diffusion/CO/
https://github.com/openchange/openchange/tree/jkerihuel/mapistore-python

could anybody tell me where to find the mapi-sources. although i think this is very complicated, i would like to have a look.

The lack of this is making my Kolab Now account almost unenjoyable to use. I don't appreciate having my groupware folders tangled amongst my personal folders. To counter this problem, I have had to create a folder called 'Folders' which all of my folders reside in, so that they are a level down from Inbox, just to stop them from being on the same level of hierarchy of groupware folders - this is annoying.

Unfortunately, Activesync is only enabled in Outlook 2013, and though the Kolab Actiesync implementation (Syncroton) is better than some of the others I have used, like Z-Push which has several bugs (folders don't appear under the mailbox tree but rather the inbox, problems deleting folders etc), I wouldn't say it is good enough to be the sole connector between the Kolab Server and Outlook, making MAPI integration more important.