Vanity Domains

Vanity domains are a mechanism that allows addresses in some domain to be associated with one or more user entries without requiring a domain entry in the LDAP directory.

The actual mechanism is quite simple. The following attributes are all that&#x27;s needed to attach an address in a vanity domain to a user entry: msgVanityDomain: vanity.com mailAlternateAddress: user@vanity.com Once this is done mail may be sent to user@vanity.com and it will go to this user, assuming of course that the necessary DNS entries for vanity.com have been made. Note that vanity domains are specific to MTA address handling and cannot be used for authentication or other purposes.

Catchall handling is also possible for vanity domains, that is, any address that doesn&#x27;t explicitly match will be routed to a given user. This is done by adding a specially formatted mailAlternateAddress attribute value to the user entry: mailAlternateAddress: @vanity.com Support for vanity domains is not enabled by default; the MTA&#x27;s configuration has to be modified for this to work. First, the  MTA option has to be set to the value: ldap:///$B?msgVanityDomain?sub?(msgVanityDomain=$D) Second, one ore more additional alias resolution operations are required. Assuming the  MTA option is set to the normal setting of      ldap:///$V?&#x2a;?sub?$R The  NTA option needs to be set to: ldap:///$B?&#x2a;?sub?(&(msgVanityDomain=$D)$R) Third, if catchall support for vanity domains is desired  also needs to be set: ldap:///$1V?&#x2a;?sub?(mailAlternateAddress=@$D) The order in which these lookups are done is very important. Vanity domain address lookups have to be done after other address lookups have been tried and failed and of course the catchall lookup has to be done after trying to find the specific address. Performing the lookups in the wrong order may create a security hole where vanity domain attributes may be used to interfere with the proper functioning of hosted domains.

Note that despite the user of a mailAlternateAddress atribute, vanity domain addresses in message headers are not rewritten to the value of the user&#x27;s mail LDAP attribute.

Vanity domains are a lot easier to set up than a hosted domain. However, this simplicity is actually a weakness: The lack of a separate domain entry makes it impossible to associate domain-level attributes with a vanity domain. (Domain-level attributes for user entries located via a vanity domain are instead taken from the canonical domain for the user entry.)

There is no support for vanity domains in Messaging Server&#x27;s administrative tools. Even worse, they are essentially incompatible with delegated administrative models. In order to see why this is so, suppose coke.com and pepsi.com were set up as vanity domains on a single system. If the administrators for coke.com are allowed to change the attributes in their entries there is nothing to stop them from adding a msgVanityDomain attribute value of pepsi.com and a mailAlternateAddress for a pepsi.com address to one of their entries. If the pepsi.com address was already attached to a pepsi.com user entry it would become ambiguous and could no longer receive mail. Alternately, if the specific address did not exist elsewhere coke.com would now have control over a valid pepsi.com address, with all that implies.

Of course LDAP access controls can be used to block such tricks, but such setups are likely to be fragile and some functionality may be lost. This is in sharp contrast to hosted domains, where the ability of one domain&#x27;s user entries to affect anothers is easily minimized by having their respective user entries in disjoint locations in LDAP.

Since vanity domains do not employ separate domain entries information about them cannot be cached as part of normal domain lookups and processing. However, the MTA has its own caching layer on top of domain lookups (controlled by the  and   MTA options) that that prevents this from being a problem. Since vanity domain address lookup is handled by normal alias processing the same alias caches for user entries also serve to cache user entries accessed through vanity domain addresses. Vanity domains are therefore reasonably scalable as far as the MTA is concerned. However, having vast numbers of either vanity domains or hosted domains may present other infrastructure issues, such as requiring additional DNS server capacity and redundancy.