TPA-RFC-45: long term mail architecture plans
In TPA-RFC-44 (#40981 (closed)), we made a pretty stab at deploying urgent fixes to ensure better deliverability across servers and services. It seems we have mostly recovered from the dramatic gmail delivery failures.
But we are still likely to have delivery problems because we forward mail a lot. In fact, we only forward mail still: we don't offer people mailboxes, in any shape or form.
There are also clunky things in the way email is setup: all mail routes through eugeni, except not all mail. Some of that mail gets signed by eugeni, but then those keys are not under the right host.
TPA-RFC-44 featured a long term, ambitious plan to fix all of those problems and more. Review this plan to come up with something that may work for 2023 and the forseeable future.
This may include outsourcing, but should include cost estimates, in any case.
Once this is adopted, if this is like TPA-RFC-44 and it blows up in N more tickets, create a milestone for the RFC so we can do better time tracking.
Minimal task list:
-
split long-term parts of TPA-RFC-44 out of it into a new proposal (yes, editing the standard, omg)nah we'll just make a new proposal, old one is good as an archive -
survey users on requirements (#41657) -
propose and adopt TPA-RFC-45 https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-45-mail-architecture -
summary -
background -
requirements -
scope -
affected users -
actual proposal -
cost estimates -
timeline -
challenges -
architecture diagrams -
personas -
alternatives -
deadline -
check all TODOs -
editing -
propose -
review from comments -
adopt or reject
-
-
followup work: -
make milestone(s) (for each phase?) and issues -
update service/email.md to link to TPA-RFC-45 when done -
Deploy a new, sender-rewriting, mail exchanger (#40987)
-
and probably many more...