TPA-RFC-45: TODOs, challenges (team#41009)

## Long term changes

Those changes are not purely mandatory, but will make our lives easier

in lots of ways.

TODO: justify

TODO: in particular, explain how we don't have control over mailboxes

which makes some security situations harder to handle

in lots of ways. In particular, it will give TPA the capacity to

actually provide email services to people we onboard, something which

is currently left to the user. It should also make it easier to

deliver emails for users, especially internally, as we will control

both ends of the mail delivery system.

We *might* still have trouble delivering email to the outside world,

but that should normally improve as well. That is because we will not

be forwarding mail to the outside, which basically makes use

masquerade as other mail servers, triggering all sorts of issues.

Controlling our users' mailboxes will also allow us to implement

stricter storage policies like on-disk encryption and stop leaking

confidential data to third parties. It will also allow us to deal with

situations like laptop seizures or security intrusions better as we

will be able to lock down access to a compromised or vulnerable user,

something which is not possible right now.

### Mailboxes

This might also include extra work for MTA-STS feedback loops.

TODO  harden DMARC records?

### Hardened DNS records

We should consider hardening our DNS records. This is a minor, quick

change but that we can deploy only after monitoring is in place, which

is not currently the case.

This should improve our reputation a bit as some providers treat a

negative or neutral policy as "spammy".

### CiviCRM bounce rate monitoring

### Staff resources and work overlap

We are already a rather busy team, and the work planned in this

proposal overlaps with the work planned in [TPA-RFC-43][].

proposal overlaps with the work planned in [TPA-RFC-33][].

It is our belief, however, that we could split the difference in a way

that we could allocate some resources (e.g. lavamind) to building the

new cluster and other resources (e.g. anarcat, kez) to deploying

emergency measures and the new mail services.

We do, however, have to deal with this emergency, and we would much

rather have a clear plan on how to move forward with email, even if

that means we can't execute this for months, if not years, until

things calm down and we get capacity. We have designed the tasks to be

independent form each other as much as possible and much of the work

can be done incrementally.

### TPA-RFC-15 challenges

The infrastructure planned here recoups many of the challenges

The infrastructure planned recoups many of the challenges

described in the [TPA-RFC-15 proposal][tpa-rfc-15#challenges], namely:

 * Aging Puppet code base: this is mitigated by focusing on monitoring

   and emergency (non-Puppet) fixes at first, but [issue 40626][]

   remains, of course; note that this is an issue that needs to be

   delt with regardless of the outcome of this proposal

   ("cleanup the postfix code in puppet") remains, of course; note

   that this is an issue that needs to be dealt with regardless of the

   outcome of this proposal

 * Incoming filtering implementation: still somewhat of an unknown,

   although TPA operators have experience setting up spam filtering

   the inbox system to later, and using sender rewriting (or possibly

   [ARC][])

 * Security concerns: those remain an issue

 * Security concerns: those remain an issue. those are two-folder:

   lack of 2FA and extra confidentiality requirements due to hosting

   people's emails, which could be mitigated with mailbox encryption

 * Naming things: somewhat mitigated in [TPA-RFC-31][] by using "MTA"

   or "transfer agent" instead of "relay"

[challenges in TPA-RFC-31]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-31-outsource-email#challenges

### TPA-RFC-44 challenges

TODO

### Still more delays

### More delays

As foretold by [TPA-RFC-31: Challenges, Delays][], we are running out

of time. Making this proposal takes time, and deploying yet another

strategy will take more time.

As foretold by [TPA-RFC-31: Challenges, Delays][] and [TPA-RFC-44:

More delays][], we're now officially late.

[TPA-RFC-31: Challenges, Delays]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-31-outsource-email#delays

It doesn't seem like there is much of an alternative here, however; no

clear outsourcing solution seems to be available to us at this stage,

and even if they would, they would also take time to deploy.

We don't seem to have much of a choice, at least for the emergency

work. We *must* perform this upgrade to keep our machines secure.

The key aspect here is that we have a very quick fix we can deploy on

CiviCRM to see if our reputation will improve. Then a fast-track

strategy allows us, in theory, to deploy those fixes everywhere

without rebuilding everything immediately, giving us a 2 week window

during which we should be able to get results.

For the long term work, it will take time to rebuild our mail

infrastructure, but we prefer to have a clear, long-term plan to the

current situation where we are hesitant in deploying any change

whatsoever because we don't have a design. This hurts our users and

our capacity to help them.

If we fail, then we fall back to outsourcing again, but at least we

gave it one last shot.

It's possible we fail at providing good email services to our

users. If we do, then we fall back to outsourcing mailboxes, but at

least we gave it one last shot and we don't feel the costs are so

prohibitive that we should just *not* try.

### User interface changes

[TPA-RFC-44: More delays]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-44-email-emergency-recovery#more-delays

TODO mention changes between gmail and roundcube

### User interface changes

### Spam filtering

Self-hosting, when compared to commercial hosting services like Gmail,

suffer from significant usability challenges. Gmail, in particular,

has acquired a significant mind-share of how email should even work in

the first place. Users will be somewhat jarred by the change and

frustrated by the unfamiliar interface.

TODO mention how hard that is and unpredictable

One mitigation for this is that we *still* allow users to keep using

Gmail. It's not ideal, because we keep a hybrid design and we still

leak data to the outside, but we prefer this to forcing people into

using tools they don't want.

## Architecture diagram

TODO https://www.xmox.nl/ - no relay support or 1.x release

TODO review other single-stack things

## TODO mailbox encryption

## TODO harden mail submission server

# Approval

Executive director, TPA.