Telnet

(tel´net) (n.) A terminal emulation program for TCP/IP networks such as theInternet. The Telnet program runs on your
computer and connects your PC to a server on the network. You can then enter commands through the Telnet
program and they will be executed as if you were entering them directly on the server console. This enables you to
control the server and communicate with other servers on the network. To start a Telnet session, you must log in to a
server by entering a valid username and password. Telnet is a common way to remotely control Web servers.
What is Telnet?
Telnet is a user command and an underlying TCP/IP protocol for accessing remote computers. Through
Telnet, an administrator or another user canaccess someone else's computer remotely. On the
Web, HTTP and FTPprotocols allow you to request specific files from remote computers, but not to
actually be logged on as a user of that computer. With Telnet, you log on as a regular user with whatever
privileges you may have been granted to the specific application and data on that computer.

A Telnet command request looks like this (the computer name is made-up):

telnet the.libraryat.whatis.edu
The result of this request would be an invitation to log on with a userid and a prompt for a password. If
accepted, you would be logged on like any user who used this computer every day.

Telnet is most likely to be used by program developers and anyone who has a need to use specific
applications or data located at a particular hostcomputer.

Telnet commands
The telnet commands allow you to communicate with a remote computer that is using the Telnet protocol.
You can run telnet without parameters in order to enter the telnet context, indicated by the Telnet prompt
(telnet>). From the Telnet prompt, use the following commands to manage a computer running Telnet
Client.

The tlntadmn commands allow you to remotely manage a computer running Telnet Server. These
commands are run from the command prompt. Used without parameters, tlntadmn displays local server
settings.

The Telnet Client command prompt accepts the following commands:

Command Description

open Use open hostname portnumber to establish a Telnet connection to a host.

close Use the close command to close an existing Telnet connection.

display Use the display command to view the current settings for the Telnet client.
The display command lists the current operating parameters. If you are in a Telnet session (connected to a Tel
parameters, press CTRL+]. This escapes from the Telnet session. (To return to the Telnet session, press ENTER
parameters are available:
• WILL AUTH (NTLM Authentication)
• WONT AUTH
• WILL TERM TYPE
• WONT TERM TYPE
• LOCALECHO off
• LOCALECHO on

quit Use the quit command to exit from Telnet.

set Use the set command to set the terminal type for the connection, turn on local echo, set authentication to NTLM
set up logging.
 • SET NTLM turns on NTLM.
While you are using NTLM Authentication, you are not prompted for a logon name and password when conne
• SET LOCALECHO turns on local echoing.
• SET TERM {ANSI|VT100|VT52|VTNT} sets the terminal type to the appropriate terminal type.
Use the VT100 terminal type if you are running normal command-line applications. Use the VTNT terminal ty
advanced command-line applications, such as edit.
• ESCAPE Character sets the key sequence to use for switching from session to command mode. For exa
escape character, type set escape, press CTRL+P, and then press ENTER.
• LOGFILE FileName sets the file to be used for logging Telnet activity. The log file must be on your local
Logging begins automatically when you set this option.
• LOGGING turns on logging.
If no log file is set, an error message is displayed.

unset Use unset to turn off local echo or to set authentication to logon/password prompt.
• UNSET NLM turns off NLM.
• UNSET LOCALECHO turns off local echoing.

status Use the status command to determine whether the Telnet client is connected.

CTRL+] Press CTRL+] to move to the Telnet command prompt from a connected session.

enter Use the enter command from the command prompt to go to the connected session (if it exists).

?/help Prints Help information.

To use telnet commands at the Telnet prompt

To start Telnet Client and to enter the Telnet prompt

Syntax

1) telnet [\\RemoteServer]

Top of page

Parameters

\\ RemoteServer : Specifies the name of the server to which you want to connect.

Remarks

• Used without parameters, telnet starts Telnet Client.

• When you are at the Telnet prompt, you must use Telnet commands.

Syntax

2) open [\\RemoteServer] [Port]

Top of page

Parameters

\\ RemoteServer : Specifies the name of the server that you want to manage. If you do not specify a
server, the local server is assumed.
Port : Specifies the port that you want to use. If you do not specify a port, the default port is assumed.

Remarks
• You can abbreviate this command to o.

Syntax

3) close [\\RemoteServer]

Top of page

Parameters

\\ RemoteServer : Specifies the name of the server that you want to manage. If you do not specify a
server, the local server is assumed.

Remarks

Syntax

4) set [\\RemoteServer] [ntlm] [localecho] [term {ansi | vt100 | vt52 | vtnt}]

[escape Character] [logfile FileName] [logging] [bsasdel] [crlf] [delasbs]
[mode {console | stream}] [?]

Top of page

Parameters

\\ RemoteServer : Specifies the name of the server that you want to manage. If you do not specify a
server, the local server is assumed.

ntlm : Turns on NTLM authentication if it is available on the remote server.

localecho : Turns on local echo.

term { ansi | vt100 | vt52 | vtnt } : Sets the terminal to the specified type.

escape Character : Sets the escape character. The escape character can be a single character, or it can
be a combination of the CTRL key plus a character. To set a control-key combination, hold down CTRL while
you type the character that you want to assign.

logfile FileName : Sets the file to be used for logging Telnet activity. The log file must be on your local
computer. Logging begins automatically when you set this option.

logging : Turns on logging. If no log file is set, an error message appears.

bsasdel : Sets BACKSPACE to be sent as delete.

crlf : Sets the new line mode, which causes the ENTER key to send 0x0D, 0x0A.

delasbs : Sets DELETE to be sent as backspace.

mode { console | stream } : Sets the mode of operation.

? : Allows you to view the complete syntax for this command.

Remarks
• To turn off an option that was previously set, at the Telnet prompt, type:

5) unset [Option]
 • To set the escape character, type:

e Character

• On non-English versions of Telnet, the codeset Option is available. Codeset Option sets the
current code set to an option, which can be any one of the following: Shift JIS, Japanese
EUC, JIS Kanji, JIS Kanji (78), DEC Kanji, NEC Kanji. You should set the same code set on the
remote computer.

To send Telnet Client commands

net client

Syntax

6) display

Parameters

Remarks
• The display command lists the currently operating parameters for the Telnet client. If you are in a
Telnet session (in other words, if you are connected to a Telnet server), you can exit the Telnet
session to modify the parameters by pressing CTRL+]. To return to the Telnet session, press
ENTER.

To use tlntadmn commands at the command prompt

To administer a computer running Telnet Server

Syntax
tlntadmn [\\RemoteServer] [start] [stop] [pause] [continue]

Parameters
\\ RemoteServer : Specifies the name of the server that you want to manage. If you do not specify a
server, the local server is assumed.

start : Starts Telnet Server.

stop : Stops Telnet Server.

pause : Interrupts Telnet Server.

continue : Resumes Telnet Server.

/? : Displays help at the command prompt.

Remarks
• You can remotely administer a computer running Telnet Server using the tlntadmn commands if
both computers are running Windows XP. You can not use the tlntadmn commands to remotely
administer a computer running Windows 2000 and Telnet Server from a computer that is running
Windows XP.

To administer Telnet sessions

Top of page

Remarks

• You can remotely administer a computer running Telnet Server using the tlntadmn commands if
both computers are running Windows XP. You can not use the tlntadmn commands to remotely
 administer a computer running Windows 2000 and Telnet Server from a computer that is running
Windows XP.

• Formatting legend

Format Meaning

Italic Information that the user must supply

Bold Elements that the user must type exactly as shown

Ellipsis (...) Parameter that can be repeated several times in a command line

Between brackets ([]) Optional items

Between braces ({}); choices separated by pipe Set of choices from which the user must choose only one
(|). Example: {even|odd}

Courier font Code or program output

TELNET is a network protocol used on the Internet or local area networks to provide a bidirectional
interactive text-oriented communications facility via a virtual terminal connection. User data is
interspersed in-band with TELNET control information in an 8-bit byte oriented data connection over
the Transmission Control Protocol (TCP).

History and standards

Telnet is a client-server protocol, based on a reliable connection-oriented transport. Typically this protocol
is used to establish a connection toTransmission Control Protocol (TCP) port number 23, where a Telnet
server application (telnetd) is listening. Telnet, however, predates TCP/IP and was originally run
over Network Control Program (NCP) protocols.

Security
When Telnet was initially developed in 1969, most users of networked computers were in the computer
departments of academic institutions, or at large private and government research facilities. In this
environment, security was not nearly as much of a concern as it became after the bandwidth explosion of
the 1990s. The rise in the number of people with access to the Internet, and by extension, the number of
people attempting to crack other people's servers made encrypted alternatives much more of a necessity.

Experts in computer security, such as SANS Institute, recommend that the use of Telnet for remote logins
should be discontinued under all normal circumstances, for the following reasons:

 Telnet, by default, does not encrypt any data sent over the connection (including passwords), and
so it is often practical to eavesdrop on the communications and use the password later for malicious
purposes; anybody who has access to a router, switch, hub or gateway located on the network
between the two hosts where Telnet is being used can intercept the packets passing by and obtain
 login and password information (and whatever else is typed) with any of several common utilities
like tcpdump and Wireshark.
 Most implementations of Telnet have no authentication that would ensure communication is
carried out between the two desired hosts and not intercepted in the middle.
 Commonly used Telnet daemons have several vulnerabilities discovered over the years.

These security-related shortcomings have seen the usage of the Telnet protocol drop rapidly, especially
on the public Internet, in favor of the Secure Shell (SSH) protocol, first released in 1995. SSH provides
much of the functionality of telnet, with the addition of strong encryption to prevent sensitive data such as
passwords from being intercepted, and public keyauthentication, to ensure that the remote computer is
actually who it claims to be. As has happened with other early Internet protocols, extensions to the Telnet
protocol provideTransport Layer Security (TLS) security and Simple Authentication and Security
Layer (SASL) authentication that address the above issues. However, most Telnet implementations do
not support these extensions; and there has been relatively little interest in implementing these as SSH is
adequate for most purposes. The main advantage of TLS-Telnet would be the ability to use certificate-
authority signed server certificates to authenticate a server host to a client that does not yet have the
server key stored. In SSH, there is a weakness in that the user must trust the first session to a host when
it has not yet acquired the server key.

Current status
As of mid-2010, the Telnet protocol itself has been mostly superseded for remote login. Telnet is popular
in various application areas:

 Enterprise networks to access host applications, e.g., on IBM Mainframes.

 Administration of network elements, e.g., in commissioning, integration and maintenance of core
network elements in mobile communication networks, and many industrial control systems.
 MUD games played over the Internet, as well as talkers, MUSHes, MUCKs, MOOes, and the
resurgent BBS community.
 Internet game clubs, like the Internet Chess Club, the Free Internet Chess Server and the Internet
Go server.
 Embedded systems.
 Mobile data collection applications where telnet runs over secure networks
 Collaboration of multiple users where the capability of session transfer, swap, sharing, and
recovery of disconnected sessions is needed.[4]
Also note that Telnet is a component of FTP protocol. FTP control data are transmitted in Telnet format,
although some software implements it incorrectly.

File Transfer Protocol (FTP) is a standard network protocol used to copy a file from one host
to another over a TCP/IP-based network, such as the Internet. FTP is built on a client-server architecture
and utilizes separate control and data connections between the client and server.[1]FTP users may
authenticate themselves using a clear-text sign-in protocol but can connect anonymously if the server is
configured to allow it.

The first FTP client applications were interactive command-line tools, implementing standard commands
and syntax. Graphical user interfaceclients have since been developed for many of the popular desktop
operating systems in use today.

History
The original specification for the File Transfer Protocol was written by Abhay Bhushan and published
as RFC 114 on 16 April 1971 and later replaced by RFC 765 (June 1980) and RFC 959 (October 1985),
the current specification. Several proposed standards amend RFC 959, for example RFC 2228 (June
1997) proposes security extensions and RFC 2428 (September 1998) adds support for IPv6 and defines
a new type of passive mode. [2]

Protocol overview
A client makes a TCP connection to the server's port 21. This connection, called the control connection,
remains open for the duration of the session, with a second connection, called the data connection,
opened by the server from its port 20 to a client port (specified in the negotiation dialog) as required to
transfer file data. The control connection is used for session administration (i.e., commands, identification,
passwords) exchanged between the client and server using a telnet-like protocol.

While transferring data over the network, four data representations can be used[2]:

 ASCII mode: used for text. Data is converted, if needed, from the sending host's character
representation to "8-bit ASCII" before transmission, and (again, if necessary) to the receiving host's
character representation. As a consequence, this mode is inappropriate for files that contain data
other than plain text.
 Image mode (commonly called Binary mode): the sending machine sends each file byte for byte,
and the recipient stores the bytestream as it receives it. (Image mode support has been
recommended for all implementations of FTP).
 EBCDIC mode: use for plain text between hosts using the EBCDIC character set. This mode is
otherwise like ASCII mode.
  Local mode: Allows two computers with identical setups to send data in a proprietary format
without the need to convert it to ASCII

Security
 FTP was not designed to be a secure protocol—especially by today's standards—and has many
security weaknesses. In May 1999, the authors of RFC2577 enumerated the following flaws

 Bounce Attacks
 Spoof Attacks
 Brute Force Attacks
 Packet Capture (Sniffing)
 Username Protection
 Port Stealing

FTP was not designed to encrypt its traffic; all transmissions are in clear text, and user names,
passwords, commands and data can be easily read by anyone able to perform packet capture (sniffing)
on the network. This problem is common to many Internet Protocol specifications (such as SMTP, Telnet,
POP and IMAP) designed prior to the creation of encryption mechanisms such as TLS or SSL[2]. A
common solution to this problem is use of the "secure", TLS-protected versions of the insecure protocols
(e.g. FTPS for FTP, TelnetS for Telnet, etc.) or selection of a different, more secure protocol that can
handle the job, such as the SFTP/SCP tools included with most implementations of the Secure
Shell protocol.

Anonymous FTP
A host that provides an FTP service may additionally provide anonymous FTP access. Users typically log
into the service with an 'anonymous' account when prompted for user name. Although users are
commonly asked to send their email address in lieu of a password, no verification is actually performed on
the supplied data[7]; examples of anonymous FTP servers can be found here.

Remote FTP or FTPmail

Where FTP access is restricted, a remote FTP (or FTPmail) service can be used to circumvent the
problem. An e-mail containing the FTP commands to be performed is sent to a remote FTP server, which
is a mail server that parses the incoming e-mail, executes the FTP commands, and sends back an e-mail
with any downloaded files as an attachment. Obviously this is less flexible than an FTP client, as it is not
possible to view directories interactively or to modify commands, and there can also be problems with
large file attachments in the response not getting through mail servers. As most internet users these days
have ready access to FTP, this procedure is no longer in everyday use.

List of FTP commands

Below is a list of FTP commands that may be sent to an FTP server, including all commands that are
standardized in RFC 959 by the IETF. All commands below are RFC 959based unless stated otherwise.
Note that most command-line FTP clients present their own set of commands to users. For example, GET
is the common user command to download a file instead of the raw command RETR.

Command RFC Description

ABOR Abort an active file transfer.
ACCT Account information.
ADAT RFC 2228 Authentication/Security Data
ALLO Allocate sufficient disk space to receive a file.
APPE Append.
AUTH RFC 2228 Authentication/Security Mechanism
CCC RFC 2228 Clear Command Channel
CDUP Change to Parent Directory.
CONF RFC 2228 Confidentiality Protection Command
CWD Change working directory.
DELE Delete file.
ENC RFC 2228 Privacy Protected Channel
EPRT RFC 2428 Specifies an extended address and port to which the server should connect.
EPSV RFC 2428 Enter extended passive mode.
FEAT RFC 2389 Get the feature list implemented by the server.
HELP Returns usage documentation on a command if specified, else a general help document is returned
LANG RFC 2640 Language Negotiation
LIST Returns information of a file or directory if specified, else information of the current working direc
LPRT RFC 1639 Specifies a long address and port to which the server should connect.
LPSV RFC 1639 Enter long passive mode.
MDTM RFC 3659 Return the last-modified time of a specified file.
MIC RFC 2228 Integrity Protected Command
MKD Make directory.
MLSD RFC 3659 Lists the contents of a directory if a directory is named.
MLST RFC 3659 Provides data about exactly the object named on its command line, and no others.
MODE Sets the transfer mode (Stream, Block, or Compressed).
NLST Returns a list of file names in a specified directory.
NOOP No operation (dummy packet; used mostly on keepalives).
OPTS RFC 2389 Select options for a feature.
PASS Authentication password.
PASV Enter passive mode.
PBSZ RFC 2228 Protection Buffer Size
PORT Specifies an address and port to which the server should connect.
PROT RFC 2228 Data Channel Protection Level.
PWD Print working directory. Returns the current directory of the host.
QUIT Disconnect.
REIN Re initializes the connection.
REST Restart transfer from the specified point.
RETR Transfer a copy of the file
RMD Remove a directory.
RNFR Rename from.
RNTO Rename to.
SITE Sends site specific commands to remote server.
SIZE RFC 3659 Return the size of a file.
SMNT Mount file structure.
STAT Returns the current status.
STOR Accept the data and to store the data as a file at the server site
STOU Store file uniquely.
STRU Set file transfer structure.
SYST Return system type.
TYPE Sets the transfer mode (ASCII/Binary).
USER Authentication username.

Email
For the former manufacturing conglomerate, see Email Limited.
The at sign, a part of every e-mail address

Electronic mail, commonly called email or e-mail, is a method of exchanging digital messages across
the Internet or other computer networks. Originally, email was transmitted directly from one user to
another computer. This required both computers to be online at the same time, a la instant messenger. Today's
email systems are based on a store-and-forward model. Email servers accept, forward, deliver and store
messages. Users no longer need be online simultaneously and need only connect briefly, typically to an email
server, for as long as it takes to send or receive messages.

An email message consists of two components, the message header, and the message body, which is the
email's content. The message header contains control information, including, minimally, an originator's email
address and one or more recipient addresses. Usually additional information is added, such as a subject
header field.

Originally a text-only communications medium, email was extended to carry multi-media content attachments, a
process standardized in RFC 2045 through 2049. Collectively, these RFCs have come to be
called Multipurpose Internet Mail Extensions (MIME).

Message format
The Internet e-mail message format is defined in RFC 5322 and a series of RFCs, RFC
2045 through RFC 2049, collectively called, Multipurpose Internet Mail Extensions, or MIME. Although as
of July 13, 2005, RFC 2822 is technically a proposed IETF standard and the MIME RFCs are draft IETF
standards,[26] these documents are the standards for the format of Internet e-mail. Prior to the introduction
of RFC 2822 in 2001, the format described by RFC 822 was the standard for Internet e-mail for nearly 20
years; it is still the official IETF standard. The IETF reserved the numbers 5321 and 5322 for the updated
versions of RFC 2821 (SMTP) and RFC 2822, as it previously did with RFC 821 and RFC 822, honoring
the extreme importance of these two RFCs. RFC 822 was published in 1982 and based on the
earlier RFC 733

Internet e-mail messages consist of two major sections:

 Header — Structured into fields such as summary, sender, receiver, and other information about
the e-mail.
 Body — The message itself as unstructured text; sometimes containing a signature block at the
end. This is exactly the same as the body of a regular letter.

The header is separated from the body by a blank line.

Message header
Each message has exactly one header, which is structured into fields. Each field has a name and a
value. RFC 5322 specifies the precise syntax.
Informally, each line of text in the header that begins with a printable character begins a separate field.
The field name starts in the first character of the line and ends before the separator character ":". The
separator is then followed by the field value (the "body" of the field). The value is continued onto
subsequent lines if those lines have a space or tab as their first character. Field names and values are
restricted to 7-bit ASCII characters. Non-ASCII values may be represented using MIME encoded words.

Header fields:

The message header should include at least the following fields:

 From: The e-mail address, and optionally the name of the author(s). In many e-mail clients not
changeable except through changing account settings.
 To: The e-mail address(es), and optionally name(s) of the message's recipient(s). Indicates
primary recipients (multiple allowed), for secondary recipients see Cc: and Bcc: below.
 Subject: A brief summary of the topic of the message. Certain abbreviations are commonly used
in the subject, including "RE:" and "FW:".
 Date: The local time and date when the message was written. Like the From: field, many email
clients fill this in automatically when sending. The recipient's client may then display the time in the
format and time zone local to him/her.

Message body
Content encoding
E-mail was originally designed for 7-bit ASCII.[29] Much e-mail software is 8-bit clean but must assume it
will communicate with 7-bit servers and mail readers. The MIME standard introduced character set
specifiers and two content transfer encodings to enable transmission of non-ASCII data: quoted
printable for mostly 7 bit content with a few characters outside that range and base64 for arbitrary binary
data.

Plain text and HTML

Most modern graphic e-mail clients allow the use of either plain text or HTML for the message body at the
option of the user. HTML e-mail messages often include an automatically-generated plain text copy as
well, for compatibility reasons.

Filename extensions
Upon reception of e-mail messages, e-mail client applications save message in operating system files in
the file-system. Some clients save individual messages as separate files, while others use various
database formats, often proprietary, for collective storage. A historical standard of storage is
the mbox format. The specific format used is often indicated by specialfilename extensions:
eml
 Used by many e-mail clients including Microsoft Outlook Express, Windows Mail and Mozilla
Thunderbird.[34] The files are plain text in MIME format, containing the e-mail header as well as
the message contents and attachments in one or more of several formats.
emlx

Used by Apple Mail.

msg

Used by Microsoft Office Outlook and OfficeLogic Groupware.

mbx

Used by Opera Mail, KMail, and Apple Mail based on the mbox format.

Some applications (like Apple Mail) leave attachments encoded in messages for searching while also
saving separate copies of the attachments. Others separate attachments from messages and save them
in a specific directory.

IMAP
The Internet Message Access Protocol (IMAP) is one of the two most prevalent Internet
standard protocols for e-mail retrieval, the other being the Post Office Protocol (POP).[1]Virtually all
modern e-mail clients and mail servers support both protocols as a means of transferring e-mail
messages from a server.

E-mail protocols
The Internet Message Access Protocol (commonly known as IMAP, and previously called Internet Mail
Access Protocol, Interactive Mail Access Protocol (RFC 1064), and Interim Mail Access Protocol[2]) is
an Application Layer Internet protocol that allows an e-mail client to access e-mail on a remote mail
server. The current version, IMAP version 4 revision 1 (IMAP4rev1), is defined by RFC 3501.

IMAP supports both on-line and off-line modes of operation. E-mail clients using IMAP generally leave
messages on the server until the user explicitly deletes them. This and other characteristics of IMAP
operation allow multiple clients to manage the same mailbox. Most e-mail clients support IMAP in addition
to POP to retrieve messages; however, fewer emailservices support IMAP.[3] IMAP offers access to the
mail store. Clients may store local copies of the messages, but these are considered to be a temporary
cache.

Incoming e-mail messages are sent to an e-mail server that stores messages in the recipient's email box.
The user retrieves the messages with an e-mail client that uses one of a number of e-mail retrieval
protocols. Some clients and servers preferentially use vendor-specific, proprietary protocols, but most
support the Internet standard protocols, SMTP for sending e-mail and POP and IMAP for retrieving e-
mail, allowing interoperability with other servers and clients. For example, Microsoft's Outlook client uses
a proprietary protocol to communicate with a Microsoft Exchange Server server as
does IBM's Notes client when communicating with a Domino server, but all of these products also support
POP, IMAP, and outgoing SMTP. Support for the Internet standard protocols allows many e-mail clients
such as Pegasus Mail or Mozilla Thunderbird (see comparison of e-mail clients) to access these servers,
and allows the clients to be used with other servers (see list of mail servers).

Original IMAP
The original Interim Mail Access Protocol was implemented as a Xerox Lisp machine client and a TOPS-
20 server.

No copies of the original interim protocol specification or its software exist. Although some of its
commands and responses were similar to IMAP2, the interim protocol lacked command/response tagging
and thus its syntax was incompatible with all other versions of IMAP.

IMAP2
The interim protocol was quickly replaced by the Interactive Mail Access Protocol (IMAP2), defined
in RFC 1064 (in 1988) and later updated by RFC 1176 (in 1990). IMAP2 introduced command/response
tagging and was the first publicly distributed version.

IMAP3
IMAP3 is an extinct and extremely rare variant of IMAP.[5] It was published as RFC 1203 in 1991. It was
written specifically as a counter proposal to RFC 1176, which itself proposed modifications to IMAP2.
[6]
IMAP3 was never accepted by the marketplace.[7][8] The IESG reclassified RFC1203 "Interactive Mail
Access Protocol - Version 3" as a Historic protocol in 1993. The IMAP Working Group used RFC1176
(IMAP2) rather than RFC1203 (IMAP3) as its starting point.

IMAP4
An IMAP Working Group formed in the IETF in the early 1990s and took over responsibility for the
IMAP2bis design. The IMAP WG decided to rename IMAP2bis to IMAP4 to avoid confusion with a
competing IMAP3 proposal from another group that never got off the ground. The expansion of the IMAP
acronym also changed to the Internet Message Access Protocol.

Advantages over POP

Connected and disconnected modes of operation
When using POP, clients typically connect to the e-mail server briefly, only as long as it takes to download
new messages. When using IMAP4, clients often stay connected as long as the user interface is active
and download message content on demand. For users with many or large messages, this IMAP4 usage
pattern can result in faster response times.

Multiple clients simultaneously connected to the same mailbox

The POP protocol requires the currently connected client to be the only client connected to the mailbox. In
contrast, the IMAP protocol specifically allows simultaneous access by multiple clients and provides
mechanisms for clients to detect changes made to the mailbox by other, concurrently connected, clients.

Access to MIME message parts and partial fetch

Usually all Internet e-mail is transmitted in MIME format, allowing messages to have a tree
structure where the leaf nodes are any of a variety of single part content types and the non-leaf nodes are
any of a variety of multipart types. The IMAP4 protocol allows clients to separately retrieve any of the
individual MIME parts and also to retrieve portions of either individual parts or the entire message. These
mechanisms allow clients to retrieve the text portion of a message without retrieving attached files or
to stream content as it is being fetched.

Multiple mailboxes on the server

IMAP4 clients can create, rename, and/or delete mailboxes (usually presented to the user as folders) on
the server, and move messages between mailboxes. Multiple mailbox support also allows servers to
provide access to shared and public folders.

Server-side searches
IMAP4 provides a mechanism for a client to ask the server to search for messages meeting a variety of
criteria. This mechanism avoids requiring clients to download every message in the mailbox in order to
perform these searches.

Built-in extension mechanism

Reflecting the experience of earlier Internet protocols, IMAP4 defines an explicit mechanism by which it
may be extended. Many extensions to the base protocol have been proposed and are in common use.
IMAP2bis did not have an extension mechanism, and POP now has one defined by RFC 2449.

Disadvantages of IMAP
While IMAP remedies many of the shortcomings of POP, this inherently introduces additional complexity.
Much of this complexity (e.g., multiple clients accessing the same mailbox at the same time) is
compensated for by server-side workarounds such as Maildir or database backends.

Unless the mail store and searching algorithms on the server are carefully implemented, a client can
potentially consume large amounts of server resources when searching massive mailboxes.

IMAP4 clients need to maintain a TCP/IP connection to the IMAP server in order to be notified of the
arrival of new mail. Notification of mail arrival is done through in-band signaling, which contributes to the
complexity of client-side IMAP protocol handling somewhat[13]. A private proposal, push IMAP, would
extend IMAP to implement push e-mail by sending the entire message instead of just a notification.

However, push IMAP has not been generally accepted and current IETF work has addressed the
problem in other ways (see the Lemonade Profilefor more information).

Unlike some proprietary protocols which combine sending and retrieval operations, sending a message
and saving a copy in a server-side folder with a base-level IMAP client requires transmitting the message
content twice, once to SMTP for delivery and a second time to IMAP to store in a sent mail folder. This is
remedied by a set of extensions defined by the IETF LEMONADE Working Group for mobile devices:
URLAUTH (RFC 4467) and CATENATE (RFC 4469) in IMAP and BURL (RFC 4468) in SMTP-
SUBMISSION. POP servers don't support server-side folders so clients have no choice but to store sent
items on the client. Many IMAP clients can be configured to store sent mail in a client-side folder, or to
BCC oneself and then filter the incoming mail instead of saving a copy in a folder directly. In addition to
the LEMONADE "trio", Courier Mail Server offers a non-standard method of sending using IMAP by
copying an outgoing message to a dedicated outbox folder.

POP
In computing, the Post Office Protocol (POP) is an application-layer Internet standard protocol used by
local e-mail clients to retrieve e-mailfrom a remote server over a TCP/IP connection. POP
and IMAP (Internet Message Access Protocol) are the two most prevalent Internet standard protocols for
e-mail retrieval. Virtually all modern e-mail clients and servers support both. The POP protocol has been
developed through several versions, with version 3 (POP3) being the current standard. POP3 is used for
most webmail services such as Gmail and Yahoo.

Overview
POP supports simple download-and-delete requirements for access to remote mailboxes (termed
maildrop in the POP RFC's). Although most POP clients have an option to leave mail on server after
download, e-mail clients using POP generally connect, retrieve all messages, store them on the user's PC
as new messages, delete them from the server, and then disconnect. Other protocols, notably IMAP,
(Internet Message Access Protocol) provide more complete and complex remote access to typical
mailbox operations. Many e-mail clients support POP as well as IMAP to retrieve messages; however,
fewer Internet Service Providers (ISPs) support IMAP.

A POP3 server listens on well-known port 110. Encrypted communication for POP3 is either requested
after protocol initiation, using the STLS command, if supported, or by POP3S, which connects to the
server using Transport Layer Security (TLS) or Secure Sockets Layer (SSL) on well-known TCP port 995
(e.g. Google Gmail).
Available messages to the client are fixed when a POP session opens the maildrop, and are identified by
message-number local to that session or, optionally, by a unique identifier assigned to the message by
the POP server. This unique identifier is permanent and unique to the maildrop and allows a client to
access the same message in different POP sessions. Mail is retrieved and marked for deletion by
message-number. When the client exits the session, the mail marked for deletion is removed from the
maildrop.

Extensions
An extension mechanism was proposed in RFC 2449 to accommodate general extensions as well as
announce in an organized manner support for optional commands, such as TOP and UIDL. The RFC did
not intend to encourage extensions, and reaffirmed that the role of POP3 is to provide simple support for
mainly download-and-delete requirements of mailbox handling.

The extensions are termed capabilities and are listed by the CAPA command. Except for APOP, the
optional commands were included in the initial set of capabilities. Following the lead of ESMTP (RFC
2821), capabilities beginning with an X signify local capabilities.
STLS

POP uses the Transmission Control Protocol on port number 110. Transmission may be encrypted
using Transport Layer Security (TLS) or Secure Sockets Layer (SSL). This is negotiated in the POP3
protocol using the STLS command. Some clients and servers, such as Google Gmail, instead use the
deprecated alternate-port method, which uses TCP port 995 (POP3S).
SDPS

Demon Internet introduced extensions to POP3 that allow multiple accounts per domain, and has become
known as Standard Dial-up POP3 Service (SDPS).[1] To access each account, the username includes
the hostname, as john@hostname or john+hostname.

Google Apps uses the same method.

Comparison with IMAP

Clients who leave mail on servers generally use the UIDL command to get the current association of
message-numbers to message identified by its unique identifier. The unique identifier is arbitrary, and
might be repeated if the mailbox contains identical messages. In contrast, IMAP uses a 32-bit unique
identifier (UID) that is assigned to messages in ascending (although not necessarily consecutive) order as
they are received. When retrieving new messages, an IMAP client requests the UIDs greater than the
highest UID among all previously-retrieved messages, whereas a POP client must fetch the entire UIDL
map. For large mailboxes, this can require significant processing.
MIME serves as the standard for attachments and non-ASCII text in e-mail. Although neither POP3 nor
SMTP require MIME-formatted e-mail, essentially all Internet e-mail comes MIME-formatted, so POP
clients must also understand and use MIME. IMAP, by design, assumes MIME-formatted e-mail.

Simple Mail Transfer Protocol (SMTP) is an Internet standard for electronic

mail (e-mail) transmission across Internet Protocol (IP) networks. SMTP was first defined by RFC
821 (STD 10) (1982),[1] and last updated by RFC 5321 (2008)[2] which includes the extended
SMTP(ESMTP) additions, and is the protocol in widespread use today. SMTP is specified for outgoing
mail transport and uses TCP port 25. The protocol for new submissions is effectively the same as SMTP,
but it uses port 587 instead.

While electronic mail servers and other mail transfer agents use SMTP to send and receive mail
messages, user-level client mail applications typically use only SMTP for sending messages to a mail
server for relaying. For receiving messages, client applications usually use either thePost Office
Protocol (POP) or the Internet Message Access Protocol (IMAP) or a proprietary system (such as
Microsoft Exchange or Lotus Notes/Domino) to access their mail box accounts on a mail server.

Mail processing model

Blue arrows can be implemented using SMTP variations.

The overall flow for message creation, mail transport, and delivery may be illustrated as shown.

Email is submitted by a mail client (MUA, mail user agent) to a mail server (MSA, mail submission agent)
using SMTP on TCPport 587. Most mailbox providers still allow submission on traditional port 25. From
there, the MSA delivers the mail to its mail transfer agent (MTA, mail transfer agent). Often, these two
agents are just different instances of the same software launched with different options on the same
machine. Local processing can be done either on a single machine, or split among various appliances; in
the former case, involved processes can share files; in the latter case, SMTP is used to transfer the
message internally, with each host configured to use the next appliance as a smart host. Each process is
an MTA in its own right; that is, an SMTP server.

The boundary MTA has to locate the target host. It uses the in the Domain name system (DNS) to look up
the mail exchanger record (MX record) for the recipient's domain (the part of the address on the right
of @). The returned MX record contains the name of the target host. The MTA next looks up the A
record for that name in order to get the IP address and connect to such host as an SMTP client. (The
article on MX record discusses many factors in determining which server the sending MTA connects to.)

Once the MX target accepts the incoming message, it hands it to a mail delivery agent (MDA) for local
mail delivery. An MDA is able to save messages in the relevant mailbox format. Again, mail reception can
be done using many computers or just one —the picture displays two nearby boxes in either case. An
MDA may deliver messages directly to storage, orforward them over a network using SMTP, or any other
means, including the Local Mail Transfer Protocol (LMTP), a derivative of SMTP designed for this
purpose.

Once delivered to the local mail server, the mail is stored for batch retrieval by authenticated mail clients
(MUAs). Mail is retrieved by end-user applications, called email clients, usingInternet Message Access
Protocol (IMAP), a protocol that both facilitates access to mail and manages stored mail, or the Post
Office Protocol (POP) which typically uses the traditionalmbox mail file format or a proprietary system
such as Microsoft Exchange/Outlook or Lotus Notes/Domino. Webmail clients may use either method, but
the retrieval protocol is often not a formal standard.

Protocol overview
SMTP is a text-based protocol, in which a mail sender communicates with a mail receiver by issuing
command strings and supplying necessary data over a reliable ordered data stream channel, typically
a Transmission Control Protocol (TCP) connection. An SMTP session consists of commands originated
by an SMTP client (the initiating agent, sender, or transmitter) and corresponding responses from the
SMTP server (the listening agent, or receiver) so that the session is opened, and session parameters are
exchanged. A session may include zero or more SMTP transactions. An SMTP transaction consists of
three command/reply sequences (see example below.) They are:

1. MAIL command, to establish the return address, a.k.a. Return-Path, 5321.From, mfrom,
or envelope sender. This is the address for bounce messages.
2. RCPT command, to establish a recipient of this message. This command can be issued
multiple times, one for each recipient. These addresses are also part of the envelope.
 3. DATA to send the message text. This is the content of the message, as opposed to its
envelope. It consists of a message header and a message body separated by an empty line.
DATA is actually a group of commands, and the server replies twice: once to the DATA
command proper, to acknowledge that it is ready to receive the text, and the second time after
the end-of-data sequence, to either accept or reject the entire message.

Security and spamming

The original SMTP specification did not include a facility for authentication of senders. Subsequently,
the SMTP-AUTH extension was defined by RFC 2554.[17] The SMTP extension(ESMTP) provides a
mechanism for email clients to specify a security mechanism to a mail server, authenticate the exchange,
and negotiate a security profile (Simple Authentication and Security Layer, SASL) for subsequent
message transfers.

Microsoft products implement the proprietary Secure Password Authentication (SPA) protocol through the
use of the SMTP-AUTH extension.

However, the impracticality of widespread SMTP-AUTH implementation and management means that E-
mail spamming is not and cannot be addressed by it.

Modifying SMTP extensively, or replacing it completely, is not believed to be practical, due to the network
effects of the huge installed base of SMTP. Internet Mail 2000 was one such proposal for replacement.

Spam is enabled by several factors, including vendors implementing broken MTAs (that do not adhere to
standards, and therefore make it difficult for other MTAs to enforce standards), security vulnerabilities
within the operating system (often exacerbated by always-on broadband connections) that allow
spammers to remotely control end-user PCs and cause them to send spam, and a lack of "intelligence" in
many MTAs.

There are a number of proposals for sideband protocols that will assist SMTP operation. The Anti-Spam
Research Group (ASRG) of the Internet Research Task Force (IRTF) is working on a number of E-mail
authentication and other proposals for providing simple source authentication that is flexible, lightweight,
and scalable. Recent Internet Engineering Task Force(IETF) activities include MARID (2004) leading to
two approved IETF experiments in 2005, and DomainKeys Identified Mail in 2006.
Distributed computing
Distributed computing is a field of computer science that studies distributed systems. A distributed
system consists of multiple autonomous computers that communicate through acomputer network. The
computers interact with each other in order to achieve a common goal. A computer program that runs in a
distributed system is called a distributed program, and distributed programming is the process of writing
such programs.[1]

Distributed computing also refers to the use of distributed systems to solve computational problems. In
distributed computing, a problem is divided into many tasks, each of which is solved by one computer.[2]

Introduction
The word distributed in terms such as "distributed system", "distributed programming", and "distributed
algorithm" originally referred to computer networks where individual computers were physically distributed
within some geographical area.[3] The terms are nowadays used in a much wider sense, even referring to
autonomous processes that run on the same physical computer and interact with each other by message
passing.[4]

While there is no single definition of a distributed system,[5] the following defining properties are commonly
used:

 There are several autonomous computational entities, each of which has its own local memory.[6]
 The entities communicate with each other by message passing.[7]

In this article, the computational entities are called computers or nodes.

A distributed system may have a common goal, such as solving a large computational problem.
[8]
Alternatively, each computer may have its own user with individual needs, and the purpose of the
distributed system is to coordinate the use of shared resources or provide communication services to the
users.[9]

Other typical properties of distributed systems include the following:

 The system has to tolerate failures in individual computers.[10]

 The structure of the system (network topology, network latency, number of computers) is not
known in advance, the system may consist of different kinds of computers and network links, and the
system may change during the execution of a distributed program.[11]
 Each computer has only a limited, incomplete view of the system. Each computer may know only
one part of the input.[12]
(a)–(b) A distributed system.
(c) A parallel system.

Parallel or distributed computing?

The terms "concurrent computing", "parallel computing", and "distributed computing" have a lot of overlap,
and no clear distinction exists between them.[13] The same system may be characterised both as "parallel"
and "distributed"; the processors in a typical distributed system run concurrently in parallel.[14] Parallel
computing may be seen as a particular tightly-coupled form of distributed computing,[15] and distributed
computing may be seen as a loosely-coupled form of parallel computing.[5] Nevertheless, it is possible to
roughly classify concurrent systems as "parallel" or "distributed" using the following criteria:

 In parallel computing, all processors have access to a shared memory. Shared memory can be
used to exchange information between processors.[16]
 In distributed computing, each processor has its own private memory (distributed memory).
Information is exchanged by passing messages between the processors.[17]

The figure on the right illustrates the difference between distributed and parallel systems. Figure (a) is a
schematic view of a typical distributed system; as usual, the system is represented as a graph in which
each node (vertex) is a computer and each edge (line between two nodes) is a communication link.
Figure (b) shows the same distributed system in more detail: each computer has its own local memory,
and information can be exchanged only by passing messages from one node to another by using the
available communication links. Figure (c) shows a parallel system in which each processor has a direct
access to a shared memory.

The situation is further complicated by the traditional uses of the terms parallel and
distributed algorithm that do not quite match the above definitions of parallel and distributed systems; see
the section Theoretical foundations below for more detailed discussion. Nevertheless, as a rule of thumb,
high-performance parallel computation in a shared-memory multiprocessor uses parallel algorithms while
the coordination of a large-scale distributed system uses distributed algorithms.

Properties of distributed systems

So far the focus has been on designing a distributed system that solves a given problem. A
complementary research problem is studying the properties of a given distributed system.

The halting problem is an analogous example from the field of centralised computation: we are given a
computer program and the task is to decide whether it halts or runs forever. The halting problem
is undecidable in the general case, and naturally understanding the behaviour of a computer network is at
least as hard as understanding the behaviour of one computer.

However, there are many interesting special cases that are decidable. In particular, it is possible to
reason about the behaviour of a network of finite-state machines. One example is telling whether a given
network of interacting (asynchronous and non-deterministic) finite-state machines can reach a deadlock.
This problem is PSPACE-complete,[39] i.e., it is decidable, but it is not likely that there is an efficient
(centralised, parallel or distributed) algorithm that solves the problem in the case of large networks.

Applications
There are two main reasons for using distributed systems and distributed computing. First, the very
nature of the application may require the use of a communication network that connects several
computers. For example, data is produced in one physical location and it is needed in another location.

Second, there are many cases in which the use of a single computer would be possible in
principle, but the use of a distributed system is beneficial for practical reasons. For example, it
may be more cost-efficient to obtain the desired level of performance by using a cluster of
several low-end computers, in comparison with a single high-end computer. A distributed system
can be more reliable than a non-distributed system, as there is no single point of failure.
Moreover, a distributed system may be easier to expand and manage than a monolithic
uniprocessor system.
Examples of distributed systems and applications of distributed computing include the following:[22]

 Telecommunication networks:
 Telephone networks and cellular networks.
 Computer networks such as the Internet.
 Wireless sensor networks.
 Routing algorithms.
 Network applications:
 World wide web and peer-to-peer networks.
 Massively multiplayer online games and virtual reality communities.
 Distributed databases and distributed database management systems.
 Network file systems.
 Distributed information processing systems such as banking systems and airline
reservation systems.
 Real-time process control:
 Aircraft control systems.
 Industrial control systems.
 Parallel computation:
 Scientific computing, including cluster computing and grid computing and
various volunteer computing projects; see the list of distributed computing projects.
 Distributed rendering in computer graphics.

Distributed algorithm
Models
Many tasks that we would like to automate by using a computer are of question–answer type: we would
like to ask a question and the computer should produce an answer. In theoretical computer science, such
tasks are called computational problems. Formally, a computational problem consists
of instances together with a solution for each instance. Instances are questions that we can ask, and
solutions are desired answers to these questions.

Theoretical computer science seeks to understand which computational problems can be solved by
using a computer (computability theory) and how efficiently (computational complexity theory).
Traditionally, it is said that a problem can be solved by using a computer if we can design
an algorithm that produces a correct solution for any given instance. Such an algorithm can be
 implemented as a computer program that runs on a general-purpose computer: the program reads a
problem instance from input, performs some computation, and produces the solution as output.

Consider the computational problem of finding a coloring of a given graph G. Different fields might take
the following approaches:

Centralized algorithms

 The graph G is encoded as a string, and the string is given as input to a computer. The computer
program finds a coloring of the graph, encodes the coloring as a string, and outputs the result.

Parallel algorithms

 Again, the graph G is encoded as a string. However, multiple computers can access the same
string in parallel. Each computer might focus on one part of the graph and produce a colouring for
that part.
 The main focus is on high-performance computation that exploits the processing power of
multiple computers in parallel.

Distributed algorithms

 The graph G is the structure of the computer network. There is one computer for each node
of G and one communication link for each edge of G. Initially, each computer only knows about its
immediate neighbours in the graph G; the computers must exchange messages with each other to
discover more about the structure of G. Each computer must produce its own colour as output.
 The main focus is on coordinating the operation of an arbitrary distributed system.

While the field of parallel algorithms has a different focus than the field of distributed algorithms, there is a
lot of interaction between the two fields. For example, the Cole–Vishkin algorithm for graph
colouring[27] was originally presented as a parallel algorithm, but the same technique can also be used
directly as a distributed algorithm.

Moreover, a parallel algorithm can be implemented either in a parallel system (using shared memory) or
in a distributed system (using message passing).[28] The traditional boundary between parallel and
distributed algorithms (choose a suitable network vs. run in any given network) does not lie in the same
place as the boundary between parallel and distributed systems (shared memory vs. message passing).

Domain Name System

The Domain Name System (DNS) is a distributed hierarchical naming system for computers, services, or any
resource connected to the Internet or a private network. It associates various information with domain
names assigned to each of the participants. Most importantly, it translates domain names meaningful
to humans into the numerical (binary) identifiers associated with networking equipment for the purpose of
locating and addressing these devices worldwide. An often-used analogy to explain the Domain Name System
is that it serves as the "phone book" for the Internet by translating human-friendly computer hostnames into IP
addresses. For example, www.example.com translates to the addresses 192.0.32.10 (IPv4)
and 2620:0:2d0:200::10 (IPv6).

The Domain Name System makes it possible to assign domain names to groups of Internet users in a
meaningful way, independent of each user's physical location. Because of this,World Wide
Web (WWW) hyperlinks and Internet contact information can remain consistent and constant even if the current
Internet routing arrangements change or the participant uses a mobile device. Internet domain names are
easier to remember than IP addresses such as 208.77.188.166 (IPv4)

The Domain Name System distributes the responsibility of assigning domain names and mapping those names
to IP addresses by designating authoritative name servers for each domain. Authoritative name servers are
assigned to be responsible for their particular domains, and in turn can assign other authoritative name servers
for their sub-domains. This mechanism has made the DNS distributed and fault tolerant and has helped avoid
the need for a single central register to be continually consulted and updated.

Overview
The Internet maintains two principal namespaces, the domain name hierarchy[2] and the Internet
Protocol (IP) address system.[3] The Domain Name System maintains the domain namespace and
provides translation services between these two namespaces. Internet name servers and a
communications protocol implement the Domain Name System.[4] A DNS name server is a server that
stores the DNS records, such as address (A) records, name server (NS) records, and mail exchanger
(MX) records for a domain name (see also List of DNS record types) and responds with answers to
queries against its database.
Structure

The hierarchical domain name system, organized into zones, each served by a name server

The domain name space consists of a tree of domain names. Each node or leaf in the tree has zero or
moreresource records, which hold information associated with the domain name. The tree sub-divides
into zonesbeginning at the root zone. A DNS zone consists of a collection of connected nodes
authoritatively served by anauthoritative nameserver. (A single nameserver can host several zones.)

Administrative responsibility over any zone may be divided, thereby creating additional zones. Authority is
said to be delegated for a portion of the old space, usually in form of sub-domains, to another nameserver
and administrative entity. The old zone ceases to be authoritative for the new zone.

DNS resource records

Further information: List of DNS record types

A Resource Record (RR) is the basic data element in the domain name system. Each record has a type
(A, MX, etc.), an expiration time limit, a class, and some type-specific data. Resource records of the same
type define a resource record set. The order of resource records in a set, returned by a resolver to an
application, is undefined, but often servers implementround-robin ordering to achieve load
balancing. DNSSEC, however, works on complete resource record sets in a canonical order.

When sent over an IP network, all records use the common format specified in RFC 1035 and shown
below:
 RR (Resource record) fields

Length
Field Description
(octets)

NAME Name of the node to which this record pertains (variable)

TYPE Type of RR in numeric form (e.g. 15 for MX RRs) 2

CLASS Class code 2

Unsigned time in seconds that RR stays valid (maximum

TTL 4
2147483647)

RDLENG
Length of RDATA field 2
TH

RDATA Additional RR-specific data (variable)

NAME is the fully qualified domain name of the node in the tree. On the wire, the name may be shortened
using label compression where ends of domain names mentioned earlier in the packet can be substituted
for the end of the current domain name.

TYPE is the record type. It indicates the format of the data and it gives a hint of its intended use. For
example, the A record is used to translate from a domain name to an IPv4 address, the NS record lists
which name servers can answer lookups on a DNS zone, and the MX record specifies the mail server
used to handle mail for a domain specified in an e-mail address(see also List of DNS record types).

RDATA is data of type-specific relevance, such as the IP address for address records, or the priority and
hostname for MX records. Well known record types may use label compression in the RDATA field, but
"unknown" record types must not (RFC 3597).

The CLASS of a record is set to IN (for Internet) for common DNS records involving Internet hostnames,
servers, or IP addresses. In addition, the classes CH (Chaos) and HS (Hesiod) exist. Each class is a
completely independent tree with potentially different delegations of DNS zones.
Wildcard DNS recordsThe domain name system supports wildcard domain names which
are names that start with the asterisk label, '*', e.g., *.example.[2][15] DNS records
belonging to wildcard domain names specify rules for generating resource records within
a single DNS zone by substituting whole labels with matching components of the query
name, including any specified descendants.

Security issues
DNS was not originally designed with security in mind, and thus has a number of security issues.

One class of vulnerabilities is DNS cache poisoning, which tricks a DNS server into believing it has
received authentic information when, in reality, it has not.

DNS responses are traditionally not cryptographically signed, leading to many attack possibilities;
the Domain Name System Security Extensions (DNSSEC) modifies DNS to add support for
cryptographically signed responses. There are various extensions to support securing zone transfer
information as well.

Even with encryption, a DNS server could become compromised by a virus (or for that matter a
disgruntled employee) that would cause IP addresses of that server to be redirected to a malicious
address with a long TTL. This could have far-reaching impact to potentially millions of Internet users if
busy DNS servers cache the bad IP data. This would require manual purging of all affected DNS caches
as required by the long TTL (up to 68 years).

Some domain names can spoof other, similar-looking domain names. For example, "paypal.com" and
"paypa1.com" are different names, yet users may be unable to tell the difference when the
user's typeface (font) does not clearly differentiate the letter l and the numeral 1. This problem is much
more serious in systems that support internationalized domain names, since many character codes in ISO
10646, may appear identical on typical computer screens. This vulnerability is often exploited in phishing.
[citation needed]

Techniques such as Forward-confirmed reverse DNS can also be used to help validate DNS results.

Dynamic Host Configuration Protocol

The Dynamic Host Configuration Protocol (DHCP) is an autoconfiguration protocol used on IP networks.
Computers that are connected to IP networks must be configured before they can communicate with other
computers on the network. DHCP allows a computer to be configured automatically, eliminating the need for
intervention by a network administrator. It also provides a central database for keeping track of computers that
have been connected to the network. This prevents two computers from accidentally being configured with the
same IP address.
In the absence of DHCP, hosts may be manually configured with an IP address. Alternatively IPv6 hosts may
use stateless address autoconfiguration to generate an IP address. IPv4 hosts may use link-local addressing to
achieve limited local connectivity.

In addition to IP addresses, DHCP also provides other configuration information, particularly the IP addresses
of local caching DNS resolvers. Hosts that do not use DHCP for address configuration may still use it to obtain
other configuration information.

There are two versions of DHCP, one for IPv4 and one for IPv6. While both versions bear the same name and
perform much the same purpose, the details of the protocol for IPv4 and IPv6 are sufficiently different that they
can be considered separate protocols.[1]

Technical overview
Dynamic Host Configuration Protocol automates network-parameter assignment to network devices from
one or more DHCP servers. Even in small networks, DHCP is useful because it makes it easy to add new
machines to the network.

When a DHCP-configured client (a computer or any other network-aware device) connects to a network,
the DHCP client sends a broadcast query requesting necessary information from a DHCP server. The
DHCP server manages a pool of IP addresses and information about client configuration parameters such
as default gateway, domain name, the name servers, other servers such as time servers, and so forth. On
receiving a valid request, the server assigns the computer an IP address, a lease (length of time the
allocation is valid), and other IP configuration parameters, such as the subnet mask and the default
gateway. The query is typically initiated immediately after booting, and must complete before the client
can initiate IP-based communication with other hosts.

Depending on implementation, the DHCP server may have three methods of allocating IP-addresses:

 dynamic allocation: A network administrator assigns a range of IP addresses to DHCP, and each
client computer on the LAN is configured to request an IP address from the DHCPserver during
network initialization. The request-and-grant process uses a lease concept with a controllable time
period, allowing the DHCP server to reclaim (and then reallocate) IP addresses that are not renewed.
 automatic allocation: The DHCP server permanently assigns a free IP address to a requesting
client from the range defined by the administrator. This is like dynamic allocation, but the DHCP
server keeps a table of past IP address assignments, so that it can preferentially assign to a client the
same IP address that the client previously had.
 static allocation: The DHCP server allocates an IP address based on a table with MAC
address/IP address pairs, which are manually filled in (perhaps by a network administrator). Only
 requesting clients with a MAC address listed in this table will be allocated an IP address. This feature
(which is not supported by all DHCP servers) is variously called Static DHCP Assignment (by DD-
WRT), fixed-address (by the dhcpd documentation), Address Reservation (by Netgear), DHCP
reservation or Static DHCP (by Cisco/Linksys), and IP reservation or MAC/IP binding (by various
other router manufacturers).

Technical details
 DHCP uses the same two ports assigned by IANA for BOOTP: UDP port 67 for sending data to
the server, and UDP port 68 for data to the client. DHCP communications areconnectionless in
nature.

 DHCP operations fall into four basic phases: IP discovery, IP lease offer, IP request, and IP lease
acknowledgement.

 DHCP clients and servers on the same subnet communicate via UDP broadcasts. If the client and
server are on different subnets, IP discovery and IP request messages are sent via UDP
broadcasts, but IP lease offer and IP lease acknowledgement messages are unicast.

DHCP discovery
 The client broadcasts messages on the physical subnet to discover available DHCP servers.
Network administrators can configure a local router to forward DHCP packets to a DHCP server
from a different subnet. This client-implementation creates a User Datagram Protocol (UDP)
packet with the broadcast destination of 255.255.255.255 or the specific subnet broadcast
address.

 A DHCP client can also request its last-known IP address (in the example below, 192.168.1.100).
If the client remains connected to a network for which this IP is valid, the server might grant the
request. Otherwise, it depends whether the server is set up as authoritative or not. An
authoritative server will deny the request, making the client ask for a new IP address immediately.
A non-authoritative server simply ignores the request, leading to an implementation-dependent
timeout for the client to give up on the request and ask for a new IP address.

Security
The base DHCP protocol does not include any mechanism for authentication.[5] Because of this, it is
vulnerable to a variety of attacks. These attacks fall into three main categories:

 Unauthorized DHCP servers providing false information to clients.[6]

  Unauthorized clients gaining access to resources.[6]
 Resource exhaustion attacks from malicious DHCP clients.[6]

Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers can
be operated on networks, providing incorrect information to DHCP clients. This can serve either as a
denial-of-service attack, preventing the client from gaining access to network connectivity[citation needed], or as
a man-in-the-middle attack. Because the DHCP server provides the DHCP client with server IP
addresses, such as the IP address of one or more DNS servers[6], an attacker can convince a DHCP
client to do its DNS lookups through its own DNS server, and can therefore provide its own answers to
DNS queries from the client[citation needed]. This in turn allows the attacker to redirect network traffic through
itself, allowing it to eavesdrop on connections between the client and network servers it contacts, or to
simply replace those network servers with its own.[citation needed]

Because the DHCP server has no secure mechanism for authenticating the client, clients can gain
unauthorized access to IP addresses by presenting credentials, such as client identifiers, that belong to
other DHCP clients.[citation needed] This also allows DHCP clients to exhaust the DHCP server's store of IP
addresses--by presenting new credentials each time it asks for an address, the client can consume all the
available IP addresses on a particular network link, preventing other DHCP clients from getting service.
[citation needed]

DHCP does provide some mechanisms for mitigating these problems. The Relay Agent Information
Option protocol extension (RFC 3046) allows network operators to attach tags to DHCP messages as
these messages arrive on the network operator's trusted network. This tag is then used as an
authorization token to control the client's access to network resources. Because the client has no access
to the network upstream of the relay agent, the lack of authentication does not prevent the DHCP server
operator from relying on the authorization token.[5]