Page MenuHomekolab.org

Hosted Kolab: Autonomous Alias Management
Closed, ResolvedPublic

Description

Users of a Hosted Kolab Environment should be able to create and delete email aliases directly in #HKCCP. This should work for individual users on publicly available domains and for group manager accounts within their own domain including domain aliases.

Details

Ticket Type
Epic

Event Timeline

grote created this task.Apr 20 2015, 3:38 AM
grote updated the task description. (Show Details)
grote raised the priority of this task from to 60.
grote changed Ticket Type from Task to Epic.
grote added a subscriber: grote.
grote moved this task from Incoming to In Triage on the Product Owners board.Apr 20 2015, 3:45 AM

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.

grote raised the priority of this task from 60 to High.Jul 8 2015, 1:58 PM
vanmeeuwen closed this task as Resolved.Nov 25 2015, 3:14 PM
vanmeeuwen claimed this task.