Sounds great. I hope that Windows support without an additional crypto library dependency is added soon, e.g. using Windows CryptoAPI or Windows Cryptography API: Next Generation (CNG).
The plaintext password could probably be replaced by hashed passwords. Directly within the spec. Even though it already allows additional or different layers of security, this motivates developers to implement a basic level of security right into the application layer.
hashed passwords are security theatre unless you have a challenge-response in which password is hashed along with a challenge from the server, otherwise you don't need the password - you only need the hash to gain access. I've MITMed a system like that before when I wrote a nice interface to the awful timesheet system at a previous job.
Mandating specific security mechanisms isn't future proof. Authentication is almost a side issue to JMAP itself. Getting a securely authenticated and protected channel is phase 1, sending and receiving the JMAP protocol items is phase 2.
The reality is that almost everyone is sending plaintext passwords over SSL these days, and the reason isn't that they hate you - the reason is that it means they can bcrypt the password on the server side.
An interesting factor about most of the challenge response protocols out there - the server side needs to know either the plaintext password or something pretty reversible about the plaintext password. That's how the server can have a little chat over the wire with your client about the shared secret that they both know.
Since my security protocol design credentials aren't that much greater than the average internet commentator, I don't trust myself to design, or the average client writer to implement, a fancy security protocol that nobody has used before. Tried and true please.
Mostly agree with you, but minor nit: The server doesn't need to know anything reversible about the password. A message digest is enough.
And your final paragraph is the reason I posted my original comment in the first place. Don't design a auth/security protocol when you design a mail protocol. Delegate to OAuth, move on. (Then again... debate rages there, too[1]. Auth is not fun(tm))
I just tested GlassWire with OpenVPN on Windows 7 64-bit. I get an instant bluescreen as soon as the GlassWire driver is installed and started and OpenVPN is connected. The order doesn't matter, as soon as both applications are active, boom. Please investigate. I had to manually remove the driver, because the bluescreen occurred during installation and corrupted the deinstallation routine.
Yep, I second that feature request. My OpenVPN connection with redirect-gateway enabled sometimes looses its route definitions and suddenly all my traffic goes directly to the internet instead.
