Unless you meant how Protonmail specifically handles it (maybe they do it this way), I think general principles are different in some regards.
> 3) Same thing that happens right now? Two separate emails get sent out each encrypted separately
I thought the email gets encrypted to multiple recipients (at PGP level), then MUA submits one single email with all those Cc and Bcc addresses. Then the SMTP service sends the same copy (that every recipient can decrypt) to every recipient's individual mail server (one message with per mailhost).
Not the way you've described it. I don't think anyone wants to trust SMTP server with their private keys (one single reason I do not use Protonmail).
> 4) Separate emails get sent out with the receivers' public keys.
I'm afraid this won't work. Mailing lists and encryption are quite incompatible. The whole point of a mailing list is that your client doesn't know or bother to know the recipients - and they can come and go. And if you specify every recipient it's just (3).
I'm not aware about any standard on how to implement email lists/archives/newsgroups with encryption (so one joining can read past messages) and forward secrecy (so kicking someone out ensures they can only read what they have already seen).
> 5a) Everything.
Problem with existing email infrastructure is that MTAs and MDAs do a lot of transformations on the headers part of "everything". So just saying "everything" isn't exactly informative. I think the best approach is to send a full MIME-encrypted message as an attachment in a minimal envelope (so just From/To/Subject). But then there's the infamous SPAM problem - and I'd really wish it would've worked, but sadly filtering solely based on sender-receiver pairs doesn't work in reality (or I wouldn't have to maintain and train rspamd on my servers).
I was proposing that as a back of the napkin sketch for how Apple+Gmail+Office365 could implement it. But this description of ProtonMail is hugely illuminating.
This wasn't a description of Protonmail - I don't have much experience with them specifically and they may do some things differently, but of one's casual email service, like how people use PGP with existing mail systems.
I also do not claim that description to be 100% accurate - it's been a while since I've used PGP with email in practice, so I might misremember something. But to best of my awareness, this is how things are done today.
In my opinion, the main three problems with PGP today are: 1) lack of good no-frills "just works"-type tools; 2) issue with email metadata (at the very least, to/from addresses) being impossible to encrypt by design; and 3) abundance of haters (and they have a lot of right arguments, although many just boil down to the tooling issue and how it's easy to shoot everyone's legs with the current tools) who claim PGP should be buried (all together with email) - which is not exactly wrong.
> 3) Same thing that happens right now? Two separate emails get sent out each encrypted separately
I thought the email gets encrypted to multiple recipients (at PGP level), then MUA submits one single email with all those Cc and Bcc addresses. Then the SMTP service sends the same copy (that every recipient can decrypt) to every recipient's individual mail server (one message with per mailhost).
Not the way you've described it. I don't think anyone wants to trust SMTP server with their private keys (one single reason I do not use Protonmail).
> 4) Separate emails get sent out with the receivers' public keys.
I'm afraid this won't work. Mailing lists and encryption are quite incompatible. The whole point of a mailing list is that your client doesn't know or bother to know the recipients - and they can come and go. And if you specify every recipient it's just (3).
I'm not aware about any standard on how to implement email lists/archives/newsgroups with encryption (so one joining can read past messages) and forward secrecy (so kicking someone out ensures they can only read what they have already seen).
> 5a) Everything.
Problem with existing email infrastructure is that MTAs and MDAs do a lot of transformations on the headers part of "everything". So just saying "everything" isn't exactly informative. I think the best approach is to send a full MIME-encrypted message as an attachment in a minimal envelope (so just From/To/Subject). But then there's the infamous SPAM problem - and I'd really wish it would've worked, but sadly filtering solely based on sender-receiver pairs doesn't work in reality (or I wouldn't have to maintain and train rspamd on my servers).