Like the other services we have discussed so far, POP and IMAP each need a server pro-
cess to handle requests. The server processes listen on ports 110 and 143, respectively.
Each request to and response from the server is in clear-text ASCII, which means it’s
easy for us to test the functionality of the server using Telnet. This is especially useful
for quickly debugging mail server connectivity/availability issues. Like an SMTP server,
one can interact with a POP or IMAP server using a short list of commands.
To get a look at the most common commands, let’s walk through the process of con-
necting and logging on to a POP server and an IMAP server. This simple test allows you
to verify that the server does in fact work and is providing valid authentication.
Although there are many POP commands, a few worth mentioning are
? USER
? PASS
A few noteworthy IMAP commands are
? LOGIN
? LIST
? STATUS
? EXAMINE/SELECT
? CREATE/DELETE/RENAME
? LOGOUT
INSTALLING THE UW-IMAP AND POP3 SERVER
The University of Washington produces a well-regarded IMAP server that is used in
many production sites around the world. It is a well-tested implementation; thus, it is the
version of IMAP that we will install
Most Linux distributions have prepackaged binaries for UW-IMAP in the distros
repositories. For example, UW-IMAP can be installed in Fedora by using Yum like so:
[root@serverA ~]# yum -y install uw-imap
On Debian-like systems, such as Ubuntu, UW-IMAP can be installed by using
Advanced Packaging Tool (APT) like so:
yyang@ubuntu-serverA:~$ sudo apt-get -y install uw-imapd
Installing UW-IMAP from Source
Begin by downloading the UW-IMAP server to /usr/local/src. The latest version of
the server can be found at ftp://ftp.cac.washington.edu/imap/imap.tar.Z. Once it
is downloaded, unpack it as follows:
[root@serverA src]# tar xvzf imap.tar.Z
This will create a new directory under which all of the source code will be pres-
ent. For the version we are using, we will see a new directory called imap-2007b
created. Change into the directory as follows:
[root@serverA src]# cd imap-2007b/
The defaults that ship with the UW-IMAP server work well for most installa-
tions. If you are interested in tuning the build process, open the makefile (found
in the current directory) with an editor and read through it. The file is well docu-
mented and shows what options can be turned on or off. For the installation we are
doing now, we will want to stick with a simple configuration change that we can
issue on the command line.
In addition to build options, the make command for UW-IMAP requires that
you specify the type of system that the package is being built on. This is in contrast
to many other open source programs that use the ./configure program (also
known as Autoconf) to automatically determine the running environment. The
options for Linux are as follows:
Parameter Environment
ldb
Debian Linux
lnx
Linux with traditional passwords
lnp
Linux with Pluggable Authentication Modules (PAM)
lmd
Mandrake Linux (also known as Mandriva Linux)
lrh
Red Hat Linux 7.2 and later
Parameter Environment
lr5
Red Hat Enterprise 5 and later (should cover recent Fedora
versions)
lsu
SuSE Linux
sl4
Linux with Shadow passwords (requiring an additional library)
sl5
Linux with Shadow passwords (not requiring an additional
library)
slx
Linux needing an extra library for password support
A little overwhelmed with the choices? Don’t be. Many of the choices are for old
versions of Linux that are not used anymore. If you have a Linux distribution that
is recent, the only ones you need to pay attention to are lsu (SuSE), lrh (Red Hat),
lmd (Mandrake), slx, and ldb (Debian).
If you are using SuSE, Red Hat/Fedora, Debian, or Mandrake/Mandriva, go ahead
and select the appropriate option. If you aren’t sure, the slx option should work on
almost all Linux-based systems. The only caveat with the slx option is that you may
need to edit the makefile and help it find where some common tool kits, such as OpenSSL,
are. (You can also simply disable those features, as we do in this installation.)
To keep things simple, we will follow the generic case and disable OpenSSL
but enable Internet Protocol version 6 (IPv6) support. To proceed with the build,
simply run
[root@serverA imap-2007b]# make slx IP=6 SSLTYPE=none
The entire build process should take only a few minutes, even on a slow machine.
Once complete, you will have four executables in the directory: mtest, ipop2d,
ipop3d, and imapd. Copy these to the /usr/local/sbin directory, like so:
[root@serverA imap-2007b]# cp mtest/mtest /usr/local/sbin/
[root@serverA imap-2007b]# cp ipopd/ipop2d /usr/local/sbin/
[root@serverA imap-2007b]# cp ipopd/ipop3d /usr/local/sbin/
[root@serverA imap-2007b]# cp imapd/imapd /usr/local/sbin/
Be sure their permissions are set correctly. Since they only need to be run by root, it is
appropriate to limit their access accordingly. Simply set their permissions as follows:
[root@serverA imap-2007b]# cd /usr/local/sbin
[root@serverA sbin]# chmod 700 mtest ipop2d ipop3d imapd
[root@serverA sbin]# chown root mtest ipop2d ipop3d imapd
That’s it
Running UW-IMAP
Most distributions automatically set up UW-IMAP to run under the superdaemon xinetd
(for more information on xinetd, see Chapter 8). Sample configuration files to get the
IMAP server and the POP3 servers running under xinetd in Fedora are shown here.
For the IMAP server, the configuration file is /etc/xinetd.d/imap.
service imap
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/imapd
log_on_success += HOST DURATION
log_on_failure += HOST
disable = no
}
For the POP3 server, the configuration file is /etc/xinetd.d/ipop3.
service pop3
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/ipop3d
log_on_success += HOST DURATION
log_on_failure += HOST
disable = no
Before telling xinetd to reload its configuration, you will want to check that your
/etc/ services file has both POP3 and IMAP listed. If /etc/services does not have the pro-
tocols listed, simply add the following two lines:
pop3 110/tcp
imap 143/tcp
Finally, tell xinetd to reload its configuration. If you are using Fedora, RHEL, or
Centos, this can be done with the following command:
[root@fedora-serverA bin]# service xinetd reload
If you are using another distribution, you might be able to restart xinetd by passing
therestart argument to xinetd’s run control, like so:
yyang@ubuntu-serverA:~$ sudo /etc/init.d/xinetd restart
If everything worked, you should have a functional IMAP server and POP3 server.
Using the commands and methods shown in the earlier section “POP and IMAP Basics”
we can connect and test for basic functionality.
Checking Basic POP3 Functionality
We begin by using Telnet to connect to the POP3 server (localhost in this example). From
a command prompt, type
[root@serverA ~]# telnet localhost 110
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
+OK POP3 localhost.localdomain 2006k.101 server ready
The server is now waiting for you to give it a command. (Don’t worry that you don’t
see a prompt.) Start by submitting your login name as follows:
USER yourlogin
where yourlogin is, of course, your login ID. The server responds with
+OK User name accepted, password please
Now tell the server your password using the PASS command
PASS yourpassword
where yourpassword is your password. The server responds with
+OK Mailbox open,
where X represents the number of messages in your mailbox. You’re now logged in and can
issue commands to read your mail. Since we are simply validating that the server is work-
ing, we can log out now. Simply type QUIT, and the server will close the connection.
QUIT
+OK Sayonara
Connection closed by foreign host.
That’s it.
Checking Basic IMAP Functionality
We begin by using Telnet to connect to the IMAP server (localhost in this example). From
the command prompt, type
[root@serverA ~]# telnet localhost 143
The IMAP server will respond with something similar to
* OK [CAPABILITY.......
No comments:
Post a Comment