How stuff works section
Introduction
E-mail is a familiar way of transferring messages between two Internet users. E-mail was one of the earliest applications to be developed on the Internet, the first e-mail was, reputedly, sent in 1973.
The Internet E-mail system is associated with the RFC822 protocol commonly (and incorrectly) known as Simple Mail Transfer Protocol (SMTP) although as these notes will show there are several other protocols involved in the actual transfer of E-mail.
Historically there have been several other E-Mail protocols including the failed ISO-CCITT X.400 protocol, the retired UK-JANET Coloured Book protocol and numerous proprietary protocols for use under proprietary operating systems and environments. All non-SMTP systems still operational have gateways to the Internet SMTP E-mail system.
Basics
E-Mail Addresses
An E-mail address such as [email protected] has two parts known as the local part and the domain part separated by the @ symbol. The domain part identifies directly or indirectly an Internet host for receipt of the message. This host will run mail server software that will examine the local part and take whatever action is appropriate to deliver the message to the end user.
User and Transfer Agents
There are two sorts of software functionality involved in the transfer of E-mail. These are.
These are permananetly running programs on hosts with permanent Internet connections. An MTA listens for incoming e-mail from both local users and remote MTAs, examines the e-mail and either saves it locally (in a mail spool) for retrieval by the destination user or identifies and contacts a remote MTA and transfers the e-mail to the remote MTA. Several MTAs may be involved in the transfer of e-mail from originator to destination, the intermediate MTAs are known as mail relays. Typical MTAs are programs such as sendmail and exim.
A different type of MTA will listen for requests from users for any e-mail saved for them and will transfer the e-mail to the user. Host computers running MTA software are commonly known as mail servers.
An MUA is a program that a user runs when he or she wishes to send or receive E-mail. It provides a user interface for composition and local storage of mail messages and also has facilities to communicate with MTAs.
There are numerous MUAs available under modern windows based environments. Typical examples include Eudora and Microsoft Outlook. On Unix based systems character based (non-windows) based programs such as elm and mail may be encountered. World Wide Web browsers such as Netscape also commonly incorporate MUA functions.
The Mechanism
The transfer of an E-mail from a local user to a remote user will typically involve the following steps assuming both users are using personal computers with dial-up Internet connections.
The local user starts his MUA program ensuring that it is configured with the Internet address of a host running an SMTP server MTA. Theoretically he could use any MTA anywhere on the Internet, however mail server administrators normally configure MTAs so they will only accept such requests from or for users in the same domain as the server. See notes on open relaying.
The local user composes the E-mail message possibly attaching files and then tells the MUA to send the E-mail to the MTA using SMTP. He may, of course, have prepared several items of mail "off-line" and send them all once a connection is established with the MTA. The MUA autommically includes the required headers in the E-mail message based on information supplied by the user either as part of the MUA configuration or entered interactively during mail composition.
The MTA analyses the headers of the incoming message to identify the destination mail server. The MTA then attempts to communicate with the destination mail server and transfers the message using SMTP. If the message cannot be transferred it is queued in the mail spool for further attempts.
It is common that a single mail server host provides services for a large group of machines. The Internet DNS mechanism provides the facility for identifying a mail exchanger or MX host for a DNS domain so that E-mail can, apparently, be sent to a domain (such as wlv.ac.uk) rather than a specific host within that domain.
The destination mail server examines the incoming message to identify the local part of the address from the headers. This may be a nick-name (or alias) for an actual user, group of users or even a file or a program input. The server will usually store the incoming E-mail in the mail spool.
The remote user starts his MUA program ensuring that it is configured with the Internet address of a host running a POP server MTA. This may well be the same host as he uses for outgoing E-mail although this is not essential. He establishes his bona-fides to the POP server by quoting a user identification code and password and the POP server examines the mail spool and responds with details of the number of incoming E-mail messages.The user can then instruct his MUA to transfer or copy the E-mail messages to his personal computer. If the destination mail server host is a general purpose computer into which users may login, there is no need for the use of POP, user programs can directly manipulate the mail spool. This used to be standard practice and is still widely used.
This protocol is used for communication between MTAs and between MUAs and MTAs. Like many Internet protocols it runs on top of TCP and the basic structure consists of ASCII messages starting with a four letter code indicating the function of the message. Responses messages start with a three digit numeric code. All messages have a single space after the function code and are terminated with a carriage return and line feed pair. [Known as
It is possible to send E-mail without using an MUA by running a telnet session to port 23 on the mail server host although administrators are likely to discourage the practice as it by-passes any checks on the validity of the RFC 822 headers.
The RFC defines 13 standard messages.
This protocol defines the actual format of an e-mail message, particularly the headers that appear at the start of a message. All headers are required to consist of a name part and and value part. The two parts are separated by a colon followed immediately by a space. The list of headers is terminated by a null line.
The headers beginning with the letter x are not defined in RFC 822 and have been generated by the various transfer and user agents for various purposes specific to those agents.
The 'MIME' and 'content' headers are also not part of RFC 822. RFC 822 imposes no limits on the length of headers and allows headers to be folded by inserting the sequence
There are a significant number of headers defined in RFC 822. These are some of the most common.
It is now possible to discover several facts about the e-mail whose headers are shown above.
From the second Received: header, the email was originated on the host scf-6.conted.ox.ac.uk and was transferred to the host oxmail.ox.ac.uk (presumably Oxford University's main mail handling system or mail hub) which was running version 2.10 of the 'Exim' software.
The Oxford machine then contacted the SCIT mail system (sunc.scit.wlv.ac.uk) which runs version 1.73 of Exim. From the X-Mailer: header it is celar that the sender was using Microsoft Internet Mail 4.70.1161 From the Received: headers and the Delivery-Date: header the message was received by the Oxford mail hub at 11:53:26, received by the SCIT hub at 11:53:37 (11 seconds later) and delivered to the recipient's mailbox at 11:53:38. The recipient's mailbox is part of the SCIT hub's file system.
From the Date: header it will be seen that the originator's computer clock was running about 8 minutes fast ! Talking to the Mail Server - RFC822
Here's an example of a typical dialogue between an MUA and an MTA. In this example a simple telnet client is used to talk to the mail server.
The lines starting with 3 digit numbers are replies from the mail server program, the remaining lines, after the initial establishment of connection are direct user input in this case. The mail was duly delivered.