Since none of the existing replies go into technical detail, I'll add a few points: E-mail is sent via the SMTP protocol, a protocol that made perfect sense in

Since none of the existing replies go into technical detail, I'll add a few points: E-mail is sent via the SMTP protocol, a protocol that made perfect sense in 1982. Since then, changes have been hacked together and the protocol has been bastardized beyond recognition to achieve various goals. For example, if you want to transmit messages via an encrypted channel, you'll use the STARTTLS mode (tacked onto the protocol in the mid 2000s). But even if you are using STARTTLS, the server is likely not actually validating the certificate, as very few really do (even Google Apps / Gmail doesn't seem to check, as far as I can tell). So a MITM attacker could just set up their system to answer with a self-signed certificate, and there's a very high chance the client sending the message is going to go ahead anyway, even if it can't verify that the server it's talking to is the real SMTP server for example.com Additionally, we've had a serious problem verifying that the sender of an e-mail is legitimate. In 2006 SPF (Sender Policy Framework) was proposed, which allows a domain to declare what IP addresses can send mail from it. However using SPF breaks things (like Gmail's ability to allow you to send from another non-Gmail account, for example) and almost nobody uses hard-fail mode to reject mail based on SPF. In 2011 DKIM (DomainKeys Identified Mail) was officially standardized, and this security add-on allows the message to contain an RSA-signed header vouching that the "real" example.com generated the message. DKIM is a really big step for e-mail authentication, and is really starting to see wide adoption. However, many mail providers don't check for the DKIM header on receipt, thus leaving their users susceptible. Other grossness includes the actual message transmission schemes - using multipart messages with base64-encoded attachments, all encoded (typically) in the quoted-printable encoding. Again a great method for the late 80s, but completely, totally, 100% inappropriate for modern communications. Base64 encoding an attachment also causes the attachment to grow by roughly 33%. Client software has to be incredibly complex to deal with all of the bastardized, non-spec implementations of message boundaries, character encodings, etc. The standards are there, but are complicated and ripe for accidental or intentional abuse. And, finally, messages have to be pretty grossly constructed to support unicode (this is an example UTF-8 subject line: =?utf-8?B?Hello!?= ). The entire protocol needs a ground-up re-write. In my opinion, a lot (perhaps all) could even be borrowed from HTTPS. Imagine just sending e-mail by using a REST API, authenticated by utilizing client-side certificates. But that's probably just a pipe dream :)