v0.0.8

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