dovecot - Feb 2020 - shared folder name or public folder with mail address

On 2/14/20 2:23 PM, Tobias Kirchhofer wrote:
> On 14 Feb 2020, at 14:05, Armin Schindler wrote:
> 
>> On 2/14/20 11:44 AM, Tobias Kirchhofer wrote:
>>> On 14 Feb 2020, at 11:06, Armin Schindler wrote:
>>>
>>> ??? Hello!
> 
> [?]
> 
>>> For our new setup (planned with CentOS 8, waiting for the official
repo for the latest dovecot
>>> version?) we have a prototype on Debian base with the latest
version of Dovecot. In opposite to our
>>> current solution we will implement global acls with user and groups
from LDAP. This is very nice.
>>
>> Wow, thanks. This seem to be exactly what I need to go on.
>> Our base system is a Univention UCS, so LDAP users and groups is what
we already have working :-)
>>
>> With your elements I think we really could have the cyrus shared
folders with dovecot by
>> using a namespace of
>> ?type=public
>> but with
>> ?prefix=shared/
>> (we might use type=shared with prefix=usershared/ later).
> 
> There is not something like one way do to this. You could also make your
life easier and choose to
> create a ?Share user? which is only there to share folders. This will then
be Dovecot ?Shared
> folders? shared by this pseudo user to other users. You then could use
Roundcube or such to maintain
> acl with this pseudo user. But we did not follow this path then for reasons
i cannot remember
> anymore :)
> 
> For each Public folder we have a defined namespace. ?Newsletter?,
?Client1?, ?Client2? etc. We have
> many, around 30 or so. ACL goes on this namespace (namespace/*). I guess
ACL are first match. Each
> namespace has its own prefix. (eq. prefix = Newsletter/, prefix = Client1
etc.) User can subscribe
> namespace by namespace acl assumed.
What is the benefit using own namespace for each public folder?
If the config is equal for all folders, wouldn't one namespace with
subfolders
be the same?
One public namespace would look like it is with cyrus in the client: one
"shared/"
folder to open/close.

Armin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2900 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20200214/2324d8d9/attachment.p7s>

> Armin Schindler <armin.schindler at sysgo.com> hat am 14. Februar
2020 15:02 geschrieben:
> One public namespace would look like it is with cyrus in the client: one
"shared/"
> folder to open/close.
That's right, but there is one important difference: Cyrus sorts those
folders alphabetically, Dovecot doesn't. Dovecot guys say it's the
client's job and that's also what the RFC says. So if you have many
subfolders, e.g. one per order it can be a bit confusing. Thunderbird is sorting
those folders, but not always. It seems to depend on when you refreshed the list
last time and if it was cached.

- Chris

Hello Chris,

On 15.02.2020 09:45, chris2014 at postbox.xyz wrote:
> 
>> Armin Schindler <armin.schindler at sysgo.com> hat am 14. Februar
2020 15:02 geschrieben:
> 
>> One public namespace would look like it is with cyrus in the client:
one "shared/"
>> folder to open/close.
> 
> That's right, but there is one important difference: Cyrus sorts those
folders alphabetically, Dovecot doesn't. Dovecot guys say it's the
client's job and that's also what the RFC says. So if you have many
subfolders, e.g. one per order it can be a bit confusing. Thunderbird is sorting
those folders, but not always. It seems to depend on when you refreshed the list
last time and if it was cached.
thanks for the hint.
I will check this in our environment.

Armin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2900 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20200215/8ca81c6e/attachment-0001.p7s>

On 14 Feb 2020, at 15:02, Armin Schindler wrote:
> On 2/14/20 2:23 PM, Tobias Kirchhofer wrote:
>> On 14 Feb 2020, at 14:05, Armin Schindler wrote:
>>
>>> On 2/14/20 11:44 AM, Tobias Kirchhofer wrote:
>>>> On 14 Feb 2020, at 11:06, Armin Schindler wrote:
>>>>
>>>> ??? Hello!
>>
>> [?]
>>
>>>> For our new setup (planned with CentOS 8, waiting for the
official
>>>> repo for the latest dovecot
>>>> version?) we have a prototype on Debian base with the latest 
>>>> version of Dovecot. In opposite to our
>>>> current solution we will implement global acls with user and
groups
>>>> from LDAP. This is very nice.
>>>
>>> Wow, thanks. This seem to be exactly what I need to go on.
>>> Our base system is a Univention UCS, so LDAP users and groups is 
>>> what we already have working :-)
>>>
>>> With your elements I think we really could have the cyrus shared 
>>> folders with dovecot by
>>> using a namespace of
>>> ?type=public
>>> but with
>>> ?prefix=shared/
>>> (we might use type=shared with prefix=usershared/ later).
>>
>> There is not something like one way do to this. You could also make 
>> your life easier and choose to
>> create a ?Share user? which is only there to share folders. This 
>> will then be Dovecot ?Shared
>> folders? shared by this pseudo user to other users. You then could 
>> use Roundcube or such to maintain
>> acl with this pseudo user. But we did not follow this path then for 
>> reasons i cannot remember
>> anymore :)
>>
>> For each Public folder we have a defined namespace. ?Newsletter?, 
>> ?Client1?, ?Client2? etc. We have
>> many, around 30 or so. ACL goes on this namespace (namespace/*). I 
>> guess ACL are first match. Each
>> namespace has its own prefix. (eq. prefix = Newsletter/, prefix = 
>> Client1 etc.) User can subscribe
>> namespace by namespace acl assumed.
>
> What is the benefit using own namespace for each public folder?
> If the config is equal for all folders, wouldn't one namespace with 
> subfolders
> be the same?
> One public namespace would look like it is with cyrus in the client: 
> one "shared/"
> folder to open/close.
Yes, this was a misunderstanding - we have a lot of subfolders per 
namespace. The subfolders have ACLs.


-- 
collect at shift.agency