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:
-
Deploy a new, sender-rewriting, mail exchanger (#40987) -
split long-term parts of TPA-RFC-44 out of it into a new proposal (yes, editing the standard, omg) -
update service/email.md to link to TPA-RFC-45 when done
and probably many more...