Changes

Page history
email: fix headings and remove duplicate spam filter section authored by anarcat's avatar anarcat
Show whitespace changes
Inline Side-by-side
service/email.md
View page @ 69783766
...@@ -590,7 +590,7 @@ The MX resolves all aliases. It does *not* resolve forwards, but transports them ...@@ -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. 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. 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 ...@@ -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. 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. #### Aliases and forwards
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 are defined in `data/common/mail.yaml` and end up in `/etc/postfix/maps/alias`. 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: ...@@ -662,7 +647,7 @@ SRS servers need to be manually added to:
and must have a matching PTR record. 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. 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 ...@@ -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. 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: Forwards are defined in two places:
...@@ -687,7 +672,7 @@ This should return the address to forward to. ...@@ -687,7 +672,7 @@ This should return the address to forward to.
### Submission ### 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: It provides the following functionality:
...@@ -763,7 +748,7 @@ Other TPO nodes are authenticated using client certificates. Distribution is don ...@@ -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. 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. 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 ...@@ -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. 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. 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: ...@@ -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 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* [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 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 ...@@ -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 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: 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" @ 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"
...@@ -864,7 +849,7 @@ We use the `a:` mechanism instead of the (somewhat more common) `ip4:` ...@@ -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 mechanism because we do not want to add both the IPv4 and IPv6
records. records.
### db.torproject.org: a #### db.torproject.org: a
Some servers have a record like that: 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 ...@@ -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 will match only if the connecting server has an IP matching the `A` or
`AAAA` record for `db.torproject.org` or `alberti.torproject.org`. `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" 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 ...@@ -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 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. different location than the web interface, for example.
### CRM: hard record #### CRM: hard record
Finally, one last example is the CiviCRM records: Finally, one last example is the CiviCRM records:
...@@ -909,13 +894,13 @@ Those are similar to the `db.torproject.org` records except they are ...@@ -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 reject attempts from servers not in the `A` or `AAAA` record of
`crm.torproject.org`. Note that `-all` is rarely enforced this strictly. `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. 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. 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. 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 ...@@ -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 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:
``` ```
/usr/bin/rspamc -h localhost learn_spam /usr/bin/rspamc -h localhost learn_spam
... ...
......