In the Internet, users may want to run application programs at a remote site and create results that can be transferred to their local site.
For example, students may want to connect to their university computer lab from their home to access application programs for doing homework assignments or projects.
One way to satisfy that demand and others is to create a client/server application program for each desired service.
Programs such as file transfer programs (FTPs), e-mail (SMTP), and so on are currently available.
However, it would be impossible to write a specific client/server program for each demand.
The better solution is a general-purpose client/server program that lets a user access any application program on a remote computer; in other words, allow the user to log on to a remote computer.
After logging on, a user can use the services available on the remote computer and transfer the results back to the local computer.
To explain the architecture of e-mail, we give four scenarios. We begin with the simplest situation and add complexity as we proceed. The fourth scenario is the most common in the exchange of email.
First Scenario :
In the first scenario, the sender and the receiver of the e-mail are users (or application programs) on the same system; they are directly connected to a shared system.
The administrator has created one mailbox for each user where the received messages are stored.
A mailbox is part of a local hard drive, a special file with permission restrictions. Only the owner of the mailbox has access to it.
When Alice, a user, needs to send a message to Bob, another user, Alice runs a user agent (UA) program to prepare the message and store it in Bob's mailbox.
The message has the sender and recipient mailbox addresses (names of files).
Bob can retrieve and read the contents of his mailbox at his convenience, using a user agent.
Figure below shows the concept. This is similar to the traditional memo exchange between employees in an office.
There is a mailroom where each employee has a mailbox with his or her name on it.
When Alice needs to send a memo to Bob, she writes the memo and inserts it into Bob's mailbox. When Bob checks his mailbox, he finds Alice's memo and reads it.
Second Scenario :
In the second scenario, the sender and the receiver of the e-mail are users (or application programs) on two different systems.
The message needs to be sent over the Internet. Here we need user agents (UAs) and message transfer agents (MTAs), as shown in Figure below.
Alice needs to use a user agent program to send her message to the system at her own site. The system (sometimes called the mail server) at her site uses a queue to store messages waiting to be sent.
Bob also needs a user agent program to retrieve messages stored in the mailbox of the system at his site.
The message, however, needs to be sent through the Internet from Alice's site to Bob's site.
Here two message transfer agents are needed: one Client and one server.
Like most client/server programs on the Internet, the server needs to run all the time because it does not know when a client will ask for a connection.
The client, on the other hand, can be alerted by the system when there is a message in the queue to be sent.
Third Scenario :
In the third scenario, Bob, as in the second scenario, is directly connected to his system. Alice, however, is separated from her system.
Either Alice is connected to the system via a point-to-point WAN, such as a dial-up modem, a DSL, or a cable modern; or she is connected to a LAN in an organization that uses one mail server for handling e-mails-all users need to send their messages to this mail server.
Figure below shows the situation.Alice still needs a user agent to prepare her message. She then needs to send the message through the LAN or WAN.
This can be done through a pair of message transfer agents (client and server).
Whenever Alice has a message to send, she calls the user agent which, in tum, calls the MTA client.
The MTA client establishes a connection with the MTA server on the system, which is running all the time.
The system at Alice's site queues all messages received.
It then uses an MTA client to send the messages to the system at Bob's site; the system receives the message and stores it in Bob's mailbox.
At his convenience, Bob uses his user agent to retrieve the message and reads it. Note that we need two pairs of MTA client/server programs.
Fourth Scenario :
In the fourth and most common scenario, Bob is also connected to his mail server by a WAN or a LAN.
After the message has arrived at Bob's mail server, Bob needs to retrieve it. Here, we need another set of client/server agents, which we call message access agents (MAAs).
Bob uses an MAA client to retrieve his messages. The client sends a request to the MAA server, which is running all the time, and requests the transfer of the messages.
The situation is shown in Figure below. There are two important points here.
First, Bob cannot bypass the mail server and use the MTA server directly.
To use MTA server directly, Bob would need to run the MTA server all the time because he does not know when a message will arrive.
This implies that Bob must keep his computer on all the time if he is connected to his system through a LAN.
If he is connected through a-WAN, he must keep the connection up all the time.
Neither of these situations is feasible today.
Second, note that Bob needs another pair of client/server programs: message access programs.
This is so because an MTA client/server program is a push program: the client pushes the message to the server.
Bob needs a pull program. The client needs to pull the message from the server.
Figure below shows the difference.
The first component of an electronic mail system is the user agent (UA). It provides service to the user to make the process of sending and receiving a message easier.
A user agent is a software package (program) that composes, reads, replies to, and for- wards messages. It also handles mailboxes.
Composing Messages : A user agent helps the user compose the e-mail message to be sent out. Most user agents provide a template on the screen to be filled in by the user. Some even have a built-in editor that can do spell checking, grammar checking, and other tasks expected from a sophisticated word processor. A user, of course, could alternatively use his or her favorite text editor or word processor to create the message and import it, or cut and paste it, into the user agent template.
Reading Messages : The second duty of the user agent is to read the incoming messages. When a user invokes a user agent, it first checks the mail in the incoming mailbox. Most user agents show a one-line summary of each received mail.
Each e-mail contains the following fields
A number field.
A flag field that shows the status of the mail such as new, already read but not replied to, or read and replied to.
The size of the message.
The sender.
The optional subject field.
Replying to Messages After reading a message : , a user can use the user agent to reply to a message. A user agent usually allows the user to reply to the original sender or to reply to all recipients of the message. The reply message may contain the original message (for quick reference) and the new message.
Forwarding Messages : Replying is defined as sending a message to the sender or recipients of the copy. Forwarding is defined as sending the message to a third party. A user agent allows the receiver to forward the message, with or without extra comments, to a third party.
Handling Mailboxes : A user agent normally creates two mailboxes: an inbox and an outbox. Each box is a file with a special format that can be handled by the user agent. The inbox keeps all the received e-mails until they are deleted by the user. The outbox keeps all the sent e-mails until the user deletes them. Most user agents today are capable of creating customized mailboxes.
Command- Driven : Command-driven user agents belong to the early days of electronic mail. They are still present as the underlying user agents in servers.
A command-driven user agent normally accepts a one-character command from the keyboard to perform its task.
For example, a user can type the character r, at the command prompt, to reply to the sender of the message, or type the character R to reply to the sender and all recipients.
Some examples of command-driven user agents are mail, pine, and elm.
GUI-Based : Modem user agents are GUI-based. They contain graphical-user interface (GUI) components that allow the user to interact with the software by using both the keyboard and the mouse.
They have graphical components such as icons, menu bars, and windows that make the services easy to access. Some examples of GUI-based user agents are Gmail, Eudora, Microsoft's Outlook, and Netscape.
To send mail, the user, through the UA, creates mail that looks very similar to postal mail. It has an envelope and a message
Envelope : The envelope usually contains the sender and the receiver addresses. Message The message contains the header and the body.
The header of the message : defines the sender, the receiver, the subject of the message, and some other information (such as encoding type, as we see shortly).
The body of the message contains the actual information to be read by the recipient.
Receiving Mail : The user agent is triggered by the user (or a timer). If a user has mail, the UA informs the user with a notice.
If the user is ready to read the mail a list is displayed in which each line contains a summary of the information about a particular message in the mail- box.
The summary usually includes the sender mail address, the subject, and the time the mail was sent or received. The user can select any of the messages and display its contents on the screen.
Addresses : To deliver mail, a mail handling system must use an addressing system with unique addresses. In the Internet, the address consists of two parts: a local part and a domain name, separated by an @ sign
Local Part : The local part defines the name of a special file, called the user mailbox, where all the mail received for a user is stored for retrieval by the message access agent. Domain Name The second part of the address is the domain name.
An organization usually selects one or more hosts to receive and send e-mail; the hosts are sometimes called mail servers or exchangers.
The domain name assigned to each mail exchanger either comes from the DNS database or is a logical name (for example, the name of the organization).
Mailing List : Electronic mail allows one name, an alias, to represent several different e-mail addresses; this is called a mailing list.
Every time a message is to be sent, the system checks the recipient's name against the alias database; if there is a mailing list for the defined alias, separate messages, one for each entry in the list, must be prepared and handed to the MTA.
If there is no mailing list for the alias, the name itself is the receiving address and a single message is delivered to the mail transfer entity.
Electronic mail has a simple structure. Its simplicity, however, comes at a price. It can send messages only in 7-bit ASCII format.
In other words, it has some limitations.
For example, it cannot be used for languages that are not supported by 7-bit ASCII characters (such as French, German, Hebrew, Russian, Chinese, and Japanese).
Also, it cannot be used to send binary files or video or audio data.
Multipurpose Internet Mail Extensions (MIME) is a supplementary protocol that allows non-ASCII data to be sent through e-mail.
MIME transforms non-ASCII data at the sender site to ASCII data and delivers them to the client MTA to be sent through the Internet.
The message at the receiving side is transformed back to the original data.
We can think of MIME as a set of software functions that transforms non-ASCII data (stream of bits) to ASCII data and vice versa
MIME defines five headers that can be added to the original e-mail header section to define the transformation parameters:
MIME-Version : This header defines the version of MIME used. The current version is 1.1.
Content-Type : This header defines the type of data used in the body of the message. The content type and the content subtype are separated by a slash. Depending on the subtype, the header may contain other parameters.
Content- Transfer-Encoding : This header defines the method used to encode the messages into Osand Is for transport
Content-Id : This header uniquely identifies the whole message in a multiple-message environment.
Content-Description : This header defines whether the body is image, audio, or video.