Skip to content
Snippets Groups Projects
Verified Commit 1bd80efe authored by anarcat's avatar anarcat
Browse files

major edit: reread everything on a ereader, 24h after

parent 236f6d76
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
policy/tpa-rfc-15-email-services.md
+ 167
− 152
View file @ 1bd80efe
......@@ -6,7 +6,7 @@ title: TPA-RFC-15: email services
Summary: deploy incoming and outgoing [SPF][], [DKIM][], [DMARC][],
and (possibly) [ARC][] checks and records on torproject.org
infrastructure. Deployment of an IMAP service, alongside the
infrastructure. Deploy an IMAP service, alongside
enforcement of the use of the submission server for outgoing
mail. Establish end-to-end deliverability monitoring. Rebuild mail
services to get rid of legacy infrastructure.
......@@ -41,17 +41,18 @@ users to send emails themselves through our infrastructure.
This situation led to users sending email with `@torproject.org` email
addresses from arbitrary locations on the internet: Gmail, Riseup, and
other service providers were typically used to send email for
other service providers (including personal mail servers)
are typically used to send email for
`torproject.org` users.
This changed at the end of 2021 when the new [submission service][]
came online. We still, however, have limited adoption of this service,
with only 14 users registered compared to the ~100 users in LDAP.
with only 16 users registered compared to the ~100 users in LDAP.
[submission service]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/submission
In parallel to this, we have historically not embarked in any modern
email standards like SPF, DKIM, or DMARC. But more recently, we have
In parallel, we have historically not adopted any modern
email standards like SPF, DKIM, or DMARC. But more recently, we
added SPF records to both the Mailman and CiviCRM servers (see [ticket
40347][]).
......@@ -63,7 +64,7 @@ are running Spamassassin on the RT server to try to deal with the
large influx of spam on the generic support addresses (`support@`,
`info@`, etc) that the server processes. We do not process SPF records
on incoming mail in any way, which has caused problems with Hetzner
(see [issue 40539][]).
([issue 40539][]).
[issue 40539]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40539
......@@ -73,17 +74,16 @@ sender has DMARC records, since September 2021 (see [ticket 19914][]).
[ticket 19914]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/19914
We still do not offer mailboxes and this proposal does not plan to
address this, although we do have Dovecot servers deployed for
We do not offer mailboxes, although we do have Dovecot servers deployed for
specific purposes. The GitLab and CiviCRM servers, for example, use it
for incoming email processing, and the submission server uses it for
authentication.
## Known issues
The current email infrastructure has many problems, ranging from
deliverability to monitoring. In general, people feel like their
emails are not being delivered or "getting to spam". And sometimes, in
The current email infrastructure has many problems.
In general, people feel like their
emails are not being delivered or "getting into spam". And sometimes, in
the other direction, people simply cannot get mail from certain
domains.
......@@ -127,7 +127,7 @@ It did not touch on email standards like this proposal does.
# Proposal
After a grace period, we progressively start adding "soft", then
After a grace period, we progressively add "soft", then
"hard" SPF, DKIM, and DMARC record to the `lists.torproject.org`,
`crm.torproject.org`, `rt.torproject.org`, and, ultimately,
`torproject.org` domains.
......@@ -135,6 +135,9 @@ After a grace period, we progressively start adding "soft", then
This deployment will be paired with end to end deliverability tests
alongside "reports" analysis (from DMARC, mainly).
An IMAP server with a webmail is configured on a new server. A new
mail exchanger and relay are setup.
This assumes that, during the grace period, everyone eventually adopts
the submission server for outgoing email, or stop using their
`@torproject.org` email address for outgoing mail.
......@@ -175,25 +178,22 @@ users, users with LDAP accounts or forwards under `@torproject.org`.
It especially affects users which send email from their own provider
or another provider than the [submission service][]. Those users will
eventually be unable to send mail with a `torproject.org` email
address unless they take action before Q4 2022.
In general, reputation of email *not* sent using the official channels
will start to degrade some time or before Q3 2022.
address.
## Actual changes
The actual changes proposed here are divided in smaller chunks,
described in detail below:
a. End-to-end deliverability checks
b. DMARC reports analysis
c. DKIM and ARC signatures
d. IMAP deployment
e. SPF/DMARC records
f. Incoming mail filtering
g. New mail exchangers
h. New mail relays
i. Puppet refactoring
1. End-to-end deliverability checks
2. DMARC reports analysis
3. DKIM and ARC signatures
4. IMAP deployment
5. SPF/DMARC records
6. Incoming mail filtering
7. New mail exchangers
8. New mail relays
9. Puppet refactoring
### End-to-end deliverability checks
......@@ -203,10 +203,10 @@ End-to-end deliverability monitoring involves:
* block list checks
* DMARC/MTA-STS feedback loops (covered below)
Implementation details are in [issue 40539][], but those would
typically be implemented as Nagios or Prometheus checks. This also
This may be implemented as Nagios or Prometheus checks ([issue
40539][]). This also
includes evaluating how to monitor metrics offered by [Google
postmaster tools][] and Microsoft (see also [issue 40168][]).
postmaster tools][] and Microsoft ([issue 40168][]).
[issue 40168]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40168
[Google postmaster tools]: https://postmaster.google.com
......@@ -224,19 +224,15 @@ This might also include extra work for MTA-STS feedback loops.
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
servers, so we will reuse some of that Puppet code 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)
records, affecting either "reputation" (e.g. add a marker in mail headers)
or just downright rejection (e.g. rejecting mail before queue).
We currently use Spamassassin for this purpose, and we could consider
......@@ -249,60 +245,46 @@ if it is a viable alternative.
### 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`.
Configure 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
Configure new "mail relay" server(s) to relay mails from servers that
do not send their own email, replacing a part of `eugeni`.
This is 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
established program and standard used in many locations, and it is not
expected to cause problems in deployment, software wise.
There might be problems implementing support for this in the DNS as
userdir-ldap already has some support for DKIM records, which *can* be
provided by users (!). This might conflict with TPA-managed records,
for example.
It's currently unclear how [ARC][] would be implemented, as the known
implementations ([OpenARC][] and [Fastmail's authentication milter][])
are not packaged in Debian. ARC can help with riseup -> TPO -> riseup
forwarding trips, which can be marked as spam by riseup.
Other things to be careful about:
* watch out for [DKIM replay attacks][]
* decide key rotation policy (how frequently, should we [publish
private keys][])
Implement outgoing DKIM signatures, probably with OpenDKIM.
### SPF/DMARC records
The deployment of SPF and DMARC DNS records, which will impact users
not on the submission and IMAP servers, which includes users with
plain forwards and without an LDAP account, as indicated above.
Deploy of SPF and DMARC DNS records, which will impact users not on
the submission and IMAP servers. This includes users with plain
forwards and without an LDAP account.
Possible solutions include:
Possible solutions for those users include:
0. users adopt the submission server for outgoing mail
1. aliases are removed or,
2. transformed into LDAP accounts or,
3. they can't use them for outgoing or,
4. we deploy something like [SRS][]
0. users adopt the submission server for outgoing mail,
1. or aliases are removed,
2. or transformed into LDAP accounts,
3. or forwards can't be used for outgoing mail,
4. or forwarded emails are rewritten (e.g. [SRS][])
This goes in hand with the [email policy problem][] which is basically
the question of what service can be used for (e.g. forwards vs lists
vs RT). In general, email forwarding causes all sorts of problems and
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.
aliases, either mailing lists or issue trackers. That question is out
of scope of this proposal for now. See also the broader [End of
Email][] discussion.
[SRS]: https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme
[End of Email]: #the-end-of-email
### Puppet refactoring
......@@ -347,7 +329,7 @@ Legend:
Changes in this diagram:
* added: `relay`, `mx`, `mailbox`, the hosts defined in steps e, g,
* added: `submission-tls`, `mx`, `mailbox`, the hosts defined in steps e, g,
and h above
* changed:
* `eugeni` stops relaying email for all the hosts and stops
......@@ -369,8 +351,13 @@ Changes in this diagram:
This timeline is a draft, and will be updated according to when this
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.
proposal is adopted.
Obviously, the deployment will depend on availability of TPA staff and
the collaboration of TPO members. It might also be reordered to
prioritize more urgent problems that come up. The complaints we
received from Hetzner, for example should probably be a priority
([issue 40539][]).
* Q1:
* End-to-end deliverability checks
......@@ -396,6 +383,8 @@ availability of TPA staff and the collaboration of TPO members.
## Challenges
### Aging Puppet code base
This deployment will require a lot of work on the Puppet modules,
since our current codebase around email services is a little old and
hard to modify. We will need to spend some time to refactor and
......@@ -403,14 +392,33 @@ cleanup that codebase before we can move ahead with more complicated
solutions like incoming SPF checks or outgoing DKIM signatures, for
example. See [issue tpo/tpa/team#40626][] for details.
### Incoming filtering implementation
Some research work will need to be done to determine the right tools
to use to deploy the various checks on incoming mail.
Some work might be needed on `userdir-ldap` for DKIM support, although
some support for user-provided DKIM records already exists. It's
possible we can just ignore that functionality and setup separate DKIM
For DKIM, OpenDKIM is a well established program and standard used in
many locations, and it is not expected to cause problems in
deployment, software wise.
Our LDAP server already has support for per-user DKIM records, but we
will probably ignore that functionality and setup separate DKIM
records, maintained manually.
It's currently unclear how [ARC][] would be implemented, as the known
implementations ([OpenARC][] and [Fastmail's authentication milter][])
are not packaged in Debian. ARC can help with riseup -> TPO -> riseup
forwarding trips, which can be marked as spam by riseup.
Other things to be careful about:
* watch out for [DKIM replay attacks][]
* decide key rotation policy (how frequently, should we [publish
private keys][])
### Security concerns
The proposed architecture does not offer users two-factor
authentication (2FA) and could therefore be considered less secure
than other commercial alternatives. Implementing 2FA in the context of
......@@ -441,15 +449,15 @@ process follows the [Kaplan-Moss estimation technique](https://jacobian.org/2021
| Task | Estimate | Uncertainty | Note | Total (days) |
|----------------------------|----------|-------------|-----------------------------------------------|--------------|
| a. e2e deliver. checks | 3 days | medium | access to other providers uncertain | 4.5 |
| b. DMARC reports | 1 week | high | needs research | 10 |
| c. DKIM signing | 3 days | medium | expiration policy and per-user keys uncertain | 4.5 |
| d. IMAP deployment | 2 week | high | may require training to onboard users | 20 |
| e. SPF/DMARC records | 3 days | high | impact on forwards unclear, SRS | 7 |
| f. incoming mail filtering | 1 week | high | needs research | 10 |
| g. new MX | 1 week | high | key part of eugeni, might be hard | 10 |
| h. new mail relays | 3 days | low | similar to current submission server | 3.3 |
| i. Puppet refactoring | 1 week | high | | 10 |
| 1. e2e deliver. checks | 3 days | medium | access to other providers uncertain | 4.5 |
| 2. DMARC reports | 1 week | high | needs research | 10 |
| 3. DKIM signing | 3 days | medium | expiration policy and per-user keys uncertain | 4.5 |
| 4. IMAP deployment | 2 week | high | may require training to onboard users | 20 |
| 5. SPF/DMARC records | 3 days | high | impact on forwards unclear, SRS | 7 |
| 6. incoming mail filtering | 1 week | high | needs research | 10 |
| 7. new MX | 1 week | high | key part of eugeni, might be hard | 10 |
| 8. new mail relays | 3 days | low | similar to current submission server | 3.3 |
| 9. Puppet refactoring | 1 week | high | | 10 |
This amounts to a total estimate time of 80 days, or about 16 weeks
or four months, full time. At 50EUR/hr, that's about 32,000EUR of
......@@ -459,22 +467,17 @@ This estimate doesn't cover for ongoing maintenance costs and support
associated with running the service. So far, the submission server has
yielded little support requests. After a bumpy start requiring patches
to userdir-ldap and a little documentation, things ran rather
smoothly. Since we're providing mailboxes, we are probably not going
to have a lot more documentation to write or extra hand-holding to do.
smoothly.
It is possible, however, that the remaining 85% of users that do *not*
currently use the submission server might require extra hand-holding,
so that's one variable that is not currently considered. We should
consider at least one person-day per month, possibly even per week,
which gives us a range of 12 to 52 days of work, for an extra cost of
5,000-20,000EUR, per year.
This estimate doesn't include hardware costs. It is hoped that,
because the changes are mostly policy and software changes, hardware
requirements will be minimal. We will need a handful of new virtual
machines (between 2 and 4, depending on how highly available we want
the service to be), and it is believed we can cover for those
requirements with the current infrastructure.
so that's one variable that is not currently considered. Furthermore,
we do not have any IMAP service now and this will require extra
onboarding, training and documentation
We should consider at least one person-day per month, possibly even
per week, which gives us a range of 12 to 52 days of work, for an
extra cost of 5,000-20,000EUR, per year.
## Hardware
......@@ -512,17 +515,17 @@ Here we collect a few "personas" and try to see how the changes will
affect them.
> We have taken the liberty of creating mostly fictitious personas, but
> they are somewhat based in real-life people. We do not mean to
> offend, any similarity that might seem offensive is an honest
> they are somewhat based on real-life people. We do not mean to
> offend. Any similarity that might seem offensive is an honest
> mistake on our part which we will be happy to correct. Also note that
> we might have mixed up people together, or forgot some. If your use
> case is not mentioned here, please, please do mention it. We don't
> need to have *exactly* you here, but all your current use cases
> case is not mentioned here, please do report it. We don't
> need to have *exactly* "you" here, but all your current use cases
> should be covered by one or many personas.
## Ariel, the fundraiser
Ariel does a lot of mailing. From talking to fundraisers through her
Ariel does a lot of mailing. From talking to fundraisers through their
normal inbox to doing mass newsletters to thousands of people on
CiviCRM, they get a lot of shit done and make sure we have bread on
the table at the end of the month. They're awesome and we want to make
......@@ -549,13 +552,13 @@ server, but that configuration will be unsupported.
## Gary, the support guy
Gary is the ticket master. He eats tickets for breakfast, then files
10 more before coffee. A hundred tickets a day is just a normal day at
10 more before coffee. A hundred tickets is just a normal day at
the office. Tickets come in through email, RT, Discourse, Telegram,
Snapchat and soon, TikTok dances.
Email is absolutely mission critical, but some days he wishes there
could be slightly less of it. He deals with a lot of spam, and
he doesn't know why, and it's annoying.
surely something could be done about that.
His mail forwards to Riseup and he reads his mail over Thunderbird and
sometimes webmail.
......@@ -570,8 +573,8 @@ configured to relay mail through the submission server.
John is a freelance contractor that's really into privacy. He runs his
own relays with some cools hacks on Amazon, automatically deployed
with Terraform. They typically run their own infra in the cloud, but
for email they just got tired of fighting and moved their stuff to
with Terraform. He typically run theihis own infra in the cloud, but
for email he just got tired of fighting and moved his stuff to
Microsoft's Office 365 and Outlook.
Email is important, but not absolutely mission critical. The
......@@ -587,21 +590,19 @@ Nancy has all the elite skills in the world. She can configure a
Postfix server with her left hand while her right hand writes the
Puppet manifest for the Dovecot authentication backend. She knows her
shit. She browses her mail through a UUCP over SSH tunnel using
mutt. She runs her own mail server in her basement since 1996 (true
story).
mutt. She runs her own mail server in her basement since 1996.
Email is a pain in the back and she kind of hates it, but she still
believes everyone should be entitled to run their own mail server,
damnit.
believes everyone should be entitled to run their own mail server.
Their email is, of course, hosted on their own mail server, and they
have an LDAP account.
Her email is, of course, hosted on her own mail server, and she have
an LDAP account.
She will have to reconfigure their Postfix server to relay mail
through the submission or relay servers, if they want to go fancy. To
She will have to reconfigure her Postfix server to relay mail
through the submission or relay servers, if she want to go fancy. To
read email, she will need to download email from the IMAP server,
although it will still be technically possible to forward their
`@torproject.org` email to their personal server directly, as long as
although it will still be technically possible to forward her
`@torproject.org` email to her personal server directly, as long as
the server is configured to send email through the TPO servers.
## Mallory, the director
......@@ -611,10 +612,9 @@ mailing lists from accounting to HR and other obscure ones everyone
forgot what they're for. She also deals with funders, job
applicants, contractors and staff.
Email is absolutely mission critical for her. They often fail to
Email is absolutely mission critical for her. She often fails to
contact funders and critical partners because state.gov blocks our
email (or we do? she's never quite sure, and the sysadmins don't seem
to quite know either). Sometimes, she gets told through Linked in that
email (or we block theirs!). Sometimes, she gets told through LinkedIn that
a job application failed, because mail bounced at Gmail.
She has an LDAP account and it forwards to Gmail. She uses Apple
......@@ -626,8 +626,8 @@ her to keep using Gmail, but that is unsupported.
The new mail relay servers should be able to receive mail state.gov
properly. Because of the better reputation related to the new
SPF/DKIM/DMARC records, mail should bounce less (but may sometimes end
up in spam) at Gmail.
SPF/DKIM/DMARC records, mail should bounce less (but still may
sometimes end up in spam) at Gmail.
## Orpheus, the developer
......@@ -641,7 +641,7 @@ disclosures from third parties.
They have an LDAP account and it forwards to their self-hosted mail
server on a OVH virtual machine.
Email is not mission critical, but it's pretty damn annoying when it
Email is not mission critical, but it's pretty annoying when it
doesn't work.
They will have to reconfigure their mail server to relay mail through
......@@ -659,14 +659,16 @@ to be investigated and discussed further.
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).
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.
mail of Office 365 with a remote SMTP server unless they also provide an
IMAP service, see [issue tpo/tpa/team#40586][] for details.
[issue tpo/tpa/team#40586]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40586
It's also possible that implementing mailboxes could help improve spam
filtering capabilities, which are after all necessary to ensure good
......@@ -691,10 +693,10 @@ We have not explicitly designed this proposal for high availability
situations, which have been explicitly requested in [issue
tpo/tpa/team#40604](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40604). The current design actually is more scalable
than the previous legacy setup, because each machine will be setup by
Puppet and highly reproducible, with minimal local state (except the
IMAP server). So while it *may* be possible to scale up the service
for higher availability in the future, it's not a mandatory part of
the work described here.
Puppet and highly reproducible, with minimal local state (except for
the IMAP server). So while it *may* be possible to scale up the
service for higher availability in the future, it's not a mandatory
part of the work described here.
In particular, setting up new mail exchanger and submission servers is
somewhat trivial. It consists of setting up new machines in separate
......@@ -719,13 +721,13 @@ multiple servers and is definitely considered out of scope.
At Debian.org, it's possible for members to configure their own DKIM
records which allows them to sign their personal, outgoing email with
their own DKIM keys and send signed emails out to the world from their
own email. We will not support such a configuration, as it is
own email server. We will not support such a configuration, as it is
considered too complex to setup for normal users.
Furthermore, it would not *easily* help people currently hosted by
Gmail or Riseup: while it's technically possible for users to
*individually* delegate their DKIM signatures to those entities, those
keys could change without notice and would immediately break.
keys could change without notice and break delivery.
DMARC has similar problems, particularly with monitoring and error
reporting.
......@@ -762,25 +764,28 @@ the project.
## The end of email
One might also considered that email is a deprecated technology from
One might also consider that email is a deprecated technology from
another millennia, and it is not the primary objective of the Tor
Project to continue hosting or even using it.
Project to continue using it, let alone host the infrastructure.
There are, in fact, many different alternatives to email emerging,
many of which are already present and in use in the community. We
already have a [Discourse server][] that is generating great community
participation and organisation.
There are actually many different alternatives to email emerging, many
of which are already in use in the community.
For example, we already have a [Discourse server][] that is generating
great community participation and organisation.
[Discourse server]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40539
We have also seen a good uptake on the Matrix bridges to our IRC
channels. Many places are seeing increase use of chat tools like Slack
as a replacement for email, and we could adopt Matrix more broadly as
such an alternative. We also use informal Signal groups to organise
certain conversations as well.
such an alternative.
We also use informal Signal groups to organise certain conversations
as well.
[Nextcloud][] and [Big Blue Button][] also provide us with asynchronous and
synchronous coordination mechanisms already.
synchronous coordination mechanisms.
[Big Blue Button]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/conference/
[Nextcloud]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/nextcloud
......@@ -797,13 +802,24 @@ other tools:
* Schleuder could be replaced by Matrix and/or Discourse?
That being said, I doubt *all* of our personas would be in a position
That being said, we doubt *all* of our personas would be in a position
to *abandon* email completely at this point. We suspect many of our
personas, particularly in the fundraising team, would absolutely not
be able to do our work without email. We also do recurring fundraising
campaigns where we send *emails* to *thousands* of users to raise
money. An alternative to this is completely unclear so we consider
email to be a mandatory part of our infrastructure for the moment.
be able to do their work without email. We also do recurring
fundraising campaigns where we send *emails* to *thousands* of users
to raise money.
Note that if we do consider commercial alternatives, we *could* use a
mass-mailing provider service like [Mailchimp][] or [Amazon SES][] for
mass mailings, but this raises questions regarding the privacy of our
users. This is currently considered to be an unacceptable compromise.
[Mailchimp]: https://mailchimp.com/
[Amazon SES]: https://docs.aws.amazon.com/ses/
There is therefore not a clear alternative to all of those problems
right now, so we consider email to be a mandatory part of our
infrastructure for the time being.
## External hosting
......@@ -823,9 +839,8 @@ All of those service providers come with significant caveats:
makes it accessible to hostile or corrupt staff, law enforcement,
or external attackers
Therefore most of those solutions involve a significant compromise
(very large in the case of commercial providers) in terms of
privacy.
Therefore most of those solutions involve a significant compromise in
terms of privacy.
The costs here also do not take into account the residual maintenance
cost of the email infrastructure that we'll have to deal with if the
......@@ -850,8 +865,8 @@ mailboxes. While it's possible that an hostile attacker or staff could
modify the code to inspect a mailbox's content, it's leagues ahead of
most other providers in terms of privacy.
Riseup's prices are not public, but they may be close to "market"
prices quoted below.
Riseup's prices are not public, but they are close to "market" prices
quoted below.
### Gandi: 480$-2400$/year
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment