Should we require custom domain support for email providers?

Continuing the discussion from Posteo (email provider):

I think this warrants a more general discussion, before we get back to talking about Posteo.

I’m open to the idea of removing this criteria, but I’m personally opposed to it and I will share why to get this discussion started:

I think that a big factor when it comes to privacy is personal autonomy. One of the biggest reasons we are in such a bad state when it comes to privacy online today is vendor lock-in and centralization. Locking people into silos based on properties of the network effect like usernames on a social network, or email domains, is a standard part of the playbook for malicious companies.

This is one of the big reasons I promote federation and ownership. You brought up Skiff in the Posteo thread, but people who used a custom domain with Skiff were far less impacted by their failure than those who did not. If it’s challenging to jump ship to the best available option at any given time, it becomes much harder to defend your privacy and other rights in the long term. This is what I think anyways.


This is not true. It would oblige someone to collect this information, sure, but not necessarily Posteo unless they are also acting as a registrar, which is not a requirement to meet this criteria.

2 Likes

when you get a custom domain, aren’t you renting it? you don’t own it the same as the email. your provider can kick you off at any time for any made-up reason or go under.
requiring custom domains is something that is dependent on the person using it. why make it a criteria for everyone?

1 Like

This should be the best-case requirement, some people might not care about custom domains.

4 Likes

iirc the reason posteo wasn’t listed wasn’t just the domain issue but also the fact that they have no dmarc policy anyone can send a fake email from a posteo domain.

I don’t really agree with them and their whole “we don’t do custom domains because privacy” line either, if you really want you can do monero or whatever just the same and people can set up mx records.

2 Likes

I think custom domain support doesn’t need to be a hard criterium for PrivacyGuides but a provider not offering it should definitely be downranked somewhat, similar to how Tuta is listed as the bottom in “more providers” because it’s incompatible with PGP.

2 Likes

I strongly share the concern over vendor lock-in and maintaining autonomy & flexibility. But I don’t think that custom domain support should be a hard requirement (for E-mail) and here is why:

E-mail Aliasing reduces the importance/significance of your base e-mail. And e-mail aliasing is a highly recommended strategy/approach regardless. If you use an aliasing service, you can mostly sidestep the issue of vendor lock-in with your e-mail provider even if you don’t use a custom domain. When you want to change from you@posteo[.]de to you@mailbox[.]org you just have to update your forwarding address with your alias provider. This assumes the user is using aliases for most or all things, but I believe that is a strategy we want to encourage regardless.

Of course you still have to consider vendor-lockin with the aliasing service itself (this is in my opinion a big thing tot consider) but that is a separate issue that will exist regardless, and should be addressed in the e-mail aliasing section.

I think I agree with @lukas that custom domain support should probably be under recommended criteria, not minimum critieria (in the context of e-mail services). Most people who will use a custom domain, know what they want, I think it can be left to readers to make that determination for themselves.

5 Likes

I think that custom domains is about as important as allowing for use with mail cilents when it comes to autonomy and freedom. IMO either make both of these things a hard requirement or make both a “best case”

No. if you buy a domain you legally are the owner of the domain.

2 Likes

I actually don’t know anyone from real life who uses a custom domain or would know how to purchase and use one. It doesn’t make sense to have this as a minimum requirement.

6 Likes

I do like custom domain support, for the reasons mentioned above, however, I feel one could argue that security issues could arise when one has accounts set to a custom domain if renewing the domain failed. But the same could happen if an email service goes belly-up and you’re not using your own domain.

Both of these can be mitigated to some degree though, and there’s other drawbacks to custom domains (getting one anonymously can be difficult) to consider.

2 Likes

I guess the question is less about whether people should use custom domains, and more about whether people should always have the option to use custom domains.

Of course some people won’t care about custom domains themselves, that is not being argued.

1 Like

There should be a red warning that the provider doesn’t support custom domains, or maybe the orange one would suffice too.

The goal is to make the user aware of such limitation while still providing a recommendation for those who don’t care.

4 Likes

A first test would be is to look whether our current recommendations all support it.

All four do.

*Snip, ignore my last comment, i forget is was already part of the minimum.

It’s already there, we’re discussing moving that to best case criteria so we can consider providers like Posteo.

There’s only three since Skiff was removed.

Posteo, the proposed fourth provider, doesn’t support custom domains.

edit: sorry, your comment explaining it was posted just 1 second before me

Forward Email will be recommended sooner or later, that’s why I said four.

I vote against such requirement.

Custom domains only increase autonomy if the user purchases their own. This requires sacrificing anonymity. Although privacy and anonymity are not the same, anonymity is nevertheless a matter of keeping your identity private. I find the custom domain requirement to be absurd because so much of the Guide is about anonymity - including the Tor and anti-fingerprinting information and recommendation.

I think the people who need this Guide the most (at least for the right reasons) are activists and journalists in undemocratic countries. Maintaining internet anonymity could be a matter of survival for them, and whether their email provider allows for custom domains is irrelevant to them, as registering a domain is not an option.

Also, the increased agency of custom domains still is not complete freedom. Correct me if I’m mistaken, but the state has the ultimate power over the domains. Don’t forget, a democratic country could become a non-democratic country.

Custom domain should definitely not be a requirement. In any case, readers of the Guide should be equipped with more information about them. The anonymity sacrifice needs to be made clear - not least because anonymous payment options are highlighted for the email service providers. No matter the country or person, I think most people would much prefer their email provider to be able to link their real identity to pseudonymous email than their state.

2 Likes

Anyone can’t fake email from a posteo domain. This was discussed here, and here.

I support removing the custom domain requirement for email services while providing information to help users make good choices for their circumstances. We might want to retain custom domains as a hard requirement for email aliasing services. (Currently, the alias service criteria just reference the email service criteria.)

It looks like PG usually recommends individual vendors, but why not consider a solution including both email aliasing and an email provider as a recommended package? For example, could “simplelogin+posteo” be a recommended email service even if posteo is not? Another approach would be to allow conditional recommendations (e.g. recommended but only in conjunction with email aliasing). [Feel free to let me know if this paragraph is too general to include in this thread.]

Below are key points that have already been made:

Users of the recommendations have varied needs. If a common and reasonable use case is excluded because of a requirement that doesn’t help in their use case, they might miss the best provider for their circumstances.

Especially since email aliasing is a recommended approach, I’d support removing custom domains as a hard requirement for email services.

1 Like