diff --git a/policy/tpa-rfc-15-email-services.md b/policy/tpa-rfc-15-email-services.md index cdaa71f42142dfda6734779c35ea3384ecf75137..e787ab33a4d36f613d8e304a1923ea8395ec308a 100644 --- a/policy/tpa-rfc-15-email-services.md +++ b/policy/tpa-rfc-15-email-services.md @@ -75,6 +75,26 @@ server uses it for authentication. [issue 40539]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40539 [issue 19914]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/19914 +### Processing mail servers + +Those servers handle their own outgoing email (ie. they do *not* go +through `eugeni`) and handle incoming email as well, unless otherwise +noted: + + * BridgeDB (`polyanthum`) + * CiviCRM (`crm-int-01`, Dovecot) + * Gettor (`gettor-01`) + * GitLab (`gitlab-02`) + * LDAP (`alberti`) + * MTA (`eugeni`) + * Nagios/Icinga (`hetzner-hel1-01`, no incoming) + * Prometheus (`prometheus-02`, no incoming) + * RT (`rude`) + * Submission (`submit-01`) + +Surprisingly, the Gitolite service (`cupani`) does *not* relay mail +through the MTA (`eugeni`). + ## Known issues The current email infrastructure has many problems. In general, @@ -255,20 +275,30 @@ replacing a part of `eugeni`. ### New mail relays Configure new "mail relay" server(s) to relay mails from servers that -do not send their own email, replacing a part of `eugeni`. +do not send their own email, replacing a part of `eugeni`. Those are +temporarily called `submission-tls` but could be named something else, +see the [Naming things](#naming-things) Challenge below. This is similar to current submission server, except with TLS authentication instead of password. ### DKIM and ARC signatures -Implement outgoing DKIM signatures, probably with OpenDKIM. +Implement outgoing DKIM signatures, probably with OpenDKIM. This will +actually involve deploying that configuration on *any* server that +produces outgoing email. Each of those servers (listed in "Processing +mail servers" above) will therefore require its own DKIM records and +running a copy of the DKIM configuration. ### SPF/DMARC records -Deploy of SPF and DMARC DNS records, which will impact users not on -the submission and IMAP servers. This includes users with plain -forwards and without an LDAP account. +Deploy of SPF and DMARC DNS records to a strict list of allowed +servers. This list should include any email servers that send their +own email (without going through the relay, currently `eugeni`), +listed in the "Processing mail servers" section. + +This will impact users not on the submission and IMAP servers. This +includes users with plain forwards and without an LDAP account. Possible solutions for those users include: @@ -432,6 +462,32 @@ we suddenly have a much higher risk of leaking personal data in case of compromise. This is a trade-off with the privacy we gain from not giving that data to a third party. +### Naming things + +Throughout this document, the term "relay" has been used liberally to +talk about a new email server processing email for other +servers. That terminology, unfortunately, clashes with the term +"relay" used extensively in the Tor network to designate "Tor relays", +which create circuits that make up the Tor network. + +As a stopgap measure, the new relays were called `submission-tls` in +the architecture diagram, but that is also problematic because it +might be confused with the current `submission` server, which serves a +very specific purpose of relaying mail for *users*. + +Technically, the `submission` server and the `submission-tls` servers +are both MTA, or a [Message Transfer Agent][MTA]. Maybe that terminology +could be used for the new "relay" servers to disambiguate them from +the submission server, for example the first relay would be called `mta-01.torproject.org`. + +Or, inversely, we might want to consider both servers to be the same +and both name them `submission` and have the `submission` service also +accept mail from other TPO servers over TLS. So far that approach has +been discarded to separate those tasks, as it seemed simpler +architecturally. + + [MTA]: https://en.wikipedia.org/wiki/Message_transfer_agent + ## Cost estimates Summary: @@ -649,6 +705,23 @@ They will have to reconfigure their mail server to relay mail through the submission server. They will also likely start using the IMAP server. +## Blipblop, the bot + +Blipblop is not a real human being, it's a program that receives mails +from humans and acts on them. It can send you a list of bridges +(bridgedb), or a copy of the Tor program (gettor), when requested. It +has a brother bot called Nagios/Icinga who also sends unsolicited mail +when things fail. Both of those should continue working properly, but +will have to be added to SPF records and an adequate OpenDKIM +configuration should be deployed on those hosts as well. + +There's also a bot which sends email when commits get pushed to +gitolite. That bot is deprecated and is likely to go away. + +In general, attention will be given to those precious little bots we +have everywhere that send their own email. They will be taken care of, +as much as humanely possible. + # Other alternatives Those are other alternatives that were considered as part of drafting