E-mail client
From Wikipedia, the free encyclopedia
An e-mail client, aka Mail User Agent (MUA), aka e-mail reader is a frontend computer program used to manage e-mail.
Sometimes, the term e-mail client is also used to refer to any agent acting as a client toward an e-mail server, independently of it being a real MUA, a relaying server, or a human typing directly on a telnet terminal. In addition, a web application providing the relevant functionality is sometimes considered an e-mail client.
Contents |
[edit] Functionality and configuration of an MUA
Although mail user agents aim at enabling users to deal with their mail with minimal technical knowledge, some understanding of the operations involved is useful for making configuration decisions appropriate to the user's requirements.
[edit] Retrieving messages from a mailbox
Like most client programs, an MUA is only active when a user runs it. Messages arrive on the Mail Transfer Agent (MTA) server. Unless the MUA has access to the server's disk, messages are stored on a remote server and the MUA has to request them on behalf of the user.
In the first case, shared disk, a user logs on a server and runs an MUA on that machine. The MUA reads messages from a conventionally formatted storage, typically mbox, within the user's HOME directory. The MTA uses a suitable Mail Delivery Agent (MDA) to add messages to that storage, possibly in concurrence with the MUA. This is the default setting on many Unix systems. Webmail applications running on the relevant server can also benefit from direct disk access to the mail storage.
For personal computing, and whenever messages are stored on a remote system, a mail user agent connects to a remote mailbox to retrieve messages. Access to remote mailboxes comes in two flavors. On the one hand, the Post Office Protocol (POP) allows the client to download messages one at a time and only delete them from the server after they have been successfully saved on local storage. It is possible to leave messages on the server in order to let another client download 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 or clients. On the other hand, the Internet Message Access Protocol (IMAP) allows users to keep messages on the server, flagging them as appropriate. IMAP provides sub-folders. Typically, the Sent, Drafts, and Trash folders are created by default.
Both POP and IMAP clients can be configured to access more mailboxes at the same time, as well as to check each mailbox every given number of minutes. IMAP features an idle extension for real time updates, providing faster notification than polling where long lasting connections are feasible.
Client settings require the server's name or IP address, and the user name and password for each remote incoming mailbox.
[edit] Formatting messages
Mail user agents usually have built-in the ability to display and edit text. Editing HTML text is a popular feature. Invoking an external editor may be an alternative.
MUAs responsibilities include proper formatting according to RFC 5322 for headers and body, and MIME for non-textual content and attachments. Headers include the destination fields, To, Cc, and Bcc, 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 e-mail address for each user's identity, and possibly a list of LDAP servers.
[edit] Submitting messages to a server
As a basic function, an MUA is able to introduce new messages in the transport system. Typically, it does so by connecting to either an MSA or an MTA, two variations of the SMTP protocol. The client needs to put a message quickly without worrying about where the message eventually will be delivered: that's why a transport system exists. Thus it always connects to the same preferred server, however, how does that server know that it should accept and relay submissions from that client? There are two ways. The older method recognizes 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. The newer method, since the SMTP protocol has an authentication extension, is to authenticate. The latter method eases modularity and nomadic computing.
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. Transport Layer Security encryption can be configured for the standard ports, if both the client and the server support it.
[edit] Encryption
With no encryption, much like for postcards, e-mail activity is plainly visible by any occasional eavesdropper. E-mail encryption enables to safeguard privacy by encrypting the mail sessions, the body of the message, or both. Without it, anyone (examples: the government (warrantless wiretapping, great firewall of China), fellow wireless network users such as at an Internet cafe or other public network, whether the network is open or not) with network access and the right tools can monitor email and obtain login passwords.
[edit] Encryption of mail sessions
All relevant e-mail protocols have an option to encrypt the whole session. Remarkably, those options prevent a user's name and password from being sniffed, therefore they are recommended for nomadic users and whenever the internet access provider is not trusted. On sending mail, users can only control encryption at the 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 e-mail hosting service provider, possibly a different entity than the internet access provider currently at hand.
[edit] Encryption of the message body
There are two 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. Headers, including originator, recipients, and subject, remain in plain text.
[edit] Standards
While popular protocols for retrieving mail include POP3 and IMAP4, sending mail is usually done using the SMTP protocol.
Another important standard supported by most e-mail clients is MIME, which is used to send binary file e-mail attachments. Attachments are files that are not part of the e-mail proper, but are sent with the e-mail.
Most e-mail clients use an X-Mailer header to identify the software used to send the message. According to RFC 2076, this is a common but non-standard header.
RFC 4409, Message Submission for Mail, details the role of the Mail submission agent.
RFC 5068, E-mail 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."
[edit] Port numbers
TCP port numbers for e-mail default as follows:
| protocol | use | plain text or encrypt sessions | plain text sessions only | encrypt sessions only |
|---|---|---|---|---|
| POP3 | incoming mail | 110 | 995 | |
| IMAP4 | incoming mail | 143 | 993 | |
| SMTP | outgoing mail | 25 | (unofficial) 465 | |
| MSA | outgoing mail | 587 | ||
| HTTP | webmail | 80 | 443 |
[edit] Webmail
In addition to the fat client e-mail clients and small MUAs, there are also Web-based e-mail programs called webmail. Webmail has several advantages which include the ability to send and receive e-mail from anywhere using a single application: a web browser. This eliminates the need to configure an e-mail client. Significant examples of e-mail services which also provide the user a webmail interface are Hotmail, Gmail, AOL and Yahoo. The main drawbacks of webmail are that user interactions are subject to network response and that there is no offline capability. For instance, while webmail generally provides the best experience over broadband, a fat client can provide a satisfactory experience over dialup, and messages can be searched and viewed without an internet connection.
[edit] See also
|
|||||||||||||||||