Kolab policy with alias domains

Wed Sep 3 15:24:40 CEST 2014

Hi Stuart

I really recommend read the docs over and over :-) some parts are just
hidden or just mentioned in little sentences, I know. Maybe the 
documentation
can be extended, but it's a group/community effort. Everyone is invited.

Regards
Daniel

------ Originalnachricht ------
Von: "Stuart Naylor" <StuartIanNaylor at inbox.com>
An: "Daniel Hoffend" <dh at dotlan.net>
Gesendet: 03.09.2014 05:24:17
Betreff: Re: Kolab policy with alias domains

>Many thanks Daniel.
>
>
>
>Don't think you missed anything.
>
>
>
>I made a boob and changed the Mail to normal.
>
>Then released I should of changed Alias to normal.
>
>
>
>Now I can't remember the mail auto gen fields, doesn't matter as its 
>just a VM and I know what to do.
>
>I don't really mind the autogen on the primary just felt the 
>secondaries where a little pointless for my scope and just messy in my 
>scenario.
>
>
>
>Is there anyway that you can edit on new but its RO after submit?
>
>
>
>I tried changing the settings with 3.2 and all went very wrong but all 
>seems fine in 3.3.
>
>
>
>Still evaluating Kolab, well actually I know I will use it. I should 
>say I am still getting to grips with kolab before I install in 
>production.
>
>
>
>So apols for the silly questions.
>
>
>
>Stuart.
>
>
>
>
>
>
>
>
>
>On Tuesday 02 September 2014 22:32:22 Daniel Hoffend wrote:
>
> > 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 <http://docs.kolab.org/> (mostly)
>
> >
>
> > Did I missed something?
>
> >
>
> > --
>
> > Regards
>
> > Daniel Hoffend
>
>--------------------------------------------------------------------------------
><http://mysecurelogon.com/password-manager>
-------------- 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/20140903/7cbe6f47/attachment-0001.bin>