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 application which provides message management, composition, and reception functions may act as a 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.
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 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 idle extension for real-time updates, providing faster notification than polling, where long-lasting connections are feasible. See also the 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 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 applications.
Email clients usually contain user interfaces to display and edit text. Some applications permit the use of a program-external editor.
The email clients will perform formatting according to RFC 5322 for headers and 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.
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 an MSA or an 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 (25 for MTA, 587 for MSA), and the user name and password for the authentication, if any. There is a non-standard port 465 for SSL encrypted SMTP sessions, that many clients and servers support for backward compatibility.
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 sniffed. They are strongly suggested for nomadic users and whenever the Internet access provider is not trusted. [1] 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. [2] [3]
Alternatively, if the user has SSH access to their mail server, they can use SSH port forwarding to create an encrypted tunnel over which to retrieve their emails. [4]
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.
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 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 providers 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 next section.
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. [5]
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 attachments. Attachments are files that are not part of the email proper but are sent with the email.
Most email clients use a User-Agent [6] 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 [7] in e-mail headers.
RFC 6409, Message Submission for Mail, details the role of the Mail submission agent.
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."
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."
Email servers and clients by convention use the 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 records and discover both the host name and the port number of the corresponding service. [8]
Protocol | Use | Plain text or encrypt sessions | Plain text sessions only | Encrypt sessions only |
---|---|---|---|---|
POP3 | incoming mail | 110 _pop3._tcp | 995 _pop3s._tcp | |
IMAP4 | incoming mail | 143 _imap._tcp | 993 _imaps._tcp | |
SMTP | outgoing mail | 25 | 587 | |
MSA | outgoing mail | 587 _submission._tcp | 465 [9] _submissions._tcp | |
HTTP | webmail | 80 | 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 RFC 2595 used to discourage the use of the previously established ports 995 and 993, RFC 8314 promotes the use of implicit TLS when available.
Microsoft mail systems use the proprietary Messaging Application Programming Interface (MAPI) in client applications, such as Microsoft Outlook, to access Microsoft Exchange electronic mail servers.
Electronic mail is a method of transmitting and receiving messages using electronic devices. It was conceived in the late–20th century as the digital version of, or counterpart to, mail. Email is a ubiquitous and very widely used communication medium; in current use, an email address is often treated as a basic and necessary part of many processes in business, commerce, government, education, entertainment, and other spheres of daily life in most countries.
In computing, the Internet Message Access Protocol (IMAP) is an Internet standard protocol used by email clients to retrieve email messages from a mail server over a TCP/IP connection. IMAP is defined by RFC 9051.
Within the Internet email system, a message transfer agent (MTA), mail transfer agent, or mail relay is software that transfers electronic mail messages from one computer to another using the Simple Mail Transfer Protocol. In some contexts, the alternative names mail server, mail exchanger, or MX host are used to describe an MTA.
In computing, the Post Office Protocol (POP) is an application-layer Internet standard protocol used by e-mail clients to retrieve e-mail from a mail server. Today, POP version 3 (POP3) is the most commonly used version. Together with IMAP, it is one of the most common protocols for email retrieval.
The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.
Telnet is a client/server application protocol that provides access to virtual terminals of remote systems on local area networks or the Internet. It is a protocol for bidirectional 8-bit communications. Its main goal was to connect terminal devices and terminal-oriented processes.
The following tables compare general and technical features of notable email client programs.
A message submission agent (MSA), or mail submission agent, is a computer program or software agent that receives electronic mail messages from a mail user agent (MUA) and cooperates with a mail transfer agent (MTA) for delivery of the mail. It uses ESMTP, a variant of the Simple Mail Transfer Protocol (SMTP), as specified in RFC 6409.
Sieve is a programming language that can be used for email filtering. It owes its creation to the CMU Cyrus Project, creators of Cyrus IMAP server.
In cryptography, CRAM-MD5 is a challenge–response authentication mechanism (CRAM) based on the HMAC-MD5 algorithm. As one of the mechanisms supported by the Simple Authentication and Security Layer (SASL), it is often used in email software as part of SMTP Authentication and for the authentication of POP and IMAP users, as well as in applications implementing LDAP, XMPP, BEEP, and other protocols.
The following tables compare general and technical information for a number of notable webmail providers who offer a web interface in English.
Opportunistic TLS refers to extensions in plain text communication protocols, which offer a way to upgrade a plain text connection to an encrypted connection instead of using a separate port for encrypted communication. Several protocols use a command named "STARTTLS" for this purpose. It is a form of opportunistic encryption and is primarily intended as a countermeasure to passive monitoring.
Email encryption is encryption of email messages to protect the content from being read by entities other than the intended recipients. Email encryption may also include authentication.
A mailbox is the destination to which electronic mail messages are delivered. It is the equivalent of a letter box in the postal system.
SMTP Authentication, often abbreviated SMTP AUTH, is an extension of the Simple Mail Transfer Protocol (SMTP) whereby a client may log in using any authentication mechanism supported by the server. It is mainly used by submission servers, where authentication is mandatory.
Invisible mail, also referred to as iMail, i-mail or Bote mail, is a method of exchanging digital messages from an author to one or more recipients in a secure and untraceable way. It is an open protocol and its java implementation (I2P-Bote) is free and open-source software, licensed under the GPLv3.
A mailbox provider, mail service provider or, somewhat improperly, email service provider is a provider of email hosting. It implements email servers to send, receive, accept, and store email for other organizations or end users, on their behalf.
In cryptography, the Salted Challenge Response Authentication Mechanism (SCRAM) is a family of modern, password-based challenge–response authentication mechanisms providing authentication of a user to a server. As it is specified for Simple Authentication and Security Layer (SASL), it can be used for password-based logins to services like LDAP, HTTP, SMTP, POP3, IMAP and JMAP (e-mail), XMPP (chat), or MongoDB and PostgreSQL (databases). For XMPP, supporting it is mandatory.
Mailfence is secure encrypted email service that offers OpenPGP based end-to-end encryption and digital signatures. It was launched in November 2013 by Belgium-based company ContactOffice Group that has been operating an online collaboration suite since 1999.
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.
APOP
, replaces the standard USER/PASS
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."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).
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):root@laptop:~# ssh -f -N -L110:mailhost:110 -l usermailhost
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.
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.
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
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.