What is a Mail User Agent?

Mail User Agent is a computer program used to access and manage a user’s email. A web application that 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.

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

Message composition

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

Encryption

With no encryption, much like for postcards, email activity is 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 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. 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 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.

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.

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.