docs: Start design for aliases

README.md

@@ -20,6 +20,21 @@ Compared to lldap, llldap:
 - supports mailalias with multiple values in search queries
 - support listening on unix domain sockets (UDS) out-of-the-box
 
+## Design
+
+> [!IMPORTANT]
+> Most of these design decisions have not been implemented yet.
+
+- different users can have the same username across different domains, so `foo@bar.com` is not the same
+  user as `foo@baz.com`
+- service accounts are separated from normal user accounts, and do not have an associated domain;
+  they allow 3rd-party programs to connect via LDAP with special sets of permissions
+- service groups are separated from normal user groups, and do not have an associated domain;
+  they are meant to store permissions (eg. `admins`, or `mail`)
+- aliases are supported, but remain associated with a user account forever ([more details](docs/aliases.md))
+- TODO: should users be able to create custom groups/aliases? that sounds useful, but may need monitoring
+  to prevent accidental/malicious abuse (such as registering `comptabilité@` or `legalteam@`)
+
 ## Potential future features
 
 We may explore in the future:

docs/aliases.md

@@ -0,0 +1,55 @@
+# 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