And what do you actually use? I know the answer is probably self-hosting but maybe there are other solutions for a decent privacy.
Never use email for anything requiring privacy. Email is for paper trails. That’s it. Sometimes for you, often times against you. It doesn’t matter if you use Proton, Tutanota, FastMail, Gmail etc. The other person probably isn’t and they + their provider will share anything you send so be on your best behavior.
Correct answer
Certified email would solve this, if it was possible to self host it.
Unfortunately running it requires government approval and the resulting emails are legally binding, so I assume hosts will have to go through all kinds of security controls and audits.
I think that misses the point. Emails are kind of antithetical to transient and private communications. People are much better off using a generally respectful service that doesn’t scan their mail for normal use and turn to better tools like Signal (which require both receivers to use an agreed-upon/enforced and privacy-focused infrastructure) or any other messenger with disappearing chats that limits metadata retention.
Both hands in favor!
What is the sound of one hand in favor?
Arrr! Ok, correcting to “with both hands”! Sounds better?
https://www.privacyguides.org/en/email/
Normal email is unencrypted when it’s on the wire in transit. (Nowadays they use SSL between servers, but it’s totally readable by every server in your pathway. Which isn’t much better ). The best you can hope for email is to encrypt it and store it at rest once it arrives at the server. If you self host the server you could have one way encryption enabled. If you don’t want to self host the privacy guide options are pretty good.
Don’t have any conversations via email if you can avoid it. Prefer end-to-end encrypted platforms like signal instead
These days almost every mail server will send mail over tls, but it’s not a guarantee which is a little unfortunate. Like you say there’s always privacy concerns with email, unfortunately.
I think in terms of privacy it really depends what you care about and what you’re using it for. If you care about Google reading your inbox, then self hosting can in theory help (at least for emails where the other party isn’t on Google or whatever)… Personally I like the idea of Google not knowing every company that I have an account with and everything I order online, which is information that’s definitely in your inbox. If you care about obscuring who you are to services that you sign up for with email, then arguably self hosting is not ideal because you’ll be the only one using that domain for email, and you might be better obscuring yourself through something like Apple’s “hide my email” service (which of course means you trust Apple to see those emails instead).
If you have more serious concerns and are having conversations that you don’t want anybody other than the recipient to know about email is probably the wrong choice for that conversation, but PGP is a decent option in these cases, albeit too clunky for most people. You may consider other services like protonmail or tutanota, but there are concerns with these services as well (eg, protonmail gets some flack for not encrypting metadata like message subjects, which is a big deal) and again there aren’t necessarily good guarantees for anybody you’re talking to on gmail or whatever.
Personally I like self hosting my email because of the flexibility that it offers and the price. It’s nice to be able to have as many email accounts as I want and it’s cheap to host, and I enjoyed learning about it and setting it up. My personal inbox is out of the hands of giants, but obviously if I’m emailing normal people it’s probably going to be available in the clear to Google or Microsoft (which is likely the case regardless of your solution). That’s not ideal, but it’s the reality right now with email. I kind of think of email more like a Twitter account or something at this point. It’s a semi-public way for random people to get in touch with you and a lot of conversations might be kind of explicitly public like on mailing lists, or something more akin to talking to a colleague in a public space — not super private, but a convenience, I guess?
I’d still recommend that people do try to self host their email if they’re thinking about this. Independent mail servers seem like a healthy thing for the web and learning more about it will give you a better sense of how secure / private your emails really are. Things like protonmail seem to have some advantages, but I also get some weird vibes from them and I’m not sure how much of a privacy increase they really give if you aren’t talking to other protonmail users and stuff anyway.
I use Protonmail
Proton mail with your own domain + catchall.
Has quite a few benefits over other options.
A privacy email provider and email aliases for everything you sign up for.
Email Providers
Protonmail
Tutanota
Email Alias Providers
Simplelogin
addy
There is also Firefox relay which gives you 5 email aliases. I have found that some services such as discord do not accept addy or simplelogin domains but they accept firefox relay domain which is mozmail.com if I am not mistaken
Proton pass does e-mail aliases if you pay up for the high tier subscription
Which is through SimpleLogin, which Proton bought.
Cool, didn’t know that!
Theres plenty of good reason to keep your alias provider separate from your email provider.
The first being you can lift and shift to another email provider very easily.
Secondly if something happens to your account you don’t lose the lot.
Thirdly, just get a domain with alias provider and it matters not what email provider you use ever.
The first being you can lift and shift to another email provider very easily.
All alias providers I have seen (including SimpleLogin) allow arbitrary target/“backing” mailboxes.
just get a domain with alias provider and it matters not what email provider you use ever.
Personal domains are nice for “important stuff” that should be tied to your real person.
One of the features of mail aliasing services is it to provide pseudonymity which you cannot achieve if the domain literally contains your real name.
I have a pseudo domain that has none of my info on it.
It’s something along the lines of “thisisspam.com” that forwards to my personal email accounts.
The point is, since I and not the service control my addresses I can take them anywhere.
Problem is that this domain (whether it includes your real name or not) is still related to your person as you are the sole user.
If you created accounts at Google, Amazon and Facebook using a schema of
servicename@thisspam.com, don’t you think they’d be able to tell it’s the same person who created those accounts?With the likes of
google.quothfaaoa@aliassingservice.com,amazon.qwrlaklfas9@aliassingservice.comandfacebook.1afglasdah@aliassingservice.com, that identification vector is simply ruled out.This is going to be controversial, but if I was a user of these three scummy sites what you say above isn’t the hill I’m willing to die on or care about.
However I have half a dozen domains, I could quite easily add one or two more for dumb shit like this if I wanted to.
They do but it’s a limited kind of alias. You can’t set up reverse-aliases (you send first) for example which the regular SimpleLogin can.
But its though SimpleLogin, not ProtonMail itself.
I am new to the alias world so I’ve a question. How can I be sure that an alias provider doesn’t have access to my emails when they are forwarded?
Unfortunately there is no way, it requires trust. Just like you need to trust your email provider to not have access to your emails.
A point can be made here for email providers that also provide aliasing services such as Protonmail/SimpleLogin: Since they’re the same entity, using an aliasing service requires no additional trust.
True but I believe SimpleLogin is based in France while Protonmail is based in Switzerland. Two seperate governments.
Indeed, interesting
SimpleLogin is the product of SimpleLogin SAS, registered in France under the SIREN number 884302134. SimpleLogin SAS is part of Proton AG.
Privacy is a spectrum…. A journey not a destination…
Yes self hosted is the most private to a point… ie you are responsible life configuration and security, and even good admins screw it up.
Proton is good as far as we trust them, how paranoid are you do you trust them a nS their audits?
Sigh. It is hard. Email isn’t that secure. Treat as though it will be and can be exhibit A in court…
Use signal for anything that needs to stay “that” private
Ymmv
There isn’t really privacy in email unless all recipients are encrypting the email body itself. Email leaks a lot of metadata even with GPG use, and it’s typically stored at rest in plain text.
There are tweaks you can do that will accept the unencrypted email, then immediately encrypt the message with your key so only you can read it. Then it would be safer at rest, but less convenient. It really depends on your threat model.
I own a custom domain and actually use Tutanota as my host. Self hosting is a nightmare and easy to fuck up, which leads to your emails getting sent to spam or just not receiving. I use custom domain support in Tutanota that costs me $12/yr (2 custom domains) and my domain is $15/yr. Since custom domains stick out like a sore thumb, if I need privacy then I will use AnonAddy to forward to my email with an anonymous forwarder.
Like 99.9% of my emails aren’t encrypted but that’s not the point. Tutanota removes a lot of the privacy leaks via metadata and has privacy protection measures by default like disabling images from automatically loading. Also it’s calendar/contacts/email all rolled into one and everything is e2ee. Not to mention, unlike ProtonMail, they have their own push service that works on DeGoogled Android and can be installed from fdroid.
this is a very sensible alternative to actually going all-in on self-hosting mail, which is a total pain in the ass.
deleted by creator
Oh wow. Maybe I will migrate to Tutanota from Proton then. That price, function, and dedication to privacy sounds quite attractive to me.
I’ll just say though, the client is kind of rough and may be missing a lot of features you’re used to.
self hosting email is not worth it unless you are Edward Snowden or some whistleblower trying to hide from the biggest government agencies in the world
I use fastmail.com to generate e-mail aliases. Creation is rate limited, but they are virtually unlimited; I have 500+ and counting. Aliases are randomly generated as [email protected], so they aren’t identifiable to your account.
If you want to self host, I recommend mailcow. It is not that hard to install and if you follow the instructions you’ll have a working solution whose mails are not considered spam by every other sane server. Sadly, some operate with whitelists.
I have looked at it and its system requirements are just insane. No way it would run on my cheap 1 GB VPS. I use a script for setting everything up, but less because I want to (I was warned about complications) and more because I cannot afford a second subscription.
6GB of RAM is for up to 8 concurrent users.
FWIW, self hosting email is such a pain in the arse to get to a working state, I’ll join the rest of the comments and say proton
I think if somebody does want to self host email we really shouldn’t discourage them. It’s a bit more complicated than somebody might expect going in, but you really don’t need that much to get everything in a working state, and it’s something that will get better the more people do it because more people will write tools and guides and make saner defaults, and large mail companies will have to take independent mail servers more seriously.
Totally cool if it isn’t for you of course, and people should be aware that it’s important to set up rDNS, dkim, DMARC, and SPF (most of these are just simple DNS entries that you need that help with interacting with other mail servers), because otherwise their emails are going to be sent to the spam zone… But these are not insurmountable obstacles if you really do want to do it!
No you’re right, I shouldn’t discourage, just wanted to warn it’s not the same as most other self hosting projects, where often you just need to spin up a docker container.
FWIW hasn’t DNSSEC/DANE been added to the prerequisites these days or is that still optional?
No you’re right, I shouldn’t discourage, just wanted to warn it’s not the same as most other self hosting projects, where often you just need to spin up a docker container.
Yeah, this is very fair! I just wanted to also provide the other perspective. Self hosting e-mail is very doable, and I think there are some things like mailcow / mail-in-a-box that make setting up the software on the server a lot easier (I haven’t used these, but I’ve heard good things)… But you’re probably still going to have to double check your rDNS and make sure to add the appropriate DNS entries… And you might not even realize that you have to do that, and then you’re like “why the hell can’t I send e-mail to anybody”, and it’s not the easiest thing to debug (especially if you haven’t set up DMARC entries for getting reports from other mail servers). Plus… If you get the DNS entries wrong it can be a pain to wait for the TTL to expire to make changes. The setup definitely isn’t without its headaches and hassles, but it’s not impossible and once it’s good to go you probably won’t have to change anything.
FWIW hasn’t DNSSEC/DANE been added to the prerequisites these days or is that still optional?
This is currently optional afaik. I believe you can use this to establish that your e-mail server accepts TLS so other mail servers can know not to downgrade to an unencrypted connection. Admittedly, I’m not super up to date on this, and I’m slightly confused about the differences between MTA-STS and DANE. Also fwiw, I think both of these solutions mainly impact receiving mail, and shouldn’t make much of a difference if any for you sending mail to the big providers.
Okay, so I did some research to confirm my previous understanding and for the sake of completeness I just wanted to throw this information into this thread… Neither DNSSEC/DANE nor MTA-STS is required. AFAIK none of the huge e-mail providers like Gmail, Outlook, or iCloud implement DNSSEC/DANE, but protonmail and tutanota both do. Of those everybody implements MTA-STS, except for iCloud.
In the case of e-mail both of these aim to alleviate a big security flaw in e-mail, which is that when Alice is trying to send you an e-mail, Alice’s mail server has no clue whether or not your e-mail server supports TLS (e-mail is older than TLS, so it’s bolted on in an opportunistic fashion)… As a result if somebody can get in the middle of Alice’s mail server and your mail server they can say “hey, I don’t support TLS”, and then Alice’s mail server will just say “okay, fine, here’s the e-mail unencrypted”. Obviously such a downgrade attack is BAD, so DNSSEC/DANE and MTA-STS are attempts to prevent this from happening.
DNSSEC/DANE solves this problem because it guarantees that DNS records are legitimate and it can guarantee whether or not a DNS record that says “hey the mailserver supports TLS” does or doesn’t exist. The disadvantage of this is just that it relies on DNSSEC, which has its own caveats.
MTA-STS attempts to mitigate the problem… With MTA-STS you add some DNS records that say “hey, look up the MTA-STS policy from this HTTPS server”, and the HTTPS server provides a file that says whether or not the mail server requires TLS connections to prevent downgrades. This always bothered me, though, because if somebody can attack DNS this arguably gives you very little… And if somebody is in the position to block HTTPS traffic they can prevent the policy from being fetched as well. Theoretically this doesn’t provide much of a guarantee, but I guess in practice it’s probably a decent mitigation because if a policy has been fetched before there will be a cached version available, so you’d need a sustained or well-timed attack to break MTA-STS, and on the plus side they can’t generate a bogus policy file to disable TLS connections to the mail server unless they can get a valid TLS certificate for your domain.
Either way, both of these things are pretty much entirely about receiving e-mail, and aren’t spam mitigation measures, so they shouldn’t have anything to do with your ability to send e-mail (which is the harder part). It matters for sending in the sense that you don’t want e-mail that you send to other mail servers to get downgraded from TLS when it shouldn’t either, which means your mail server should validate MTA-STS + DNSSEC/DANE for mail servers that you are sending mail to. Ideally you would set up DNSSEC/DANE and MTA-STS in order to prevent this class of attacks on your personal e-mail, though it’s not strictly necessary. MTA-STS is pretty trivial to set up as long as you already have an HTTP server on hand to serve up the policy file (which you probably do). DNSSEC may be a heavier ask for people depending on TLD support, registrar support, nameserver support, and software support (a lot of the DNSSEC signing software coughldnscough seems to choke on certain RRs -_-), but this may be easy for many people to implement.
Self-hosting email is a major pain in the ass. Good luck avoiding spam filters.
Anonaddy/Addy.io to create aliases, then PGP encrypt it before forwarding to my Google mailbox.
I also use Proton but considering ditching it in favor of Anonaddy.
I’m using Skiff Mail with two custom domains.
People here seem to think that email alias providers are more secure then a custom domain. I would argue they are the same.
If someone is going through the trouble to find you, the alias provider will give up your payment information and your real email address.
A custom domain will give up your registered information.
If you want a truly anonymous email, don’t have it funnel to your personal / main account.
