Loading policy/tpa-rfc-31-outsource-email.md +34 −5 Original line number Diff line number Diff line Loading @@ -211,7 +211,35 @@ Considering that email is a critical service at the Tor Project, we want to have some idea of how long problems would take to get resolved. TODO: detail SLA for external service provider #### Availability We expect the service to be generally available 24/7, with outages limited to one hour or less per month (~99.9% availability). We also expect the provider to be able to deliver mail to major providers, see the [deliverability](#deliverability) section, above, for details. #### Support TPI staff should be able to process level 1 support requests about email like password resets, configuration assistance, and training. Ideally, those could be forwarded directly to support staff at the service provider. We expect same-day response for reported issues, with resolution within a day or a week (business hours), depending on the severity of the problem reported. #### Backups We do not expect users to require mailbox recovery, that will remain the responsibility of users. But we do expect the provider to set clear RTO (Recovery Time Objective) and PTO (Point-in-Time Objective). For example, we would hope a full system failure would not lose more than a day of work, and should be restored within less than a week. # Proposal Loading Loading @@ -389,15 +417,16 @@ The following operations will be required, specifically: | RT | `rude` | external SMTP/IMAP, forward cleanups | | Submission | `submit-01` | retirement | TODO: it might be worth checking with community/funding/support teams whether they want to keep RT at all, considering ongoing experiments with cdr.link. Discourse wouldn't need modification as they handle email themselves in their own domain and mail server. If we would be to self-host, it is assumed Discourse could use an existing SMTP and IMAP configuration as well. RT is likely to stick around for at least 2023. There are plans to review its performance when compared to the `cdr.link` instance, but any change will not happen before this proposal needs to be implemented, so we need to support RT for the foreseeable future. #### Eugeni retirement The current, main, mail server (`eugeni`) deserves a little more Loading Loading
policy/tpa-rfc-31-outsource-email.md +34 −5 Original line number Diff line number Diff line Loading @@ -211,7 +211,35 @@ Considering that email is a critical service at the Tor Project, we want to have some idea of how long problems would take to get resolved. TODO: detail SLA for external service provider #### Availability We expect the service to be generally available 24/7, with outages limited to one hour or less per month (~99.9% availability). We also expect the provider to be able to deliver mail to major providers, see the [deliverability](#deliverability) section, above, for details. #### Support TPI staff should be able to process level 1 support requests about email like password resets, configuration assistance, and training. Ideally, those could be forwarded directly to support staff at the service provider. We expect same-day response for reported issues, with resolution within a day or a week (business hours), depending on the severity of the problem reported. #### Backups We do not expect users to require mailbox recovery, that will remain the responsibility of users. But we do expect the provider to set clear RTO (Recovery Time Objective) and PTO (Point-in-Time Objective). For example, we would hope a full system failure would not lose more than a day of work, and should be restored within less than a week. # Proposal Loading Loading @@ -389,15 +417,16 @@ The following operations will be required, specifically: | RT | `rude` | external SMTP/IMAP, forward cleanups | | Submission | `submit-01` | retirement | TODO: it might be worth checking with community/funding/support teams whether they want to keep RT at all, considering ongoing experiments with cdr.link. Discourse wouldn't need modification as they handle email themselves in their own domain and mail server. If we would be to self-host, it is assumed Discourse could use an existing SMTP and IMAP configuration as well. RT is likely to stick around for at least 2023. There are plans to review its performance when compared to the `cdr.link` instance, but any change will not happen before this proposal needs to be implemented, so we need to support RT for the foreseeable future. #### Eugeni retirement The current, main, mail server (`eugeni`) deserves a little more Loading
