Changes

Page history
finish filling up the email service template authored by anarcat's avatar anarcat
Show whitespace changes
Inline Side-by-side
service/email.md
View page @ 67254339
...@@ -361,14 +361,6 @@ the email providers they were using before this service was deployed. ...@@ -361,14 +361,6 @@ the email providers they were using before this service was deployed.
# Reference # Reference
<!-- this section is a more in-depth review of how this service works, -->
<!-- how it's setup. day-to-day operation should be covered in -->
<!-- tutorial or how-to, this is more in-depth -->
<!-- a good guide to "audit" an existing project's design: -->
<!-- https://bluesock.org/~willkg/blog/dev/auditing_projects.html -->
<!-- the following sections are partially based on that -->
## Installation ## Installation
### DKIM configuration ### DKIM configuration
...@@ -722,9 +714,8 @@ record. ...@@ -722,9 +714,8 @@ record.
## Upgrades ## Upgrades
<!-- how upgrades are performed. preferably automated through Debian --> Upgrades should generally be covered by the normal Debian package
<!-- packages, otherwise document how upgrades are performed. see also --> workflow.
<!-- the Testing section below -->
## SLA ## SLA
...@@ -753,15 +744,23 @@ documentation](howto/tls)). ...@@ -753,15 +744,23 @@ documentation](howto/tls)).
## Storage ## Storage
<!-- databases? plain text file? the frigging blockchain? memory? --> Mail services currently do not involve any sort of storage other than
mail queues (below).
## Queues ## Queues
<!-- email queues, job queues, schedulers --> Mail servers typically transfer emails into a queue on reception, and
flush them out of the queue when the email is successfully
delivered. Temporary delivery failures are retried for 5 days
([`bounce_queue_lifetime`](https://www.postfix.org/postconf.5.html#bounce_queue_lifetime) and [`maximal_queue_lifetime`](https://www.postfix.org/postconf.5.html#maximal_queue_lifetime)).
We use the Postfix defaults for those settings, which may vary from
the above.
## Interfaces ## Interfaces
<!-- e.g. web APIs, commandline clients, etc --> Most of Postfix and Dovecot operations are done through the
commandline interface.
## Authentication ## Authentication
...@@ -778,12 +777,16 @@ haven't been resolved yet. ...@@ -778,12 +777,16 @@ haven't been resolved yet.
## Implementation ## Implementation
<!-- programming languages, frameworks, versions, license --> Most software in this space is written in C (Postfix, Dovecot, OpenDKIM).
## Related services ## Related services
<!-- dependent services (e.g. authenticates against LDAP, or requires --> The submission and mail forwarding services both rely on the [LDAP
<!-- git pushes) --> service](howto/ldap), for secrets and aliases, respectively.
The [mailing list service](services/lists) and [schleuder](service/schleuder) both depend on basic
email services for their normal operations. The [CiviCRM service](service/crm)
is also a particularly large mail sender.
## Issues ## Issues
...@@ -807,7 +810,7 @@ and SPF records) were done as part of [TPA-RFC-44](policy/tpa-rfc-44-email-emerg ...@@ -807,7 +810,7 @@ and SPF records) were done as part of [TPA-RFC-44](policy/tpa-rfc-44-email-emerg
## Maintainer ## Maintainer
This service is mostly written as a set of Puppet manifests. It was This service is mostly written as a set of Puppet manifests. It was
built by anarcat, and is maintained by TPA. There is no upstream. built by anarcat, and is maintained by TPA.
Some parts of the mail services (the submission service, in Some parts of the mail services (the submission service, in
particular) depends on patches on `userdir-ldap` that were partially particular) depends on patches on `userdir-ldap` that were partially
...@@ -815,14 +818,25 @@ merged in the upstream, see [LDAP docs](howto/ldap#maintainer-users-and-upstream ...@@ -815,14 +818,25 @@ merged in the upstream, see [LDAP docs](howto/ldap#maintainer-users-and-upstream
## Users ## Users
<!-- who the main users are, how they use the service. possibly reuse --> Users of this service are mostly core tor members. But effectively,
<!-- the Personas section in the RFC, if available. --> any email user on the internet can interact with our mail servers in
one way or another.
## Upstream ## Upstream
<!-- who the upstreams are, if they are still active, --> Upstreams vary.
<!-- collaborative, how do we keep up to date, support channels, see -->
<!-- also the "Issues" section above --> Most of the work done in our mail services is performed by
[Postfix](https://www.postfix.org/), which is an active project and de-facto standard for new
mail servers out there. Postfix was written by [Wietse Venema](https://www.porcupine.org/wietse/)
while working at [IBM research](http://www.research.ibm.com/).
The [Dovecot mail server](https://dovecot.org/) was written by [Timo Sirainen](https://en.wikipedia.org/wiki/Timo_Sirainen) and is
one of the most widely used IMAP servers out there. It is an active
upstream as well.
[OpenDKIM](https://github.com/trusteddomainproject/OpenDKIM) is not in such good shape: it hasn't had a commit or
release in over 4 years (as of late 2022).
## Monitoring and metrics ## Monitoring and metrics
...@@ -899,15 +913,10 @@ This service was setup following some or all of those documents: ...@@ -899,15 +913,10 @@ This service was setup following some or all of those documents:
# Discussion # Discussion
<!-- the "discussion" section is where you put any longer conversation --> The mail services at Tor have been rather neglected,
<!-- about the project that you will not need in a casual --> traditionally. No effort was done to adopt modern standards (SPF,
<!-- review. history of the project, why it was done the way it was --> DKIM, DMARC) which led to significant deliverability problems in late
<!-- (as opposed to how), alternatives, and other proposals are --> 2022.
<!-- relevant here. -->
<!-- this at least partly overlaps with the TPA-RFC process (see -->
<!-- policy.md), but in general should defer to proposals when -->
<!-- available -->
## Overview ## Overview
...@@ -919,36 +928,36 @@ This service was setup following some or all of those documents: ...@@ -919,36 +928,36 @@ This service was setup following some or all of those documents:
## Security and risk assessment ## Security and risk assessment
<!-- No audit was ever performed on the mail services.
5. When was the last security review done on the project? What was
the outcome? Are there any security issues currently? Should it
have another security review?
6. When was the last risk assessment done? Something that would cover The lack of SPF records and DKIM signatures mean that users must rely
risks from the data stored, the access required, etc. on out-of-band mechanisms (like OpenPGP) to authenticate incoming
emails. Given that such solutions (especially OpenPGP) are not widely
adopted, in effect it means that anyone can easily impersonate
`torproject.org` users.
--> We have heard regular reports of phishing attempts against our users
as well ([tpo/tpa/team#40596](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40596)), sometimes coming from our own
domain. Inbound mail filters are expected to improve that situation
([tpo/tpa/team#40539](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40539)).
## Technical debt and next steps ## Technical debt and next steps
<!-- The next step in this project is to rebuild a proposal to followup on
the long term plan from TPA-RFC-44. This will mean either outsourcing
7. Are there any in-progress projects? Technical debt cleanup? mail services or building a proper mail hosting service.
Migrations? What state are they in? What's the urgency? What's the
next steps?
8. What urgent things need to be done on this project?
-->
## Proposed Solution ## Proposed Solution
<!-- Link to RFC --> We went through a number of proposals to improve mail services over
time:
## Other alternatives
<!-- include benchmarks and procedure if relevant --> * [TPA-RFC-15: Email services](policy/tpa-rfc-15-email-services) (rejected, replaced with
TPA-RFC-31)
* [TPA-RFC-31: outsource email services](policy/tpa-rfc-31-outsource-email) (rejected as well, in
favor of TPA-RFC-44 and following)
* [TPA-RFC-44: Email emergency recovery](policy/tpa-rfc-44-email-emergency-recovery) (DKIM, SPF, DMARC
records, long term plan postponed)
## Submission server proposal ## Submission server proposal
... ...
......