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.
# 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
### DKIM configuration
......@@ -722,9 +714,8 @@ record.
## Upgrades
<!-- how upgrades are performed. preferably automated through Debian -->
<!-- packages, otherwise document how upgrades are performed. see also -->
<!-- the Testing section below -->
Upgrades should generally be covered by the normal Debian package
workflow.
## SLA
......@@ -753,15 +744,23 @@ documentation](howto/tls)).
## 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
<!-- 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
<!-- e.g. web APIs, commandline clients, etc -->
Most of Postfix and Dovecot operations are done through the
commandline interface.
## Authentication
......@@ -778,12 +777,16 @@ haven't been resolved yet.
## Implementation
<!-- programming languages, frameworks, versions, license -->
Most software in this space is written in C (Postfix, Dovecot, OpenDKIM).
## Related services
<!-- dependent services (e.g. authenticates against LDAP, or requires -->
<!-- git pushes) -->
The submission and mail forwarding services both rely on the [LDAP
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
......@@ -807,7 +810,7 @@ and SPF records) were done as part of [TPA-RFC-44](policy/tpa-rfc-44-email-emerg
## Maintainer
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
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
## Users
<!-- who the main users are, how they use the service. possibly reuse -->
<!-- the Personas section in the RFC, if available. -->
Users of this service are mostly core tor members. But effectively,
any email user on the internet can interact with our mail servers in
one way or another.
## Upstream
<!-- who the upstreams are, if they are still active, -->
<!-- collaborative, how do we keep up to date, support channels, see -->
<!-- also the "Issues" section above -->
Upstreams vary.
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
......@@ -899,15 +913,10 @@ This service was setup following some or all of those documents:
# Discussion
<!-- the "discussion" section is where you put any longer conversation -->
<!-- about the project that you will not need in a casual -->
<!-- review. history of the project, why it was done the way it was -->
<!-- (as opposed to how), alternatives, and other proposals are -->
<!-- relevant here. -->
<!-- this at least partly overlaps with the TPA-RFC process (see -->
<!-- policy.md), but in general should defer to proposals when -->
<!-- available -->
The mail services at Tor have been rather neglected,
traditionally. No effort was done to adopt modern standards (SPF,
DKIM, DMARC) which led to significant deliverability problems in late
2022.
## Overview
......@@ -919,36 +928,36 @@ This service was setup following some or all of those documents:
## Security and risk assessment
<!--
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?
No audit was ever performed on the mail services.
6. When was the last risk assessment done? Something that would cover
risks from the data stored, the access required, etc.
The lack of SPF records and DKIM signatures mean that users must rely
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
<!--
7. Are there any in-progress projects? Technical debt cleanup?
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?
-->
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
mail services or building a proper mail hosting service.
## Proposed Solution
<!-- Link to RFC -->
## Other alternatives
We went through a number of proposals to improve mail services over
time:
<!-- 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
......
......