Kolab policy with alias domains

[Daniel Hoffend]

Hi
>On setup kolab I have been changing the default domain prompt from 
>mysubdomain.mypublicdomain to mypublicdomain.
>The next prompt its the root DN
>Because I just changed the domain to mypublicdomain the default prompt 
>is
>dc=mypublicdomain which I change to dc=mysubdomain,dc=mypublicdomain.
>So I end up with an ldap directory structure that is a subdomain but 
>the email address is my public domain address.
I don't see many issues with this. As long as the domains you're using 
are added as associatedInetDomain (aka alias domain)
then the ldap domain searches should be able to identify your domain and 
root dn.


>Also when it comes to aliases then alias domains are important maybe 
>some users might want to be able to send and recieve from different 
>email addresses.
This is valid and works out of the box if you use the correct attributes 
(mail and alias, not mailAlternativeAddress)

>Also with aliases such as info@, sales@ it might just be an alias or 
>group alias.
For such generic use cases you've different ways on how to make use of 
it
1) Single user account
* add aliases to your liking
* add additional persons as delegates to this account == others can send 
on behalf of this user (all email addys)
* (optional) allow others to view the inbox or a special folder (via 
roundcube > folders > managesieve)

2) Shared Mail Folder
* Create a shared mailbox
* add email address and aliasses
* add delegates (who're allowed to send on behalf)
* add IMAP ACLs to allow others to access this shared mailfolder

>This is just opinion but I have being try to work out what use the 
>current secondary automatically created email aliases are for. Even if 
>I delete them before I submit a new user they still end up being 
>created.
primary_mail and secondary_mail are auto generated by the 
receiption_policy. If you dislike the policy feel free to remove those 
options in the kolab.conf file and either make all fields writeable 
(kolab_admin_rw) or adjust the user_type "Kolab User" and switch mail 
from "generated (protected)" to "normal"

https://docs.kolab.org/administrator-guide/configuring-the-kolab-server.html#recipient-policy

>I have been totally puzzled by them as I can't think of any rationale 
>reason for automatically generated email aliases based on user name.
This may not make sense for a small installation or an installation that 
is being migrated, but bigger installation and companies may have a 
naming policy in place or user email addresses. If you don't like it, 
don't use it :-) I personally have it turned of as well, but this is 
everyones choice.

>Domain aliases or group aliases yeah I can understand, aliases that the 
>user wants specifically I can understand. I have been puzzled and if 
>someone can forward a rationale usage I would be interested as I say 
>they have puzzled me.
# Domains and Domain Aliases:

Lets give them a different name: "Kolab Instance and assigned domains" 
One Kolab Instance (named by the primary domain) is one LDAP Directory 
where users, groups, resources and more are managed. Usually the members 
of this Instance can see each other in the ldap directory (global 
addressbook if enabled). This Kolab instance can have additional domains 
that users of this instance or company or organization might wanna use.

If you create an additional domain (or instance in my speech), this 
would be a 2nd separated instance with it's own ldap directory, acl, 
resources, people, etc. This is ideal if you want to host multiple small 
organizations on one kolab server/installation and you want them to be 
separate or give them admin access (via kolab-admin role) to manage 
their users, groups, resources them self.

Keep in mind that if you want to run multiple kolab 
domains/instances/whatever on a single server that you need some special 
configuration (aka the Multi Domain Howto) and maybe have some 
experience with ldap, postfix and such.

# Users and Alias

A user has 3 different attributes that can provide mail addresses
* mail: this is the primary mail address belonging to the user
* alias: these are secondary mail addresses where the user can 
send+receives mails
* mailAlternativeAddress: those fields can contain external mail 
addresses that the user has access to but are not linked or used within 
kolab. Think about adding your gmail address to your ldap user account 
which other people within the organisation can see via the ldap global 
addressbook.

# Groups

* Kolab Distribution Group (dynamic): This is ldap-search-based 
usergroup. Example: All Users of a company. Usually this kind of list 
wants to be protected via kolaballowsmtpsender so only X personal are 
allowed to send messages to the whole company
* Kolab Distribution Group (static): Just a simple group with a mail 
address. mails received will be send to all users belonging to this 
group.

Most things are described in the Kolab Documentation at 
http://docs.kolab.org (mostly)

Did I missed something?

--
Regards
Daniel Hoffend
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5714 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/users/attachments/20140902/6cd9fd84/attachment.bin>