reshuffle and match task list and timeline

policy/tpa-rfc-15-email-services.md

@@ -197,7 +197,12 @@ End-to-end deliverability monitoring involves:
  * DMARC/MTA-STS feedback loops (covered below)
 
 Implementation details are in [issue 40539][], but those would
-typically be implemented as Nagios or Prometheus checks.
+typically be implemented as Nagios or Prometheus checks. This also
+includes evaluating how to monitor metrics offered by [Google
+postmaster tools][] and Microsoft (see also [issue 40168][]).
+
+[issue 40168]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40168
+[Google postmaster tools]: https://postmaster.google.com
 
 ### DMARC reports analysis
 
@@ -207,6 +212,44 @@ implemented separately because they are considered to be more complex
 
 This might also include extra work for MTA-STS feedback loops.
 
+### IMAP deployment
+
+This consists of an IMAP and webmail server deployment.
+
+We are currently already using Dovecot in a limited way on some
+servers, so we will likely reuse this service for the IMAP server. The
+webmail will likely be deployed with Roundcube, alongside the IMAP
+server. Both programs are packaged and well supported in Debian. Mail
+filtering is detailed in another section below.
+
+It is estimated that deploying mailboxes would require an 2 weeks
+setup time, with high uncertainty. Ongoing costs would probably be
+similar to the forwarding setup, with high uncertainty as well.
+
+### Incoming mail filtering
+
+Deploy a tool for inspection of incoming mail for SPF, DKIM, DMARC
+records, affecting either "reputation" (e.g. marker in mail headers)
+or just downright rejection (e.g. rejecting mail before queue).
+
+We currently use Spamassassin for this purpose. [rspamd][] should also
+be evaluated as part of this work to see if it is a viable alternative.
+
+[rspamd]: https://rspamd.com/
+
+### New mail exchangers
+
+This is the configuration of new "mail exchanger" (MX) server(s) with
+TLS certificates signed by a public CA, most likely Let's Encrypt for
+incoming mail, replacing a part of `eugeni`.
+
+### New mail relays
+
+This is configuration of new "mail relay" server(s) to relay mails from
+servers that do not send their own email, replacing a part of
+`eugeni`, similar to current submission server, except with TLS
+authentication instead of password.
+
 ### DKIM and ARC signatures
 
 DKIM will be generally implemented with OpenDKIM. It is a well
@@ -230,20 +273,6 @@ Other things to be careful about:
  * decide key rotation policy (how frequently, should we [publish
    private keys][])
 
-### IMAP deployment
-
-This consists of an IMAP and webmail server deployment.
-
-We are currently already using Dovecot in a limited way on some
-servers, so we will likely reuse this service for the IMAP server. The
-webmail will likely be deployed with Roundcube, alongside the IMAP
-server. Both programs are packaged and well supported in Debian. Mail
-filtering is detailed in another section below.
-
-It is estimated that deploying mailboxes would require an 2 weeks
-setup time, with high uncertainty. Ongoing costs would probably be
-similar to the forwarding setup, with high uncertainty as well.
-
 ### SPF/DMARC records
 
 The deployment of SPF and DMARC DNS records, which will impact users
@@ -265,30 +294,6 @@ we may want to consider, in the long term, other options for many
 aliases, either mailing lists or issue trackers. But that question is
 out of scope of this proposal for now.
 
-### Incoming mail filtering
-
-Deploy a tool for inspection of incoming mail for SPF, DKIM, DMARC
-records, affecting either "reputation" (e.g. marker in mail headers)
-or just downright rejection (e.g. rejecting mail before queue).
-
-We currently use Spamassassin for this purpose. [rspamd][] should also
-be evaluated as part of this work to see if it is a viable alternative.
-
-[rspamd]: https://rspamd.com/
-
-### New mail exchangers
-
-This is the configuration of new "mail exchanger" (MX) server(s) with
-TLS certificates signed by a public CA, most likely Let's Encrypt for
-incoming mail, replacing a part of `eugeni`.
-
-### New mail relays
-
-This is configuration of new "mail relay" server(s) to relay mails from
-servers that do not send their own email, replacing a part of
-`eugeni`, similar to current submission server, except with TLS
-authentication instead of password.
-
 ### Puppet refactoring
 
 Refactor the mail-related code in Puppet, and reconfigure all servers
@@ -352,35 +357,32 @@ Changes in this diagram:
 ## Timeline
 
 This timeline is a draft, and will be updated according to when this
-proposal is adopted.
-
- 1. Q1: start filtering incoming mail for SPF, DKIM and DMARC, first
-    on `bridges.torproject.org`, then on `lists.torproject.org` and
-    `torproject.org` ([ticket 40539](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40539))
-
- 2. Q1: publish DMARC record to get reports to estimate effects of
-    adding SPF records (`p=none`)
-    
- 3. Q1: deploy end-to-end deliverability tests with major providers
-    (Google, Microsoft, Fastmail, Riseup)
-    
- 4. Q1: evaluate how to monitor metrics offered by [Google postmaster
-    tools][] and Microsoft (see also [issue 40168][])
-
- 3. Q1: start signing outgoing mail with DKIM, globally 
-
- 4. Q2: everyone adopts the submission server
-    
- 5. Q3: once submission is adopted, add SPF records, soft (`~all`)
- 
- 6. Q4: deploy hard DMARC (`p=reject`) and SPF (`-all`)
+proposal is adopted. The changes will be distributed over a year, and
+the following is a per-quarter breakdown, starting from when the
+proposal is adopted. Obviously, the deployment will depend on
+availability of TPA staff and the collaboration of TPO members.
+
+ * Q1:
+   * End-to-end deliverability checks
+   * DMARC reports analysis (DMARC record `p=none`)
+   * partial incoming mail filtering (bridges, lists, tpo, [issue
+     40539][])
+   * progressive adoption of submission server
+   * Puppet refactoring
+ * Q2:
+   * IMAP and webmail server deployment
+   * mail exchanger deployment
+   * relay server deployment
+   * global incoming mail filtering
+   * deadline for adoption of the submission server
+ * Q3:
+   * DKIM and ARC signatures
+   * SPF records, "soft" (`~all`)
+ * Q4:
+   * hard DMARC (`p=reject`) and SPF (`-all`) records
  
 [publish private keys]: https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/
 [DKIM replay attacks]: https://utcc.utoronto.ca/~cks/space/blog/spam/DKIMSpamReplayAttack
-[issue 40168]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40168
-[Google postmaster tools]: https://postmaster.google.com
-
-TODO: set exact deploy dates for specific records and milestones.
 
 ## Caveats