Computer Networks, lab. 5
IFE
The aim of the laboratory is to provide some basic information about the most popular
e-mail protocols, demonstrate e-mail client configuration and get acquainted with some
protocol implementations testing them via Telnet. Before you start performing actions
described in sections 2 and 3, read carefully information included in section 1 describing the
protocols.
1. Mail Protocols
There are advantages to collecting mail destined to PCs and workstations on a central
server, to be turned over to the PC or workstation on demand:
 Your PC or workstation may be down quite a bit and less network bandwidth and less
of the processing resources of the sending computer are used if the computer receiving
your mail is ready.
 Some people use more than one PC or workstation to read mail.
 A PC or workstation may not have the resources to store all the mail you receive.
 It can make your e-mail address more like other users'.
The easiest way to "implement" this is to run the central mail serer like any multi-user
system: let people sign on to it and use some mail utility. Then PC and workstation users can
use "terminal sessions" to sign on to the central mail server and read their mail. This has the
disadvantage of making the PC and workstation users learn and use the central mail server's
procedures.
1.1. Simple Mail Transfer Protocol (SMTP)
The "internet" mail protocol used to deliver mail between multi-user systems only
supports mail transfer initiated by the sender (actually, it has a method to initiate reception,
but the method didn't catch on and is not used). Other protocols have been devised to allow a
workstation or PC to request transfer of mail, thus able to make use of a central server. These
include the published protocols POP (probably not used anymore), POP2, POP3, IMAP2,
IMAP3 (not used), IMAP4 and DMSP.
1.2. Post Office Protocol (POP, POP2, POP3)
These are rather minimal and are designed to be so. The three are similar but not
enough alike to be interoperable. They are basically designed to identify the user by username
and password, to transfer the mail from server to PC or workstation and to delete the mail
transferred. It is assumed that SMTP will be used to send mail. Messages can be retrieved
individually, but the only information you can get about a message without transferring it is
its length in bytes-- useful for PCs with limited storage.
POP3 has a number of extensions including Xtnd Xmit which allows clients to send
mail through the POP3 session rather than using SMTP. Another extension is APOP which
allows RSA MD5 encryption of passwords passed over the network.
POP3 is now the most-used POP, but POP2 is still used. POP3 has a couple of
optional extensions: one to avoid sending passwords, and one to aid in reading bulletin
boards.
1.3. Internet Message Access Protocol (IMAP2, IMAP3, IMAP4)
The IMAP family is similar to the POP family, but also gives clients a way to do string
searches through mail that still resides on the server. This is designed to allow the PC or
workstation to be more selective as to which mail will be transferred. The POP protocols, on
the other hand, are designed for simpler server software.
source: http://www.eits.uga.edu/~ucns/lans/docs/lanmail.htm
1
Computer Networks, lab. 5
IFE
IMAP2 is used quite a bit. IMAP3 is an incompatible offshoot that has not been
implemented much. IMAP4 is a relatively recent extension of IMAP2 which makes the
servers cogniscent of the MIME-structure of a message. IMAP4 also extends IMAP to have
many other features including some of DMSP's.
1.4. Interactive Mail Support Protocol (IMSP)
IMSP is a protocol which is being developed to compliment IMAP4 by offering
related e-mail services beyond the scope of IMAP4. It includes the ability to subscribe find &
subscribe to bulletin boards, mailboxes, and to find and search address books.
1.5. Distributed Mail Service Protocol DMSP (aka PCMAIL)
PCs and workstations can use this protocol to both send and receive mail. The system
is designed around the idea that each user can own more than one workstation; however, the
system doesn't seem to handle the idea of a "public workstation" very well. The PCs and
workstations are assumed to hold state information about the mail, a directory so to speak, and
when the PC or workstation is connected to the server, this directory is updated to "reality".
1.6. Multipurpose Internet Mail Extensions (MIME)
MIME is a relatively new Internet standard for the format for messages with multiple
parts, and with non-ASCII data. It is not an e-mail protocol itself.
Any client that can import or export files can use MIME in a clumsy way if you have a
program to create and/or decode a MIME message. Some clients have built-in features to do
this. Client-server mail protocols generally only deal with entire messages, and can retrieve
MIME messages as well as any other messages since MIME was carefully designed to be
transparent to existing mail systems. However, IMAP4 has features to allow retrieval of
individual parts of MIME-encoded messages. The chart below lists whether a package has
MIME support. Servers for protocols that don't offer any special MIME features are marked
na for Not Applicable since they need do nothing for users to use MIME. All IMAP4 servers
can also do this, but the chart lists whether they include explicit MIME support.
Approaches not covered by this memo: proprietary protocols; file sharing; APIs;
X.400. X.400 is the message transport defined for use between telecommunications vendors
and customers by the international consortium of national standards bodies known as ISO. It
roughly corresponds to the Internet's SMTP and RFC822 header format.A consortium of
X.400 vendors (XAPIA) have developed an API for X.400 applications called CMC.
1.7. Other approaches to e-mail
Vendors can invent their own protocols similar to those listed above, and some have.
LAN e-mail can also be implemented using file sharing, e.g. using NFS (Network File
System) to allow separate Unix workstations to share the same mail spool area just as if it
were mail being stored on one system. If the applications are written so that they are careful to
lock files correctly, then this works. An advantage is that any network file protocol can be
used and the e-mail application can be somewhat independent of the file protocol. For
example, Unix systems could use either AFS (Andrew File System) or NFS. Pegasus is a PC
& Mac application that uses Novell file service to do something similar. Specifications for
client-server interaction consist of the file service protocol along with the server directory
structures & conventions used for storing e-mail.
A very popular approach with commercial vendors is the use of APIs. The client talks
to the server using an API (Applications Programming Interface), i.e., a set of
subroutine/procedure library call definitions for a library providing subroutines/procedures to
source: http://www.eits.uga.edu/~ucns/lans/docs/lanmail.htm
2
Computer Networks, lab. 5
IFE
send, receive, and manipulate e-mail. With the use of any remote procedure call mechanism,
the client can be located on a different computer from the server. This allows some mixing
and matching of RPC mechanisms, underlying protocol stacks and APIs: e.g., a vendor
defines an API, and it can be run over IPX or TCP/IP, in each case over the protocol stack's
RPC mechanism. There are a number of APIs now being pushed by vendors: MAPI
(Microsoft); VIM (Lotus); AOCE (Apple); SMF (Novell, part of MHS). These API's have
been the basis for numerous mail-enabled applications: e.g. a word processor that allows you
to send or receive documents through e-mail simply uses one of these APIs allowing it to
communicate with any server supporting the same API. Specifications for client-server
interaction consist of the protocol stack up to the RPC protocol, then the API itself.
Note that though the API approach in combination with remote procedure calls allows
one to implement client-server e-mail without the use of the protocols covered by this
document (IMAP, POP, etc), that there is no theoretical reason why such APIs can't be used
in an IMAP or POP environment. The necessary software would be a "driver" or piece of
"middleware" that provides the APIs calls to mail-enabled applications and uses POP, IMAP,
or whatever over a LAN to reach a server. The advantages/disadvantages of such an approach
as compared to the use of RPCs is open to debate. UniPalm's Mail-IT is an example of client
software that provides MAPI within the client and uses POP3 to access the server.
2. Testing protocols’ implementations via Telnet
Your task during the laboratory is to connect via Telnet to your mail server and to test
protocol commands. Since the most popular ones seem to be POP3 (e-mail retrieval) and
SMTP (e-mail sending), this part of the instruction covers their commands.
The mail protocol services are running on some specific ports depending on the server
configuration (if you do not know them, check in your server’s documentation). However, the
default ones are 25 for SMTP and 110 for POP3.
2.1. SMTP (RFC 821)
2.1.1. SMTP Commands
HELO
This command is used to identify the sender-SMTP to the receiver-SMTP. The
argument field contains the host name of the sender-SMTP. The receiver-SMTP identifies
itself to the sender-SMTP in the connection greeting reply, and in the response to this
command. This command and an OK reply to it confirm that both the sender-SMTP and the
receiver-SMTP are in the initial state, that is, there is no transaction in progress and all state
tables and buffers are cleared.
MAIL FROM:
This command is 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 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. As each relay host adds itself to the beginning of the list, it
must use its name as known in the IPCE to which it is relaying the mail rather than the IPCE
from which the mail came (if they are different). In some types of error reporting messages
(for example, undeliverable mail notifications) the reverse-path may be null.
RCPT TO:
source: http://www.eits.uga.edu/~ucns/lans/docs/lanmail.htm
3
Computer Networks, lab. 5
IFE
This command is 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. When 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-SMTP does not implement the relay function it may user the same reply it would for
an unknown local user (550).
When mail is relayed, the relay host must remove itself from the beginning forwardpath and put itself at the beginning of the reverse-path. When mail reaches its ultimate
destination (the forward-path contains only a destination mailbox), the receiver-SMTP inserts
it into the destination mailbox in accordance with its host mail conventions.
DATA
The receiver treats the lines following the command as mail data from the sender. This
command causes the mail data from this command to be appended to the mail data buffer. The
mail data may contain any of the 128 ASCII character codes. The mail data is terminated by a
line containing only a period, that is the character sequence "<CRLF>.<CRLF>". This is the
end of mail data indication.
The end of mail data indication requires that the receiver must now process the stored
mail transaction information. This processing consumes the information in the reverse-path
buffer, the forward-path buffer, and the mail data buffer, and on the completion of this
command these buffers are cleared. If the processing is successful the receiver must send an
OK reply. If the processing fails completely the receiver must send a failure reply.
RSET
This command specifies that the current mail transaction is to be aborted. Any stored
sender, recipients, and mail data must be discarded, and all buffers and state tables cleared.
The receiver must send an OK reply.
SEND FROM:
This command is 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. As each relay host adds
itself to the beginning of the list, it must use its name as known in the IPCE to which it is
relaying the mail rather than the IPCE from which the mail came (if they are different).
SOML FROM:
This command is 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. This
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. As each relay host adds
itself to the beginning of the list, it must use its name as known in the IPCE to which it is
relaying the mail rather than the IPCE from which the mail came (if they are different).
source: http://www.eits.uga.edu/~ucns/lans/docs/lanmail.htm
4
Computer Networks, lab. 5
IFE
SAML FROM:
This command is 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 for all recipients to the recipient's mailbox. The argument field contains a reverse-path.
This 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. As each relay host adds
itself to the beginning of the list, it must use its name as known in the IPCE to which it is
relaying the mail rather than the IPCE from which the mail came (if they are different).
VRFY
This command 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.
EXPN
This command 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 reply.
HELP
This command 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.
NOOP
This command does not affect any parameters or previously entered commands. It
specifies no action other than that the receiver send an OK reply.
QUIT
This command specifies that the receiver must send an OK reply, and then close the
transmission channel.
The receiver should not close the transmission channel until it receives and replies to a
QUIT command (even if there was an error). The sender should not close the transmission
channel until it send a QUIT command and receives the reply (even if there was an error
response to a previous command). If the connection is closed prematurely the receiver should
act as if a RSET command had 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 (4xx).
TURN
This command specifies that the receiver must either (1) send an OK reply and then
take on the role of the sender-SMTP, or (2) send a refusal reply and retain the role of the
receiver-SMTP.
If program-A is currently the sender-SMTP and it sends the TURN command and
receives an OK reply (250) then program-A becomes the receiver-SMTP. Program-A is then
in the initial state as if the transmission channel just opened, and it then sends the 220 service
ready greeting.
source: http://www.eits.uga.edu/~ucns/lans/docs/lanmail.htm
5
Computer Networks, lab. 5
IFE
If program-B is currently the receiver-SMTP and it receives the TURN command and
sends an OK reply (250) then program-B becomes the sender-SMTP. Program-B is then in the
initial state as if the transmission channel just opened, and it then expects to receive the 220
service ready greeting.
2.1.2. SMTP Replies
211
214
220
221
250
251
354
421
450
451
452
500
501
502
503
504
550
551
552
553
554
System status, or system help reply
Help message
Service ready
Service closing transmission channel
Requested mail action okay, completed
User not local; will forward to
Start mail input; end with .
Service not available, closing transmission channel
Requested mail action not taken: mailbox unavailable
Requested action aborted: local error in processing
Requested action not taken: insufficient system storage
Syntax error, command unrecognized
Syntax error in parameters or arguments
Command not implemented
Bad sequence of commands
Command parameter not implemented
Requested action not taken: mailbox unavailable
User not local; please try
Requested mail action aborted: exceeded storage allocation
Requested action not taken: mailbox name not allowed
Transaction failed
2.1.3. Sample SMTP transaction
S: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
C: HELO USC-ISIF.ARPA
S: 250 BBN-UNIX.ARPA
C: MAIL FROM:<Smith@USC-ISIF.ARPA>
S: 250 OK
C: RCPT TO:<Jones@BBN-UNIX.ARPA>
S: 250 OK
C: RCPT TO:<Green@BBN-UNIX.ARPA>
S: 550 No such user here
C: RCPT TO:<Brown@BBN-UNIX.ARPA>
S: 250 OK
C:
S:
C:
C:
C:
S:
DATA
354 Start mail input; end with <CRLF>.<CRLF>
Blah blah blah...
...etc. etc. etc.
.
250 OK
C: QUIT
S: 221 BBN-UNIX.ARPA Service closing transmission channel
source: http://www.eits.uga.edu/~ucns/lans/docs/lanmail.htm
6
Computer Networks, lab. 5
IFE
2.2. POP 3 (RFC 1725)
2.2.1. POP3 Commands and Replies
1. Minimal (Standard) Commands:
a) valid in the AUTHORIZATION state
USER name
Arguments:
Restrictions:
a string identifying a mailbox (required), which is of
significance ONLY to the server
may only be given in the AUTHORIZATION state after the
POP3 greeting or after an unsuccessful USER or PASS
command
Possible Responses:
+OK name is a valid mailbox
-ERR never heard of mailbox name
Examples:
C: USER mrose
S: +OK mrose is a real hoopy frood
...
C: USER frated
S: -ERR sorry, no mailbox for frated here
PASS string
Arguments:
Restrictions:
a server/mailbox-specific password (required)
may only be given in the AUTHORIZATION state after a
successful USER command
Possible Responses:
+OK maildrop locked and ready
-ERR invalid password
-ERR unable to lock maildrop
Examples:
C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: +OK mrose's maildrop has 2 messages (320 octets)
...
C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: -ERR maildrop already locked
QUIT
Arguments:
none
Restrictions:
none
Possible Responses:
+OK
Examples:
C: QUIT
S: +OK dewey POP3 server signing off
b) valid in the TRANSACTION state
STAT
Arguments:
none
Restrictions:
may only be given in the TRANSACTION state
Possible Responses:
+OK nn mm
Examples:
source: http://www.eits.uga.edu/~ucns/lans/docs/lanmail.htm
7
Computer Networks, lab. 5
IFE
C: STAT
S: +OK 2 320
LIST [msg]
Arguments:
Restrictions:
Possible Responses:
a message-number (optional), which, if present, may NOT refer
to a message marked as deleted
may only be given in the TRANSACTION state
+OK scan listing follows
-ERR no such message
Examples:
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
...
C: LIST 2
S: +OK 2 200
...
C: LIST 3
S: -ERR no such message, only 2 messages in
maildrop
RETR msg
Arguments:
Restrictions:
Possible Responses:
a message-number (required) which may not refer to a message
marked as deleted
may only be given in the TRANSACTION state
+OK message follows
-ERR no such message
Examples:
C:
S:
S:
S:
RETR 1
+OK 120 octets
<the POP3 server sends the entire message here>
.
DELE msg
Arguments:
Restrictions:
Possible Responses:
a message-number (required) which may not refer to a message
marked as deleted
may only be given in the TRANSACTION state
+OK message deleted
-ERR no such message
Examples:
C: DELE 1
S: +OK message 1 deleted
...
C: DELE 2
S: -ERR message 2 already deleted
NOOP
Arguments:
none
Restrictions:
may only be given in the TRANSACTION state
Possible Responses:
+OK
Examples:
C: NOOP
S: +OK
RSET
Arguments:
none
source: http://www.eits.uga.edu/~ucns/lans/docs/lanmail.htm
8
Computer Networks, lab. 5
IFE
Restrictions:
may only be given in the TRANSACTION state
Possible Responses:
+OK
Examples:
C: RSET
S: +OK maildrop has 2 messages (320 octets)
c) valid in the UPDATE state
QUIT
Arguments:
none
Restrictions:
none
Possible Responses:
+OK
Examples:
C: QUIT
S: +OK dewey POP3 server signing off (maildrop
empty)
...
C: QUIT
S: +OK dewey POP3 server signing off (2 messages
left)
...
2. Optional Commands:
a) valid in the AUTHORIZATION state
APOP name digest
Arguments:
a string identifying a mailbox and a MD5 digest string (both
required)
Restrictions: may only be given in the AUTHORIZATION state after the POP3
greeting
Possible Responses:
+OK maildrop locked and ready
-ERR permission denied
Examples:
S: +OK POP3 server ready
<1896.697170952@dbc.mtview.ca.us>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK maildrop has 1 message (369 octets)
b) valid in the TRANSACTION state
TOP msg n
Arguments:
Restrictions:
Possible Responses:
a message-number (required) which may NOT refer to a
message marked as deleted, and a non-negative number
(required)
may only be given in the TRANSACTION state
+OK top of message follows
-ERR no such message
Examples:
C: TOP 1 10
S: +OK
S: <the POP3 server sends the headers of the
message, a blank line, and the first 10 lines
of the body of the message>
S: .
...
C: TOP 100 3
S: -ERR no such message
source: http://www.eits.uga.edu/~ucns/lans/docs/lanmail.htm
9
Computer Networks, lab. 5
IFE
UIDL [msg]
Arguments:
Restrictions:
Possible Responses:
a message-number (optionally) If a message-number is given, it
may NOT refer to a message marked as deleted.
may only be given in the TRANSACTION state.
+OK unique-id listing follows
-ERR no such message
Examples:
C: UIDL
S: +OK
S: 1 whqtswO00WBw418f9t5JxYwZ
S: 2 QhdPYR:00WBw1Ph7x7
S: .
...
C: UIDL 2
S: +OK 2 QhdPYR:00WBw1Ph7x7
...
C: UIDL 3
S: -ERR no such message, only 2 messages in
maildrop
3. POP3 Replies:
+OK
-ERR
Note that with the exception of the STAT, LIST, and UIDL commands, the reply given by the
POP3 server to any command is significant only to "+OK" and "-ERR". Any text occurring
after this reply may be ignored by the client.
2.2.2. Sample POP3 session
S:
C:
S:
C:
S:
C:
S:
C:
S:
S:
S:
S:
C:
S:
S:
S:
C:
S:
C:
S:
S:
S:
C:
S:
C:
S:
C:
S:
<wait for connection on TCP port 110>
<open connection>
+OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
APOP mrose c4c9334bac560ecc979e58001b3e22fb
+OK mrose's maildrop has 2 messages (320 octets)
STAT
+OK 2 320
LIST
+OK 2 messages (320 octets)
1 120
2 200
.
RETR 1
+OK 120 octets
<the POP3 server sends message 1>
.
DELE 1
+OK message 1 deleted
RETR 2
+OK 200 octets
<the POP3 server sends message 2>
.
DELE 2
+OK message 2 deleted
QUIT
+OK dewey POP3 server signing off (maildrop empty)
<close connection>
<wait for next connection>
source: http://www.eits.uga.edu/~ucns/lans/docs/lanmail.htm
10
Computer Networks, lab. 5
IFE
3. Mail client configuration
This section covers sample procedure of basic e-mail client configuration, i.e. MS Outlook
Express 6. Only e-mail accounts configuration is covered below for SMTP and POP3
protocols (source: http://www1.umn.edu/adcs/help/email/WinOutlook5.html#email):
1. Go to the Tools menu and select Accounts....
2. In the Internet Accounts window, click the Add button and select the Mail... option.
3. Enter your name as you would like it to appear on your email in Display name: field.
4. Click the Next button.
5. Fill in E-mail address which is of the form <Internet ID>@umn.edu (e.g.
user1234@umn.edu).
6. Click the Next button.
7. For My incoming mail server is a select POP3.
8. For Incoming mail (POP3, IMAP, or HTTP) server put your e-mail server, which is of
the form <Internet ID>.email.umn.edu (e.g. user1234.email.umn.edu).
9. Place smtp.umn.edu in the Outgoing mail (SMTP) server: location.
10. Click the Next button.
11. Enter the Account name: which is your University Internet ID (e.g. user1234).
12. Enter the Password which corresponds to this account.
13. Do NOT select Log on using Secure Password Authentication (SPA).
14. Click the Next button.
15. Click the Finish button.
source: http://www.eits.uga.edu/~ucns/lans/docs/lanmail.htm
11
Computer Networks, lab. 5
IFE
16. In the Internet Accounts window, click the Mail tab, then double-click your account
name, this will open the properties window.
17. In the Account Properties window, click the Servers tab.
18. Under Outgoing Mail Server, check next to My server requires authentication.
19. Click the Settings button.
20. In the Outgoing Mail Server window, under Logon Information, check Use same
settings as my incoming mail server and click the OK button.
21. In the Account Properties window, click the Advanced tab.
22. Under Server Port Numbers, next to Outgoing mail (SMTP): type 465 and check This
server requires a secure connection (SSL). Click the OK button.
source: http://www.eits.uga.edu/~ucns/lans/docs/lanmail.htm
12