Deploy a new, sender-rewriting, mail exchanger

TPA-RFC-44 emergency procedures (#40981 (closed)) was adopted, let's move on with the next step:

Configure new "mail exchanger" (MX) server(s) with TLS certificates signed by a public CA, most likely Let's Encrypt for incoming mail, replacing that part of eugeni.

This would take care of forwarding mail to other services (e.g. mailing lists) but also end-users.

To work around reputation problems caused by SPF records (below), deploy a Sender Rewriting Scheme (SRS) with postsrsd (packaged in Debian) and postforward (not packaged in Debian, but zero-dependency Golang program).

Having it on a separate mail exchanger will make it easier to swap in and out of the infrastructure if problems would occur.

The mail exchangers should also sign outgoing mail with DKIM.

implementation

we now have 2 new machines:

• mx-dal-01.torproject.org
  • has a TLS certificate signed by a public CA
  • resolves the same aliases as eugeni does
  • transports all mail with external forwards to srs-dal-01.torproject.org
  • does DMARC checks and adds Authentication-Results headers
  • rejects only the most blatantly obvious spa
  • greylists anything that might be spam, this still needs testing
  • should probably do AV scanning with clamav
  • should probably reject unauthorised incoming mail claiming to be from torproject.org, see #41889
  • has DANE
  • should accept incoming mail for node subdomains (e.g., nevii.torproject.org)
  • has basic monitoring, more to be implemented in #40494
  • needs MX records pointed at it (only after thorough review and testing!)
• srs-dal-01.torproject.org
  • accepts connections from mx-dal-01.torproject.org
  • forwards mail to their external addresses, using SRS
  • DKIM signs mail with a From: @torproject.org header
  • needs rate limiting on outgoing mail
  • should adapt its tls policy for stanford.edu
  • dkim key has been added to DNS
  • has been added to the SPF record

these both make direct queries to LDAP to fetch forwarding information, in contrast to the previous ud-ldap based provisioning. this saves us from having to deal with ud-ldap, but introduces LDAP as SPOF, we should find a way to harden this. See also: #41888

I've started documenting this setup here: https://pad.tails.net/S70AP1A1R16-5hn8IodD1w#