Deliver mail between servers and enable client-server connections over Onion services

[dkg]

I read #487 and i like the direction of work that's taking, but i wonder whether there is a simpler step chatmail can take to get some of the network resiliency benefits of onion routing without having to re-architect message delivery.

onionmx describes how to route mail from normal (non-onion) domains over onion services, in a way that has been working for a few dozen providers for many years.

Even simpler, it seems, would be to add an XXX.onion MX record, and XXX.onion SRV records for _submission._tcp and _imap._tcp .

This still leaves in place the dependency on DNS and DKIM, but it enables chatmail servers and clients to avoid network-layer blocking for all communications as long as they can reach Tor.

[link2xt]

Last time we evaluated onionmx it had a problem with MTA-STS: ehloonion/onionmx#29
We have since removed MTA-STS, so this can be revisited: #488
onionmx with no TLS may still be a reduction in security compared to using TLS.

SRV records are irrelevant, we never resolve them in https://github.com/chatmail/core/ and use https://www.ietf.org/archive/id/draft-ietf-mailmaint-autoconfig-03.html instead. As for adding .onion domain to autoconfig, it will not work with existing clients because they still expect TLS and don't treat .onion differently. Clients also only look into autoconfig file during initial configuration, so .onion domain cannot be changed afterwards.

This still leaves in place the dependency on DNS and DKIM, but it enables chatmail servers and clients to avoid network-layer blocking for all communications as long as they can reach Tor.

For clients this is already possible, they can use Tor to reach existing chatmail servers.