Secure

#Security model

Alt8Mail separates three trust boundaries:

Each plane has its own session cookie, CSRF token, rate limits and authorization checks. A tenant administrator cannot manage the mail stack through the customer admin console. A System Control session is not accepted by webmail or the tenant admin API.

System Control runs with root-equivalent authority and listens on port 8808 outside the nginx proxy. Restrict it to a management network or VPN. The installer opens the port; the operator is responsible for closing it to the public internet.

#Authentication and sessions

• Webmail passwords use Argon2id. Mailbox credentials use a separate Dovecot {SHA512-CRYPT} hash, rotated when the web password changes.
• Webmail and customer admin sessions are opaque PostgreSQL records. The browser receives a random token; the database stores only its hash.
• Cookies are HttpOnly for the session and require a CSRF header on state-changing requests. Admin and webmail cookies are separate.
• System Control uses its own SameSite=Strict cookie and CSRF header, and a separate account/role system.
• Login throttling is applied per client IP. The exact window and limit should be reviewed against your operational environment.
• Cookies must be marked Secure in production. Set the application environment and reverse-proxy trust correctly.
• Changing a public hostname changes the WebAuthn relying-party identity and invalidates existing webmail passkeys.

#MFA and recovery

The customer admin console does not support WebAuthn/passkeys. If a policy requires MFA and an admin has only a passkey, that admin must add an authenticator app.

Tenant policy can enforce MFA for administrators or all users. Enrolment is part of the security baseline for any internet-facing deployment.

#Roles and authorization

Tenant users have an owner, admin, member or readonly role. Owners and admins have full tenant administration. Additional tenant roles can be scoped from a server-enforced permission catalog, including user, group, domain, policy, audit, legal, encryption, API, webhook and CRM permissions. The last active owner cannot be removed or demoted by ordinary admin changes.

System Control has its own roles: superadmin, admin, operator and readonly, with custom permission groups. Only a superadmin can create another superadmin or grant the most privileged access. At least one active superadmin must remain.

Treat the following as privileged:

• customer-admin custom role administration;
• System Control access and API keys;
• the root-equivalent Control terminal;
• mail import and backup/restore;
• legal hold, eDiscovery and audit export;
• license and update operations.

#SSO, SAML and SCIM

These capabilities are paid and configured at the environment level, not per tenant through System Control.

#OIDC

• Authorization-code flow with PKCE, state and nonce validation.
• Issuer, audience, signature, expiry and nonce checks.
• Exact email-domain allowlists are optional; there is no just-in-time provisioning or account linking.
• The email must match an existing active user in an active tenant.
• IdP-initiated login is not supported.

#SAML 2.0

• SP-initiated only; unsigned assertions are rejected.
• AuthnRequests and assertions are signed; SAML metadata is cached for the process lifetime, so restart after IdP key or endpoint rotation.
• No JIT provisioning, profile mutation, IdP-initiated login or single logout.
• The SAML replay cache is in-process and bounded; restarting clears it. This is not a shared persistent replay store.
• The current SAML dependency has an allowlisted advisory with no fixed upstream release. Treat SAML as an evaluated capability, not a risk-free checkbox.

#SCIM 2.0

• Paid subset for Users and Groups.
• Bearer tokens are shown once and stored as hashes.
• Supports equality filters and paging up to 500.
• No bulk, sorting, ETag/If-Match, password sync, JIT, /Me or enterprise-user extension.
• Group-to-role mapping is local and cannot grant or remove owner.

SSO, SAML and SCIM create and authenticate webmail access only. The customer admin and System Control have no external IdP federation.

#Mail security

#Domain authentication

A sender domain is mail-ready only when the customer admin verification checks pass:

• ownership TXT;
• MX pointing to the mail hostname;
• SPF;
• exact DKIM public-key match;
• DMARC policy.

Outbound send is gated on those checks. A previously verified domain is not silently downgraded, but mailReady can become false after a later DNS failure. Fix DNS rather than bypassing the gate.

#Inbound and outbound controls

• Postfix, Dovecot and Rspamd provide the SMTP, mailbox and filtering path.
• Rspamd inspects inbound and outbound mail; ClamAV scans attachments and messages.
• A local-domain anti-spoofing rule rejects unauthenticated mail claiming to be from a hosted domain.
• The webmail trust panel consumes the message's Authentication-Results; it is not an independent cryptographic verifier.
• Outbound recipient caps are enforced by a Postfix policy daemon and the webmail path. The default is 200 recipients per mailbox per rolling 24 hours.
• Remote images are proxied, and Junk mail can block images and attachments.
• MTA-STS can be published in testing or enforce mode. Its validation needs a trusted certificate for the policy host.
• Domain verification proves control of DNS and alignment; it does not guarantee inbox placement or sender reputation.

#TLS

• nginx supports TLS 1.2 and 1.3 with HSTS.
• Postfix, Dovecot and System Control require TLS 1.2 or later.
• Let's Encrypt is the default automatic path. Renewal must be monitored; the installer's fallback self-signed certificate is not a production substitute.
• System Control starts with a bootstrap certificate. Replace it before remote use.

#Data protection, DLP and retention

DLP labels are Public, Internal, Confidential and Restricted. Rules can scan subject, body and attachment names. Detectors include terms, dictionaries, regex, credit-card Luhn checks, IBAN mod-97 and national-ID patterns. Actions are label, warn or block.

Important boundaries:

• DLP does not scan attachment bytes or OCR content by default. Office XML text can be extracted for some formats, but PDF and image content is not a complete DLP surface.
• AI draft replies are checked against DLP; a policy can still block or warn.
• Retention is opt-in and global/classification-based; per-folder retention is not available.
• Legal hold blocks deletion and retention for the held scope. Do not work around a hold to solve an operational problem.
• eDiscovery searches synchronized mail rows, not unindexed raw Maildir files.
• BYOK can seal tenant secrets and Office/Cabinet blobs, but mail rows and search vectors remain plaintext in PostgreSQL. Use encrypted volumes or database encryption at rest.
• There is no S/MIME, OpenPGP or end-to-end encryption. TLS protects transit, not mailbox contents from the server.

The secure-at-rest baseline is therefore infrastructure-level disk/database encryption, restricted host access, protected backups and tested key ownership.

#Audit and SIEM

The product maintains separate audit stores for webmail user activity, customer admin activity and System Control. Audit entries can be exported as CSV and, with the audit_export entitlement, delivered to a signed SIEM webhook.

• SIEM endpoints must be public HTTPS on port 443 with no credentials or fragments; redirects and private targets are rejected.
• Payloads are HMAC-SHA256 signed and delivery failures are recorded and retried.
• Signed audit bundles include a content SHA-256 and HMAC signature. Verify both before ingest.
• Audit logs are not WORM/immutable and do not have a universal retention guarantee in the current implementation. Export or forward them for evidentiary retention.
• System Control /metrics is unauthenticated and port 8808 is root-equivalent. Restrict the network edge; do not expose it to the internet.

#Hardening checklist

Complete these before production:

1. Restrict port 8808 to a VPN or management CIDR at the provider firewall.
2. Replace self-signed certificates with trusted certificates and verify renewal.
3. Require MFA for tenant administrators and host operators.
4. Change the bootstrap passwords immediately and remove one-time credential files.
5. Apply the supplied SSH hardening profile after confirming key access.
6. Use least-privilege tenant and System Control roles.
7. Disable unused IMAP, POP3, SMTP, ManageSieve, connected-account and external-sharing paths.
8. Configure password, session, forwarding, attachment and retention policy deliberately.
9. Publish and monitor SPF, DKIM, DMARC, MX, PTR and MTA-STS.
10. Restrict outbound recipient and domain caps.
11. Encrypt backups and copy them off-host; test a restore.
12. Forward audit logs to a separate system where required.
13. Monitor health, queue, disk, certificates and service restarts.
14. Run alt8mail-control doctor and Config sync regularly.
15. Review add-ons, API keys, webhooks, active sessions and delegated access quarterly.

#Incident response

1. Preserve logs and audit exports before restarting services.
2. Contain the affected plane: revoke sessions and API keys, disable a compromised user, block a sender, or restrict a network path.
3. Do not delete a mailbox or a legal-hold record to "clean up" an incident.
4. Rotate secrets through the supported surface; do not edit sealed values in the database by hand.
5. Use the documented backup/restore path if data integrity is in question.
6. For a vulnerability in Alt8Mail itself, follow the repository security policy rather than posting exploit details publicly: security policy.

#Boundaries and claims

• No SOC 2, ISO 27001, HIPAA, FedRAMP, PCI DSS or WCAG certification is claimed or implied.
• The product is not guaranteed to be free of security defects. The source includes an allowlisted dependency advisory and documented pre-production gates.
• The external assessment recorded in the repository is an assessment, not a certification.
• No WAL/PITR, off-site backup replication, high availability or cross-installation restore is provided.
• No end-to-end encryption, S/MIME or OpenPGP is provided.
• Data residency is enforced only for the S3 upload region where implemented; it is not a general residency guarantee for local storage.
• System Control's terminal and service are root-equivalent. Treat access as equivalent to root on the host.

If a security control is not evidenced on this page, do not assume it exists. Ask the operator or the project maintainers for the current evidence.