I only rarely encrypt email messages themselves, mostly because few (if any) of their recipients have personal certificates. Of my encrypted messages, most aren't sent using S/MIME or whatever we are calling the standard these days - recipients get a link to a web site, where they have to register an account, authenticate, and view the message. That's not only cheating; it's also pretty weak in terms of assuring confidentiality. To be honest I think the point of the web site is that it lets you send large files to people, not strong crypto.
All of the email servers I operate support STARTTLS. Transport-layer security is just as important to me as message integrity/confidentiality/authenticity. If I could get away with it, I would force all SMTP traffic over TLS, just like I already do with my web sites (even my intranet sites are HTTPS-only). As with my human correspondents, many of the MTAs out there don't support SMTP encryption.
I sign every email I send from my computer, thanks to my client's use of smartcards for employee badges. Windows and Outlook both make this really easy to do. Mac OS X, BSD Unix, and Linux? Not a great user experience there. And smartphones? I don't know if accessing a smartcard is even possible. I wouldn't mind putting certificates on my phone as long as accessing them would still require a PIN, but my client's enrollment process doesn't encompass smartphones yet, plus I sincerely doubt that they are as difficult to compromise as my smartcard.
All of the email servers I operate support STARTTLS. Transport-layer security is just as important to me as message integrity/confidentiality/authenticity. If I could get away with it, I would force all SMTP traffic over TLS, just like I already do with my web sites (even my intranet sites are HTTPS-only). As with my human correspondents, many of the MTAs out there don't support SMTP encryption.