Wow, thanks for the insight and the effort in the response! > terminals and text-mode email all day, I appreciate being able to turn off settings like "Convert

Wow, thanks for the insight and the effort in the response! > terminals and text-mode email all day, I appreciate being able to turn off settings like "Convert dashes to unicode characters" and "Convert emoticons to images as you type." Emails are normally sent with a mime type of multipart/alternative with two subtypes of text/plain and text/html. Therefore, for your terminal using friend it would simply look at the text/plain version instead of the html version. Im sure you already know this, but what I am trying to illustrate here is that I believe that all of these details should be managed by the technology as in this case: the client which has a hard time displaying images etc should use the text/plain version. > "Put new text below quoted text in replies (bottom-post)" setting. This is interesting. I remember when I was in a corporate network I got about 300 emails/hour from one mailing list. Now, the client I was using then had a view that looked like a forum where you could see an email and its responses below and indented. When I wanted to follow a thread, having bottom posting was annoying because I'd have to scroll through the quote. On the other hand, If I were jumping between threads, then it was useful. I wonder if there might be a better approach which separated the quote from the response and allowed the client to display the quote when necessary. Do you understand my line of thinking or am I entirely crazy? Are there any options that you feel cannot or should not be managed by the client? Do you believe in this idea that the client should do as much as possible? As far as the security stuff, I'll try to break down my thinking. Variables to account for: valid/invalid, same as known/different from known, self signed/trusted signer/untrusted signer/unsigned. Errors in each variable mean different things and have a different chance to occur under normal conditions. For example, if the cert is plain invalid (e.g. the trusted signers signature is incorrect) this almost certainly indicates malice as opposed to the cert being different than what is currently known. This is opposed to having an untrusted signer or a self signed cert where it is possible (and almost likely) to have occurred either out of ignorance of the issuer or their simple denial to pay large sums of money for a valid cert. Furthermore, it isnt entirely uncommon for servers to switch their keys due to some security hole such as a problem in the key generation algorithm. Since the PKI provides no express way to state: this server is switching its keys, we simply take it on faith. You might think that this is unnecessary since we trust the signer, but CA's have been compromised before. The problem of no visible consequences I feel is also mishandled. If you get the initial warning at a cafe and you click through and then later at home, you get a trusted signer different from what you had at the cafe, a warning should pop up that your information was probably stolen at the cafe so you can at least change your passwords. There is a hidden problem here of dns hijacking. This is actually done commonly at "pay-for-your-wiki" places. They do not have the intention of stealing your information, but they will case security problems since they will pretend to be google.com or whomever else until you pay for the internet. I suppose that the browser should check the entity of the cert and if different from the requested entity, treat it as a redirect. This whole situation, however, requires more thought. All in all, I feel like technology is burdening the user by trying to make the user understand the technology and not the situation. Sorry if I rambled too much, but what do you think?