new website for www.xmox.nl

most content is in markdown files in website/, some is taken out of the repo README and rfc/index.txt. a Go file generates html. static files are kept in a separate repo due to size.
2025-07-12 17:44:35 +03:00 · 2024-01-10 16:48:53 +01:00
parent dda0a4ced1
commit 0bc3072944
37 changed files with 10274 additions and 505 deletions
--- a/website/features/index.md
+++ b/website/features/index.md
@ -0,0 +1,504 @@
+# Features
+
+## Easy to operate
+
+The initial installation should be easy when using the quickstart. It performs
+some DNS checks, generates config files, an initial admin account and an email
+address account, and it prints all the DNS records (quite a few!) you need to
+add for sending and receiving email. It also creates a systemd unit file to run
+mox as a service on Linux, along with commands to enable the server. When run,
+it fixes up file permissions. You normally only have to copy/paste text and run
+the suggested commands.
+
+Upgrades are usually a matter of replacing the binary and restart mox. Mox
+tries hard to not make incompatible changes. After an update you may want to
+change a configuration file to enable new functionality or behaviour.
+
+The [configuration files](../config/) that come annotated with documentation
+make it easy to discover and configure functionality. The web admin interface
+guides you even more in making runtime configuration changes. The web admin
+interface also writes to the runtime configuration file. So you get the power
+of plain files for configuration (for readability, version control/diffs), and
+the ease of a user interface for making changes.
+
+Mox is an all-in-one email server built in a single coherent code base. This
+ensures that all functionality works well together. And that you don't have to
+configure lots of individual components for a fully working system.
+
+
+## SMTP
+
+SMTP is used to deliver and receive email messages on the internet. Email
+clients also use it to ask an SMTP server to deliver messages (called
+submission).
+
+Mox implements:
+
+- An SMTP server to accept deliveries of incoming messages, on port 25.
+- An SMTP client and delivery queue for delivering messages to other mail
+  servers, connecting to other servers on port 25.
+- A "submission" (SMTP) server, so authenticated clients can submit messages to
+  the queue, from which Mox will deliver, with retries.
+- Commonly used SMTP extensions.
+
+## SPF/DKIM/DMARC
+
+SPF, DKIM and DMARC are mechanisms for "message authentication". SPF and DKIM
+can be used to verify that a domain is indeed associated with an incoming
+message. This allows mail servers to keep track of the reputation of a domain,
+which is used during junk filtering.
+
+SPF is a mechanism whereby a domain specifies in a TXT DNS record which IPs are
+allowed to use its domain in an address in the `MAIL FROM` command in an SMTP
+transaction. If a sending IP is not listed, a receiving mail server may reject
+the email as likely being junk. However, the decision to reject isn't made
+solely based on the SPF record, keep reading.
+
+DKIM is a mechanism whereby a domain specifies public keys in DNS TXT records.
+Legitimate messages originating from the domain will have one or more
+`DKIM-Signature` message headers that reference a public key and contain a
+signature. During delivery, the signature is verified.
+
+DMARC is a mechanism whereby a domain specifies a policy in a DNS TXT record
+about what to do messages that are not authenticated with "aligned" SPF and/or
+DKIM. These policies include "reject", or "quarantine" (put in junk mailbox),
+or "none" (don't treat differently).  DMARC authenticates the address in the
+"From" header in an email message, since that is what users will typically look
+at and trust.  For a message to pass the "aligned SPF" check, the SPF-domain
+must match the domain the message "From" header.  For a message to pass the
+"aligned DKIM" check, at least one verified DKIM domain must match the domain
+in the message "From" header.  A non-aligned verified domain is not used for
+DMARC, but can still be useful in junk filtering.
+
+Mox sets up SPF, DKIM and DMARC for your domain, and adds `DKIM-Signature`
+headers to outgoing messages.
+
+For incoming messages, mox will perform SPF, DKIM and DMARC checks. DMARC
+policies of domains are honored by mox, though mox interprets policy
+"quarantine" as "reject": Mox does not claim to accept messages, only to hide
+them away in a junk mailbox. Mox uses reputation of SPF-, DKIM- and
+DMARC(-like) verified domains in its reputation-based junk filtering.
+
+A domain's DMARC policy, as published in DNS records, can request reports about
+DMARC policies as performed by other mail servers. This gives you, as domain
+owner, insights into where both authenticated and non-authenticated messages
+are being sent from. The policy specifies an email address whereto such reports
+should be sent. Mox helps set up a policy to request such reports,
+automatically processes such reports, and provides access through its admin web
+interface. Mox also sends reports with the results of its DMARC evaluations to
+domains that request them.
+
+
+## DANE and MTA-STS
+
+DANE and MTA-STS are mechanisms for more secure email delivery using SMTP.
+
+Originally, SMTP delivered email messages over the internet in plain text.
+Message delivery was vulnerable to eavesdropping/interception.
+
+The SMTP STARTTLS extension added opportunistic TLS: If a server announces
+support, a (delivering) SMTP client can "upgrade" a connection to TLS. This
+prevents passive attackers from eavesdropping. But an active attacker can
+simply strip server support for STARTTLS, causing a message to be transferred
+in plain text. With opportunistic TLS for SMTP, the TLS certificate of a server
+is not verified: Certificates that are expired or for other host names are
+accepted.
+
+Both old-fashioned plain text delivery and STARTTLS don't protect against
+another active attack: Simply modifying DNS MX responses, causing email to be
+delivered to another server entirely. That other server may implement STARTTLS,
+and even have a certificate that can be verified. But the MX records need
+protection as well.
+
+Both DANE and MTA-STS are (different) opt-in mechanisms to protect MX records,
+and for verifying TLS certificates of SMTP servers.
+
+DANE protects MX records by requiring that they are DNSSEC-signed, causing
+changes to DNS records to be detected.  With DANE, TLS certificates of an MX
+host are verified through (hashes of) either public keys or full certificates.
+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
+both MX records and to verify TLS during SMTP STARTTLS. MTA-STS serves
+existence/version of a policy at DNS record `_mta-sts.<recipientdomain>`, and
+the policy itself at the PKIX-verified `https://mta-sts.<recipientdomain>`,
+specifying allowed MX host names.  During delivery, MX targets not in the
+MTA-STS policy are rejected.  The MTA-STS, MX, and MX target IP address DNS
+records are not required to be protected with DNSSEC, and often aren't.  If an
+attacker modifies the IP address of an MTA-STS-allowed MX target, the
+PKIX-verification during SMTP STARTTLS will not pass. MTA-STS policies specify
+how long they should be cached.  Attackers can suppress existence of an MTA-STS
+record during the first communication between mail servers, but not on
+subsequent deliveries.
+
+For delivery of outgoing messages, mox will use both DANE and MTA-STS, if
+configured for a recipient domain. MTA-STS policies are cached and periodically
+refreshed.
+
+Domains hosted by mox are both DANE- and MTA-STS protected by default. However,
+DANE only applies if recipient domains and their MX records are DNSSEC-signed.
+Mox requests certificates with ACME from Let's Encrypt by default, so TLS
+certificates used in SMTP STARTTLS can be PKIX-verified.  Mox also serves
+MTA-STS policies by default.
+
+Mox also implements the REQUIRETLS SMTP extension. It allows message delivery
+to specify that MX DNS records and SMTP server TLS certificates must be
+verified along the full delivery path (not just the next hop), and that
+delivery must be aborted if that cannot be guaranteed.
+
+Mox also implements both incoming and outgoing TLS reporting, with both DANE
+and MTA-STS details. TLS reports have aggregated counts of SMTP connections
+(with failures, including about TLS, and success) and the DANE/MTA-STS policies
+encountered. Domains can request delivery of TLS reports by specifying a report
+destination address in a TLSRPT policy, specified in a DNS TXT record under a
+domain.
+
+
+## IMAP4
+
+Email clients (also called Mail User Agents, MUAs) typically access messages
+through IMAP4. IMAP4 gives access to all mailboxes (folders) in an account, and
+all messages in those mailboxes. IMAP4 is a protocol with a long history, and
+for which many extensions have been specified. IMAP4 can be used for
+efficiently synchronizing an entire account for offline/local use, or used
+reading messages "online" (e.g. with third party webmail software).
+
+Mox implements up to IMAP4rev2, the latest revision of IMAP4 that includes lots
+of functionality that used to be an extension. And mox implements commonly used
+extensions on top of that, such as CONDSTORE and QRESYNC, with more extensions
+to be implemented.
+
+
+## Junk filtering
+
+Junk email/spam/UCE (unsolicited commercial email) is still a big problem on
+the internet. One great feature of email, that is worth protecting, is that you
+can send an email to another person without previous introduction. However,
+spammers have the same opportunity. Various mechanisms have been developed over
+time to reduce the amount of junk.
+
+### Reputation-based
+
+Most of these mechanisms have components that involves reputation. The
+reputation can be based on the IP address of the sending server, or the email
+address (or just its domain) of the sender, or the contents of the message. Mox
+uses the junk/non-junk classifications of messages by the user to evaluate
+incoming messages.
+
+Email clients have the ability to mark a message as junk, which typically sets
+the junk-flag for the message and/or moves the message to the designated Junk
+mailbox. An email client can also mark a message as non-junk, but this isn't
+commonly done, so mox automatically automatically marks messages moved to
+certain mailboxes (like Archive, Trash) as non-junk.
+
+The message database, including junk/non-junk flags, is accessible by the SMTP
+server. The database allows for efficiently looking up messages by (non)-junk
+flags, verified SPF/DKIM/DMARC sender domain/address and originating IP
+address. This allows mox to quickly analyze the reputation of an incoming
+message, and make a decision to accept/reject a message if the sender
+address/domain/IP has enough reputation signal. This means messages from people
+you've communicated with before will reliably make it through the junk filter.
+At least if they have set up SPF and/or DKIM, which allows associating their
+messages with their domain.  Only messages without reputation, "first-time
+senders", are subject to further scrutiny.
+
+### First-time senders
+
+For first-time senders, there is no, or not enough, signal in the sending
+address/domain/IP address to make a decision. Mox does bayesian analysis on the
+contents of such messages: The reputation of the words in a message are used to
+calculate the probability that a message is junk, which must not pass a
+configurable threshold.  The reputation of words is based on their occurrence
+in historic junk/non-junk messages, as classified by the user.
+
+### Delivery feedback
+
+When an incoming message is rejected for being junk, mox returns a temporary
+error. Mox never claims to accept a message only to drop it (some cloud mail
+providers are known to do this!), or place it in a Junk mailbox, out of view of
+the user. The effect is that a spammer will not learn whether there is an
+actual temporary error, or their message is treated as junk. A legitimate
+sender whose message is erroneously classified as junk will receive a DSN
+message about the failed delivery attempts, making it clear a different means
+of communication should be tried.
+
+### Rejects mailbox
+
+When mox rejects a message for being junk, it stores a copy of the message in
+the special "Rejects" mailbox (automatically cleaned up). If you are expecting
+an email, e.g. about signup to a new service, and it is rejected, you will find
+the message in that mailbox. By moving the message to the Inbox, and marking it
+as non-junk (e.g. by moving it to the Archive or Trash mailbox), future
+messages by that sender will be accepted due to the now positive reputation.
+
+### Reputation is per account
+
+In mox, all reputation is per account, not shared among accounts. One account
+may mark all messages from a sender as junk, causing them to be rejected, while
+another account can accept messages from the same sender.
+
+### DNSBL
+
+Mox can be configured to use an IP-based DNS blocklist (DNSBL). These are
+typically employed early in the SMTP session, to see if the remote IP is a
+known spammer. If so, the delivery attempt is stopped early. Mox doesn't use
+DNSBLs in its default installation. But if it is configured to use a DNSBL, it
+is only invoked when the other reputation-based checks are not conclusive. For
+these reasons:
+
+1. If a sender with positive reputation finds their IP listed in a DNSBL, the
+   email communication channels that have always worked will keep working (until
+   the user marks a few of their messages as junk).
+2. As little reliance on centralized parties (which DNSBLs typically are) as
+   possible.
+3. No leaking of IP addresses of mail servers a mox instance is communicating
+   with to the DNSBL operator.
+
+### Greylisting
+
+Greylisting is a commonly implemented mechanism whereby the first delivery
+attempt from a first-time sender is rejected with a temporary error. The idea
+is that spammers don't implement delivery queueing, and will never try again.
+A legitimate mail server would try again, typically within 5-15 minutes, and
+the second or third attempt will be accepted. Mox does not implement
+greylisting in this manner:
+
+Mail servers typically send from multiple IP addresses. At least both an IPv4
+and IPv6 address, and often multiple of each to reduce impact of a negative
+reputation for an IP address (e.g. being listed in a DNSBL). IP-based
+reputation incentivizes mail servers to use a different IP address for delivery
+retries after encountering a failure. Greylisting incentivizes mail servers to
+use the same IP address for retries. These incentives conflict, and mox regards
+IP-based reputation as more (long-term) valuable. Due to delivering from
+different IP addresses, greylisting can cause very long delays, or cause
+delivery failures altogether.
+
+Mox does employ mechanisms to slow down possible spammers: SMTP transactions of
+first-time senders and for messages classified as junk are slowed down. This
+reduces the rate at which junk mail would be received, and consumes resources
+of the spammer. First-time senders are delayed for 15 seconds, making it
+possible to wait for expected messages, such as for signups.
+
+
+## Webmail
+
+Mox includes a webmail client, still in early stages. Despite its looks, and
+missing features like composing messages in HTML, it is surprisingly usable,
+featuring:
+
+- Text and HTML rendering of messages, with/without external resources
+  (tracking images).
+- Threading, including muting threads
+- Drag-and-drop for moving messages
+- Layout: top/bottom vs left/right, adjustable widths/heights
+- Keyboard shortcuts
+
+The webmail benefits from having access to the message database, allowing for
+new functionality that wouldn't be easy to implement with SMTP/IMAP4. For
+example, mox keeps track of REQUIRETLS support of MX hosts (mail servers) of
+recipient domains. The webmail show this information when composing a message,
+and can enable REQUIRETLS by default.
+
+See [webmail screenshots](../screenshots/#hdr-webmail).
+
+
+## Internationalized email
+
+Originally, email addresses were ASCII-only. An email address consists of a
+"localpart", an "@" and a domain name. Only ASCII was allowed in message
+headers. With internationalized email, localparts can be in UTF-8, domains can
+use internationalized domain names (IDN/IDNA: unicode names with both an UTF-8
+encoding, and an ASCII encoding for use in DNS with domains starting with
+"xn--"), and message headers are allowed to contain UTF-8 as well.
+
+With internationalized email, users of scripts not representable in ASCII can
+use their native scripts for their email addresses.
+
+Mox implements internationalized email.
+
+
+## Automatic account configuration
+
+To configure an email account in an email client, you typically need to specify:
+
+1. Email address and full name.
+2. Submission (SMTP) server address, port, TLS mode, username, password and
+   authentication mechanism.
+3. IMAP4 server address, port, TLS mode, username, password and authentication
+   mechanism.
+
+This can be cumbersome to configure manually. Email clients can choose from
+several autoconfiguration mechanisms to automatically find (some of) the right
+settings, given an email address:
+
+SRV DNS records
+: The domain of the email address is used for looking up DNS SRV records, which
+point to the submission (SMTP) and IMAP servers, ports (with implied TLS
+mode). Not specified: username, authentication mechanism. Only secure when used
+with DNSSEC. Mox prints SRV records to add for a domain.
+
+Thunderbird-style autoconfig
+: The domain of the email address is used for looking up an XML config file at
+`https://autoconfig.<domain>`, protected with WebPKI. The configuration file
+holds all settings. Mox serves autoconfig profiles on its webserver.
+
+Autodiscover-style autodiscovery
+: The domain of the email address is used to look up a SRV record that points
+to an PKIX-protected HTTPS webserver that serves an XML configuration file with
+all settings. Only secure when the SRV lookup is DNSSEC-protected. Mox serves
+autodiscover profiles on its webserver.
+
+Apple device management profile
+: A configuration file with all settings must be transferred to the device
+manually. Mox lets users download these profiles in the account web interface,
+and shows a QR code to easily download the profile.
+
+Even though email clients have many options to automatically find the correct
+settings, many still prefer to guess incorrect legacy settings.
+
+
+## ACME for automatic TLS
+
+A modern email server needs a PKIX TLS certificate for its own hostname, used
+for SMTP with STARTTLS. Each domain with a "mail" CNAME for IMAP4 and SMTP
+submission, with MTA-STS and with autoconfiguration needs three more
+PKIX/WebPKI TLS certificates. Manually preventing your email infrastructure
+from automatic periodic expiration is cumbersome, but [an
+option](../config/#cfg-mox-conf-Listeners-x-TLS-KeyCerts). With ACME, TLS
+certificates are retrieved and refreshed automatically.
+
+The quickstart sets mox up with ACME using Let's Encrypt. Other ACME providers
+can be [defined](../config/#cfg-mox-conf-ACME-x) and
+[configured](../config/#cfg-mox-conf-Listeners-x-TLS-ACME). Mox supports
+[external account binding](../config/#cfg-mox-conf-ACME-x-ExternalAccountBinding)
+(EAB) for ACME providers that require association with an existing non-ACME
+account. Mox also suggests DNS CAA records, explicitly allowlisting Certificate
+Authorities (CAs) allowed to sign certificates for a domain. Mox recommends CAA
+records that only allow the account ID that mox has registered, preventing
+potential MitM attempts.
+
+ACME is also used for TLS certificates for the webserver, see below.
+
+## Webserver
+
+Mox includes a configurable webserver. This may seem to add unnecessary
+complexity and functionality to an email server, but contemporary email already
+requires the complexity of an HTTP stack due to MTA-STS and automatic account
+configuration. Not to mention webmail and an admin web interface. Luckily, mox
+can build on the proven HTTP client and server stack of the Go standard
+library.
+
+Mox mostly adds configuration options for:
+
+- Redirections of [entire domains](../config/#cfg-domains-conf-WebDomainRedirects) or
+  [paths](../config/#cfg-domains-conf-WebHandlers-dash-WebRedirect).
+- [Serving static files](../config/#cfg-domains-conf-WebHandlers-dash-WebStatic)
+  from a directory, including optional directory listings.
+- [Forwarding/Reverse proxying](../config/#cfg-domains-conf-WebHandlers-dash-WebForward),
+  including WebSocket connections.
+
+Incoming requests are handled by going through the list of configured handlers.
+The first matching handler takes care of the request, matching on:
+
+- Host
+- Path (regular expression)
+
+Handlers can specify additional behaviour:
+
+- Automatically redirect plain HTTP requests to HTTPS.
+- Automatically compress the response if it seems compressible (based on
+  content-type). A compressed static files are kept in a fixed size cache.
+- Strip the matched path before serving static file or forwarding the request.
+- Add custom headers to the response.
+
+These settings can all be configued through the admin web interface.
+
+TLS certificates for configured domains are managed automatically if ACME is
+configured.
+
+You may be tempted to install mox on a server that already runs a webserver. It
+is possible to configure mox to work with an existing webserver, but it will
+complicate the configuration significantly: The mox configuration has to be
+modified for
+[autoconfig](../config/#cfg-mox-conf-Listeners-x-AutoconfigHTTPS-NonTLS) and
+[MTA-STS](../config/#cfg-mox-conf-Listeners-x-MTASTSHTTPS-NonTLS) and the
+existing webserver needs to be configured to forward. You will likely manage
+TLS certificates outside of mox and have to configure the paths to the [keys
+and certificates](../config/#cfg-mox-conf-Listeners-x-TLS-KeyCerts), and
+refresh them timely, restarting mox. Also see the `-existing-webserver` option
+in the [quickstart command](../commands/#hdr-mox-quickstart).
+
+
+## Localserve
+
+The [mox localserve](../commands/#hdr-mox-localserve) starts a local mox
+instance with a lot of its functionality: SMTP/submission, IMAP4, Webmail,
+account and admin web interface and the webserver. Localserve listens on the
+standard ports + 1000, so no special privileges are needed.
+
+Localserve is useful for testing the email functionality of your application:
+Localserve can accept all email (catchall), optionally return
+temporary/permanent errors, and you can read messages in the webmail.
+Localserve enables "pedantic mode", raising errors for non-standard protocol
+behaviour.
+
+
+## Admin web interface
+
+The admin web interface helps admins set up accounts, configure addresses, and
+set up new domains (with instructions to create DNS records, and with a check
+to see if they are correct). Changes made through the admin web interface
+updates the [domains.conf config file](../config/#hdr-domains-conf).
+
+Received DMARC and TLS reports can be viewed, and cached MTA-STS policies
+listed.
+
+DMARC evaluations for outgoing DMARC reports, and SMTP (TLS) connection results
+for outgoing TLS reports can be viewed, and removed. Suppression lists for
+addresses for outgoing reports can be managed as well. Some domains don't
+accept reports at the addresses they configure, and send DSNs. The suppression
+list helps reduce operational noise.
+
+See [Admin web interface screenshots](../screenshots/#hdr-admin-web-interface).
+
+
+## Metrics and logging
+
+Mox provides [prometheus metrics](https://prometheus.io/docs/concepts/metric_types/)
+for monitoring.  A standard set of application metrics are exposed: Open file
+descriptors, memory/cpu usage, etc. Mox also exposes metrics specific to its
+internals. See the example
+[prometheus rules](https://github.com/mjl-/mox/blob/main/prometheus.rules) in
+the repository.
+
+Mox has configurable log levels, per
+[functional package](https://pkg.go.dev/github.com/mjl-/mox#section-directories).
+Mox logs in structured [logfmt](https://brandur.org/logfmt) format, which is
+easy to work with (parse, filter, derive metrics from). Mox also includes three
+trace-level logs, for SMTP and IMAP4: trace, traceauth (logs sensitive
+authentication data, like passwords), tracedata (logs (bulk) message content).
+
+
+## Security
+
+Mox aims to be a secure mail server. Many email-security features have been
+implemented. Mox comes with a automated test suite, which includes fuzzing. Mox
+is written in Go, a modern safer programming language that prevents whole
+classes of bugs, or limits their impact.
+
+
+## Reusable components
+
+Most non-server Go packages mox consists of are written to be reusable Go
+packages.
+
+There is no guarantee that there will be no breaking changes. With Go's
+dependency versioning approach (minimal version selection), Go code will never
+unexpectedly stop compiling. Incompatibilities will show when explicitly
+updating a dependency. Making the required changes is typically fairly
+straightforward.
+
+Incompatible changes compared to previous releases are tracked in the git
+repository, see [apidiff/](https://github.com/mjl-/mox/tree/main/apidiff).
--- a/website/index.md
+++ b/website/index.md
@ -0,0 +1,64 @@
+# Mox - modern, secure, all-in-one email server
+## Stay in control of your email and keep email decentralized!
+
+Complete email solution
+: For sending and receiving email. With support for IMAP4, SMTP, SPF, DKIM,
+DMARC, MTA-STS, DANE and DNSSEC, reputation-based
+and content-based junk filtering, Internationalization (IDNA), automatic TLS
+with ACME and Let's Encrypt, account autoconfiguration, webmail.
+
+Quick & easy
+: Use the quickstart command to set up mox for your domain(s) within 10
+minutes. You'll get a secure mail server with a modern protocol stack. Upgrades
+are mostly a matter of downloading the new version and restarting. Maintenance
+via web interface (easy) or config file (powerful). No dependencies.
+
+High quality and secure
+: Mox has a modern Go code base with plenty of automated tests, automated
+integration tests, is manually tested against popular mail server and client
+software, and is fuzz-tested. The code is well-documented and cross-referenced
+with the relevant standards (RFC's).
+
+Open Source
+: Mox is an open source project, [source code](https://github.com/mjl-/mox) is
+MIT-licensed.
+
+See [Features](features/) for the details, including roadmap.
+
+## Latest release
+
+The latest release is v0.0.9, released on 2024-01-09, see [release
+notes](https://github.com/mjl-/mox/releases/tag/v0.0.9), [download
+binaries](https://beta.gobuilds.org/github.com/mjl-/mox@v0.0.9/linux-amd64-latest/),
+or see [all releases](https://github.com/mjl-/mox/releases).
+
+
+## News
+
+- 2024-01-09, [v0.0.9](https://github.com/mjl-/mox/releases/tag/v0.0.9) released
+- 2023-12-08, There will be a
+  [talk about mox](https://fosdem.org/2024/schedule/event/fosdem-2024-2261--servers-mox-a-modern-full-featured-mail-server/)
+  in the ["Modern Email" devroom](https://fosdem.org/2024/schedule/track/modern-email/)
+  at [FOSDEM 2024](https://fosdem.org/2024/) (Feb 3 & 4, Brussels). See you there!
+- 2023-11-22, [v0.0.8](https://github.com/mjl-/mox/releases/tag/v0.0.8) released
+- 2023-09-24, [v0.0.7](https://github.com/mjl-/mox/releases/tag/v0.0.7) released
+
+
+## Background
+
+Work on mox started in 2021. Admins were migrating their emails to just a few
+cloud/hosting providers. In part because running and maintaining email software
+had become more complicated over time: additional email protocols required yet
+another component in the software stack. Combining all these components into a
+working email server had become too troublesome over time. These components
+were also often written in C, a programming language where a small mistake
+typically has large consequences.
+
+Mox is a modern email server that implements all modern email protocols in a
+single easy to use and maintain application.
+
+
+## Sponsors
+
+Mox development is sponsored from August 2023 to August 2024 through NLnet/EU's
+NGI0 Entrust, see https://nlnet.nl/project/Mox/.
--- a/website/install/index.md
+++ b/website/install/index.md
@ -0,0 +1,99 @@
+# Install
+
+Mox aims to be easy to install. The commands and config files to set mox up for
+a new domain, including running it as a service on Linux, are printed/created
+through the quickstart.
+
+## Quickstart
+
+The easiest way to get started with serving email for your domain is to get a
+(virtual) machine dedicated to serving email, name it `[host].[domain]` (e.g.
+mail.example.com). Having a DNSSEC-verifying resolver installed, such as
+unbound, is highly recommended. Run as root:
+
+	# Create mox user and homedir (or pick another name or homedir):
+	useradd -m -d /home/mox mox
+
+	cd /home/mox
+	... compile or download mox to this directory, see below ...
+
+	# Generate config files for your address/domain:
+	./mox quickstart you@example.com
+
+The quickstart:
+
+- Creates configuration files mox.conf and domains.conf.
+- Adds the domain and an account for the email address to domains.conf
+- Generates an admin and account password.
+- Prints the DNS records you need to add, for the machine and domain.
+- Prints commands to start mox, and optionally install mox as a service.
+
+A machine that doesn't already run a webserver is highly recommended because
+modern email requires HTTPS, and mox currently needs to run a webserver for
+automatic TLS with ACME.  You could combine mox with an existing webserver, but
+it requires a lot more configuration. If you want to serve websites on the same
+machine, consider using the webserver built into mox. It's pretty good! If you
+want to run an existing webserver on port 443/80, see `mox help quickstart`.
+
+After starting, you can access the admin web interface on internal IPs.
+
+
+## Download
+
+Download a mox binary from
+https://beta.gobuilds.org/github.com/mjl-/mox@latest/linux-amd64-latest/.
+
+Symlink or rename it to "mox".
+
+The URL above always resolves to the latest release for linux/amd64 built with
+the latest Go toolchain.  See the links at the bottom of that page for binaries
+for other platforms.
+
+
+## Compiling
+
+You can easily (cross) compile mox yourself. You need a recent Go toolchain
+installed.  Run `go version`, it must be >= 1.20. Download the latest version
+from https://go.dev/dl/ or see https://go.dev/doc/manage-install.
+
+To download the source code of the latest release, and compile it to binary "mox":
+
+	GOBIN=$PWD CGO_ENABLED=0 go install github.com/mjl-/mox@latest
+
+Mox only compiles for and fully works on unix systems. Mox also compiles for
+Windows, but "mox serve" does not yet work, though "mox localserve" (for a
+local test instance) and most other subcommands do. Mox does not compile for
+Plan 9.
+
+
+## Docker
+
+Although not recommended, you can also run mox with docker image
+`r.xmox.nl/mox`, with tags like `v0.0.1` and `v0.0.1-go1.20.1-alpine3.17.2`, see
+https://r.xmox.nl/r/mox/.  See
+https://github.com/mjl-/mox/blob/main/docker-compose.yml to get started.
+
+New docker images aren't (automatically) generated for new Go runtime/compile
+releases.
+
+It is important to run with docker host networking, so mox can use the public
+IPs and has correct remote IP information for incoming connections (important
+for junk filtering and rate-limiting).
+
+
+## Configuration
+
+Mox tries to choose sane defaults. When you add a domain or account, you
+shouldn't have to change any more configuration files in most cases. If you do
+need to make changes, you can edit the configuration files: `config/mox.conf`
+and/or `config/domains.conf`. You do have to separately add DNS records.
+
+See [Config reference](../config/) for configuration files annotated with
+documentation.
+
+Mox comes with various subcommands, useful especially for testing. See [Command
+reference](../commands/) for a list of commands, and their documentation.
+
+If you have a question, see the [FAQ](../faq/). If your question remains
+unanswered, please ask it on the [issue
+tracker](https://github.com/mjl-/mox/issues/new).
--- a/website/protocols/summary.md
+++ b/website/protocols/summary.md
@ -0,0 +1,43 @@
+# Protocols
+
+## Summary
+
+First a high-level description of protocols and implementation status. Each
+topic links to the second table with more detailed implementation status per
+RFC.
+
+<table>
+<tr><th>Topic</th><th>Implemented</th><th>Description</th></tr>
+<tr><td><a href="#topic-internet-message-format">Internet Message Format</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>The format of email messages</td></tr>
+<tr><td><a href="#topic-smtp">SMTP</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>Delivering email</td></tr>
+<tr><td><a href="#topic-spf">SPF</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>Message authentication based on sending IP</td></tr>
+<tr><td><a href="#topic-dkim">DKIM</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>Message authentication based on message header</td></tr>
+<tr><td><a href="#topic-dmarc">DMARC</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>Reject/accept policy for incoming messages that pass/fail DKIM and/or SPF message authentication</td></tr>
+<tr><td><a href="#topic-arc">ARC</a></td> <td style="text-align: center"><span class="roadmap">Roadmap</span></td> <td>Signed message authentication results from forwarding server</td></tr>
+<tr><td><a href="#topic-dane">DANE</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>Verification of TLS certificates through DNSSEC-protected DNS records</td></tr>
+<tr><td><a href="#topic-mta-sts">MTA-STS</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>PKIX-based protection of TLS certificates and MX records</td></tr>
+<tr><td><a href="#topic-tls-reporting">TLS Reporting</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>Reporting about TLS interoperability issues</td></tr>
+<tr><td><a href="#topic-arf">ARF</a></td> <td style="text-align: center"><span class="roadmap">Roadmap</span></td> <td>Abuse reporting format</td></tr>
+<tr><td><a href="#topic-imap">IMAP</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>Email access protocol</td></tr>
+<tr><td><a href="#topic-sieve">Sieve</a></td> <td style="text-align: center"><span class="roadmap">Roadmap</span></td> <td>Scripts to run on incoming messages</td></tr>
+<tr><td><a href="#topic-jmap">JMAP</a></td> <td style="text-align: center"><span class="roadmap">Roadmap</span></td> <td>HTTP/JSON-based email access protocol</td></tr>
+<tr><td><a href="#topic-caldav-ical">CalDAV/iCal</a></td> <td style="text-align: center"><span class="roadmap">Roadmap</span></td> <td>Calendaring</td></tr>
+<tr><td><a href="#topic-carddav-vcard">CardDAV/vCard</a></td> <td style="text-align: center"><span class="roadmap">Roadmap</span></td> <td>Contacts</td></tr>
+<tr><td><a href="#topic-sasl">SASL</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>Authentication mechanisms</td></tr>
+<tr><td><a href="#topic-internationalization">Internationalization</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>Internationalization of domain names.</td></tr>
+<tr><td><a href="#topic-tls">TLS</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>TLS, for encrypted and authenticated communication.</td></tr>
+<tr><td><a href="#topic-acme">ACME</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>Automatically manage PKIX TLS certificates</td></tr>
+<tr><td><a href="#topic-caa">CAA</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>CAA DNS reords specify which certificate authorities (CAs) are allowed to sign certificates for a domain.</td></tr>
+<tr><td><a href="#topic-http">HTTP</a></td> <td style="text-align: center"><span class="implemented">Yes</span></td> <td>HTTP for webservers. Required for automatic account configuration and MTA-STS. Also relevant for the built-in webserver.</td></tr>
+</table>
+
+## RFCs
+
+The mox source code is quite heavily annotated with references to the RFCs.
+This makes the implementation more maintainable, and makes it easier for new
+developers to make changes. See [cross-referenced code and RFCs](../xr/dev/) to
+navigate RFCs and source code side by side.
+
+Implementation status per RFC, grouped by topic.
+
+### Statuses
--- a/website/screenshots/index.md
+++ b/website/screenshots/index.md
@ -0,0 +1,43 @@
+# Screenshots
+
+Mox is an email server, so most of its functionality can't really be
+visualized. But the webmail client, and account and the admin web interface can
+be. See screenshots below.
+
+## Webmail
+
+### Mailbox
+<div style="margin-bottom: 4ex"><a href="../files/webmail-mailbox.png"><img class="img2" src="../files/webmail-mailbox.jpg" /></a></div>
+
+### Top/bottom split and selecting multiple messages
+<div style="margin-bottom: 4ex"><a href="../files/webmail-top-bottom-split-multiselect.png"><img class="img2" src="../files/webmail-top-bottom-split-multiselect.jpg" /></a></div>
+
+### Search
+<div style="margin-bottom: 4ex"><a href="../files/webmail-search.png"><img class="img2" src="../files/webmail-search.jpg" /></a></div>
+
+### Compose
+<div style="margin-bottom: 4ex"><a href="../files/webmail-compose.png"><img class="img2" src="../files/webmail-compose.jpg" /></a></div>
+
+### Attachments
+<div style="margin-bottom: 4ex"><a href="../files/webmail-attachments.png"><img class="img2" src="../files/webmail-attachments.jpg" /></a></div>
+
+### Help
+<div style="margin-bottom: 4ex"><a href="../files/webmail-help.png"><img class="img2" src="../files/webmail-help.jpg" /></a></div>
+
+
+## Account web interface
+
+### Overview
+<div style="margin-bottom: 4ex"><a href="../files/account-overview.png"><img class="img1" src="../files/account-overview.png" /></a></div>
+
+### Address
+<div style="margin-bottom: 4ex"><a href="../files/account-address.png"><img class="img1" src="../files/account-address.png" /></a></div>
+
+
+## Admin web interface
+
+### Overview
+<div style="margin-bottom: 4ex"><a href="../files/admin-overview.png"><img class="img1" src="../files/admin-overview.png" /></a></div>
+
+### Domain
+<div style="margin-bottom: 4ex"><a href="../files/admin-domain.png"><img class="img1" src="../files/admin-domain.png" /></a></div>
--- a/website/website.go
+++ b/website/website.go
@ -0,0 +1,552 @@
+//go:build website
+
+package main
+
+import (
+	"bufio"
+	"bytes"
+	"errors"
+	"flag"
+	"fmt"
+	"html"
+	htmltemplate "html/template"
+	"io"
+	"log"
+	"os"
+	"strconv"
+	"strings"
+
+	"golang.org/x/exp/slices"
+
+	"github.com/russross/blackfriday/v2"
+)
+
+func xcheck(err error, msg string) {
+	if err != nil {
+		log.Fatalf("%s: %s", msg, err)
+	}
+}
+
+func main() {
+	var commithash = os.Getenv("commithash")
+	var commitdate = os.Getenv("commitdate")
+
+	var pageRoot, pageProtocols bool
+	var title string
+	flag.BoolVar(&pageRoot, "root", false, "is top-level index page, instead of in a sub directory")
+	flag.BoolVar(&pageProtocols, "protocols", false, "is protocols page")
+	flag.StringVar(&title, "title", "", "html title of page, set to value of link name with a suffix")
+	flag.Parse()
+	args := flag.Args()
+	if len(args) != 1 {
+		flag.Usage()
+		os.Exit(2)
+	}
+	linkname := args[0]
+
+	if title == "" && linkname != "" {
+		title = linkname + " - Mox"
+	}
+
+	// Often the website markdown file.
+	input, err := io.ReadAll(os.Stdin)
+	xcheck(err, "read")
+
+	// For rendering the main content of the page.
+	r := &renderer{
+		linkname == "Config reference",
+		"",
+		*blackfriday.NewHTMLRenderer(blackfriday.HTMLRendererParameters{HeadingIDPrefix: "hdr-"}),
+	}
+	opts := []blackfriday.Option{
+		blackfriday.WithExtensions(blackfriday.CommonExtensions | blackfriday.AutoHeadingIDs),
+		blackfriday.WithRenderer(r),
+	}
+
+	// Make table of contents of a page, based on h2-links, or "## ..." in markdown.
+	makeTOC := func() ([]byte, []byte) {
+		var title string
+
+		// Get the h2's, split them over the columns.
+		type link struct {
+			Title string
+			ID    string
+		}
+		var links []link
+
+		node := blackfriday.New(opts...).Parse(input)
+		if node == nil {
+			return nil, nil
+		}
+		for c := node.FirstChild; c != nil; c = c.Next {
+			if c.Type != blackfriday.Heading {
+				continue
+			}
+			if c.Level == 1 {
+				title = string(c.FirstChild.Literal)
+			} else if c.Level == 2 {
+				link := link{string(c.FirstChild.Literal), c.HeadingID}
+				links = append(links, link)
+			} else {
+				// log.Fatalf("heading, level %d", c.Level)
+			}
+		}
+
+		// We split links over 2 columns if we have quite a few, to keep the page somewhat compact.
+		ncol := 1
+		if len(links) > 6 {
+			ncol = 2
+		}
+
+		n := len(links) / ncol
+		rem := len(links) - ncol*n
+		counts := make([]int, ncol)
+		for i := 0; i < ncol; i++ {
+			counts[i] = n
+			if rem > i {
+				counts[i]++
+			}
+		}
+		toc := `<div class="toc">`
+		toc += "\n"
+		o := 0
+		for _, n := range counts {
+			toc += "<ul>\n"
+			for _, link := range links[o : o+n] {
+				toc += fmt.Sprintf(`<li><a href="#%s">%s</a></li>`, html.EscapeString("hdr-"+link.ID), html.EscapeString(link.Title))
+				toc += "\n"
+			}
+			toc += "</ul>\n"
+			o += n
+		}
+		toc += "</div>\n"
+		var titlebuf []byte
+		if title != "" {
+			titlebuf = []byte(fmt.Sprintf(`<h1 id="%s">%s</h1>`, html.EscapeString("hdr-"+blackfriday.SanitizedAnchorName(title)), html.EscapeString(title)))
+		}
+		return titlebuf, []byte(toc)
+	}
+
+	var output []byte
+	if pageRoot {
+		// Split content into two parts for main page. First two lines are special, for
+		// header.
+		inputstr := string(input)
+		lines := strings.SplitN(inputstr, "\n", 3)
+		if len(lines) < 2 {
+			log.Fatalf("missing header")
+		}
+		inputstr = inputstr[len(lines[0])+1+len(lines[1])+1:]
+		lines[0] = strings.TrimPrefix(lines[0], "#")
+		lines[1] = strings.TrimPrefix(lines[1], "##")
+		sep := "## Background"
+		inleft, inright, found := strings.Cut(inputstr, sep)
+		if !found {
+			log.Fatalf("did not find separator %q", sep)
+		}
+		outleft := blackfriday.Run([]byte(inleft), opts...)
+		outright := blackfriday.Run([]byte(sep+inright), opts...)
+		output = []byte(fmt.Sprintf(`
+<div class="rootheader h1">
+	<h1>%s</h1>
+	<h2>%s</h2>
+</div>
+<div class="two"><div>%s</div><div>%s</div></div>`, html.EscapeString(lines[0]), html.EscapeString(lines[1]), outleft, outright))
+	} else if pageProtocols {
+		// ../rfc/index.txt is the standard input. We'll read each topic and the RFCs.
+		topics := parseTopics(input)
+
+		// First part of content is in markdown file.
+		summary, err := os.ReadFile("protocols/summary.md")
+		xcheck(err, "reading protocol summary")
+
+		output = blackfriday.Run(summary, opts...)
+
+		var out bytes.Buffer
+		_, err = out.Write(output)
+		xcheck(err, "write")
+
+		err = protocolTemplate.Execute(&out, map[string]any{"Topics": topics})
+		xcheck(err, "render protocol support")
+
+		output = out.Bytes()
+	} else {
+		// Other pages.
+		xinput := input
+		if bytes.HasPrefix(xinput, []byte("# ")) {
+			xinput = bytes.SplitN(xinput, []byte("\n"), 2)[1]
+		}
+		output = blackfriday.Run(xinput, opts...)
+		title, toc := makeTOC()
+		output = append(toc, output...)
+		output = append(title, output...)
+	}
+
+	// HTML preamble.
+	before = strings.Replace(before, "<title>...</title>", "<title>"+html.EscapeString(title)+"</title>", 1)
+	before = strings.Replace(before, ">"+linkname+"<", ` style="font-weight: bold">`+linkname+"<", 1)
+	if !pageRoot {
+		before = strings.ReplaceAll(before, `"./`, `"../`)
+	}
+	_, err = os.Stdout.Write([]byte(before))
+	xcheck(err, "write")
+
+	// Page content.
+	_, err = os.Stdout.Write(output)
+	xcheck(err, "write")
+
+	// Bottom, HTML closing.
+	after = strings.Replace(after, "[commit]", fmt.Sprintf("%s, commit %s", commitdate, commithash), 1)
+	_, err = os.Stdout.Write([]byte(after))
+	xcheck(err, "write")
+}
+
+// Implementation status of standards/protocols.
+type Status string
+
+const (
+	Implemented    Status = "Yes"
+	Partial        Status = "Partial"
+	Roadmap        Status = "Roadmap"
+	NotImplemented Status = "No"
+	Unknown        Status = "?"
+)
+
+// RFC and its implementation status.
+type RFC struct {
+	Number      int
+	Title       string
+	Status      Status
+	StatusClass string
+	Obsolete    bool
+}
+
+// Topic is a group of RFC's, typically by protocol, e.g. SMTP.
+type Topic struct {
+	Title string
+	ID    string
+	RFCs  []RFC
+}
+
+// parse topics and RFCs from ../rfc/index.txt.
+// headings are topics, and hold the RFCs that follow them.
+func parseTopics(input []byte) []Topic {
+	var l []Topic
+	var t *Topic
+
+	b := bufio.NewReader(bytes.NewReader(input))
+	for {
+		line, err := b.ReadString('\n')
+		if line != "" {
+			if strings.HasPrefix(line, "# ") {
+				// Skip topics without RFCs to show on the website.
+				if t != nil && len(t.RFCs) == 0 {
+					l = l[:len(l)-1]
+				}
+				title := strings.TrimPrefix(line, "# ")
+				id := blackfriday.SanitizedAnchorName(title)
+				l = append(l, Topic{Title: title, ID: id})
+				t = &l[len(l)-1] // RFCs will be added to t.
+				continue
+			}
+
+			// Tokens: RFC number, implementation status, is obsolete, title.
+			tokens := strings.Split(line, "\t")
+			if len(tokens) != 4 {
+				continue
+			}
+
+			ignore := strings.HasPrefix(tokens[1], "-")
+			if ignore {
+				continue
+			}
+			status := Status(strings.TrimPrefix(tokens[1], "-"))
+			var statusClass string
+			switch status {
+			case Implemented:
+				statusClass = "implemented"
+			case Partial:
+				statusClass = "partial"
+			case Roadmap:
+				statusClass = "roadmap"
+			case NotImplemented:
+				statusClass = "notimplemented"
+			case Unknown:
+				statusClass = "unknown"
+			default:
+				log.Fatalf("unknown implementation status %q, line %q", status, line)
+			}
+
+			number, err := strconv.ParseInt(tokens[0], 10, 32)
+			xcheck(err, "parsing rfc number")
+			flags := strings.Split(tokens[2], ",")
+			title := tokens[3]
+
+			rfc := RFC{
+				int(number),
+				title,
+				status,
+				statusClass,
+				slices.Contains(flags, "Obs"),
+			}
+			t.RFCs = append(t.RFCs, rfc)
+		}
+		if err == io.EOF {
+			break
+		}
+		xcheck(err, "read line")
+	}
+	// Skip topics without RFCs to show on the website.
+	if t != nil && len(t.RFCs) == 0 {
+		l = l[:len(l)-1]
+	}
+	return l
+}
+
+// renderer is used for all HTML pages, for showing links to h2's on hover, and for
+// specially rendering the config files with links for each config field.
+type renderer struct {
+	codeBlockConfigFile      bool   // Whether to interpret codeblocks as config files.
+	h2                       string // Current title, for config line IDs.
+	blackfriday.HTMLRenderer        // Embedded for RenderFooter and RenderHeader.
+}
+
+func (r *renderer) RenderNode(w io.Writer, node *blackfriday.Node, entering bool) blackfriday.WalkStatus {
+	if node.Type == blackfriday.Heading && node.Level == 2 {
+		r.h2 = string(node.FirstChild.Literal)
+
+		id := "hdr-" + blackfriday.SanitizedAnchorName(string(node.FirstChild.Literal))
+		if entering {
+			_, err := fmt.Fprintf(w, `<h2 id="%s">`, id)
+			xcheck(err, "write")
+		} else {
+			_, err := fmt.Fprintf(w, ` <a href="#%s">#</a></h2>`, id)
+			xcheck(err, "write")
+		}
+		return blackfriday.GoToNext
+	}
+	if r.codeBlockConfigFile && node.Type == blackfriday.CodeBlock {
+		if !entering {
+			log.Fatalf("not entering")
+		}
+
+		_, err := fmt.Fprintln(w, `<div class="config">`)
+		xcheck(err, "write")
+		r.writeConfig(w, node.Literal)
+		_, err = fmt.Fprintln(w, "</div>")
+		xcheck(err, "write")
+		return blackfriday.GoToNext
+	}
+	return r.HTMLRenderer.RenderNode(w, node, entering)
+}
+
+func (r *renderer) writeConfig(w io.Writer, data []byte) {
+	var fields []string
+	for _, line := range bytes.Split(data, []byte("\n")) {
+		var attrs, link string
+
+		s := string(line)
+		text := strings.TrimLeft(s, "\t")
+		if strings.HasPrefix(text, "#") {
+			attrs = ` class="comment"`
+		} else if text != "" {
+			// Add id attribute and link to it, based on the nested config fields that lead here.
+			ntab := len(s) - len(text)
+			nfields := ntab + 1
+			if len(fields) >= nfields {
+				fields = fields[:nfields]
+			} else if nfields > len(fields)+1 {
+				xcheck(errors.New("indent jumped"), "write codeblock")
+			} else {
+				fields = append(fields, "")
+			}
+
+			var word string
+			if text == "-" {
+				word = "dash"
+			} else {
+				word = strings.Split(text, ":")[0]
+			}
+			fields[nfields-1] = word
+
+			id := fmt.Sprintf("cfg-%s-%s", blackfriday.SanitizedAnchorName(r.h2), strings.Join(fields, "-"))
+			attrs = fmt.Sprintf(` id="%s"`, id)
+			link = fmt.Sprintf(` <a href="#%s">#</a>`, id)
+		}
+		if s == "" {
+			line = []byte("\n") // Prevent empty, zero-height line.
+		}
+		_, err := fmt.Fprintf(w, "<div%s>%s%s</div>\n", attrs, html.EscapeString(string(line)), link)
+		xcheck(err, "write codeblock")
+	}
+}
+
+var before = `<!doctype html>
+<html>
+	<head>
+		<meta charset="utf-8" />
+		<title>...</title>
+		<meta name="viewport" content="width=device-width, initial-scale=1" />
+		<link rel="icon" href="noNeedlessFaviconRequestsPlease:" />
+		<style>
+* { font-size: 18px; font-family: ubuntu, lato, sans-serif; margin: 0; padding: 0; box-sizing: border-box; }
+html { scroll-padding-top: 4ex; }
+.textblock { max-width: 50em; margin: 0 auto; }
+p { max-width: 50em; margin-bottom: 2ex; }
+ul, ol { max-width: 50em; margin-bottom: 2ex; }
+pre, code, .config, .config * { font-family: "ubuntu mono", monospace; }
+pre, .config { margin-bottom: 2ex; padding: 1em; background-color: #f8f8f8; border-radius: .25em; }
+pre { white-space: pre-wrap; }
+code { background-color: #eee; }
+pre code { background-color: inherit; }
+h1 { font-size: 1.8em; }
+h2 { font-size: 1.25em; margin-bottom: 1ex; }
+h2 > a { opacity: 0; }
+h2:hover > a { opacity: 1; }
+h3 { font-size: 1.1em; margin-bottom: 1ex; }
+.feature {display: inline-block; width: 30%; margin: 1em; }
+dl { margin: 1em 0; }
+dt { font-weight: bold; margin-bottom: .5ex; }
+dd { max-width: 50em; padding-left: 2em; margin-bottom: 1em; }
+table { margin-bottom: 2ex; }
+
+.video { box-shadow: 0 0 20px 0 #bbb; }
+.img1 { width: 1050px; max-width: 100%; box-shadow: 0 0 20px 0 #bbb; }
+.img2 { width: 1500px; max-width: 100%; box-shadow: 0 0 20px 0 #bbb; }
+
+.implemented { background: linear-gradient(90deg, #bbf05c 0%, #d0ff7d 100%); padding: 0 .25em; display: inline-block; }
+.partial { background: linear-gradient(90deg, #f2f915 0%, #fbff74 100%); padding: 0 .25em; display: inline-block; }
+.roadmap { background: linear-gradient(90deg, #ffbf6c 0%, #ffd49c 100%); padding: 0 .25em; display: inline-block; }
+.notimplemented { background: linear-gradient(90deg, #ffa2fe 0%, #ffbffe 100%); padding: 0 .25em; display: inline-block; }
+.unknown { background: linear-gradient(90deg, #ccc 0%, #e2e2e2 100%); padding: 0 .25em; display: inline-block; }
+
+.config > * { white-space: pre-wrap; }
+.config .comment { color: #777; }
+.config > div > a { opacity: 0; }
+.config > div:hover > a { opacity: 1; }
+.config > div:target { background-color: gold; }
+
+.rfcs .topic a { opacity: 0; }
+.rfcs .topic:hover a { opacity: 1; }
+
+.rootheader { background: linear-gradient(90deg, #ff9d9d 0%, #ffbd9d 100%); display: inline-block; padding: .25ex 3em .25ex 1em; border-radius: .2em; margin-bottom: 2ex; }
+h1, .h1 { margin-bottom: 1ex; }
+h2 { background: linear-gradient(90deg, #6dd5fd 0%, #77e8e3 100%); display: inline-block; padding: 0 .5em 0 .25em; margin-top: 2ex; font-weight: normal; }
+.rootheader h1, .rootheader h2 { background: none; display: block; padding: 0; margin-top: 0; font-weight: bold; margin-bottom: 0; }
+.meta { padding: 1em; display: flex; justify-content: space-between; margin: -1em; }
+.meta > div > * { font-size: .9em; opacity: .5; }
+.meta > nth-child(2) { text-align: right; opacity: .35 }
+
+.navbody { display: flex; }
+.nav { padding: 1em; text-align: right; background-color: #f4f4f4; }
+.nav li { white-space: pre; }
+.main { padding: 1em; }
+.main ul, .main ol { padding-left: 1em; }
+.two { display: flex; gap: 2em; }
+.two > div { max-width: 50em; }
+.toc { display: flex; gap: 2em; margin-bottom: 3ex; }
+.toc ul { margin-bottom: 0; }
+
+@media (min-width:1025px) {
+	.nav { box-shadow: inset 0 0 10px rgba(0, 0, 0, 0.075); min-height: 100vh; }
+	.main { padding-left: 2em; }
+}
+@media (max-width:1024px) {
+	.navbody { display: block; }
+	.main { box-shadow: 0 0 10px rgba(0, 0, 0, 0.075); }
+	.nav { text-align: left; }
+	.nav ul { display: inline; }
+	.nav li { display: inline; }
+	.nav .linkpad { display: none; }
+	.extlinks { display: none; }
+	.two { display: block; }
+	.two > div { max-width: auto; }
+	.toc { display: block; }
+}
+		</style>
+	</head>
+	<body>
+		<div class="navbody">
+			<nav class="nav">
+				<ul style="list-style: none">
+					<li><a href="./">Mox</a></li>
+					<li><a href="./features/">Features</a></li>
+					<li><a href="./screenshots/">Screenshots</a></li>
+					<li><a href="./install/">Install</a></li>
+					<li><a href="./faq/">FAQ</a></li>
+					<li><a href="./config/">Config reference</a></li>
+					<li><a href="./commands/">Command reference</a></li>
+					<li class="linkpad" style="visibility: hidden; font-weight: bold; height: 0"><a href="./commands/">Command reference</a></li>
+					<li><a href="./protocols/">Protocols</a></li>
+				</ul>
+				<div class="extlinks">
+					<br/>
+					External links:
+					<ul style="list-style: none">
+						<li><a href="https://github.com/mjl-/mox">Sources at github</a></li>
+					</ul>
+				</div>
+			</nav>
+
+			<div class="main">
+`
+
+var after = `
+				<br/>
+				<br/>
+				<div class="meta">
+					<div><a href="https://github.com/mjl-/mox/issues/new?title=website:+">feedback?</a></div>
+					<div><span>[commit]</span></div>
+				</div>
+			</div>
+		</div>
+	</body>
+</html>
+`
+
+// Template for protocol page, minus the first section which is read from
+// protocols/summary.md.
+var protocolTemplate = htmltemplate.Must(htmltemplate.New("protocolsupport").Parse(`
+<table>
+	<tr>
+		<td><span class="implemented">Yes</span></td>
+		<td>All/most of the functionality of the RFC has been implemented.</td>
+	</tr>
+	<tr>
+		<td><span class="partial">Partial</span></td>
+		<td>Some of the functionality from the RFC has been implemented.</td>
+	</tr>
+	<tr>
+		<td><span class="roadmap">Roadmap</span></td>
+		<td>Implementing functionality from the RFC is on the roadmap.</td>
+	</tr>
+	<tr>
+		<td><span class="notimplemented">No</span></td>
+		<td>Functionality from the RFC has not been implemented, is not currently on the roadmap, but may be in the future.</td>
+	</tr>
+	<tr>
+		<td><span class="unknown">?</span></td>
+		<td>Status undecided, unknown or not applicable.</td>
+	</tr>
+</table>
+
+<table class="rfcs">
+	<tr>
+		<th>RFC #</th>
+		<th>Status</th>
+		<th style="text-align: left">Title</th>
+	</tr>
+{{ range .Topics }}
+	<tr>
+		<td colspan="3" style="font-weight: bold; padding: 3ex 0 1ex 0" id="topic-{{ .ID }}" class="topic">{{ .Title }} <a href="#topic-{{ .ID }}">#</a></td>
+	</tr>
+	{{ range .RFCs }}
+	<tr{{ if .Obsolete }} style="opacity: .3"{{ end }}>
+		<td style="text-align: right"><a href="../xr/dev/#code,rfc/{{ .Number }}">{{ .Number }}</a></td>
+		<td style="text-align: center"><span class="{{ .StatusClass }}">{{ .Status }}</span></td>
+		<td>{{ if .Obsolete }}Obsolete: {{ end }}{{ .Title }}</td>
+	</tr>
+	{{ end }}
+{{ end }}
+</table>
+`))