Glossary

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.

See also

assets

Assets are static contents (…)

authorization realm

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 null.

After user login name canonification – a process to translate an authentication ID in to an authorization ID – the resulting authorization ID may have become john.doe@example.org.

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 john.doe@example.org will result in the session using user/john.doe@example.org as 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 @example.org.

canonification

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 <doe@example.org> has a primary email address of doe@example.org, and a user ID of doe. Suppose therefore his mailbox is user/doe@example.org, and his authorization ID is doe@example.org.

When John logs in however, he may also use one of his secondary recipient addresses, such as john.doe@example.org or jdoe@example.org.

This login username needs to be translated to doe@example.org in 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 inetDomainStatus to track the confirmation and activation status of domainRelatedObject entries, 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.

See also

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.

See also

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.

DN
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 uid=doe,ou=People,dc=example,dc=org.

See also

domain_filter

The domain_filter (…)

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 customer1.example.org and/or family2.example.org.

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.

See also

domain_base_dn

The domain base dn is the position in a Directory Information Tree’s hierarchy at which to start searching for domain name spaces.

See also

domain_name_attribute

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 domainrelatedobject.

The associateddomain attribute 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
domain_result_attribute

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.org is 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 example.org become dc=example,dc=org.

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.org may have a dn of o=example,c=de.

dn: associateddomain=example.org,cn=kolab,cn=config
objectclass: top
objectclass: domainrelatedobject
objectclass: inetdomain
associateddomain: example.org
inetdomainbasedn: o=example,c=de
domain_scope

The domain scope is the level of depth the searches for domain name spaces uses, and is one of base, one or sub.

EPEL

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.

See also

forwarding email address

A forwarding email address (…)

See also

FQDN
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.

See also

made-to-measure

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.

See also

MBTF

Mean time between Failure – a statistical determination of the time between failures.

msa
Mail Submission Agent

The Mail Submission Agent (MSA) (…)

mta
Mail Transfer Agent

The Mail Transfer Agent (MTA) (…)

mua
Mail User Agent

The Mail User Agent (MUA) (…)

mydestination

mydestination is a setting in Postfix, commonly used to refer to a list of domain name spaces that the local MTA is considered the final destination for.

operating system disks

Storage used for the operating system installation.

See also

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 mail is maintained) is within the domain name spaces associated with the parent domain (i.e. an alias domain name space or child domain name space).

partition
partitions

A partition in Cyrus IMAP (…)

pattern

A pattern for mailboxes can be specified using % and * wildcards.

The % 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 user/%@example.org

but to list all user folders in the example.org domain:

# kolab lm user/*@example.org
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 (…)

See also

primary hosted domain

A primary hosted domain is (…)

recipient email address
recipient email addresses

A recipient email address is (…)

See also

recipient policy

The recipient policy (…)

relative distinguished name

A relative distinguished name (…)

relay_domains

(…)

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).

See also

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.

See also

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 john.doe@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_domain and his session would then be associated with the company.com domain – now his working domain.