New features

• Per-account disk space quota. Mox now tracks the total size of messages in an
  account (overhead from the message index database or file system is not
  included). A maximum disk usage can be configured globally and/or per account.
  If configured, the maximum allowed disk usage is enforced. By default, no
  maximum is configured. Setting quota for accounts can prevent a single account
  from filling up the disks. (d73bda7)
• When suggesting CAA DNS records (specifying which Certificate Authorities are
  allowed to sign certificates for a domain), suggest variants that bind to the
  ACME account ID, and restricts the validation methods to those used by mox.
  Should prevent MitM close to a machine from requesting TLS certificates through
  ACME as seen on the internet recently. (db3fef4)
• Add config file fields for ACME external account binding (EAB). Some ACME
  providers require EAB to link an ACME account with a non-ACME account at the
  provider. With EAB, more ACME providers can be used with mox. (ee1094e)
• Implement the PLUS-variants of the SCRAM authentication mechanisms:
  SCRAM-SHA-256-PLUS and SCRAM-SHA-1-PLUS. The PLUS variants add TLS channel
  binding: Authentication only succeeds if the client and server are on the same
  TLS connection. Authentication will fail if there is a MitM (that has a valid
  TLS certificate). (e7478ed)
• Use a mail.<domain> CNAME for the SMTP (submission) and IMAP servers of a
  domain, pointing to the mail server host name. Before, clients were instructed
  to configure the mail server host name directly, but that makes it harder to
  migrate the domain to another mail server in the future: All clients would need
  to update their settings. A CNAME can be pointed to a new server without
  requiring changes to client settings. (da3ed38)

Improvements

• The admin, account and mail web interfaces now use session cookie-based
  authentication (with csrf) instead of HTTP authentication. These interfaces
  now have a "logout" button (not possible with HTTP authentication). (#58,
  0f8bf2f)
• Webmail: Don't automatically mark unclassified messages in the Rejects mailbox
  as non-junk when reading them. For all other mailboxes the behaviour is
  unchanged. (416113a)
• Webmail: Ask user to reload the application when the server version has
  changed. (8e37fad)
• Webmail: In the message view, show the DMARC status of the domain of the
  message "From" address. (fb81eff)
• Webmail: When composing, leave out our own address when replying. (7c1879d)
• Junk filtering: Make content-based filtering for first-time senders more
  strict for messages delivered over non-TLS connections, or when the addressee
  isn't in a To/Cc message header. Common for junk, uncommon for non-junk.
  (2ff87a0)
• SMTP server: after "MAIL FROM:" and "RCPT TO:" commands, allow a space (which
  is invalid syntax) also for delivery. We only allowed it for submission,
  assuming only (submitting) mail clients or spammers had sloppy SMTP
  implementations. In practice, also legitimate delivering mail servers have
  sloppy implementations. (#101, af5da17)
• When generating a Authentication-Results message header (with results for
  SPF/DKIM/DMARC/etc), put each result on a new line for better readability.
  (2710a5b)
• Make many non-server Go packages more easily reusable. Package imports were
  changed so more packages can be imported without pulling in mox internals. See
  https://github.com/mjl-/moxtools for a tool that reuses Go packages. It is
  deployed publicly at https://tools.xmox.nl/. As part of this change, mox now
  uses Go's slog package for logging. Changes in the API's between releases are
  tracked at https://github.com/mjl-/mox/tree/main/apidiff. (5b20cba,
  72ac1fd, f3a35a6)
• SMTP server: for submission, if a message has a Return-Path header, only fail
  in pedantic mode. (#103, 57fc37a)
• Webmail: For messages in the Sent mailbox, show To/Cc/Bcc in italic, and show
  all correspondents in collapsed threads. (#104, 802dcef)
• The admin and account web interfaces were changed from JavaScript to
  TypeScript, making it easier to maintain. (a9940f9).
• Implement IMAP-UTF-7 more fully, and allow creating mailboxes with "special"
  characters: "&" (the IMAP-UTF-7 escape character), "#" (the IMAP namespace
  character), "*" and "%" (matching characters). These were not allowed out of
  caution, but occur in real-world mailbox names. Mox now uses IMAP-UTF-7 when
  sending mailbox names for clients that did not enable IMAP4rev2 or UTF8=ACCEPT.
  Before, mox would always send UTF-8, but not all clients understand that, and it
  can cause confusion with IMAP-UTF-7 and "&" escaping. (#110, d84c96e)
• IMAP server: Add STATUS=SIZE as capability. It was already implemented as
  part of IMAP4rev2, but older clients won't recognize that. (59bffa4)
• And more smaller improvements.

Bug fixes

• SMTP server and SMTP smuggling: Mox was itself not vulnerable to SMTP
  smuggling, treating only "\r\n.\r\n" as end of transaction. But two
  improvements have been made: (1f9b640)
  1. Bare carriage returns are no longer accepted during SMTP transactions. Bugs
     in other mail servers can lead them to accept other sequences as
     end-of-transaction, notably "\r.\r". Mox would accept submitted messages with
     that sequence for delivery. Such messages could trigger bugs in other mail
     servers causing them to materialize non-existent messages. By no longer
     accepting bare carriage returns in submitted messages, mox can no longer be used
     to trigger the "\r.\r"-bug in other mail servers. SMTP transactions with a bare
     carriage return now result in an error mentioning SMTP smuggling. Mox can still
     store messages with bare carriage returns, e.g. from imports. Mox already added
     missing carriage returns to bare newlines.
  2. A bug in mox caused sequences of "\nX\n" for any X (including "\n.\n") to
     result in a temporary processing error. For "\n.\n" this accidentially was fine
     behaviour, for other characters the bug has been fixed. Any sequence of
     "\r\n.\r\n" where one or both carriage returns are missing now result in an
     error mentioning SMTP smuggling.
• IMAP server: The on-disk message size was not correctly calculated for messages
  added with the APPEND command (typically used for imported messages and when a
  mail client sends a message) when bare newlines ("\n") got a missing carriage
  return added ("\r\n"). This would cause errors when attempting to read the
  message. If you are affected by this, run "mox fixmsgsize " to fix up
  incorrect message sizes. Reported by daftaupe. (02eb7b5)
• SMTP server: When writing "slow responses" (when a message is deemed junk),
  ensure the total response time isn't too long (slightly less than 30 seconds).
  Slow responses were writing 1 byte per second. With a long response (e.g. long
  error message), a sending mail server may not consume a full response. If mox
  was the sending server, it would report a timeout after 30 seconds. Report by
  naturalethic. (fbc18d5)
• IMAP server: Only send "OLDNAME" in a response to the LIST command when
  IMAP4rev2 is enabled. IMAP4rev1 clients (most common) don't understand it. From
  duesee with imap-flow. (41e3d1a)

Update instructions

Before upgrading, do a dry-run first.

• Make a temporary backup with the old mox version:
  mox-v0.0.8 backup data/tmp/testupgrade
• Verify that all is well with the old version:
  mox-v0.0.8 verifydata data/tmp/testupgrade
• Verify the state with the new version:
  mox-v0.0.9 verifydata data/tmp/testupgrade

With a successful dry-run, the upgrade should go smoothly. Make a new backup
with mox-v0.0.8 backup data/tmp/backup (the previous backup was modified by
the dry-run, so couldn't be used to restore!), replace the binary and restart.
For further details, see
https://github.com/mjl-/mox#how-do-i-upgrade-my-mox-installation

If you run into any problems, please create a bug report.

After upgrading, you may want to:

• Run "mox fixmsg " if you've imported messages over IMAP that have
  bare newlines ("\n" instead of "\r\n").
• Configure your email clients to use authentication mechanism
  SCRAM-SHA-256-PLUS for SMTP (submission) and IMAP, if they support it. If mail
  clients have trouble logging in after upgrading, they may be picking a SCRAM
  PLUS variant without properly supporting it. Explicitly configuring the non-PLUS
  authentication mechanism should fix the problem and ensures a MitM cannot
  downgrade the chosen authentication mechanism by altering the list of supported
  authentication mechanisms.
• Change the CAA records for your domains to include the ACME account id and
  allowed validation methods. See the suggested DNS records for each configured
  domain.
• Set disk usage quota, either globally for all accounts or per account. See
  QuotaMessageSize in mox.conf, https://pkg.go.dev/github.com/mjl-/mox/config.
• Add ClientSettingsDomain: mail.<yourdomain> to each domain in domains.conf,
  add the CNAME record as afterwards suggested in the DNS records page, and
  update client account settings to use the new host name.
• For mox setups configured behind an existing webserver, add "Forwarded: true"
  to the (Admin|Account|Webmail)HTTP(S) sections in mox.conf. It causes them to
  use X-Forwarded-* headers for determining if HTTPS was active (for secure
  cookies), and for the IP used for rate limiting.

Thanks

Thanks for contributions and/or feedback from: Fell, duesee (and
https://github.com/duesee/imap-flow/), daftaupe, naturalethic, jsfan3, Halyul,
mattfbacon, jsaponara, pmarini (and those I missed).

Feedback, feature requests, bug reports, contributions (start small!) are all
welcome. An easy way to help mox is to use it and spread the word!

Development on mox is funded through the NLnet NGI0 Entrust Fund,
https://nlnet.nl/entrust/, with financial support from the European
Commission's Next Generation Internet programme.