From 3fef299dea6bb8fe0474dee5b7feb51f2da81157 Mon Sep 17 00:00:00 2001 From: selfhoster1312 Date: Mon, 21 Sep 2026 17:13:38 +0200 Subject: [PATCH] docs: Start design for aliases --- README.md | 15 ++++++++++++++ docs/aliases.md | 55 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 70 insertions(+) create mode 100644 docs/aliases.md diff --git a/README.md b/README.md index 51b8f76..17f4974 100644 --- a/README.md +++ b/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: diff --git a/docs/aliases.md b/docs/aliases.md new file mode 100644 index 0000000..f3db496 --- /dev/null +++ b/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