55 lines
2.6 KiB
Markdown
55 lines
2.6 KiB
Markdown
# Aliases
|
|
|
|
> [!WARNING]
|
|
> This is a design document and does not necessarily reflect the current state
|
|
> of the implementation.
|
|
|
|
[Mail aliases](https://en.wikipedia.org/wiki/Email_alias) 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
|