@Joel : You are going on a loooong rant there 
First off, plaintext password storage is not necessarily bad. In some cases, it’s even necessary (try to do cram-md5 without that, for instance). The security of the password database must be guaranteed (guess why we have /etc/shadow …).
If somebody gets your password database, it really does not matter much whether the passwords are in plaintext, in CRYPT hashes, or even in MD5 hashes. Sure, they can be salted – but let’s face it, most passwords (even those deemed “good” by some people) can be cracked via dictionary attack, brute force (John The Ripper), rainbow table lookups, or distributed brute force. If the security of your system depends on salted passwords and assumes the ability of an attacker to read your username/password database, it’s broken and you are SOL anyway. Plaintext passwords are quite ok, if you can control access to them (and salted hashes provide an additional layer of security, but can’t really be a defense against a determined attacker and the kinds of passwords you are likely to find at a shared webhost.
Weak passwords are guessable, correct. If you are worried about this possibility, switch to smartcard-based public key authentication (or even just plain public key auth) and never look back; too bad that DH does not offer you the possibility of restricting accounts to login via keypair only. (If you want to see why this is a good idea in general, have a look at sshd server logs of servers some time … people are bruteforcing entire ip ranges
Don’t fearmonger too much. Depending on how good your scheme is, dictionary words concatenated by other tokens can be quite secure (assuming the attacker has to bruteforce through login attempts and does not have the hash database already, in which case you are SOL in any case). Assuming a 1000 word dictionary, 100 ways to concatenate them, you end up with 100.000.000 combinations to try. Easy if you have the hash, kinda hard to do on a watched server – and English has more than 1000 words, and more than 100 ways to combine two of em
Choose your passwords according to what they are protecting and what a would-be attacker will have access to. Another thing to consider is that your username should be just as secure as your password, if possible. If people know your password but not your username, it’s not gonna do them a hell of a lot of good (though on DH servers you can circumvent this security by simply reading a very prominent sytem file on the server); still, a username of “joe” is probably bad, a username of “g42sSfß_3d” will probably not be guessed that easily.
Never using the same password twice is good advice. Most people don’t follow it. If you are one that does not follow this advice, consider how much the stuff the password is protecting is worth to you, and consider using different passwords for the more important stuff.
For email, “SPA” is not necessary. It’s a proprietary Microsoft crock of **** (basically NTLM over SMTP), which would explain why most servers do not support it. There are alternatives. If you absolutely have to use plaintext smtp, consider cram-md5 authentication (which requires serverside plaintext passwords, whoops), but the far better alternative is to not do POP3 or SMTP in the clear – use POP3/SSL, POP3/TLS, sSMTP, SMTP/TLS, etc. to make sure your stream is encrypted just as HTTP SSL would be; even if your password is transmitted using an algorithm that does not guarantee secrecy from eavesdroppers, it will be inside the encrypted stream (which just isn’t decipherable by the eavesdropper).
If you use unencrypted POP3/SMTP, you are doing the same thing you would be doing using telnet. People don’t use telnet anymore. There is a reason for that.
(and if your host does not offer secure SMTP or POP3 but does offer SSH, you could tunnel your POP/SMTP connections over that SSH connection, thereby encrypting it).
Webmail should similarly be encrypted.
(and just to make sure, all this is to avoid eavesdropping on your line or any line in between you and the server. There are cases when that is not of concern. But it really doesn’t hurt to encrypt.)
Your rant about email protocols is just that, a wild rant. “Reimplementing everything” does not work. There is no master switch, you can’t force people to “upgrade”, and even then, it’s hard to sell an “upgrade”. People inventing these schemes usually have something to gain when proposing them, often as the gatekeeper. Gatekeepers make money.
You are correct that there is a spam crisis. However, properly configured mailservers and recipients can avoid a lot of it – and no “new” protocol will not have issues when it reaches critical mass.
You can enjoy private email easily (encryption based on PGP/GPG or OpenSSL, plugins readily available). “Retrieve password” pages are the easiest way to accomplish a certain task – what else should one do ? Use plain old snail mail ? (some services do this) Convenience is king !
(of course it would help if there were a commonly accepted setting on most sites that such reset password links should be sent GPG-encrypted for you. That’s what some systems already do !)
-->