All e-mail is sent using SMTP. This is covered in the following RFC 821.
POP3 is a retrieval protocol only and covered in RFC 1939.
IMAP is the same and covered in RFC 3501
All web-based mail providers simply provides an interface to the mailboxes but still apply and use the above protocols which are standards, specificed and defined by the RFC documents. Your e-mail is saved on the provider servers and using the example below then sent from one of their servers.
To expand on this. The best way to understand how to send an e-mail is to do it the way it is done mentioned in the RFC. Here is a step-by-step guide on how to send an e-mail using Telnet with SMTP.
However, to the best of my knowledge, when it comes to mail-server-to-mail-server communications, most emails are still transferred in plain text and not encrypted, making it possible to anybody on the network to read their content.
Correct. SMTP, like HTTP, is plain-text by default.
These days many mail servers support TLS (previously known as SSL) for SMTP. (This includes Gmail.) However, it has the same issues as with HTTP[S]: certificates issued by well-known CAs cost money, and self-signed ones are worthless1 for protecting against MitM attacks. If your mail server does strict validation of the receiver's certificate (like web browsers do), it might fail to deliver messages to servers that are using self-signed certificates or in-house CAs. If it doesn't, then it cannot be sure that it is talking to the right server and not an impostor.
Also, TLS is a relatively recent addition to SMTP, so even when the recipient's mail server supports TLS, the sender's might not, or it might be disabled by default.
1 (Unless the sending server supports DANE (TLSA) and the receiving server's admin cares to publish the TLSA records in DNS. This is rarely done and somewhat tedious.)
Are there any technologies that give the user some guarantees that his emails are sent securely from end to end ?
Two most common email security standards:
OpenPGP, based on web of trust and free to use. The open-source implementation is GnuPG (for Windows, for Thunderbird), and the original PGP has evolved into the commercial PGP Desktop.
For web-based email clients, FireGPG is a possibility — damn it
S/MIME, based on X.509 infrastructure. Implemented by most desktop clients (including Outlook, Thunderbird, Mail.app). However, relatively unpopular due to the same authority-based structure as TLS/SSL: signed certificates cost money, and self-signed ones cannot be reliably validated.
In both cases, encryption requires that the recipient must be already using the system and have generated/obtained a keypair. (For signing, the sender's keypair is used. The normal practice is to both sign and encrypt messages.)
Why not let the user know when encryption is not supported and let him choose if he wants his email to be still delivered ?
Usually submitted messages are queued, and neither the user nor the MTA can know whether the next hop supports TLS or not – until the message is being sent, at which point there is no reliable way to ask the user for confirmation. (They may be AFK, offline, asleep, or a script/program. If I sent the message, I want it to be delivered as soon as possible.)
Besides, with SMTP you never know if the next hop is final or if it will just relay the mail somewhere else. It's not uncommon for a backup MX to be on an entirely different network.
Therefore. end-to-end security is only possible when both sides are using OpenPGP or S/MIME.
Best Answer
Unlike others you've mentioned, MIME is not a rich text format by itself. While MIME and "Enriched text" are part of the same set of standards designed specifically for email, HTML is a markup format initially developed for the Web by the W3C.
However, nowadays most email clients and services use HTML for rich text formatting. This is because email clients and webmail services can re-use existing HTML rendering engines for displaying email:
HTML email also allows for styling with CSS, enabling professionally designed email campaigns.
Therefore, HTML format is used when you use the "Rich formatting" mode for email. It is well-supported in all popular email clients, including webmail. It is the CSS support that varies wildly between clients, especially in webmail where different services (e.g. Gmail, Hotmail) force different limitations on what can be styled and in what way.
I think the reason why "Enriched text" has not seen wide adoption is not that HTML is "better" for email (there are too many reasons why HTML is not well-suited for email to list here), but because people used what they were already familiar with and what they have existing rendering engines for.
There is something else to add here. Not all email clients run in a graphical environment; there is a significant portion of people who prefer to read email from terminal emulators ("from the command-line", in other words). Therefore it's important that all email also carries a plain-text format of its contents. Regardless of whether you use the "Rich formatting" mode while you compose email, Gmail always includes the message body in plain text format. I suspect other modern email clients do the same, although I haven't tested.
When email carries multiple formats—HTML & plaintext, in our case—it's up to the email client that receives it to choose which one it will present to the user. Graphical email clients will render HTML by default, while text-only clients will ignore the HTML version and just show the plain-text one.