The following components are in place:

• The Web Administration Panel can be configured to allow a list of aliases to be limited to, say, 10 entries at most.
• The Web Administration Panel can also be configured to apply either of the following policies for validation:
  • none, meaning no validation is applied,
  • default, meaning that the domain name space is validated,
  • extended, meaning that the recipient email address(es) must be globally unique.
• PyKolab already encrypts the authenticated username in to the X-Authenticated-As header.

Autonomous control still leaves a possibility for abuse (through quickly cycling through large numbers of alias addresses), and we have no reasonable audit trail allowing us to track which alias belonged to which customer account at which time.

Currently, the local part is globally unique (for all hoster-owned public domains). Extended validation would only enforce the recipient address be globally unique, such that john@example.org could be registered by jane@example.de even if john@example.de were already in use. Since most email client software does not display the email address, but only the display name, and the two addresses are so similar, it can reasonably be argued that even a quick glance at the actual email address might misplace trust in the original sender. It is therefore argued that a registrant john@ block all other john@ recipient addresses from being registered.

In contrast it has been argued that while john@example.de and john@example.org would be considered "too similar", john@somewhere.co.uk would not and should be open for business. This would require a comparison routine beyond the current capabilities of the Web Administration Panel and not lightly achievable compared to the previous option.