they always do client-side auth rather than tradition server-side auth
They must have some server-side auth as well, otherwise I could just emulate requests from the bridge an pull all your PGP encrypted email from their servers. Even though it would be mostly useless it would still be a big vulnerability issue.
IMAP/SMTP-based provider to whom you always send your passwords in plaintext
Why do you say that? What led you to believe it?
Most providers are running IMAPS (IMAP over SSL) or IMAP with StartTLS (upgrade to TLS) and the same for submission to make sure there are no passwords in plain-text. Furthermore mail clients and servers also support password hashing and some, like Google, even go further and push people into IMAP/SMTP authentication with XOAUTH2 (OAuth token unique for each e-mail client).
Non-plaintext mechanisms have been designed to be safe to use even without SSL encryption. Because of how they have been designed, they require access to (…) their own special hashed version of it. doc.dovecot.org/…/authentication_mechanisms/#non-…
Going back to Proton, if they do use PGP in a generic way it means all your e-mail are encrypted and whenever you want to open the website or use the bridge they’ve to decrypt them. As you described before, they do this client side and that’s okay.
Now the next question is: how do they decrypt your mailbox? Their servers hold your private PGP key encrypted with your login password, once a client wants to decrypt your mailbox it has to pull that private key from the server and then use your password to locally decrypt it. Said now plain text key can then be used to decrypt the e-mails. This is a common security practice to make PGP and other asymmetric encryption schemes work securely without forcing the user to store and mange its own private key - that’s okay as well.
For e-mail coming from external providers (and people who don’t use PGP) Proton receives the unencrypted message (over TLS) and then encrypts it with your public PGP key. After this point you are the only person who can decrypt the message because while they also hold your private key it is encrypted thus they can’t use it to decrypt the message. This is reasonable and okay.
Now the thing is, all this can be accomplished via IMAP/SMTP, with the same level of security, if you employ a few rules:
Tell customers who want to use IMAP/SMTP that they’re required to configure PGP manually on their clients otherwise their mailbox will be encrypted / useless and they won’t be able to send e-mail;
Submission (sending e-mail via SMPT) servers configured to refuse any e-mail that isn’t PGP encrypted;
Only provide IMAP/SMTP authentication with SSL/TLS;
If they don’t go for XOAUTH2, then force people into creating a specific app password for each e-mail client - like Google also allows for legacy stuff that doesn’t support XOAUTH2.
Note that their current apps/bridge also needs to authenticate itself with some hashed version of your password, otherwise I could just emulate requests from the bridge an pull all your PGP encrypted messages from their servers. Actually using XOAUTH2 tokens or unique app passwords would be even be safer than what they’re doing.
Considering their PGP implementation is standard then doing those tweaks isn’t impossible and they would provide the same level of security their apps provide but also be flexible enough for more advanced users.