From 49c8dbf47e46e3f7c50220f94a7ff1adf5f1349c Mon Sep 17 00:00:00 2001 From: Mechiel Lukkien Date: Sat, 10 Feb 2024 11:39:31 +0100 Subject: [PATCH] add FAQ about directly accessing mailboxes through the file system commonly asked, again at fosdem. --- README.md | 38 ++++++++++++++++++++++++++++++++++++++ website/features/index.md | 2 +- 2 files changed, 39 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 49124be..95f1e6a 100644 --- a/README.md +++ b/README.md @@ -449,3 +449,41 @@ disable MTA-STS, autoconfig and the client-settings-domain for that domain. Mox opens the key and certificate files during initial startup, as root (and passes file descriptors to the unprivileged process). No special permissions are needed on the key and certificate files. + +## Can I directly access mailboxes through the file system? + +No, mox only provides access to email through protocols like IMAP. + +While it can be convenient for users/email clients to access email through +conventions like Maildir, providing such access puts quite a burden on the +server: The server has to continuously watch for changes made to the mail store +by external programs, and sync its internal state. By only providing access to +emails through mox, the storage/state management is simpler and easier to +implement reliably. + +Not providing direct file system access also allows future improvements in the +storage mechanism. Such as encryption of all stored messages. Programs won't be +able to access such messages directly. + +Mox stores metadata about delivered messages in its per-account message index +database, more than fits in a simple (filename-based) format like Maildir. The +IP address of the remote SMTP server during delivery, SPF/DKIM/DMARC domains +and validation status, and more... + +For efficiency, mox doesn't prepend message headers generated during delivery +(e.g. Authentication-Results) to the on-disk message file, but only stores it +in the database. This prevents a rewrite of the entire message file. When +reading a message, mox combines the prepended headers from the database with +the message file. + +Mox user accounts have no relation to operating system user accounts. Multiple +system users reading their email on a single machine is not very common +anymore. All data (for all accounts) stored by mox is accessible only by the +mox process. Messages are currently stored as individual files in standard +Internet Message Format (IMF), at `data/accounts//msg//`: +`msgid` is a consecutive unique integer id assigned by the per-account message +index database; `dir` groups 8k consecutive message ids into a directory, +ensuring they don't become too large. The message index database file for an +account is at `data/accounts//index.db`, accessed with the bstore +database library, which uses bbolt (formerly BoltDB) for storage, a +transactional key/value library/file format inspired by LMDB. diff --git a/website/features/index.md b/website/features/index.md index 2d9d9c5..fd0f3d3 100644 --- a/website/features/index.md +++ b/website/features/index.md @@ -120,7 +120,7 @@ These are published in DNS and must also be protected with DNSSEC. If a connection is intercepted by a different server, the TLS certificate validation would not pass. -MTA-STS uses PKIX (pool of trusted Certificate Authorities (CAs))to protect +MTA-STS uses PKIX (pool of trusted Certificate Authorities (CAs)) to protect both MX records and to verify TLS during SMTP STARTTLS. MTA-STS serves existence/version of a policy at DNS record `_mta-sts.`, and the policy itself at the PKIX-verified `https://mta-sts.`,