Between parent and alias domain name spaces, the validation routines for recipient email addresses obtain the operating domain, and all other domains it can find, to subsequently examine whether the parent domain name space of the recipient email domain name space holds the desired recipient email domain name space in one of the values for the domain name attribute.
This functions for a domain name space like so:
dn: associateddomain=example.org,cn=kolab,cn=config associateddomain: example.org associateddomain: example.com
Where operating against either the example.org or example.com (factually the example.org domain name space) domain name space will allow recipient addresses in both the example.org and example.com domain name spaces.
In a hosted scenario however, a provider will need to be able to allow the customer to verify ownership of additional domain name spaces. This builds the use-case for child domain name spaces:
dn: associateddomain=example.org,cn=kolab,cn=config associateddomain: example.org inetdomainbasedn: ou=example.org,dc=hosted,dc=domain dn: associateddomain=example.com,cn=kolab,cn=config associateddomain: example.com inetdomainbasedn: ou=example.org,dc=hosted,dc=domain
Validation therefore requires the association of the example.com domain name space with the (original parent) domain name space of example.org, so that both domain name spaces can be used for recipient email addresses without having to specifically select an operating domain first. Note that a single user firstname.lastname@example.org may in fact also hold aliases in example.com, and as such choosing an operating domain first is an invalid path.