@@ -590,7 +590,7 @@ The MX resolves all aliases. It does *not* resolve forwards, but transports them
The SRS server resolves all forwards, applies sender rewriting when necessary, and sends the mail out into the world.
### MX
### Mail exchangers
Our MX servers, currently only mx-dal-01, are managed by the profile::mx manifest.
...
...
@@ -606,25 +606,10 @@ MX servers need a letsencrypt certificate, so be sure to add them to the `letsen
MX servers need to be manually added to the torproject.org MX record and have a matching PTR record.
#### spamfiltering
MX servers run rspamd and clamav for spam filtering, see the [spam
filtering section below](#spam-filtering).
MX servers run rspamd and clamav for spamfiltering.
In case of false positives or negatives, you can check the logs in /var/log/rspamd/rspamd.log
You can tweak the configuration in the profile::rspamd manifest. You can manually train the bayes classifier by running:
```
/usr/bin/rspamc -h localhost learn_spam
```
or
```
/usr/bin/rspamc -h localhost learn_ham
```
#### aliases and forwards
#### Aliases and forwards
Aliases are defined in `data/common/mail.yaml` and end up in `/etc/postfix/maps/alias`.
...
...
@@ -662,7 +647,7 @@ SRS servers need to be manually added to:
and must have a matching PTR record.
#### sender address rewriting
#### Sender address rewriting
The sender address rewriting ensures forwarded mail originating from other domains doesn't break SPF by rewriting the from address to @torproject.org. This only affects the envelope-from address, not the header from.
...
...
@@ -670,7 +655,7 @@ The sender address rewriting ensures forwarded mail originating from other domai
Anything with a header from @torproject.org will be DKIM signed by the SRS server. This is done by rspamd. The required DNS record is automatically created by puppet.
### resolving and sending of forwards
### Resolving and sending of forwards
Forwards are defined in two places:
...
...
@@ -687,7 +672,7 @@ This should return the address to forward to.
### Submission
Our submission server, submit-01, is managed by the profile::submission manifest.
Our submission server, submit-01, is managed by the `profile::submission` manifest.
It provides the following functionality:
...
...
@@ -763,7 +748,7 @@ Other TPO nodes are authenticated using client certificates. Distribution is don
Anything with a header from @torproject.org will be DKIM signed by the submission server. This is done by rspamd. The required DNS record is automatically created by puppet.
## Regular nodes
### Regular nodes
Regular nodes have no special mail needs and just need to be able to deliver mail. They can be recognised in puppet by having profile::postfix::independent set to false (the default value). They use our MTA servers as relayhost. This is taken care of by the profile::postfix manifest, which is included on all TPO nodes.
...
...
@@ -776,7 +761,7 @@ By default, system users will mail as @hostname.torproject.org . This has two di
We should ideally ensure an @torproject.org address is used for outgoing mail.
## Independent mailers
### Independent mailers
Independent mailers are nodes that receive mail on their own subdomain (which should be different from the node's fqdn) and/or deliver mail themselves without using our MTA. They can be recognised in puppet by having profile::postfix::independent set to true.
...
...
@@ -802,7 +787,7 @@ If your node is going to deliver its own mail, you need to:
Examples of independent mailers are: lists-01.torproject.org, crm-int-01.torproject.org, rt.torproject.org
## DMARC
### DMARC
[DMARC](https://en.wikipedia.org/wiki/DMARC) records glue together SPF and DKIM to tell which *policy*
to apply once the rules defined above check out (or not). It is
...
...
@@ -836,7 +821,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:
@@ -864,7 +849,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:
...
...
@@ -880,7 +865,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"
...
...
@@ -893,7 +878,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:
...
...
@@ -909,13 +894,13 @@ Those are similar to the `db.torproject.org` records except they are
reject attempts from servers not in the `A` or `AAAA` record of
`crm.torproject.org`. Note that `-all` is rarely enforced this strictly.
## DANE
### DANE
TLSA records are created through puppet using the tlsaport parameter of the ssl::service resource.
We enforce DANE on all outgoing connections, except for stanford (what the hell, stanford?). This is defined in the tls_policy map in profile::postfix.
## Spamfiltering
### Spamfiltering
We use rspamd and clamav for spamfiltering.
...
...
@@ -925,7 +910,7 @@ Suspicion of possible spam results in grey listing, with spam results added as h
In case of false positives or negatives, you can check the logs in /var/log/rspamd/rspamd.log
You can tweak the configuration in the profile::rspamd manifest. You can manually train the bayes classifier by running:
You can tweak the configuration in the `profile::rspamd` manifest. You can manually train the bayes classifier by running:
