Application Layer Protocols


Bootstrap Protocol (BOOTP)

The Bootstrap Protocol (BOOTP) was the first widely-used host configuration protocol for TCP/IP networks, and is used to remote boot diskless client computers. The bootstrapping process involves two phases. In the first, the client is provided with a network address and other configuration parameters. In the second, the client downloads software that enables it to function on the network and perform various tasks. BOOTP deals with the first of these phases through the exchange of BOOTP request and reply messages, the format of which is shown below. The second phase usually involves the use of a simple file transfer protocol like the Trivial File Transfer Protocol (TFTP).

The BOOTP message format

The BOOTP message format


A description of the BOOTP message fields is given below.


The process begins when the BOOTP client creates a BOOTP request message. If the cliend knows its IP address and intends to continue using it, it inserts this address in the Client IP address field, otherwise it uses 0.0.0.0. It puts its MAC address in the Client hardware address field, and generates a random 32-bit number, which it puts in the Transaction ID field. The client may also specify a particular BOOTP server and boot file type using the Server host name and Boot file name respectively. The client then either broadcasts the BOOTREQUEST message (using the IP broadcast address 255.255.255.255) or, if it knows the address of the BOOTP server, unicasts the request to the server. In all cases, the transport mechanism used is UDP. The server listens for BOOTP request messages on port 67, while the client looks for replies on port 68.

On receiving a BOOTP request, the server creates a BOOTP reply message. It looks up the hardware address of the client in its configuration file to find the matching IP address, and enters this value into the Your IP address field. It then provides the filename for the boot file type requested by the client, or the default filename if none was specified, and inserts its own IP address and name into the Server IP address and Server host name fields. The server then sends the reply, either broadcast or unicast, depending on whether the broadcast flag was set in the BOOTP request. If the broadcast flag is not set and the BOOTP request message specified the client's IP address, the reply is sent to that address. If the broadcast flag is not set and the BOOTP request message did not specify the client's IP address, the server can either broadcast the message or use an ARP entry (if one exists). When the client receives the BOOTP reply, it stores the information provided, and completes the bootstrapping process by downloading the boot file, which contains operating system software. If the client has not received a response after a certain period of time, it re-sends the BOOTP request using an exponential backoff scheme for retransmissions, starting with a randomly generated retransmission interval of between 0 and 4 seconds, and doubling this timespan for each successive try (so, for example, the second retransmission interval will be between 0 and 8 seconds).

BOOTP was designed to allow BOOTP servers and clients to reside on different networks. Since the client does not usually know the address of a BOOTP server, it sends out BOOTP requests as broadcast messages, which are not forwarded by routers. Hence, if the server and client are on different networks, a problem exists. A BOOTP relay agent is required to forward broadcast BOOTP requestis commonly implemented on an IP router, which listens for transmissions from BOOTP clients on port 67. The client still creates its request message in the normal way, and is unaware of the existence of a BOOTP relay agent. When the relay agent receives a request, it puts its own IP address into the Client IP address field and sends the request to the server, which creates a reply in the normal way and sends it back to the relay agent. The relay agent then forwards the reply to the client on behalf of the server. Obviously, if the client already knows both its own IP address and that of the BOOTP server, the services of a relay agent are not required.


Border Gateway Protocol (BGP)

The Border Gateway Protocol (BGP) is an exterior router protocol used in TCP/IP networks, and is used to pass routing information between routers in different routing domains (or autonomous systems). BGP is now the standard exterior router protocol for the Internet. BGP allows border routers (or default gateways) in different routing domains to exchange routing information using various types of message over TCP connections.

Two routers are considered to be neighbours if they are connected to the same subnetwork. If they are in different routing domains, they may wand to exchange routing information. Before they can do this, a formal process of neighbour aquisition occurs in which the two routers agree to participate in a neighbour relationship for the purpose of exchanging routing information. This is achieved by the exchange of Open messages between the two routers. If a router agrees to establish a BGP connection, it will respond with an Open confirm message.

Once the relationship is established, an ongoing procedure called neighbour reachability is used to maintain the relationship, in which the routers regularly send each other Keepalive messages.

The exchange of routing information is carried out using the network reachability procedure. When a neighbour relationship is first established, each router sends the entire contents of its routing table to its neighbour. Thereafter, incremental updates are made, with only new or updated information being exchanged. Routing information information is sent from one router to the other using Update messages.

The BGP message header

All of the BGP messages have a 19-byte header (illustrated below) containing the following three fields:


The BGP message header

The BGP message header


The Openmessage

In order to acquire a neighbour, a router opens a TCP connection to the target router and sends an Open message, which uses the Autonomous System field to identify the routing domain to which the sender belongs, and the BGP identifier field to provide the IP address of the router. It also includes a Hold Time parameter, which indicates the number of seconds that the sender proposes for the value of the Hold Time (the maximum number of seconds that may elapse between successive Keepalive or Update messages to prevent the relationship from lapsing). The target router may propose a different Hold Time in its own Open message, and the value used will be the smaller of the two.

The BGP Open message

The BGP Open message

The Version field provides the BGP version number so that the recipient can determine whether it is running the same version as the sender. The Optional Parameters Length field indicates the length of the Optional Parameters field (if present). The Optional Parameters field itself may contains a list of optional parameters. The only optional parameter type currently defined is authentication information, consisting of the authentication code, which indicates what type of authentication is being used, and the authentication data, which contains data used by the authentication mechanism (if used).

The Open confirm message

The Open confirm message consists simply of the BGP header, with the type field set to 5, and is sent in response to an Open message confirming acceptance.

The Keepalive message

The Keepalive message consists simply of the BGP header, with the type field set to 4. Each router issues these messages to each of its peers often enough to prevent the Hold time from expiring.

The Update message

The update message can contain either information about a single route through the internet, or about one or more routes previously advertised by a router that are being withdrawn, or both. Information about withdrawn routes involves two fields:

Information about a single route through the network involves three fields:



The BGP Update message

The BGP Update message


The Notification message

A notification message is sent when an error condition is detected. It will close an active session and to inform the participating routers why the session is being closed. The following errors may be reported:



The BGP Notification message

The BGP Notification message


BGP Routing Information Exchange

The Border Gateway Protocol is concerned with the exchange of routing information among participating routers in multiple routing domains, or autonomous systems. A router that implements BGP will also implement an interior router protocol such as Open Shortest Path First (OSPF) to enable it to exchange routing information with other routers within its own routing domain. Using the autonomous systems AS1 and AS2 (shown below) as an example, router R1 can use OSPF to exchange routing information with routers R2, R3 and R4 in order to learn the topology of the subnetworks AS1. If R1 has an neighbour relationship with R5, R1 can issue an Update message to router R5 in AS2 which could include the identity of AS1 in AS_Path, the IP address of R1 in Next_Hop, and a list of the subnetworks in AS1 in NLRI.


BGP is used to exchange routing information between routing domains

BGP is used to exchange routing information between routing domains


Dynamic Host Configuration Protocol (DHCP)

The Dynamic Host Configuration Protocol (DHCP) enables a DHCP server to provide a TCP/IP network host with various configuration parameters, including an IP address. DHCP is an extension of the Bootstrap Protocol (BOOTP), has a similar message format, and uses the same UDP port numbers (67 and 68), enabling it to interoperate with BOOTP relay agents. DHCP packets are longer than BOOTP packets, however, allowing DHCP to provide a network client with all of the IP configuration parameters that it needs to operate. The DHCP packet format is illustrated below.

The DHCP frame format

The DHCP frame format

A description of the DHCP fields is given below.


DHCP enables clients to obtain an IP address for a fixed length of time (a lease period) which can vary from 1 minute to 99 years. Hosts that do not need permanent IP addresses can lease an address from a pool of addresses. When the lease period expires, the server can assign the IP address to another client. DHCP can allocate IP addresses using one of three mechanisms:


A client should use DHCP to reacquire or verify its IP address and network parameters whenever the network environment may have changed (e.g. on boot-up or after a disconnection from the network). If a client has a leased network address, but cannot contact a DHCP server, it may continue to use the existing address until the lease expires, at which time it must stop using the address and inform local users of the problem. A DHCP server holds a pool of network addresses from which it can satisfy client requests, and maintains a database of client address allocations and network parameters.


DHCP operation

If a client does not know its network address, it broadcasts a DHCPDISCOVER message. Each DHCP server on the network may respond with a DHCPOFFER message that includes a network address and other configuration parameters. The client receives one or more DHCPOFFER messages, chooses a server from which to request configuration parameters, and broadcasts a DHCPREQUEST message indicating which server it has selected (if no DHCPOFFER messages are received within a specified time, the client retransmits the DHCPDISCOVER message). The selected server responds to the DHCPREQUEST message with a DHCPACK message containing the required configuration parameters. A combination of the client's hardware address and the assigned network address create a unique identifier for the client, which is referred to by both the client and the DHCP server in subsequent messages.

If the selected server cannot satisfy the DHCPREQUEST message (e.g. because the address offered has already been allocated to another client), it will respond with a DHCPNAK message (DHCP servers may optionally reserve a network address offered to a client, and subsequently make it available again if no corresponding DHCPREQUEST message is forthcoming). If the client receives a DHCPACK message but subsequently discovers that the network address provided is already in use on the network, it must send a DHCPDECLINE message to the DHCP server and begin the configuration process again. Similarly, If a client receives a DHCPNAK message, it restarts the configuration process. If the client does not receive either a DHCPACK or a DHCPNAK message within a specified period, it times out and retransmits the DHCPREQUEST message. The client may relinquish a leased network address by sending a DHCPRELEASE message to the server.

If a client remembers and wishes to reuse a previously allocated network address, it broadcasts a DHCPREQUEST message that includes the network address in the requested IP address option. Servers with knowledge of the client's configuration parameters respond with a DHCPACK message or, if the request is invalid, with a DHCPNAK message (in which case the client must request a new address by restarting the configuration process). If a client has obtained a network address through some other means (e.g. manual configuration) it can send a DHCPINFORM request message to a DHCP server to obtain additional configuration parameters. The server responds with a DHCPACK message containing the configuration parameters appropriate for the client.


File Transfer Protocol (FTP)

Computers that are connected to a local area network can download files from, or upload files to, a local file server using the file management programs provided by the network operating systems running on the LAN. To transfer files to and from an Internet server, a different approach is needed. To download web pages, for example, we use Hypertext Transfer Protocol (HTTP). For the efficient transfer of large files, however, we normally use File Transfer Protocol (FTP). Using FTP, any two computers that are attached to the Internet can exchange files. Access to files in an FTP server is normally only granted to an authorised user, who is required to supply a valid username and password in order to log in to the server. Publicly available files can be accessed by any user, however, using a facility known as Anonymous FTP, which allows a user to login with the username set to anonymous and use their email address as the the password. FTP commands can be entered using a command line environment, but most users prefer to use one of the many graphical FTP client programs that are available. The command line utility provided by Windows XP, is a program called ftp.exe, located in the WINDOWS/System32 directory, and can be invoked using the Run facility on the Start menu. Users can log in to remote hosts, set the local and remote working directories, and initiate file transfers.


Using FTP from the command line

Using FTP from the command line


The FTP commands used to carry out the various activities involved with the transfer of files are listed below. Commands are transmitted as ASCII strings consisting of the name of the command itself, followed by zero or more arguments, then the carriage-return and line-feed characters.



FTP Commands
CommandAction
!Escape to command shell
? or helpPrint local help information
appendAppend to a file
asciiSet ASCII transfer type
bellBeep when command completed
binarySet binary transfer type
bye or quitTerminate FTP session and exit
cdChange remote working directory
close or disconnectTerminate FTP session
deleteDelete remote file
debugToggle debugging mode
dir or lsList contents of remote directory
get or recvReceive file
globToggle metacharacter expansion of local file names
hashToggle printing "#" for each buffer transferred
lcdChange local working directory
literal or quoteSend arbitrary FTP command
mdeleteDelete multiple files
mdir or mlsList contents of multiple remote directories
mgetGet multiple files
mkdirCreate remote directory
mputSend multiple files
mftpConnect to remote TFTP
promptForce interactive prompting on multiple commands
put or sendSend one file
pwdPrint working directory on remote machine
remotehelpGet help from remote server
renameRename file
rmdirDelete remote directory
statusShow current status
traceToggle packet tracing
typeSet file transfer type
userSend new user information
verboseToggle verbose mode

The remote host will respond to each command with a 3-digit ASCII code, optionally followed by a message. Some typical message codes and messages are shown below.



FTP message codes and typical messages
Message IDDescription
110Restart marker reply.
120Service ready in nnn minutes.
125Data connection already open. Transfer starting.
150File status okay, about to open data connection.
200Command OK.
202Command not implemented, superfluous at this site.
211System status, or system help reply.
212Directory status.
213File status.
214Help message.
215Name system type.
220Service ready for new user.
221Service closing control connection. Logged out if appropriate.
225Data connection open; no transfer in progress.
226Closing data connection. Requested file action successful.
227Entering passive mode.
230User logged in, proceed.
250Requested file action okay, completed.
257"PATHNAME" created.
331User name okay, need password.
332Need account for login.
350Requested file action pending further information.
421Service not available, closing control connection.
425Can't open data connection.
426Connection closed; transfer aborted.
450Requested file action not taken. File unavailable.
451Requested action aborted. Local error in processing.
452Requested action not taken. Insufficient storage space in system.
500Syntax error, command unrecognised.
501Syntax error in parameters or arguments.
502Command not implemented.
503Bad sequence of commands.
504Command not implemented for that parameter.
530Not logged in.
532Need account for storing files.
550Requested action not taken. File unavailable.
551Requested action aborted. Page type unknown.
552Requested file action aborted. Exceeded storage allocation.
553Requested action not taken. File name not allowed.

A graphical FTP client is illustrated below. Most graphical FTP clients work in more or less the same way. The application window is divided into two panes. The left-hand pane lists files and directories on the local computer. The right-hand pane lists files and directories on the remote computer.


A graphical FTP client

A graphical FTP client


FTP is typically used to download files and directories from public FTP sites that allow anonymous access. The procedure for doing this is as follows:

  1. Establish a connection to the remote host.
  2. Navigate to the directory on the remote host that contains the file you want.
  3. Set the options you want for the transfer. You can use either an "ASCI" transfer for text files or a "binary" transfer for software or graphic image files (some FTP clients will automatically select the appropriate type).
  4. Select the file to be transferred.
  5. Navigate to the directory or drive on your computer into which you wish to download the file.
  6. Initiate the file transfer.

An FTP session involves the interaction of various software elements. The client protocol interpreter controls the client data transfer process and issues commands to the server protocol interpreter, which responds to those commands and controls the server data transfer process. The client data transfer process communicates with the local file system, while the server data transfer process communicates with the remote file system. During an FTP session, two network connections are used. One allows the two protocol interpreters to communicate (the control connection). The other connects the two data transfer processes (the data connection). An FTP server listens on port 21 for incoming control connection requests, and usually (though not always) transmits data on port 20. The client will select two arbitrary port numbers greater than 1023 for control information and data (depending on what port numbers are available at the time the connection is established), and must tell the server which port numbers are to be used for incoming control messages and data. The use of separate connections for control and data means that a higher quality of service can be selected for the control connection, while the data connection can be configured for maximum throughput. It also avoids the problem of having to separate embedded control data from the data stream. File transfer is initiated by the client process, but both the client or the server may send data. The data transfer mechanism can be used both for file transfer and to transfer directory information from server to client.


Active and Passive FTP

FTP supports two modes of operations - active (the default mode) and passive. The mode determines whether it is the server or the client that initiates the TCP connections used to transfer data. In active mode, the server opens the data connection to the client, as illustrated below.


An active mode FTP connection

An active mode FTP connection


Passive mode is an alternative mode in which the client initiates the data connection, as illustrated below. Although not all FTP clients support passive mode, it can eliminate some of the problems associated with firewalls, since the firewall will usually allows internal connections to external networks, but not vice versa.


A passive mode FTP connection

A passive mode FTP connection



Routing Information Protocol (RIP)

The Routing Information Protocol (sometimes called IP RIP) is an Interior Gateway Protocol designed to work with medium-sized networks. It was initially defined in RFC 1058 in 1988, and is a distance vector (as opposed to link state) routing protocol. The protocol was updated in January 1993 (RFC 1388), and again in November 1994 (RFC 1723) asRIP 2. RIP uses distance vectors to compare routes to identify the best path to a given destination address.

RIP 2 allowed RIP messages to carry more information, including authentication codes, and unlike the original version of RIP supported subnet masks. RIP2 is a UDP-based protocol, and RIP2 hosts processes send and receive UDP datagrams via port number 520. RIP determines the distance between a source network and a destination network in terms of hops, with each hop in the path typically being assigned a value of 1. RIP routing-update messages are sent at regularintervals, and when the network topology changes. A router receiving a routing-update message containing routing information about a new destination network, or revised routing information about an existing routing entry, it increments the hop count indicated in the update message and amends its routing table to reflect the new information. The IP address of the router sending the update message is recorded as being the next hop. The router then notifies any other routers with which it regularly communicates of the changes.

RIP routers only store routing information for a single route to any destination - that with the smallest distance vector value. Indeed, RIP limits the number of hops allowed in a route to 15, to prevent packets from circulating continually. If a routing-update message is received that already has a hop count of 15, the router will consider the destination network to be unreachable. RIP uses various timers to regulate performance. The routing-update timer determines how often regular routing-update messages are sent. This usually occurs at intervals of 30 seconds plus a small, randomly generated time delay that prevents the network congestion that might occur if all routers simultaneously try to update each other. Each entry in a routing table has an associated route-timeout timer associated with it. When this timer expires (usually after an interval of 90 seconds), the route is marked as invalid, but is retained in the routing table. The expiry of the route-timeout timer triggers the route-flush timer. When this timer expires (normally after a further 180 secconds), the route is removed (flushed) from the routing table.

The diagram below shows the format of the IP RIP packet.


The format of the IP RIP packet

The format of the IP RIP packet


The IP RIP packet fields are summarised below:

The diagram below shows the format of the IP RIP 2 packet.


The format of the IP RIP 2 packet

The format of the IP RIP 2 packet


The IP RIP 2 packet fields are summarised below:

Despite its age and the emergence of more sophisticated routing protocols RIP is a stable, easy to configure protocol that is still widely supported. It is well suited for use in stub networks and small autonomous systems without a sufficient number of redundant paths to warrant the use of a more sophisticated protocol.



Simple Mail Transfer Protocol (SMTP)

Simple Mail Transfer Protocol is the standard Internet host-to-host mail transport protocol. It provides a mechanism for transporting electronic mail between TCP/IP hosts reliably and efficiently. SMTP traditionally operates over a TCP connection using port number 25.



The SMTP model of communication

When a user indicates a desire to send a mail message (for example, by clicking on the Send button), the SMTP process running on the user's computer establishes a connection with the SMTP process running on the destination computer (usually a mail server). SMTP commands are generated by the computer wishing to send a message, and elicit an appropriate SMTP message from the target computer in response.

Once the connection is established, the originating computer sends a MAIL command identifying the sender of the mail. If the destination computer can accept mail it responds with an OK message. The originating computer then sends a RCPT command identifying the recipient of the mail. If the destination computer can accept mail for the recipient identified, it again responds with an OK message. if not, it responds with a meassage indicating that that recipient is unknown to it. In some cases, several recipients may have been identified, each of which will undergo the same sequence. Assuming that at least one recipient is recognised by the destination computer, the originating computer will then send the mail message itself. If the destination computer is able to successfully processes the mail message, it responds once more with an OK reply.

Communication between the originating and destination computers consists of an alternating command-response dialogue that is controlled by the originating computer. Each command must be met with a response before further commands can be sent in order to ensure that the sequence of events at each end of the connection remain synchronised, and that the originating computer always knows the state of the destination computer. An SMTP response consists of a three-digit code number that has meaning for the originating computer, followed by a text message that does not. The text message may consist of one or more lines of text, and is either discarded or passed on to the user, depending on the implementation of the user's mail client. One of the most important response messages is the Service Ready message (code 220), which is sent by the destination computer to confirm that a connection has been established.

Mail messages can be transmitted directly from the originating computer to the destination computer (if a direct connection can be established), or via one or more SMTP servers. Each SMTP server involved in the transfer of mail messages must be provided with the name of both the destination computer and the destination mailbox. The sender of a message is identified by the MAIL command, allowing an SMTP server to send an error message to the sender when an error occurs with a relayed message.



SMTP Procedures

  1. MAIL - the MAIL command is used to initiate all SMTP mail transactions. It identifies the sender by providing a reverse-path that contains the sender's mailbox adress, as follows:

    MAIL FROM: <reverse-path>

    This command tells the destination computer that a new mail transaction is starting, causing it to reset all its state tables and buffers. If the receiver accepts the command, it returns an OK response code (250). The reverse-path is essentially a routing list containing the addresses of any intermediate hosts, as well as the source mailbox (the first host in the reverse-path will be the host sending the MAILcommand).

  2. RCPT - the RCPT command provides a forward-path identifying one recipient, as follows:

    RCPT TO: <forward-path>

    The forward-path is a routing list containing the addresses of both intermediate hosts and the destination mailbox. The first host in the forward-path should be the host receiving the command. If the recipient accepts the RCPT command, it returns an OK response code (250), and stores the forward-path. If the specified destination mailbox is unknown, the recipient returns a Failure response code (550). This step may be repeated a number of times.

  3. DATA - if the receiver accepts the DATA command, it returns an Intermediate response code (354) and assumes that the lines that follow are the text of the mail message. When all the message data has been read, the receiver sends an OK response (250). The end of message data is indicated by sending a line containing only a period. Once this has been received, command-response dialog can be resumed. The mail message data includes a header containing items such as Date, Subject, To, Cc, From. The DATA command will normally only fail if the transaction is incomplete (e.g. no recipients), or if resources are not available to process the message.



Forwarding

In some cases the destination information in the forward-path may be wrong, but the receiver knows the correct destination. In these circumstances, one of the following replies should be used to allow the sender to contact the correct destination:

251 User not local; will forward to <forward-path>

This indicates that the receiver knows that the recipient's mailbox is on another host, and provides the correct forward-path to use for future reference. The receiver takes responsibility for delivering the message.

551 User not local; please try <forward-path>

This indicates that the receiver knows the recipient's mailbox is on another host, and provides the correct forward-path to use. The receiver refuses to accept mail for this user, and the sender must either redirect the mail according to the information provided or return an error response to the originating computer.



Verifying and expanding

Additional features provided by SMTP include commands to verify (VRFY) a user name or expand (EXPN) a mailing list. The VRFY command takes one argument - a user name string. The response may include the full name of the user, and must include the mailbox of the user. The EXPN command also takes a string argument that identifies a mailing list. The multi-line response may include the full names of the users, and must give the mailboxes on the mailing list. Only one mailbox can be specified on each line of the response.



Sending and mailing

The main purpose of SMTP is to deliver mail messages to users' mailboxes. A similar service, provided by some hosts, is to deliver messages to users' terminals (provided the user is active on the host). Delivery to a user's mailbox is referred to as mailing, whereas delivery to a user's terminal is called sending. For many hosts, the implementation of these two services is almost identical, and for this reason the two functions are combined in SMTP. Most hosts give users the right to accept, or refuse to accept, such messages. The following three commands have been defined to support the sending options, and are used in the mail transaction instead of the MAIL command. They inform the receiver of the special semantics of the transaction:

SEND FROM: <reverse-path>

The SEND command requires that the mail data is delivered to the user's terminal. If the user is not active (or not accepting terminal messages) on the host, a 450 response may returned to a RCPT command. The mail transaction is successful if the message is delivered the terminal.

SOML FROM: <reverse-path>

The Send Or MaiL (SOML) command requires the mail data to be delivered to the user's terminal if the user is active (and accepting terminal messages) on the host. If the user is not active (or not accepting terminal messages), then the mail data is sent to the user's mailbox. The mail transaction is successful if the message is delivered either to the terminal, or to the mailbox.

SAML FROM: <reverse-path>

The Send And MaiL (SAML) command requires the mail data to be delivered to the user's terminal if the user is active (and accepting terminal messages) on the host, and to the user's mailbox. The mail transaction is successful if the message is delivered to the mailbox.

The same response codes are used for these commands as for the MAIL command.



Opening and closing connections

When a connection is opened, the HELO command is sent by the originating computer to identify itself to the destination computer as follows:

HELO <domain>

When a connection is opened, the QUIT command is sent by the originating computer to the destination computer.



Relaying

The forward-path may be a routing list of the form "@domain_1, @domain_2:JOE@domain_3", where domain_1, domain_2, and domain_3 are hosts. This example is used to emphasise the difference between a mailbox address and a route. A mailbox address is an absolute address, while a route contains information about how to get to a mailbox. The two concepts should not be confused.

Essentially, the elements that make up the forward-path are transferred to the reverse-path one by one as the message is relayed from one server to the next. The reverse-path is a reverse routing list (i.e. the route from the current location of the message to the computer on which the message originated). The first host in the forward-path should be the host receiving the SMTP commands. If, when the message arrives at an SMTP server, the first element of the forward-path is not the identifier of the server, that element should not be deleted from the forward-path. Instead, it is used to determine which host the message should be sent to next. The server meanwhile adds its own identifier to the reverse-path. The server's identifier will thus become the first item in the reverse-path.

When a server receives mail to be forwarded to another server, it can either accept or reject this task, just as it can accept or reject mail for a local user. If it accepts the task, it establishes a connection to the next host in the forward-path, and forwards the mail. If a server has accepted the task of forwarding mail, but later discovers that the forward-path is incorrect or that the mail cannot be delivered for some reason, it must notify the originator of the mail (as indicated in the reverse-path) that the message could not be delivered. Problems with such notification messages themselves should not be reported, as this could lead to an indefinite series of error messages being sent back and forth. For this reason, error notifcation messages do not normally specify a reverse-path.



Changing roles

The TURN command may be used to reverse the roles of the two programs communicating over a connection. If a sender sends the TURN command and receives an OK response code (250), then it becomes the receiver, and the receiver becomes the sender. If the receiver rejects the request, it responds to the TURN command with response code 502. This optional command is not normally used on standard TCP connections, but is quite useful in circumstances where the cost of establishing the connection is high.



A summary of SMTP commands

SMTP Commands
CommandDescription
HELOHELLO - used to identify the sender to the receiver. The argument field contains the host name of the sender. The receiver identifies itself to the sender in the connection greeting response, and in the response to this command. This command and an OK response to it confirm that both the sender and the receiver are in the initial state (i.e. there is no transaction in progress, and all state tables and buffers are cleared).
MAILMAIL - used to initiate a mail transaction in which the mail data is delivered to one or more mailboxes. The argument field contains a reverse-path. The reverse-path consists of an optional list of hosts and the sender's mailbox. When a list of hosts is present, it is a reverse source route and indicates that the mail was relayed through each host on the list (the first host in the list is the most recent relay). This list is used as a source route to return non-delivery notices to the sender. In some types of error reporting messages (e.g. undeliverable mail notifications) the reverse-path may be null. This command clears the reverse-path buffer, the forward-path buffer, and the mail data buffer, and inserts the reverse-path information from this command into the reverse-path buffer.
RCPTRECIPIENT - used to identify an individual recipient of the mail data. Multiple recipients are specified by multiple use of this command. The forward-path consists of an optional list of hosts and a required destination mailbox. If the list of hosts is present, it is a source route and indicates that the mail must be relayed to the next host on the list. If the receiver does not implement the relay function it may use the same response that it would use for an unknown local user (550). When mail is relayed, the relay host must remove itself from the beginning of the forward-path and put itself at the beginning of the reverse-path. When mail reaches its ultimate destination, the receiver puts it in the destination mailbox in accordance with its host mail conventions.
DATADATA - the receiver treats the lines following this command as mail data from the sender and appends it to the mail data buffer. Mail data is terminated by a line containing only a period. Once the receiver has processed the stored mail transaction information, the reverse-path, forward-path and mail data buffers are cleared, and the receiver must send an OK response. If the processing fails completely the receiver must send a failure response.

When the receiver accepts a message for relaying or for final delivery it inserts a time-stamp at the beginning of the mail data, indicating its own identity, the identity of the host that sent the message, and the date and time of receipt. Relayed messages will have multiple time stamp lines.

When the receiver makes the final delivery of a message it inserts a return path line at the beginning of the mail data, which preserves the information in the reverse-path from the MAIL command. The final mail data will begin with a return path line followed by one or more time stamp lines, then mail data header and body.

When processing of mail data is only partially successful (mail data is successfully delivered to some recipients but not others), the response to the DATA command must be an OK response, but the receiver must send an undeliverable mail notification message to the originator of the message - either a single notification which lists all of the failed recipients, or separate notification messages for each failed recipient. Undeliverable mail notification messages are sent using the MAIL command.
SENDSEND - used to initiate a mail transaction in which the mail data is delivered to one or more terminals. The argument field contains a reverse-path. This command is successful if the message is delivered to a terminal. The reverse-path consists of an optional list of hosts and the sender mailbox. When the list of hosts is present, it is a reverse source route and indicates that the mail was relayed through each host on the list (the first host in the list was the most recent relay). This list is used as a source route to return non-delivery notices to the sender. This command clears the reverse-path buffer, the forward-path buffer, and the mail data buffer; and inserts the reverse-path information from this command into the reverse-path buffer.
SOMLSEND OR MAIL - used to initiate a mail transaction in which the mail data is delivered to one or more terminals or mailboxes. For each recipient the mail data is delivered to the recipient's terminal if the recipient is active on the host (and accepting terminal messages), otherwise to the recipient's mailbox. The argument field contains a reverse-path. The command is successful if the message is delivered to a terminal or the mailbox. The reverse-path consists of an optional list of hosts and the sender mailbox. When the list of hosts is present, it is a reverse source route and indicates that the mail was relayed through each host on the list (the first host in the list was the most recent relay). This list is used as a source route to return non-delivery notices to the sender. This command clears the reverse-path buffer, the forward-path buffer, and the mail data buffer; and inserts the reverse-path information from this command into the reverse-path buffer.
SAMLSEND AND MAIL - used to initiate a mail transaction in which the mail data is delivered to one or more terminals and mailboxes. For each recipient the mail data is delivered to the recipient's terminal if the recipient is active on the host (and accepting terminal messages), and to the recipient's mailbox. The argument field contains a reverse-path. The command is successful if the message is delivered to the mailbox. The reverse-path consists of an optional list of hosts and the sender mailbox. When the list of hosts is present, it is a reverse source route and indicates that the mail was relayed through each host on the list (the first host in the list was the most recent relay). This list is used as a source route to return non-delivery notices to the sender. This command clears the reverse-path buffer, the forward-path buffer, and the mail data buffer; and inserts the reverse-path information from this command into the reverse-path buffer.
RSETRESET - specifies that the current mail transaction is to be aborted. Any stored sender, recipients, and mail data is discarded, and all buffers and state tables are cleared. The receiver must send an OK response.
VRFYVERIFY - asks the receiver to confirm that the argument identifies a user. If it is a user name, the full name of the user (if known) and the fully specified mailbox are returned. The command has no effect on any of the reverse-path, forward-path or mail data buffers.
EXPNEXPAND -asks the receiver to confirm that the argument identifies a mailing list, and if so, to return the membership of that list. The full name of the users (if known) and the fully specified mailboxes are returned in a multiline response. The command has no effect on any of the reverse-path, forward-path or mail data buffers.
HELPHELP - causes the receiver to send helpful information to the sender of the HELP command. The command may take an argument (e.g. any command name) and return more specific information as a response. The command has no effect on any of the reverse-path, forward-path or mail data buffers.
NOOPNO OPERATION - specifies no action other than that the receiver send an OK response. The command has no effect on any of the reverse-path, forward-path or mail data buffers, nor does it affect any parameters or previously entered commands.
QUITQUIT - specifies that the receiver must send an OK response, and close the transmission channel. The receiver should not close the transmission channel until it has replied to a QUIT command, even if there was an error. The sender should not close the transmission channel until it receives a response to the QUIT command, even if there was an error response to a previous command. If a connection is closed prematurely, the receiver should act as if a RSET command has been received (canceling any pending transaction, but not undoing any previously completed transaction). The sender should act as if the command or transaction in progress had received a temporary error.
TURNTURN - specifies that the receiver must either send an OK response and then take on the role of the sender, or send a refusal response and retain the role of the receiver. If a sender sends the TURN command and receives an OK response (250) then it becomes the receiver, assumes the initial state as if the transmission channel has just opened, and sends the 220 service ready greeting. The receiver in turn becomes the sender, assumes the initial state as if the transmission channel has just opened, and expects to receive the 220 service ready greeting. To refuse to change roles, the receiver sends the 502 response.

There are restrictions on the order in which commands may be used. The first command in a session must be the HELO command (the HELO command may be used again later in the session). If the HELO command argument is not accepted, a 501 failure response code must be returned, and the receiver maintains its current state.

The NOOP, HELP, EXPN, and VRFY commands can be used at any time during a session.

The MAIL, SEND, SOML, or SAML commands are used to begin a mail transaction. A mail transaction consists of one of these commands, one or more RCPT commands, and a DATA command, in that order. A mail transaction may be aborted using the RSET command. There may be zero or more transactions in a session.

If the argument provided by a MAIL, SEND, SOML, or SAML command is not acceptable, a 501 failure response code is returned, and the receiver maintains its current state. Similarly, if a transaction command is sent out of order, a 503 failure response code is returned, and the receiver maintains its current state.

The last command in a session must be the QUIT command. This command cannot be used at any other point in a session.