add "bot" to personas

This actually impacts a lot of things, as we need to take those
servers into account when we do SPF and DKIM. Right now, I think the
plan is to grant those servers their own DKIM keys.

Also note the confusion about the name of `relay` which I thought I
already did cover, but now that becomes a little more obvious as we
start to refer to those things.

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