New features:

• DNSSEC-awareness throughout the code base, based on https://github.com/mjl-/adns, a fork of Go's DNS resolver. DNSSEC is a requirement for DANE (see below). If you don't have a DNSSEC-verifying stub resolver configured, DNS lookups are regarded as unverified. Installing unbound and and is still the recommended action.
• DANE for incoming and outgoing delivery (RFCs 7672, 6698 and 7671). DANE is a mechanism to require verified TLS (with STARTTLS) for delivery over SMTP. Verification with DANE does not use the global WebPKI/PKIX pool of Certificate Authorities. With DANE, verification is done based on DNS records of type TLSA. These records specify (hashes of) public keys to allow (DANE-EE), ignoring expiration/hostname-match/issuing party, and/or they specify (hashes of) certificates of allowed certificates authorities (DANE-TA), regardless of whether those authorities are in the globally trusted WebPKI/PKIX CA pool. DANE requires that DNS records are DNSSEC-protected, both to protect the MX records and the TLSA records. MTA-STS (already implemented) has similar goals, but does use the WebPKI/PKIX Certificate Authorities pool, both to verify TLS certificates and to protect MX records. DANE and MTA-STS can coexist: In the default configuration, mox generates private keys, then retrieves certificates from Let's Encrypt for these private keys (through https://github.com/mjl-/autocert, a fork of golang.org/x/crypto/acme/autocert). These certificates are valid for MTA-STS, and TLSA records are generated for the keys for verification with DANE. For inbound delivery with DANE protection, your DNS records must be DNSSEC-protected. For outbound delivery with DANE protection, a trusted DNSSEC-verifying stub resolver is required.
• Mox now compiles on Windows, so "mox localserve" and most other commands to work, but "mox serve" (the actual mail server) does not yet work.
• "SMTP Require TLS Option" (RFC 8689), consisting of two mechanisms:
  1. A REQUIRETLS SMTP extension to require verified TLS along each hop in message delivery, either through MTA-STS or DANE.
  2. A message header "TLS-Required: No", that overrides any TLS requirement along the way as specified by any MTA-STS or DANE policy. These mechanisms can be used to ensure secure delivery, or to work around delivery issues due to TLS requirements. Mox remembers whether an SMTP server offered the REQUIRETLS extension. Webmail automatically selects it if all recipients support it. Webmail also lets the user select the "TLS-Required: No" header.
• Outgoing DMARC reports (RFC 7489). Mox now stores the results of DMARC evaluations for inbound messages. These results can be viewed in the admin web pages. Reports are typically sent every 24 hours (covering a 24 UTC day), but will be sent for up to 1 hour intervals if requested by a domain. Sending DMARC reports is enabled by default, but can be disabled through new option NoOutgoingDMARCReports in mox.conf. Reporting addresses can be added to a suppression list, to reduce noise due to deliverability issues. Incoming DMARC reports were already implemented.
• Outgoing SMTP TLS reporting (RFC 8460). When delivering outbound messages, the SMTP client will look up MTA-STS and/or DANE policies for TLS requirements, with a fallback to opportunistic TLS. The evaluated security policies, (TLS) connection success/failure counts, and any failure details, are stored. Reports are sent once per day to reporting addresses in the TLSRPT DNS record of a domain, over a 24 hour UTC day period. By default, reports are only sent if there was a failure. The pending results can be viewed in the admin web pages. Sending reports can be disabled with new option NoOutgoingTLSReports in mox.conf. Reports with only successes can be enabled through OutgoingTLSReportsForAllSuccess. Reporting addresses can be added to a suppression list to reduce noise due to delivery failures.

Improvements:

• Webmail: Recognize encoded file names in message attachments. Either with RFC2231-encoding (as specified) or Q/B-word encoding (as used in practice). (#82)
• Webmail: For portait images, don't let image extend beyond window height.
• Webmail: Wrap long header lines, instead of showing horizontal scrollbar.
• Webmail: Replying without having text selected now starts a top-post with an "On ... wrote:"-line. Replying with text selected still starts a bottom-post containing only the selected text, quoted. (#83)
• Webmail: In the compose window, autoresize address input fields to match the content.
• Webmail: When composing a message, show security properties of recipient addresses: Whether STARTTLS is known to be offered by the SMTP server (historically), whether MTA-STS is implemented, whether MX records are DNSSEC-signed, whether DANE is implemented, and whether REQUIRETLS is offered by the SMTP server (historically).
• Webmail: Add clear marker between message header and body, so an HTML message cannot fake being part of the UI.
• Webmail: If a "display name" of an address contains address-like characters ("@" or "<" or ">"), only display the actual email address in the message listing, not the display name. Should prevent confusion attacks with messages specifying an unrelated email address in the display name.
• The suggested SRV DNS record for autodiscovery now points directly to the host name, not to a CNAME (which is technically invalid, but seems to work in practice).
• When ACME-validation for a new TLS certificate fails, log error messages that may explain the reason. E.g. "your CAA record forbids Let's Encrypt from issuing certificates".
• SMTP server: workaround for Windows Mail that has invalid additional space in its "AUTH PLAIN" command.
• Fix delivery to recipient domains with an MX host containing an underscore, such as "_dc-mx.." as apparently used by cloudflare. From richard g.
• When generating a DSN message (for delivery failure), try harder to DKIM-sign it: With a configured domain, also when sending from postmaster@mailhost..
• For incoming messages, track whether TLS and REQUIRETLS was used during delivery, and whether the message matched a forwarding or mailing list rule, and show it in the webmail.
• In logging, change "fatal io error" to just "io error". The "fatal" sounds too serious, it's just the connection that will be closed. (#39)
• Add rfc/xr.go to generate HTML pages with cross-referenced code and RFC. These HTML pages are published at https://www.xmox.nl/xr/dev/
• Webmail: In case of long lists of addresses in To/Cc/Bcc headers, only show the first 4 addresses along with a "More" button. (#98)
• Clarify documentation on importing messages from the command-line, which can be unintuitive due to systemd service file mount points. (#79)
• Implement obsolete SASL LOGIN for submission, for interoperability with the new cloud Outlook.
• Fix IMAP ESEARCH response for clients before IMAP4rev2, notably cloud Outlook.
• Many small improvements.

Bug fixes:

• Security: When looking up MTA-STS policies, don't follow CNAME records for the recipient domain. A single unauthenticated CNAME response could redirect policy lookup to another domain.
• Webmail: When replying to selected text consisting of characters in multiple unicode blocks, don't loose some of the selected text in the reply.
• Don't parse DKIM "selectors" as IDNA domains. They are just DNS labels. Based on email from richard g.
• Update to latest bstore (database library) to fix a bug with deleting/updating records. Problem found during development of new features, behaviour not seen in any committed version.
• Webmail: Fix the date shown in the message headers. It was off by the timezone.
• Fix concurrency bug with accessing a math/rand PRNG with Read. Mostly replaced with crypto/rand. Found during development and tests.
• The queue page on the webadmin would fail with a JS error when a message was in the queue and no transport was configured (which is the default).
• For domains configured only to accept DMARC reports, don't request an autoconfig TLS certificate through ACME at startup.
• For incoming messages, convert bare newlines to carriage return+newline. The import code already did this. Having bare newlines could cause imapserver's fetch command to fail with a (connection) panic in some cases.

Update instructions:

Before upgrading, you should do a dry-run first:

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

With a successful dry-run, the upgrade should go smoothly. Make a new backup with mox-v0.0.7 backup data/tmp/backup (the previous backup used for the dry-run has been modified, so couldn't be used to restore!), replace the binary and restart.

If you are upgrading from v0.0.6, see its upgrade instructions for commands to execute. It's better to immediately upgrade to v0.0.8 (see issue #71).

If you run into any problems, please create an issue.

After upgrading, you may want to configure DANE:

To make use of DANE for outbound deliveries, make sure you have a trusted DNSSEC-verifying stub resolver. Unbound is recommended. Don't use systemd-resolved, its DNSSEC support is not ready for use.

To make use of DANE for inbound deliveries, first make sure your DNS records are DNSSEC signed, and your DNS operator supports TLSA records. The SMTP TLS private keys ("host keys) should be added to the TLS section of the "public" listener in mox.conf. If you use ACME (e.g. with Let's Encrypt), you will want to use the private keys of existing certificates. Run "mox config ensureacmehostprivatekeys" to find existing or generate new private keys, and print the config snippets you'll have to apply to mox.conf.

You may want to update your autodiscovery DNS record. See the "DNS check" admin page or run "mox config dnscheck ".

Thanks:

Thanks for contributions and/or feedback from: taavi, naturalethic, mattfbacon, duesee, mpldr, richard g, ArnoSen (and those I missed).

Feedback, requests, bug reports, contributions (start small!) are all welcome.

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.

To download, see https://github.com/mjl-/mox#download