document the SPF setup authored by anarcat's avatar anarcat
...@@ -185,7 +185,105 @@ example with Mailman), you can strip those with: ...@@ -185,7 +185,105 @@ example with Mailman), you can strip those with:
### SPF records ### SPF records
TODO: summarize https://gitlab.torproject.org/tpo/tpa/team/-/issues/40981 In [tpo/tpa/team#40990](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40990), anarcat deployed "soft" [SPF](https://en.wikipedia.org/wiki/Sender_Policy_Framework) records
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 our (current, 2022) policy:
#### torproject.org
```
@ IN TXT "v=spf1 a:crm-int-01.torproject.org a:eugeni.torproject.org a:submit-01.torproject.org ~all"
```
This is a "soft" (`~all`) record that will tell servers to downgrade
the reputation of mail send with a `From: *@torproject.org` header
when it doesn't match any of the preceding mechanisms.
We use the `a:` mechanism to point at 3 servers that normally should
be sending mail as `torproject.org`:
* `crm-int-01`, the [CRM](service/crm) server
* `eugeni`, the main mail server
* `submit-01`, the submission mail server
The `a` mechanism tells SPF-compatible servers to check the `A` and
`AAAA` records of the given server to see if it matches with the
connecting server.
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
Some servers have a record like that:
```
db IN A 49.12.57.132 ; alberti
IN AAAA 2a01:4f8:fff0:4f:266:37ff:fea1:4d3 ; alberti
IN MX 0 alberti
IN TXT "v=spf1 a ~all"
```
This is also a "soft" record that tells servers to check the `A` or
`AAAA` records (`a`) to see if it matches the connecting server. It
will match only if the connecting server has an IP matching the `A` or
`AAAA` record for `db.torproject.org`.
#### lists.torproject.org: mx
```
lists IN TXT "v=spf1 mx ~all"
```
This is also a "soft" record that tells servers to check the Mail
Exchanger record (`MX`) to see if it matches the connecting server.
It might be better to use a `a:` record here to avoid a DNS lookup,
but it might actually be possible that the MX for lists is in a
different location than the web interface, for example.
#### gitlab: a and CNAME
Some mail servers have a record like:
```
gitlab IN CNAME gitlab-02
gitlab-02 IN TXT "v=spf1 a ~all" ; no one else than gitlab can send for gitlab
```
This is similar to the `db` record in that it uses a `a` mechanism,
but the actual name is behind a `CNAME` record.
In other words, only that server can send email as
`gitlab-02.torproject.org`. But since there's also a `CNAME` from
`gitlab` to `gitlab-02`, this policy actually also applies to
`gitlab.torproject.org`:
$ dig -t txt gitlab.torproject.org +nostats +nocomments +nocmd +noquestion
gitlab.torproject.org. 1415 IN CNAME gitlab-02.torproject.org.
gitlab-02.torproject.org. 3496 IN TXT "v=spf1 a ~all"
#### CRM: hard record
Finally, one last example is the CiviCRM records:
```
crm IN A 116.202.120.186 ; crm-int-01
IN AAAA 2a01:4f8:fff0:4f:266:37ff:fe4d:f883
IN TXT "v=spf1 a -all"
IN MX 0 crm
```
Those are similar to the `db.torproject.org` records except they are
"hard" (`-all`) which should, in theory, make other servers completely
reject attempts from servers not in the `A` or `AAAA` record of
`crm.torproject.org`.
#### Debugging SPF
[vamsoft's SPF checker](https://vamsoft.com/support/tools/spf-policy-tester) is good to quickly diagnose issues.
### DMARC records ### DMARC records
... ...
......