2.6 KiB
Aliases
Warning
This is a design document and does not necessarily reflect the current state of the implementation.
Mail aliases are supported in llldap, in three forms:
- user aliases are associated with an account, in order to provide more pseudonymity and limit
damage in case of data breach (eg. signup to Google with
mygooglealias@example.com) - group aliases are a simple group with special permission to receive emails; all emails are forwarded to all members, and all members can send mail from the alias
- service aliases are reserved keywords (eg.
abuse) on every domain and forward emails they receive both to domain admins and to global admins
User aliases
Depending on a domain's configuration, a user may or may not create aliases. When a user acquires an alias, it is associated to their account forever.
When deleted, your alias remains as a tombstone preventing another user from acquiring it and receiving your mail. An alias can be recovered (re-enabled) by its owner at any time. Email to a deleted alias just doesn't go anywhere.
TODO: Maybe we'd like domain admins to be able to reclaim tombstones?
Group aliases
A group on a domain may or may not be configured as a mail alias. When it is, all group members can send and
receive mail with the group's address, such as mygroup@example.com.
As a consequence, uid on a domain are unique across users and groups. If there is already a user account
example@example.com, then we cannot create a group example@example.com.
A deleted group remains as a tombstone to prevent leaking future group emails by a new user registering as the group name. Email to a deleted group, or to a group that has disabled email, just doesn't go anywhere.
TODO: Maybe we'd like domain admins to be able to reclaim tombstones?
Service aliases
Some special keywords are reserved for important mail communication: admin, admins, root, hostmaster, postmaster, abuse.
TODO: should contact@ be in this list as well?
The admins group on each domain can be edited by domain admins to add/remove admins for the domain.
All global admins are part of every domain's admins group, and a domain admin cannot remove them.
Others are meta-groups that cannot ever be edited, and refer to the domain's admins group for membership information.
TODO
If we support a group as mailalias, how do we prevent collisions between users and groups?
- User aliases in DB
- Aliases in LDAP search responses
- Domain config to allow/disallow user aliases on domain
- Group setting to enable/disable receiving email to this group