View source for Email client

{{Short description|Computer program used to access and manage a user's email}}
{{about|mail readers for Internet e-mail|BBS mail readers|Offline reader}}
[[Image:Thunderbird 102 screenshot.png|right|thumb|250px|[[Mozilla Thunderbird]] email client user interface on a [[Linux]] operating system]]

An '''email client''', '''email reader''' or, more formally, '''message user agent''' (MUA) or '''mail user agent''' is a [[computer program]] used to access and manage a user's [[email]].

A [[web app|web application]] which provides message management, composition, and reception functions may act as a [[Web email|web email client]], and a piece of [[computer hardware]] or software whose primary or most visible role is to work as an email client may also use the term.

==Retrieving messages from a mailbox==
Like most client programs, an email client is only active when a user runs it. The common arrangement is for an email user (the client) to make an arrangement with a remote [[Mail Transfer Agent]]
(MTA) server for the receipt and storage of the client's emails. The MTA, using a suitable [[mail delivery agent]] (MDA), adds email messages to a client's storage as they arrive. The remote mail storage is referred to as the user's [[E-mail Mailbox|mailbox]]. The default setting on many Unix systems is for the mail server to store formatted messages in [[mbox]], within the user's [[home directory]]. Of course, users of the system can log-in and run a mail client on the same computer that hosts their mailboxes; in which case, the server is not actually ''remote'', other than in a generic sense.

Emails are stored in the user's mailbox on the remote server until the user's email client requests them to be downloaded to the user's computer, or can otherwise access the user's mailbox on the possibly remote server. The email client can be set up to connect to multiple mailboxes at the same time and to request the download of emails either automatically, such as at pre-set intervals, or the request can be manually initiated by the user.

A user's mailbox can be accessed in two dedicated ways. The [[Post Office Protocol]] (POP) allows the user to download messages one at a time and only deletes them from the server after they have been successfully saved on local storage. It is possible to leave messages on the server to permit another client to access them. However, there is no provision for flagging a specific message as ''seen'', ''answered'', or ''forwarded'', thus POP is not convenient for users who access the same mail from different machines.

Alternatively, the [[Internet Message Access Protocol]] (IMAP) allows users to keep messages on the server, flagging them as appropriate. IMAP provides folders and sub-folders, which can be shared among different users with possibly different access rights. Typically, the ''Sent'', ''Drafts'', and ''Trash'' folders are created by default. IMAP features an [[IMAP IDLE|''idle'' extension]] for real-time updates, providing faster notification than polling, where long-lasting connections are feasible.  See also the [[#Remote messages|remote messages]] section below.

The [[JSON Meta Application Protocol]] (JMAP) is implemented using JSON APIs over HTTP and has been developed as an alternative to IMAP/SMTP.

In addition, the mailbox storage can be accessed directly by programs running on the server or via [[Clustered file system##Shared-disk|shared disks]].  Direct access can be more efficient but is less portable as it depends on the mailbox format; it is used by some email clients, including some [[#Webmail|webmail]] applications.

==Message composition==
Email clients usually contain [[Graphical user interface|user interface]]s to display and edit text. Some applications permit the use of a program-external editor.

The email clients will perform formatting according to {{IETF RFC|5322}} for [[E-mail#Header|headers]] and [[E-mail#Body|body]], and [[MIME]] for non-textual content and attachments. Headers include the destination fields, ''To'', ''Cc'' (short for ''Carbon copy''), and ''Bcc'' (''Blind carbon copy''), and the originator fields ''From'' which is the message's author(s), ''Sender'' in case there are more authors, and ''Reply-To'' in case responses should be addressed to a different mailbox. To better assist the user with destination fields, many clients maintain one or more address books and/or are able to connect to an [[LDAP]] directory server. For originator fields, clients may support different identities.

Client settings require the user's ''real name'' and ''email address'' for each user's identity, and possibly a list of LDAP servers.

==Submitting messages to a server==

When a user wishes to create and send an email, the email client will handle the task. The email client is usually set up automatically to connect to the user's mail server, which is typically either a [[Mail submission agent|MSA]] or a [[Mail transport agent|MTA]], two variations of the [[SMTP]] protocol. The email client which uses the SMTP protocol creates an authentication extension, which the mail server uses to authenticate the sender. This method eases modularity and nomadic computing. The older method was for the mail server to recognize the client's IP address, e.g. because the client is on the same machine and uses internal address 127.0.0.1, or because the client's IP address is controlled by the same [[Internet service provider]] that provides both Internet access and mail services.

Client settings require the name or IP address of the preferred ''outgoing mail server'', the ''port number'', and the ''user name'' and ''password'' for authentication, if any. The following ports are used for email submission:
  
- '''Port 465''' – The officially designated port for mail submission using [[Transport Layer Security|TLS]] from the start of the connection (Implicit TLS), as per [https://www.rfc-editor.org/rfc/rfc8314.html RFC 8314]. Since encryption is enforced from the beginning, it eliminates the risk of downgrade attacks or MITM (Man-in-the-Middle) attacks that could strip away encryption.

- '''Port 587''' – Commonly used for mail submission with support for [[STARTTLS]], allowing the connection to be optionally upgraded to TLS. However, if a MITM attacker interferes with the STARTTLS command, the connection may remain unencrypted, making it less secure than implicit TLS on port 465.  

Port 25, originally intended for message relay between MTAs, is '''not for client message submission''' and is often blocked by ISPs to prevent spam.

==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.

==Webmail==
{{Main|Webmail}}
In addition to email clients running on a desktop computer, there are those hosted remotely, either as part of a remote UNIX installation accessible by [[telnet]] (i.e. a [[shell account]]), or hosted on the [[World Wide Web|Web]].  Both of these approaches have several advantages: they share an ability to send and receive email away from the user's normal base using a [[web browser]] or telnet client, thus eliminating the need to install a dedicated email client on the user's device.

Some websites are dedicated to providing email services, and many [[Internet service provider]]s provide webmail services as part of their Internet service package. The main limitations of webmail are that user interactions are subject to the website's operating system and the general inability to download email messages and compose or work on the messages offline, although there are software packages that can integrate parts of the webmail functionality into the OS (e.g. creating messages directly from third party applications via [[MAPI]]).

Like IMAP and MAPI, webmail provides for email messages to remain on the mail server.  See [[#Remote messages|next section]].

=={{anchor|Remote messages}} Remote messages==
POP3 has an option to leave messages on the server.  By contrast, both IMAP and webmail keep messages on the server as their method of operating, albeit users can make local copies as they like.  Keeping messages on the server has advantages and disadvantages.<ref>{{cite web |url=http://itservices.stanford.edu/service/emailcalendar/email/imap/rightforme |title=Is IMAP Right for Me? |author=<!--Staff writer(s); no by-line.--> |date=4 March 2010 |work=IT Services |publisher=[[Stanford University]] |access-date=14 April 2013|archive-url=https://web.archive.org/web/20100430153051/http://itservices.stanford.edu/service/emailcalendar/email/imap/rightforme|url-status=unfit|archive-date=30 April 2010}}</ref>

===Advantages===
* Messages can be accessed from various computers or mobile devices at different locations, using different clients.
* Some kind of backup is usually provided by the server.

===Disadvantages===
* With limited bandwidth, access to long messages can be lengthy, unless the email client caches a local copy.
* There may be privacy concerns since messages that stay on the server at all times have more chances to be casually accessed by IT personnel, unless [[end-to-end encryption]] is used.

==Protocols==
Popular protocols for retrieving mail include [[POP3]] and [[IMAP4]]. Sending mail is usually done using the [[SMTP]] protocol.

Another important standard supported by most email clients is [[MIME]], which is used to send [[binary file]] [[email attachment]]s. Attachments are files that are not part of the email proper but are sent with the email.

Most email clients use a ''User-Agent''<ref>{{cite IETF |title=Netnews Article Format |rfc=5536 |sectionname=User-Agent |section=3.2.13 |date=November 2009 |publisher=[[Internet Engineering Task Force|IETF]] |quote=Some of this information has previously been sent in non-standardized header fields such as X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent, and others}}</ref> [[header (computing)|header field]] to identify the software used to send the message. This header field is defined for Netnews, but not-for e-mail, and, as such, is non-standard<ref>{{cite IETF
 | title       = Common Internet Message Headers
 | rfc         = 2076
 | date        = February 1997
 | author      = J. Palme
 | section     = 2
 | sectionname = Use of gatewaying headers
 | quote       = Headers defined only in RFC 1036 for use in Usenet News sometimes appear in mail messages, either because the messages have been gatewayed from Usenet News to e-mail, or because the messages were written in combined clients supporting both e-mail and Usenet News in the same client. These headers are not standardized for use in Internet e-mail and should be handled with caution by e-mail agents.
 | access-date = May 11, 2015
 }}
</ref> in e-mail headers.

{{IETF RFC|6409}}, ''Message Submission for Mail'', details the role of the [[Mail submission agent]].

{{IETF RFC|5068}}, ''Email Submission Operations: Access and Accountability Requirements'', provides a survey of the concepts of MTA, MSA, MDA, and MUA. It mentions that "'' Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587''" and that "''MUAs SHOULD use the SUBMISSION port for message submission.''"

{{IETF RFC|5965}}, ''An Extensible Format for Email Feedback Reports'', provides "an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties." 

===Port numbers===
Email servers and clients by convention use the [[List of TCP and UDP port numbers|TCP port numbers]] in the following table.  For MSA, IMAP and POP3, the table reports also the labels that a client can use to query the [[SRV record]]s and discover both the host name and the port number of the corresponding service.<ref>{{cite IETF |title=Use of SRV Records for Locating Email Submission/Access Services |rfc=6186 |author=Cyrus Daboo |date=March 2011 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=17 April 2013}}</ref>
{| class="wikitable"
|-
! Protocol
! Use
! Plain text or <br>encrypt sessions
! Plain text <br>sessions only
! Encrypt sessions <br>only
|-
| [[Post Office Protocol|POP3]]
| incoming mail
| style="text-align: right;" | 110 <br>_pop3._tcp
|
| style="text-align: right;" | 995 <br>_pop3s._tcp
|-
| [[Internet Message Access Protocol|IMAP4]]
| incoming mail
| style="text-align: right;" | 143 <br>_imap._tcp
|
| style="text-align: right;" | 993 <br>_imaps._tcp
|-
| [[Simple Mail Transfer Protocol|SMTP]]
| outgoing mail
| style="text-align: right;" | 25
|
|style="text-align: right;" |587
|-
| [[Mail submission agent|MSA]]
| outgoing mail
| style="text-align: right;" | 587 <br>_submission._tcp
|
| style="text-align: right;" | 465<ref>{{cite IETF |title=Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access |rfc=8314 |author1=Keith Moore |author2=Chris Newman |date=January 2018 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=12 February 2018}}</ref> <br>_submissions._tcp
|-
| [[HTTP]]
| webmail
|
| style="text-align: right;" | 80
| style="text-align: right;" | 443
|}

While webmail obeys the earlier HTTP disposition of having separate ports for encrypt and plain text sessions, mail protocols use the [[STARTTLS]] technique, thereby allowing encryption to start on an already established TCP connection. While {{IETF RFC|2595}} used to discourage the use of the previously established ports 995 and 993, {{IETF RFC|8314}} promotes the use of implicit [[Transport Layer Security|TLS]] when available.

===Proprietary client protocols===
[[Microsoft]] mail systems use the [[proprietary software|proprietary]] [[Messaging Application Programming Interface]] (MAPI) in client applications, such as [[Microsoft Outlook]], to access [[Microsoft Exchange Server|Microsoft Exchange]] electronic mail servers.

==See also==
{{Wiktionary}}
* [[Comparison of email clients]]
* [[Message submission agent]] (MSA)
* [[Mailto]]
* [[Message delivery agent]] (MDA)
* [[Message transfer agent]] (MTA)
* [[Simple Mail Transfer Protocol]]
* [[Text-based email client]]

==References==
{{reflist|30em|refs=
<ref name="sill-security">{{harvnb|Sill|2003|p=353}}: "Like SMTP, POP3 is unencrypted. Unlike SMTP, however, it needs authentication: Users have to identify themselves and prove they're who they claim to be. Unfortunately, the authentication usually consists of presenting a username and a password known only to the user and the POP3 server. Because the POP3 dialogue is unencrypted, an eavesdropper can obtain a user's username and password and reuse them to access the user's mailbox. So, plain POP3 exposes the contents of the mail messages the user retrieves, and it exposes their username and password, which can then be reused by someone else.<br/>Wrapping the POP3 dialogue with transport-layer security such as SSL solves both of these problems. Because SSL-wrapped POP3 sessions are encrypted from beginning to end, no messages, usernames, or passwords are exposed in cleartext.<br/>The optional POP3 command, <code>APOP</code>, replaces the standard <code>USER/PASS</code> authentication with a challenge-response authentication mechanism. This solves the problem of the disclosure of reusable passwords, but does nothing to prevent eavesdroppers from reading users' mail messages as they're being retrieved."</ref>
}}

==Bibliography==
{{refbegin}}
* {{cite book |title=The qmail Handbook |first=Dave |last=Sill |url=https://books.google.com/books?id=yUUnCgAAQBAJ&q=%22uw+imap%22&pg=PA348 |publisher=[[Apress]] |year=2003|isbn=9781430211341 }}
*{{cite journal
 |last        = Partridge
 |first       = Craig
 |title       = The Technical Development of Internet Email
 |journal     = IEEE Annals of the History of Computing
 |volume      = 30
 |issue       = 2
 |pages       = 3–29
 |date        = April–June 2008
 |url         = http://www.ir.bbn.com/~craig/email.pdf
 |issn        = 1934-1547
 |doi         = 10.1109/mahc.2008.32
 |s2cid = 206442868
 |url-status     = dead
 |archive-url  = https://web.archive.org/web/20110512165437/http://www.ir.bbn.com/~craig/email.pdf
 |archive-date = 2011-05-12
}}
{{refend}}

{{Email clients}}

[[Category:Email clients| ]]