It’s particularly stupid as I then don’t have a copy of the email myself, and they have disabled text selection on the webpage so I can’t even copy and paste it (easily)!
I suppose it ensures that if the recipient isn’t using TLS with SMTP then it’s not sent unencrypted over the wire, but I suspect the vast majority of email servers are using TLS now. If someone hacks my email they have access to it anyway. I wish the system was intelligent enough to turn itself off if the recipient server has TLS, then I could almost support it as a concept.
But if someone is watching your unencrypted connection to your mail server they can just follow the link and then watch the password being sent. So meh, stupid pointless thing.
Go to about:config, and search for dom.event.clipboardevents.enabled and disable it.
These unfriendly encryption mechanisms also let us actually retract a message if it was sent to the wrong person, a feature that is on the honor system in traditional implementations.
On the user end all they know is that if they put [encrypt] in the subject they won't be written up by their compliance department. People really like not getting fired over clerical stuff so they over-use it.
It can still be forwarded (after extracting from a badly implemented site). The "ensure the right person got it" password is stupid as its literally sending it to the same email address.
The thing I find so bizarre about this is that lawyers/accountant etc. have been seeing out letters in the post forever and never had the desire to implement this level of security. Post can be intercepted, read by third parties and modified at will, just like unencrypted email. The only thing that's changed is that because there is supposedly the ability to do it someone has lobbied for there to be a mandate for it.
Just because it "can be done" doesn't mean is should or that it achieves what the motivation was.
If there is something that important that it can't be in the wrong hands then either do it in person or sent a courier with the signed for letter that requires id on delivery.
These systems are nothing other than security theatre that's sold to the unknowledgeable as something they need, when the reality is it's a complete waste of everyones time. (except for the person selling it!)
This is pretty much impossible. It's DRM. It's a pain in the ass for everyone while still not preventing the thing that it is supposed to. The analog hole (https://en.wikipedia.org/wiki/Analog_hole) is always there if nothing else.
Please don't encourage the use of broken software that is fundamentally flawed. I'm not unsympathetic to the goal of controlling the spread of certain information, but when the product plain doesn't work (preventing selecting the message text isn't stopping a cell phone pic for example) and it gets in the way of regular rule-following folks who have to take their time to get around it that's not helping anyone. It's just a total waste of time/money for all involved.
which our internal research shows is the typical way of exfiltrating information when right click is disabled by javascript
wear eye protection
All across the board MS picks the wrong people to say 'No, tough shit, gtf over yourself." to. They say it to normal users who want to do reasonable things, instead of to business owners and managers who want powers they have no moral right to.
It's fundamentally impossible to control information after it is communicated, no matter what technical gimmicks you concoct, and so it's invalid to even try in the first place. It's barking up the wrong tree and only harming the innocent and not even hindering the criminal.
If something is that precious then keep it in an airgapped lab and frisk people for cell phones at the door, and get nothing much done with that data that's so inconvenient to access.
If you need other people to access the info, then get over yourself and simply have people sign standard legal agreements. If the recipient gets hacked or something then they get hacked. That will still happen regardless. The annoying special access didn't change anything. A hacked client machine can siphon that same data.
MS just doesn't ever say "get over yourself" to the right people. They say it to you & me but treat the most offensive ideas from buisiness owners as very serious and valid needs.
It's made them a lot of money so it's not changing of course. I don't mean to pretend that there is any way or any remotest hope to change that. Only to point out how it's fundamentally wrong, and one of the reasons to simply try to avoid using any of their products and services as much as you can manage.
Goes all the way back to read receipts. The knowledge of when exactly I viewed a correspondence is obviously useful to a sender, but that usefulness does not make it something they have any right to, no matter what the excuse or rationalization is, no matter how much you try to invoke important sounding things that the message might have been about or how important sounding the consequenses like if a court case hinged on proving that you received a message or something. Not only does no one have the right to that knowledge, the mechanism doesn't even prove what it claims to prove anyway. A read receipt still does not prove that I read a message, only that an email client performed the transaction. If you really need an ack for a message, then you have the recipient, the person, send an ack, as in send another message back. Or send the message via a process server. If it's not important enough to justify a process server, then it's just not that critical and you should just get over yourself and accept that the recipient will get to it when they get to it, and you will survive not having this bit of control and visibility into someone else's life.
I discovered setting up an old IP camera recently that it’s now very hard to send an unencrypted email via SMTP. Nearly all servers refuse to relay unauthenticated emails (no username and password), and only permit authentication if the connection is SSL or promoted to SSL via STARTTLS (ie encrypted).
(I mention it because the camera wouldn’t cooperate or tell me what the problem was - ended up having to learn Wireshark and read the relevant RFCs re Authenticated SMTP).
> Ordinary people don’t exchange email messages that any powerful adversary would bother to read, and for those people, encrypted email is LARP security. It doesn’t matter whether or not these emails are safe, which is why they’re encrypted so shoddily.
Totally agree that there is no way of doing email right. If you want security, use other messaging systems, like signal, for all the reasons explained in that post.
Right now my bank, pension fund, utility supplier etc regularly e-mail me to inform me that a new statement is available. But they don't attach the statement to the e-mail... because "it isn't secure"
So there is real-world demand for a properly secured e-mail system. If we could jump in a time machine, go back 50 years and add end-to-end encryption to e-mail, I'd be getting my bank statements by e-mail.
(The chance of my bank deciding to deploy PGP is approximately one in a billion - which is why we'd need a time machine)
There is real-world demand for a properly secured messaging system (either real-time or asynchronous) that is as ubiquitous, as accessible, and as technologically neutral/decentralized as email.
I think you hit the nail on the head that if we could go back in time and email was encrypted from the start, it would be great, and there is a demand for that. But people keep trying to do that time travel by adding encryption after the fact, and like you I just don't think PGP works for that, I think it's throwing duck tape on top of a technology that is just not designed to handle it.
I'm not saying we should drop all email and move to something like Matrix, I still use email today for a lot of stuff. And I'm definitely not saying everyone should use Signal as a full email replacement (the phone number requirement and centralization problems make it unsuitable). But in the long, long term it would very likely be easier to drop email and move everyone everywhere to Matrix (or something else, it doesn't have to be an instant messenger), than it would be to try and retroactively make email encryption work well.
But look at it from the banks perspective. If they email you and ask for you to log in the bank can see who you are, and capture any info in case of fraud.
If they sent it as a secure message, they cannot capture any info on who saw it... They just know it was sent.
The new bit is the idea that someone will leak an email with an unencrypted CC: or forward. That's an easy to resolve user factors issue. If we were actually encrypting our emails then attempts to send unencrypted emails could easily be highlighted and discouraged.
Long form asynchronous messaging is important and useful, particularly in business. You can't just wave it away. By nature it can be made much more secure than something like an instant messenger[2]. The Cellebrite attack against Signal is a good example of that. Cellebrite gets all the archived messages in the case of Signal and none of the PGP messages.
Do you have glasses? - Could've gotten you killed under a different regime in a different time.
Do you own foreign books? - Could've gotten you killed under a different regime in a different time.
Do you have a mental disorder? - Could've gotten you killed under a different regime in a different time.
Is your religion not the majority in your country? - ...
Now consider the fact that regimes change. How uninteresting are your emails?
There are just too many ways things can go wrong, and of course they will go wrong at some point.
If you need confidentiality you need, at the minimum, disappearing messages, and for that to be the case all the way, you can't rely on decentralisation systems with various implementations.
Sorry for interoperable decentralised lovers, that includes myself, but you need control over the whole chain. And email is just the opposite of this.
Really, where then?
Suppose today it's opposite: Eye Sight will detoriate when not wearing proscription glasses, which gives actual minus points on sight and maybe three pedestrian red lights worth in negative social credit.
Wait, what? Adversaries do read emails of ordinary/average people. From Google[0] to the NSA[1]. Are we just pretending this doesn't happen?
[0] https://web.archive.org/web/20190331015638/https://www.wsj.c...
[1] https://www.theverge.com/2017/4/28/15474828/nsa-surveillance...
signal is not decentralized and requires phone numbers tied to your real identity. no thanks.
EDIT grammar
(1) SMIME/x509, and national security variants are incredibly popular for intra-organizational secure email (2) Secure Webmails have came on the scene in a big way.
Where SMIME/x509 fails, web-of-trust based solutions succeeds, and vice versa.
Working across both areas means we need solutions to bridge between the two worlds, and to buttress each other respective weaknesses in the trust model.
BUT:
> Ordinary people don’t exchange email messages that any powerful adversary would bother to read,
This just one hundred percent incorrect and it completely misstates the problem.
The problem is not that Alice and Bob are the focus of intensely focused surveillance, in the sense that they are up against a powerful adversary themselves.
The problem is that Alice and Bob live in a society where those who can and want to make such decisions, are implementing drag-net surveillance at every possible corner of society that they can get away with.
There is a powerful adversary and it would very much like to to read any and all of our communication.
In almost all cases this is consequence-free for Alice and Bob - but this is not Freedom.
My communication is mine it's not there for google so scan for ways to sell me useless shit, and it's not there for Big Brother for training their precog-ML models on it.
The threat model is not "The CIA wants to rubberhose me into revealing information" it's "The NSA routinely opens all of my letters, just to make sure I am not a terrorist/commie/vagrant/etc".
There is a lot of email based verification/authentication happening which would benefit if the email encryption was more widely accepted.
Mostly because the big boys want control.
I'd rather say the issue is that the big boys' business is NOT mails, so their goal is to provide the minimum viable mail service, and not spend one dollar more on it.
While once upon a time, when companies were actually providing email service, they had to innovate to keep on top.
If they did it right, it might even be a good thing. But there's not really much desire/push for it, because spam got "mostly solved" well enough.
You'd want it to be a feature-add (if enabled and used, your bank can send you secure statements direct to your email box that nobody else can read, etc) so you actually gain something; but then you have the whole "Google and Microsoft have MITM themselves on almost all email" problem anyway.
Consider Matrix instead.
* Requires phone number
* How do I run my own server?
* Doesn't have good spam protection
* Individual messages can't be categorised into folders and/or archived, then searched by category
Email can be thought of as an encrypted communications protocol where the parties can negotiate down to plain text. In other words, it isn't encrypted communication, it's bare communication over which the user might choose to send encrypted information.
Something with the ergonomics of email, but built over a platform with enforceable E2E such as Matrix, would be quite welcome. But it can't be an extension of mail protocols, or reuse the email address space, so it won't be email.
And it'll be harder for your email address to be harvested by bots since they'd have to actually download the key to see what address it's for.
Encryption at rest is another problem, one that I'm not even sure most users want.
With encrypted email, encryption at rest and encryption in flight are the same process. It uses an encrypt once scheme[2] which simplifies things immensely. As a result you only have one level of security to worry about.
At rest also a decent idea. Even if provider have the keys.
End-to-End however in system where you need to be able to send message to anyone and expect it to work is rather big can of worms.
I mean, sure, but let's be honest, a big majority of that is going to be spam, the next step down from that are silly little things like email verifications, password resets, notifications, newsletter spam, and other similar crap. As a millennial who doesn't touch emails for work or for personal reasons (because there is Slack, Signal or some other alternative to those two), I could very well be out of touch, but I'd be surprised if actual legitimate emails (both business and consumer) are more than 5% of that number.
I suppose 5% is still a big number, putting it at a comfortable ~16 billion emails.
Anyway, yes, we should be using encryption by default wherever possible, but honestly, encryption isn't easy for the common folk, which is going to be the majority of those 333 billion. Heck, I migrated away from PM and I struggled with a lot of it. As someone who mostly lives in the CLI, GnuPG is not easy to use. Something like MailVelope makes it easier, but still not that easy.
Then there is the matter of administration. Your sysadmin, especially of the bigger orgs, do not want encryption on your emails. Especially when the business you're in is regulated. Imagine being able to casually leak something without anyone knowing what's in the content? I know regulation is usually not a good answer for why not, but within a business, yes, it totally is. As a customer of Big Bank Corp, I do not want employees to be able to mess with my data, money, or worse, the money of the bank so that it can fail and for my money (or the tax payer's in case of govt protections) to be gone because everyone's emails were encrypted.
The only viable solution here is something like ProtonMail, which actually makes it easier to use, at $/£/€ 5 per month, not many are able to afford to part with that. And no, their free tier is really not that great. But regardless, even PM doesn't really help if a non PM user sends you an email.
Why do you think that their free tier is not great? AFAIK, it works like any other free tier email service but with encryption. Though it does have a limited storage space (which has increased recently). Anyone who would need more than that & has chosen to use PM probably also understands the cost of free products available & will be willing to get paid service
Disclaimer - I am a paid PM user (converted from free tier after using it for few years)
https://www.go350.com/posts/age-file-encryption/#additional-...
This is the nub of it. People don't know what they want from technology. Or rather, they are conflicted. Our collective illusion that rational technical concerns drive technology hides the reality that all digital technology is a set of power relations that help or hinder different spheres of interest - often within the same group or individuals. Many people want to do bad things and we have even created laws that insist people do bad things (as piss poor solutionism to the original bad things). Hole, spade, keep digging.
The problem of email can be seen two ways:
1. Bad protocols.
2. Bad actors.
Naturally, as techies we attack (1). Just encrypt it all. Zero trust. Train everybody to use encryption. Enforce it. Let's call that the "Rule of Tech".
By contrast, let's call (2) the "Rule of Law". There are already more than enough laws that deal with the fundamental immorality of reading someone else's private correspondence. However we have carved out so many exceptions, including those in the interests of our own profits, that we now just assume (2) is an intractable feature of the world. It isn't.
Email has shown us time and time again that the solutionism of getting people to use encryption is nigh-on impossible. Even the US government have pretty much said PGP is a dead approach.
So let's ask the question nobody wants to hear; Would it be economically wiser to enter into more layers of solutions, securing email at the technical and policy level (1), or to take a GDPR-like approach of bolstering the rule of law?
Let's be clear - this would mean taking NSA, GCHQ, Google, Microsoft etc to court, fining and if necessary dismantling the assets of those who interfere with private communication. It would mean stripping ISPs of listening taps, and auditing server rooms. It would mean something approcimating to a civic cyber police force acting IN THE INTERESTS of the public, rather than against us.
I realise how naive that sounds in this cynical epoch. But I think the ultimate cost of 'zero-trust' society may greatly outweigh the political cost of using the Rule of Law to re-establish 'trusted' networks.
Can't we give the law a chance?
No because law makers have at every turn attempted to undermine encryption. What makes you think they'll suddenly fine and/or dismantle the assets of the NSA/GCHQ? These are the agencies that have been central to both countries' security in times of war. Times of war that seemingly has never ended.
I would be very interested in a reference to that...
In this case the reason why I think it's worth focusing on the protocol is that, when an E2E encrypted protocol is designed properly, it removes an entire attack surface and significantly decreases the amount of possible human error. I think encrypted L7 overlay networks are a good solution to step aside these problems at the cost of a bit of overhead (wrapping packets, etc)
- it's about time people rediscover that emails are not webmails, even if except for few "geeky" modern MUA the real development of MUA is stuck at '90s level emails can and should be perfectly locally synced, accessed, sent and used in the more broad sense;
- I do not care about "secrecy" of my mails simply because I do not mail myself normally but third parties, since I have no control on them, no knowledge of their systems I can only assume that my messages will be public anyway. Yes, as many I have few friends with GNUPG keys, cross-signed in various occasions etc, but that's just "for fun", not for real usage simply because if GNUGP/PGP became a widespread habits anyone took it's almost useless: I do not have to discuss anything really secret via mail with some friends. At maximum I might have to privately contact third parties signaling a vulnerability, but in most cases those parties do not have a public key either...
- even if we arrive en masse to local/classic mail usage, with IMAP sync-ed maildirs, locally indexed, locally used etc, encryption can be useful ONLY if the system it live on can be trusted. Using a "safe" system on a proprietary OS on top of proprietary hw is not much different than mounting a super-strong door on a very fragile wall, a thief just need to detach the door from the wall without really facing it.
Spam detection is much more effective when you have access to the plain text of email as you can both build out better models of "this is spam" based on your entire customer base marking things that you miss or get wrong.
You also get to more trivially go "oh this email is only (say) 60% likely to be spam, but it was also sent to 200k people who have no relationship, so maybe it's closer to 90% spam".
The real killer is financial, all the "free" mail providers are making money from hosting your email. Gmail is especially egregious in this regard, and scans the content of inherently private communication in order to build out it the google surveillance infrastructure. Gmail's scanning is why companies like amazon no longer include actual order information in the emails that they send out.
A true E2E mail system (in which email was decrypted on the client side), would run counter to the googles goals for gmail.
What I'd love to see, though, is that organizations (banks, authorities, etc.) start using such systems as well so that they can actually send documents e2e encrypted.
Email encryption needs to be standardized and available in common email clients. A few proprietary providers is not a real, effective substitute.
But of course, the privacy invading "free email" providers would never play along with this.
The problem when approaching the issue especially with not-so-technical people is the difficulty of explaining how encryption would work in this scenario. Unlike Signal where a user A sends a message to a user B and the transmission is encrypted because they are using the same protocol, email is a bit trickier to explain. It would be like sending a Telegram message to Signal. Someone needs to do some conversion from one to another. Even when they use encryption, the methodology applied to encryption can be different.
So while I agree with "we should use encryption by default" for non-technical users, this isn't as straightforward. The top comment highlights an issue of the current "send a link to their server" approach, which is what Tutanota uses for example. Everyone moving on to encrypted emails would entail a mass education of users to use PGP keys for example, managing the keys themselves, understanding encryption at rest and the list goes on...
Finally, users are horrible at remembering/maintaining their passwords. Fully encrypted services such as Protonmail and Tutanota (I know proton doesn't encrypt the subject line) do not really offer password resets in the classical way - "Oh I forgot my password, well, here's my phone number give me a new password" or "just send me a reset link to this other email". This means that there is a very real risk of losing complete access to your email address or potentially losing a lot of emails. I believe Protonmail allowed password resets but it would wipe your inbox and Tutanota only allows reset using the account key that you have to generate and save somewhere, but again, a user would need to be aware of this and manage it well...
Great idea. We should. We won't, or at least, the majority won't.
example: `0x9be5d213245be984c0fb806a1d92c03a05448a4d@example.com`
It would still accept SMTP as backward compatibility and also implement e2e protocol without leaking metadata on side. It could implement other endless cool stuff on top of that (roaming with notifying addresses that you moved to new @example2.com. Send some crypto for better ranking in inbox as optional spam protection.
i did Ask HN about the idea few weeks ago but it did not get traction but there were people who liked idea and dm me in tg/discord, feels like this might be good place to resubmit it.
I like this idea. Eventually we are going to have to come to terms with the fact that there is going to be a ridiculously long number and that number is the identity. We can't hide this fact from the user and hope that things are going to work out.
Also, Matrix TCP port 8448 is meant for federation, not for client communication.
I have a feeling that Gmail could virtually single-handedly make E2E email encryption a standard practice with good UX, but they would rather be able to read your email.
Because mail MITM is extremely rare. It's much more likely your cell phone texts will get intercepted during 2FA rather than your mail.
And actually, if I had to send an encrypted email, I wouldn't use PGP. I'd send an encrypted zip file.
That itself has a standards problem. Most people don't have anything more than the archive reader installed with the OS which for Windows means nothing better than ZipCrypto is supported IIRC. ZipCrypto can be broken so trivially, that it isn't worth bothering with. 7zip and other tools support stronger methods, even with .zip archives, but many people can't read the result.
There is also the good old key exchange problem as you are using symmetric encryption: you need a second channel to send the key over. Fine for friends and others you already have more than one contact route between, there are a number of ways to communicate after all, but not for general comms. It is scary how many people in a supposedly security aware industry I see sending encrypted archives by mail then sending the password in another mail, or sending the password and a link to the content hosted elsewhere in the same email.
Good idea but too complicated for the average Joe.
It could be made much easier by building all the necessary steps right into the email client. Just select "Encrypt attachments".
Most of the attempts to address the issue have missed the boat by trying to encrypt the entire email in some non-standardized way.
I would not expect this to be true. TLS adoption is not universal (and it would be nice to make it so), but I don’t believe it’s that far off it. This hop-by-hop encryption protects the traffic from all but your own email service provider.
Yes, I am misconstruing the article’s intent, which seems to be talking about end-to-end encrypted message content, so that your email service provider can’t see it either, but what it actually says here is just flatly wrong. The messages are sent encrypted (conditions apply), and promptly decrypted by the receiving mail server, so that it can do useful stuff with it rather than just treating it as an opaque blob.
The article completely fails to note the harsh compromises that must be made if you want to further encrypt messages with PGP or S/MIME or whatever. For most people, the most obvious one is that any form of webmail is crippled and you lose all server-side search, meaning that you need to fetch all the mail locally and index it locally. This is normally infeasible for phones.
Fastmail explains the compromises well in this article on why they don’t offer PGP: https://fastmail.blog/advanced/why-we-dont-offer-pgp/. It boils down to (a) it crippling the service, and (b) not actually being useful anyway, because first-party encryption is pretty much unavoidably broken.
Most of what ProtonMail sells as privacy in their encrypted messages stuff is snake oil, plain and simple. As long as they provide the software that holds the keys, they can obtain those keys (this is a style of attack Fastmail refers to in that article—though Fastmail assumes you’d send the key with each request, rather than the email service provider being just a blob store and decryption happening on the client, but changing the code makes exfiltrating that trivial). This is a systemic failing of first-party encryption in the presence of automatic software updates (which is the default on almost all platforms, and fundamental to the web). The only path to real success requires that the platform and the encryption provider be distinct. To ProtonMail’s credit, they have done at least some pushing in the direction of what’s essentially reproducible builds for the web, so that clients can actually reliably detect when something’s changed (subresource integrity is a starting point, but insufficient as it doesn’t protect the top-level resource). I don’t think anything has actually come of it (it’s a fairly tiny niche that there’s not much interest in), but they are trying.
(Disclosure: I worked on Fastmail’s webmail in 2017–2020. I do not believe this has significantly influenced my position on these matters, save that my opinions are better informed than they were before; but I already saw and understood the problems of first-party end-to-end encryption. I find Fastmail’s position in this matter to be eminently reasonable and well-expressed.)
Server-side (spam-)filtering would be another victim. (Okay, so in my case my personal filters mostly operate only on the From:/To:/... headers and so wouldn't be affected, but the effectiveness of spam filtering would definitively be reduced somewhat if the spam filter didn't have access to the message text as well.)
Putting real legal barrier in place where at least some parties like employers could be swatted would already be improvement.
Ditch email and move on to encrypted comms that are end to end.
It’s far too easy to reply to the message without encryption or something of the sort.
Email was never designed to be encrypted.
Really it should have been integrated into DNS with a MXKS record that points at the keyserver for a domain or something similar. There could even be a default for domains without the MXKS record that you can fall back to (use MX server on a well known port). The keyservers could be verified the same way we verify HTTPS, which is the part where we drop web of trust into the dumpster and switch to a system that has already proven to be scalable and safe enough for regular users. All of this could be seamlessly integrated into mail clients. If you are worried that your keyserver will leak your email addresses you can have it return bogus key material for addresses that don't exist.
It's far too easy to copy-paste text from a web page into an unencrypted file or something of the sort (like an email).
The web was never designed to be encrypted.
Mail traffic is different: So that the sender and the receiver don't have to be online a the same time, we also need another intermediate party, i.e. the mail server. (In practice both sender and receiver utilise a mail server as an intermediate party, but here I'm mainly interested with "my" mail server on the receiving side.)
If the mail server's role was purely restricted to being a dumb store-and-forward store to hold any mails that arrive when I'm not online then, that'd be the end of the story, but in practice the mail server also fulfils a few additional functions that only work if the server actually has access to the message contents:
- Easy access from various sorts of mail clients ranging from full computers to phones to (especially for regular users these days) webmail, without having to worry about anything complicated like key management or whatnot - Server-side spam filtering - Server-side search, especially for mobile clients and webmail
And this has about the same number of possible failure points than PGP encrypted emails.
Trick a user into installing a root cert? Game over.
Find an exploit in one of the default, super trusted CAs and get them to issue you a certificate for a domain / with flags you have no business having in (like this has never happened before, I couldn’t quickly find this, but I clearly remeber the day when some major CA issued certificates and let you issue further certificates down the chain, for which the intended use was to allow you to do subdomains on your own, but they worked for any domain at all)? Game over
Nation state? Game over (except Kazakhstan, they chose the path of most resistance with a method that’s trivially defeatee)
Not to mention DPI, which can’t reveal contents, but can reveal what kind of content it is, and from that possibly identify exactly what it is.
HTTPS prevents only the most dumbed-down MITM attacks. Anyone with enough resources and determination will be able to find out exactly what you’re doing on the web without too much trouble.
In fact, we don't need to rewrite the email protocols to add E2E encryption, as Delta Chat has shown; and if backwards compatibility isn't a goal, then everyone could just move over to Matrix, instead of reinventing email.
Implementing something like a mix net for email is actually not that difficult once PGP encryption can be assumed. Basically you'd just need each mail provider to offer a "switchboard" address in a .well-known location (or in the DNS), so that Alice can wrap her message to Bob in an outer layer message that's encrypted using Bob's provider's switchboard address's public key.
This prevents Alice's provider from knowing who specifically she was sending the message to (it would only know which provider). Also, as Alice's message would contain her signature to authenticate it, her provider could use its own switchboard address as the sender, so that Bob's provider wouldn't know it was Alice specifically who sent it.
my Debian postfixes with their default config certainly don't
