eugeni has been decomissioned authored by groente's avatar groente
......@@ -466,7 +466,7 @@ the submission server.
The `FilesInVarMail` alert looks like this:
Files are present in /var/mail on eugeni.torproject.org
Files are present in /var/mail on mx-dal-01.torproject.org
This happens when Postfix doesn't find a proper alias to deliver mail
for a user and ends up writing to a mailbox in /var/mail. Normally,
......@@ -584,19 +584,12 @@ At this point it's a good idea to [test outgoing mail](#testing-outgoing-mail):
On some hosts it's not practical to configure OpenDKIM because it generates
some mail but otherwise doesn't process mail, so its `mail_processing` flag is
not enabled. Usually such hosts route their outbound email though `eugeni`, so
not enabled. Usually such hosts route their outbound email though `mta-dal-01`, so
we can use it to sign email on behalf of other hosts.
To do this, add the host's FQDN to the `profile::opendkim::internal_hosts`
Hiera key in `hiera/roles/mta.yaml`. If the host sends mail using the
`@torproject.org` sender domain, nothing more is needed. Otherwise, when the
host uses a subdomain in its mail sender domain, eg. `foo.torproject.org` then
we need to add a new DNS entry by copying the `eugeni` DKIM key DNS entry
`2022-eugeni._domainkey` to a new DNS entry `2022-eugeni._domainkey.foo`.
#### Manual DKIM configuration (deprecated)
This is a rushed OpenDKIM deployment procedure that was used in
This was a rushed OpenDKIM deployment procedure that was used in
[tpo/tpa/team#40981][] and [tpo/tpa/team#40988][] (eugeni and
submit-01). It has been added to Puppet in [tpo/tpa/team#40989][].
......@@ -704,7 +697,7 @@ already does some content filtering.
It's possible that some mail doesn't get signed when injected from
Mailman, consider changing the `InternalHosts` to:
InternalHosts eugeni.torproject.org,lists.torproject.org,127.0.0.1,::1,localhost # cargo-culted, to remove?
InternalHosts lists-01.torproject.org,lists.torproject.org,127.0.0.1,::1,localhost # cargo-culted, to remove?
If the signatures come from another server and cause problems (for
example with Mailman), you can strip those with:
......@@ -717,24 +710,27 @@ example with Mailman), you can strip those with:
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:
interpretation of our (current, 2025) policy:
#### torproject.org
```
@ IN TXT "v=spf1 a:crm-int-01.torproject.org a:eugeni.torproject.org a:submit-01.torproject.org ~all"
@ 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"
```
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
We use the `a:` mechanism to point at 6 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
* `rdsys-frontend-01`, the rdsys server
* `polyanthum`, the bridges server
* `srs-dal-01`, the sender-rewriting server
* `mta-dal-01`, our MTA
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
......
......