service/email.md

@@ -514,7 +514,6 @@ and use their personal address instead of user@torproject.org.
 
 # Reference
 
-
 ## Mail servers
 
 ### Design & architecture
@@ -578,6 +577,7 @@ or
 Aliases are defined in `data/common/mail.yaml` and end up in `/etc/postfix/maps/alias`.
 
 Forwards are defined in two places:
+
   - in `data/common/mail.yaml`, eventually ending up in `/etc/postfix/maps/transport`,
   - in LDAP. MX runs a local LDAP replica which it queries, according to `/etc/postfix/maps/ldap_local`
 
@@ -604,8 +604,10 @@ SRS servers *only* receive mail from our MX servers.
 SRS servers need a letsencrypt certificate, so be sure to add them to the `letsencrypt-domains` repo.
 
 SRS servers need to be manually added to:
+
   - the srs.torproject.org MX record
   - the torproject.org SPF record
+
 and must have a matching PTR record.
 
 #### sender address rewriting
@@ -619,6 +621,7 @@ Anything with a header from @torproject.org will be DKIM signed by the SRS serve
 ### resolving and sending of forwards
 
 Forwards are defined in two places:
+
   - in `data/common/mail.yaml`, eventually ending up in `/etc/postfix/maps/alias`,
   - in LDAP. SRS runs a local LDAP replica which it queries, according to `/etc/postfix/maps/alias_local`
 
@@ -648,10 +651,12 @@ Submission servers need a letsencrypt certificate for both their fqdn and submis
 ```
 
 The submission server needs to manually have:
+
   - an MX record for submission.torproject.org
   - an A record for submission.torproject.org
   - an SRV record for _submission._tcp.torproject.org
   - an entry in the torproject.org SPF record
+
 and must have a matching PTR record.
 
 There is currently no easy way to turn this into a highly available / redundant service, we'd have to research how different clients support failover mechanisms.
@@ -692,8 +697,10 @@ The submission server *only* receives mail on the submission port from other TPO
 MTA servers need a letsencrypt certificate, so be sure to add them to the `letsencrypt-domains` repo.
 
 MTA servers need to be manually added to:
+
   - the mta.torproject.org MX record
   - the torproject.org SPF record
+
 and must have a matching PTR record.
 
 #### Authentication
@@ -756,7 +763,7 @@ for all outgoing mail servers under `torproject.org`. The full
 specification of SPF is in [RFC7208](https://www.rfc-editor.org/rfc/rfc7208), here's a condensed
 interpretation of some of our (current, 2025) policies:
 
-#### torproject.org
+### torproject.org
 
 ```
 @           IN  TXT "v=spf1 a:crm-int-01.torproject.org a:submit-01.torproject.org a:rdsys-frontend-01.torproject.org a:polyanthum.torproject.org a:srs-dal-01.torproject.org a:mta-dal-01.torproject.org ~all" 
@@ -784,7 +791,7 @@ We use the `a:` mechanism instead of the (somewhat more common) `ip4:`
 mechanism because we do not want to add both the IPv4 and IPv6
 records.
 
-#### db.torproject.org: a
+### db.torproject.org: a
 
 Some servers have a record like that:
 
@@ -800,7 +807,7 @@ This is also a "soft" record that tells servers to check the `A` or
 will match only if the connecting server has an IP matching the `A` or
 `AAAA` record for `db.torproject.org` or `alberti.torproject.org`.
 
-#### lists.torproject.org: mx
+### lists.torproject.org: mx
 
 ```
 lists       IN  TXT "v=spf1 mx a:mta.tails.net a:lists-01.torproject.org a ~all"
@@ -813,7 +820,7 @@ It also allows the Tails schleuder server to send as lists.torproject.org using
 The `a` and `a:lists-01.torproject.org` are redundant here, but it might actually be possible that the MX for lists is in a
 different location than the web interface, for example.
 
-#### CRM: hard record
+### CRM: hard record
 
 Finally, one last example is the CiviCRM records: