5.0 KiB
Multi Seal Mail - Current System and Tenant Governance Model
Updated: 2026-06-16
Current migration head: f5a6b7c8d9e0
Governance Rule
System policy is authoritative for tenants and all lower levels. Each lower level may only narrow what it inherits:
system
-> tenant
-> user or group owner
-> campaign
Lower levels do not widen privileges, allowed profiles, retention durations or credential rights granted by a higher level.
Administration Structure
SYSTEM
- Settings
- Retention
- Mail servers
- Tenants
- Users
- Groups
- System roles
- Tenant roles
- Audit
TENANT
- Settings boundary
- Users
- Groups
- Roles
- API keys
- Mail servers
- Retention
- Audit
USER
- User mail
- User retention
GROUP
- Group mail
- Group retention
There is no separate System access page. Compatibility access scopes remain in the backend for assignment/read boundaries.
Tenant Governance
System settings define tenant defaults and whether tenants may narrow selected options. Tenant overrides can only restrict:
- custom groups;
- custom roles;
- tenant API keys.
The backend enforces that tenant governance cannot widen system-denied privileges.
Mail-Profile Governance
Mail server profiles may exist at these scopes:
system
tenant
user
group
campaign
Effective campaign profile availability follows campaign ownership. A campaign owned by a user resolves through system, tenant, that user and campaign policy. A group-owned campaign resolves through system, tenant, that group and campaign policy.
Policy semantics:
- higher levels define the maximum available profile set;
- lower levels can further restrict the set;
- forced profiles mean the lower level must choose from the forced set;
- a forced set with one profile effectively enforces that profile;
- campaign-level profile creation is allowed only if the effective policy permits it;
- credentials may be inherited from the authoritative profile or supplied by a lower level only when override is allowed;
- deny patterns always win over allow patterns;
- empty or
*allowlist means allow all except denied; - non-empty allowlist means at least one allow rule must match and no deny rule may match.
Pattern targets:
SMTP hostname
IMAP hostname
envelope sender
From header
recipient domains
Ownership transfer is intentionally deferred as a two-step workflow: original owner initiates, new owner accepts and reselects/repairs the mail profile if their effective policy requires it.
Retention Governance
Retention policy is hierarchical:
system -> tenant -> user/group -> campaign
Managed fields:
- raw campaign JSON retention days;
- generated EML retention days;
- stored report detail retention days;
- mock mailbox retention days;
- audit detail retention days.
Rules:
- system may set concrete defaults or unlimited retention;
- system exposes allow-limiting toggles per field;
- tenants, users/groups and campaigns may only shorten inherited retention where the parent allows limiting;
- blank lower-level values inherit;
- mock mailbox retention is currently system-level because mock mailbox records do not yet carry tenant/campaign ownership metadata;
- dry-run/apply retention actions report affected classes before destructive cleanup.
Role Definitions and Assignments
System roles
System roles define instance-wide permissions. system:* is stored as one wildcard and displayed as granting the full system catalogue. System owner is protected.
Tenant roles
Tenant roles can be system-governed templates or tenant-local definitions, subject to system tenant-governance settings and actor delegation ceilings. Wildcard counts are expanded against the canonical tenant catalogue.
Audit Access
Audit access remains scope-separated:
system audit -> system:audit:read
tenant audit -> active tenant + audit:read
Audit pages use server pagination, filtering and bounded grids.
Tenant Switching
Tenant switching preserves the current URL when possible and falls back when a route/resource is not accessible in the new tenant context.
The tenant selector is hidden for ordinary single-tenant accounts and visible for multi-tenant or system tenant-management contexts.
DataGrid Contract in Administration
Admin lists use bounded container grids:
- one flexible fill column;
- fixed total table width;
- compact action/status/count columns;
- resizable text/date columns;
- no intrinsic content growth;
- sticky headers where needed;
- server pagination for audit.
Still Deferred
- real SMTP/IMAP test-bed verification and operator runbook;
- recipient import with column mapping;
- Seafile/external connector governance;
- system/tenant/group/user file-space hierarchy and external storage hierarchy;
- session/device revocation UI;
- backup/restore, monitoring and update procedures;
- DSAR workflows and evidence bundle verifier;
- campaign ownership transfer workflow;
- policy impact analysis before delete/disable/unshare/change;
- LDAP/OIDC/SAML provisioning;
- destructive tenant erasure orchestration.