move IMAP deployment rationale to the "other alternatives" section

The idea here is that we don't need to justify every step in the
"actual changes" section. The section will be easier to read that
way. Regrouping this in the lengthy "other alternatives" section will
make the text lighter.

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

@@ -232,42 +232,21 @@ Other things to be careful about:
 
 ### IMAP deployment
 
-This consists of an IMAP server deployment. This is a requirement
-because the SPF records will *require* people to start using the
-submission server to send mail.
-
-And that, in turn requires an IMAP server because of clients
-limitations. For example, it's not possible to configure Apple mail of
-Office 365 with a remote server unless they also provide an IMAP
-service, see [issue tpo/tpa/team#40586](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40586) for details.
-
-It's also possible that implementing mailboxes could help improve spam
-filtering capabilities, which are after all necessary to ensure good
-reputation with hosts we currently relay mail to.
-
-Finally, it's possible that we will not be able to make "hard"
-decisions about policies like SPF, DKIM, or DMARC and would be forced
-to implement a "rating" system for incoming mail, which would be
-difficult to deploy without user mailboxes, especially for feedback
-loops.
+This consists of an IMAP and webmail server deployment.
 
 In [the submission service hosting cost evaluation](howto/submission#internal-hosting-cost-evaluation), the hardware
 costs related to mailboxes were evaluated at about 2500EUR/year with a
 200EUR setup fee, hardware wise. TODO: review hardware cost estimates.
 
-There's a lot of uncertainty regarding incoming email filtering, but
-that is a problem we need to solve in the current setup anyways, so we
-don't believe the extra costs of this would be significant. At worst,
-training would require extra server resources and staff time for
-deployment. User support might require more time than with a plain
-forwarding setup, however.
+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.
 
-Therefore, it is estimated that deploying mailboxes would require an
-extra 2 weeks setup time, with high uncertainty. Ongoing costs would
-probably be similar to the forwarding setup, with high uncertainty as
-well.
-
-TODO: webmail
+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
 
@@ -611,9 +590,36 @@ sysadmin it's better that way.
 
 # Other alternatives
 
-## Mailboxes (+2500€/year)
+## No mailboxes
+
+An earlier draft of this proposal considered changing the
+infrastructure to add only a mail exchanger and a relay, alongside all
+the DNS changes (SPF, DKIM, DMARC). 
+
+We realized the IMAP was a requirement requirement because the SPF
+records will *require* people to start using the submission server to
+send mail. And that, in turn requires an IMAP server because of
+clients limitations. For example, it's not possible to configure Apple
+mail of Office 365 with a remote server unless they also provide an
+IMAP service, see [issue tpo/tpa/team#40586](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40586) for details.
+
+It's also possible that implementing mailboxes could help improve spam
+filtering capabilities, which are after all necessary to ensure good
+reputation with hosts we currently relay mail to.
+
+Finally, it's possible that we will not be able to make "hard"
+decisions about policies like SPF, DKIM, or DMARC and would be forced
+to implement a "rating" system for incoming mail, which would be
+difficult to deploy without user mailboxes, especially for feedback
+loops.
+
+There's a lot of uncertainty regarding incoming email filtering, but
+that is a problem we need to solve in the current setup anyways, so we
+don't believe the extra costs of this would be significant. At worst,
+training would require extra server resources and staff time for
+deployment. User support might require more time than with a plain
+forwarding setup, however.
 
-TODO: remove this section, make sure it's not refered to elsewhere.
 ## High availability setup
 
 We have not explicitly designed this proposal for high availability