- alias domain¶
- alias domain name space¶
- alias domain name spaces¶
The intended use of an alias domain name space is to be a largely transparent alias domain for users or recipients whom would otherwise have an email address in the parent domain name space as well. In other words, what is a valid local part used with an
@example.org(the parent domain name space) email address is also considered a valid local part when used with an
@example.net(the alias domain name space) email address, for both sending and receiving email messages, and vice-versa.
Whether or not an alias domain name space is actually as transparent depends on the configuration of the result attribute, and subsequently, therefore, also the primary email address of individual recipient entries.
Assets are static contents (…)
The authorization realm is the target user authorization ID’s namespace.
When, for example, a user John Doe logs in with username
doe(the “authentication ID”), the original authorization realm (as specified in the original username) is
After user login name canonification – a process to translate an authentication ID in to an authorization ID – the resulting authorization ID may have become
The canonification process is important, because it will also be the authorization ID that is used to compose the mailbox path to the user’s INBOX.
Continuing our example user, the authorization ID having become
firstname.lastname@example.org result in the session using
email@example.com the INBOX.
The authorization realm at this point is one of
example.org. The user will not be able to access any mailboxes outside this authorization realm, meaning the user will be unable to access any mailboxes for which the mailbox path does not end in
Canonification is the process of translating a login username in to the targeted value to use throughout the rest of the infrastructure.
Suppose, for example, a user John Doe <firstname.lastname@example.org> has a primary email address of email@example.com, and a user ID of doe. Suppose therefore his mailbox is
firstname.lastname@example.org, and his authorization ID is
When John logs in however, he may also use one of his secondary recipient addresses, such as email@example.com or firstname.lastname@example.org.
This login username needs to be translated to
email@example.com order to obtain the correct INBOX, and allow applications to consistently retrieve profiles with user preferences.
- child domain¶
- child domain name space¶
- child domain name spaces¶
A child domain name space is very similar to an alias domain name space, in that a child domain name space is exactly the same, but for one aspect: Hosted Kolab Groupware.
With Kolab Groupware, parent domain name spaces are stored as individual LDAP objects, and so are they in Hosted Kolab Groupware deployments.
In hosted environments, however, any alias domain name spaces needs to be verified the ownership of (just like for the parent domain name space), before the alias domain name space is activated.
When using the LDAP attribute of
inetDomainStatusto track the confirmation and activation status of
domainRelatedObjectentries, alias domain name spaces need to be stored in entirely different LDAP entries altogether, and are solely therefore referred to as child domain name spaces.
- discretionary access control¶
Discretionary access control is a type of access control where a subject with certain permissions on a particular resource is at liberty to control the level of access any other subject have to the given resource.
- disk volume¶
- disk volumes¶
A disk volume is an entity that “can contain a filesystem”. This may be a complete disk, a set of disks, a disk partition, a logical volume, a copy-on-write snapshot, a disk image (file), a fiber-channel or iSCSI LUN, or any other such volume.
- distinguished name¶
The distinguished name is the LDAP terminology for the location of an object in a Directory Information Tree hierarchy.
The LDAP object for a user John Doe might have a distinguished name of
- domain name space¶
- domain name spaces¶
A domain name space is, among other things, the qualification of a recipient’s local-part. It is the domain name appended to the local part of an email address, the two of them divided by an ‘@’ character (sender specified routing notwithstanding).
Without domain name spaces, user ‘john’ would only ever know about user ‘jane’ if – pardon my French to those in the know – if both ‘john’ and ‘jane’ considered eachother local. In other words, if both ‘john’ and ‘jane’ used the same physical system environment. As you may be aware, the Internet is composed of a quite a few thousands of such system environments.
What qualifies users ‘john’ and ‘jane’ to all other users on the Internet is a name space. The name space must be globally unique (literally “globally” – but technically speaking more like “universally unique”).
The only name spaces available to Internet registrars and therefore service providers and therefore users, are called domains – they are composed of a top-level domain (name space) such as .org and .com, and a name that a service provider would allow you to register with the Internet registrar (a NIC) - each domain is therefore at least one but possible more domain name spaces.
To further illustrate, you require an Internet registrar to obtain your own domain name – unless you are an Internet registrar yourself, of course, though you still need one, but it just so happens you are one.
Once you have registered a domain name (and, contrary to popular belief, you don’t actually own it, ever) nothing prevents you from creating additional domain name spaces within the name space of that domain.
You could, for example, register
example.org, and create a domain name space of
In fact, every fully qualified domain name is a domain name space in and of its own – but it identifies on the individual system level as opposed to the environment level.
The domain base dn is the position in a Directory Information Tree’s hierarchy at which to start searching for domain name spaces.
The domain name attribute is the name of the attribute that holds the parent domain name space in LDAP.
By default, the domain name attribute is
associateddomain, for an object with object class
associateddomainattribute is specified as multi-valued in the LDAP schema, and as such may contain one or more values.
LDAP stores these in order, so that the first associateddomain attribute value is also the one that was the first to be added.
If you had a domain name space of
example.org, the LDAP object might look as follows:
dn: associateddomain=example.org,cn=kolab,cn=config objectclass: top objectclass: domainrelatedobject associateddomain: example.org
Then, when one or more alias domain name spaces are added for
example.org, the object may look as follows:
dn: associateddomain=example.org,cn=kolab,cn=config objectclass: top objectclass: domainrelatedobject associateddomain: example.org associateddomain: example.nl associateddomain: example.de
The domain result attribute is used to allow the specification of a custom root dn for the Directory Information Tree hierarchy associated with the domain name space.
In a default Kolab Groupware installation, when a domain of
example.orgis added to the environment, a standard translation routine is applied to the domain name space to define the associated Directory Information Tree hierarchy root, the root dn.
This routine makes
Existing environments may already have LDAP available to their systems, which does not necessarily have a standard root dn for the domain. As such, an existing root dn for domain
example.orgmay have a dn of
dn: associateddomain=example.org,cn=kolab,cn=config objectclass: top objectclass: domainrelatedobject objectclass: inetdomain associateddomain: example.org inetdomainbasedn: o=example,c=de
The domain scope is the level of depth the searches for domain name spaces uses, and is one of
EPEL stands for Extra Packages for Enterprise Linux, and is a software repository maintained by the Fedora Project community.
It contains packages that are supplementary to a base RHEL subscription including the optional software repository, such as amavisd-new and clamav.
- event notifications¶
Event notifications (in Cyrus IMAP), lemonade architecture, (…)
- external email address¶
An external email address is intended to be additional user information, and another means of contacting the user, not unlike a street and postal code may be additional, personal information for the user.
- forwarding email address¶
A forwarding email address (…)
- fully qualified domain name¶
A Fully Qualified Domain Name is intended to refer to a single node (or “operating system instance”, if you will) whether it be traditionally physical or virtual, in a manner that is globally (“universally”) unique.
As such, it SHOULD be composed of at least three (3) name space segments divided by a dot (.) character – exluding the implicit top-level dot (.), even if a domain (system environment) is comprised of a single system.
A Made-to-Measure solution is designed to be altered and adjusted to better fit one’s needs.
This is in contrast with so-called Commercial-Off-the-Shelf solutions, which allow for too little modification in the solution itself, or none at all, and require one’s needs to be flexible.
- management domain¶
A management domain is is a domain name space, usually also the primary domain name space that is reserved for managers of a multi-domain deployment. Such managers may include support staff, who could use these LDAP credentials to log in to other services and servers (provided a POSIX account).
- mandatory access control¶
Mandatory access control is a type of access control where a set of (static) rules controlled (centrally) by a security policy administrator describe the level of access subjects to objects. As such, no subject controls the level of access of other subjects.
Mean time between Failure – a statistical determination of the time between failures.
- Mail Submission Agent¶
The Mail Submission Agent (MSA) (…)
- Mail Transfer Agent¶
The Mail Transfer Agent (MTA) (…)
- Mail User Agent¶
The Mail User Agent (MUA) (…)
- operating system disks¶
Storage used for the operating system installation.
- parent domain¶
- parent domain name space¶
- parent domain name spaces¶
A parent domain, or parent domain name space, is a domain entity that corresponds to an isolated directory tree. A parent domain may have additional aliases, all of which will need to resolve back to the directory tree associated with the parent domain.
Kolab components such as the Kolab daemon, the Kolab SMTP Access Policy and the Kolab Web Administration Panel (or actually, its API) make sure that the primary email address (which becomes the authorization realm when the default result attribute configuration value of
A partition in Cyrus IMAP (…)
A pattern for mailboxes can be specified using
%wildcard matches mailboxes on a single level only, while the
*wildcard matches mailboxes in all depth levels.
To list INBOX folders for users in the example.org domain, use:
# kolab lm firstname.lastname@example.org
but to list all user folders in the example.org domain:
# kolab lm email@example.com
- payload disks¶
Storage used for information.
- Perfect Forward Secrecy¶
Perfect Forward Secrecy or PFS (…)
- policy enforcement point¶
A policy enforcement point is a point in an environment or infrastructure, that allows a policy to be enforced.
Such points include a patch-point (including virtualized networking), a communication boundary (gateway, firewall, sending node, receiving node, …), and more.
- primary domain¶
- primary domain name space¶
A primary domain is the first parent domain name space you set up when you first install Kolab Groupware.
In deployments that service multiple (parent) domain name spaces, the primary domain is usually also the management domain.
- primary email address¶
A primary email address (…)
- primary hosted domain¶
A primary hosted domain is (…)
- recipient email address¶
- recipient email addresses¶
A recipient email address is (…)
- recipient policy¶
The recipient policy (…)
- relative distinguished name¶
A relative distinguished name (…)
- result attribute¶
The result attribute is the name of the target attribute to use the value of, when translating a login username to the appropriate value (a process called canonification).
- root dn¶
A root dn describes the path to the root of a Directory Information Tree hierarchy.
It is commonly associated with LDAP databases, in that all entries contained within one root dn are in databases that are separate from the databases used for another root dn.
- sealed system¶
A sealed system is a system where the users have access to the services offered by the system, but not the system itself. In other words, a Kolab Groupware user cannot normally login to a shell on the system and start poking around.
- search base dn¶
The search base dn is the point in an LDAP hierarchy, at which to start searching.
- search scope¶
An LDAP search is executed against a scope, such as base for the search base dn entry itself only, one for all entries one level below the search base dn only, if any, and sub for the entire hierarchy.
- secondary email address¶
A secondary email address is a recipient email address associated with an object, such as a user or a distribution group, but it is not the primary email address.
- staging environments¶
Staging environments (…)
- storage volume level replication¶
Please see the generic section on Redundancy.
- working domain¶
The working domain is the currently selected domain name space to work against in the Kolab Web Administration Panel.
A user logs in to the Web Administration Panel with an initial login username of
firstname.lastname@example.org, but may have privileges to edit users in another parent domain name space such as
company.com. John would issue a
system.select_domainand his session would then be associated with the
company.comdomain – now his working domain.