Editing Email client (section)

==Encryption==
With no encryption, much like for postcards, email activity is plainly visible by any occasional eavesdropper. [[Email encryption]] enables privacy to be safeguarded by encrypting the mail sessions, the body of the message, or both.  Without it, anyone with network access and the right tools can monitor email and obtain login passwords.  Examples of concern include the government [[censorship]] and [[surveillance]] and fellow wireless network users such as at an [[Internet cafe]].

All relevant email protocols have an option to encrypt the whole session, to prevent a user's ''name'' and ''password'' from being [[Packet sniffer|sniffed]]. They are strongly suggested for nomadic users and whenever the [[Internet access provider]] is not trusted.<ref>{{cite ietf 
 |         rfc = 5068
 |         bcp = 134
 |       title = Email Submission Operations: Access and Accountability Requirements
 |     section = 5
 | sectionname = Message Submission Authentication/Authorization Technologies
 | author1     = C. Hutzler
 |     author2 = D. Crocker
 |     author3 = P. Resnick
 |     author4 = E. Allman
 |     author5 = T. Finch
 |        date = November 2007
 |   publisher = [[IETF]]
 |       quote = This document does not provide recommendations on specific security implementations.  It simply provides a warning that transmitting user credentials in clear text over insecure networks SHOULD be avoided in all scenarios as this could allow attackers to listen for this traffic and steal account data.  In these cases, it is strongly suggested that an appropriate security technology MUST be used.
 |  access-date = 24 August 2011
 }} 
</ref> When sending mail, users can only control encryption at the first hop from a client to its configured ''outgoing mail server''. At any further hop, messages may be transmitted with or without encryption, depending solely on the general configuration of the transmitting server and the capabilities of the receiving one.

Encrypted mail sessions deliver messages in their original format, i.e. plain text or encrypted body, on a user's local mailbox and on the destination server's. The latter server is operated by an [[email hosting service]] provider, possibly a different entity than the Internet ''access'' provider currently at hand.

Encrypting an email retrieval session with, e.g., SSL, can protect both parts (authentication, and message transfer) of the session.<ref name="sill-security"/><ref>{{cite ietf
 |   rfc = 7817
 | title = Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols
 }}
</ref>

Alternatively, if the user has [[Secure Shell|SSH]] access to their mail server, they can use SSH [[port forwarding]] to create an encrypted tunnel over which to retrieve their emails.<ref>{{cite book |page=[https://archive.org/details/linuxserverhacks00flic/page/146 146] |title=Linux Server Hacks: 100 Industrial-Strength Tips & Tools |isbn=978-0596004613 |first=Rob |last=Flickenger |publisher=[[O'Reilly Media]] |year=2003 |quote=In addition to providing remote shell access and command execution, OpenSSH can forward arbitrary TCP ports to the other end of your connection. This can be very handy for protecting email, web, or any other traffic you need to keep private (at least, all the way to the other end of the tunnel).<br/>''ssh'' accomplishes local forwarding by binding to a local port, performing encryption, sending the encrypted data to the remote end of the ''ssh'' connection, then decrypting it and sending it to the remote host and port you specify. Start an ''ssh'' tunnel with the ''-L'' switch (short for Local):<br/><code>root@laptop:~# '''ssh -f -N -L110:''mailhost'':110 -l ''user'' ''mailhost'''''</code><br/>Naturally, substitute ''user'' with your username, and ''mailhost'' with your mail server's name or IP address. Note that you will have to be root on the laptop for this example since you'll be binding to a privileged port (110, the POP port). You should also disable any locally running POP daemon (look in ''/etc/inetd.conf'') or it will get in the way.<br/>Now to encrypt all of your POP traffic, configure your mail client to connect to localhost port 110. It will happily talk to mailhost as if it were connected directly, except that the entire conversation will be encrypted. |url-access=registration |url=https://archive.org/details/linuxserverhacks00flic/page/146 }}</ref>

===Encryption of the message body===
There are two main models for managing cryptographic keys. [[S/MIME]] employs a model based on a trusted [[certificate authority]] (CA) that signs users' public keys. [[OpenPGP]] employs a somewhat more flexible ''[[web of trust]]'' mechanism that allows users to sign one another's public keys. OpenPGP is also more flexible in the format of the messages, in that it still supports plain message encryption and signing as they used to work before [[MIME]] standardization.

In both cases, only the message body is encrypted. Header fields, including originator, recipients, and often subject, remain in plain text.