Shared mailboxes: a second kind of account lock #148
Assignees
jcoffey-dev (John Coffey)
Clear assignees
jcoffey-dev (John Coffey)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: inbuxa/inbuxa-server#148
Reference in new issue
Block a user
A shared mailbox (support@, legal@) belongs to no one person: nobody
signs in to it, and the people assigned open it beside their own mail
at an access level an administrator chose. An account lock already is
most of that: it keeps receiving mail, refuses every sign-in, and its
delegates reach it through real grants on every container (so IMAP,
DAV and JMAP honor them), never including Share. So a shared mailbox is
a lock of a second kind (multi-account spec, MA-S; John, 2026-10-05).
Lock gains kind: "lock" (the default, so stored locks read as before)
or "sharedMailbox", set on create and fixed after. A shared mailbox:
acknowledgement goes out (a lock answers no one);
not AL-9's access and per-change records, which would bury the log
for a busy desk;
addresses, so answers come back to the mailbox and not to whoever
replied; anything else is forbiddenFrom.
The session marks it delegation: {locked: true, kind: "sharedMailbox"},
so a front end that knows no kind still treats it as a lock. The
console's layout gains Management › Directory › Shared Mailboxes
(CustomComponent/SharedMailboxes).
Tests: the account lock suite now goes on to a shared mailbox: made
without a reason with twelve people, sign-in refused, the session's
kind, its vacation reply delivered, an answer sent as it and recorded
as the agent with no per-change records, and a Reply-To naming the
agent refused; a lock unit test reads a stored lock without a kind.
account_lock_tests, jmap_tests, audit_log_tests and imap_tests pass
(RocksDB).
A shared mailbox (support@, legal@) belongs to no one person: nobody signs in to it, and the people assigned open it beside their own mail at an access level an administrator chose. An account lock already is most of that: it keeps receiving mail, refuses every sign-in, and its delegates reach it through real grants on every container (so IMAP, DAV and JMAP honor them), never including Share. So a shared mailbox is a lock of a second kind (multi-account spec, MA-S; John, 2026-10-05). Lock gains kind: "lock" (the default, so stored locks read as before) or "sharedMailbox", set on create and fixed after. A shared mailbox: - needs no reason to make, change or end; - holds up to 100 people, where a lock holds 10; - runs its own Sieve replies and redirects, so an automatic acknowledgement goes out (a lock answers no one); - records only what is sent as it (audit_send_as, which now covers it), not AL-9's access and per-change records, which would bury the log for a busy desk; - sends only as itself (MA-S3): From and Reply-To must be its own addresses, so answers come back to the mailbox and not to whoever replied; anything else is forbiddenFrom. The session marks it delegation: {locked: true, kind: "sharedMailbox"}, so a front end that knows no kind still treats it as a lock. The console's layout gains Management › Directory › Shared Mailboxes (CustomComponent/SharedMailboxes). Tests: the account lock suite now goes on to a shared mailbox: made without a reason with twelve people, sign-in refused, the session's kind, its vacation reply delivered, an answer sent as it and recorded as the agent with no per-change records, and a Reply-To naming the agent refused; a lock unit test reads a stored lock without a kind. account_lock_tests, jmap_tests, audit_log_tests and imap_tests pass (RocksDB).