Installing Uw Imap

Because it's readily available, ships with all major Linux distributions, and supports both POP and IMAP, this section describes the installation and configuration of UW IMAP. This server should work well with only a few tweaks in conjunction with sendmail, Postfix, or Exim. If you use qmail, though, you'll have to reconfigure qmail to use the mbox format. Consult the qmail documentation for details. Alternatively, you could use qmail-pop3d, Courier, or some other pull mail server instead of UW IMAP.

The first step in using UW IMAP is to install the package. Do so using whatever method your distribution supports, as described in Chapter 11, "Managing Packages." Most distributions ship UW IMAP under the name imap or uw-imapd. Unfortunately, Debian's uw-imapd package doesn't include support for POP, so if you want to use POP with Debian, you must either install UW IMAP from another source or use another server. Debian ships with the popa3d server, which works much like UW IMAP's POP support, except that the filenames are different (popa3d versus ipop3d).

Once the server is installed, you must activate it. UW IMAP's servers are designed to be run from super servers, as described in Chapter 22, "Running Servers." If you're using Debian, Slackware, or SuSE, this means editing /etc/inetd.conf. The lines that will activate the P0P2, P0P3, and IMAP servers, respectively, are:

pop2 stream tcp nowait root /usr/sbin/tcpd ipop2d pop3 stream tcp nowait root /usr/sbin/tcpd ipop3d imap stream tcp nowait root /usr/sbin/tcpd imapd

You may find lines like these in your/etc/inetd.conf already, but they may be commented out with a hash mark (#) at the start of each line. If so, you should uncomment the lines to activate the configuration. Some systems ship with multiple POP or IMAP configurations, one for each of several servers. If you find more than one for each server type, be sure to uncomment the correct line.

Warning If you want to support only one pull mail protocol, don't activate any others!

Doing so would pose a potential security risk. For instance, if you don't want or need to support POP, uncommenting the ipop2d oripop3d servers' configurations would leave your system vulnerable if a security flaw in these servers, but not in the imapd server, were found.

If you use Red Hat or Mandrake, the imap package installs five files in /etc/xinetd.d: ipop2, ipop3, pop3s, imap, and imaps. Each of these files launches one pull mail server. (The files whose names end in s launch versions with encryption enabled.) With the exception of Mandrake's ipop3 file, all of these files ship with a disable = yes line, which has the effect of disabling the server. To activate a server, you must change yes to no on this line, comment the line out, or use a tool such as chkconfig (as described in Chapter 22) to enable the server.

Whether you use inetd or xinetd, you must restart the super server or tell it to reload its configuration file after you change your super server configuration. In most cases, typing killall -HUP inetd or killall -HUP xinetd should do the trick.

The UW IMAP servers are very simple; they don't read configuration files or accept arguments to alter their behavior. Once you've configured your super server to launch these servers, they should work. Try configuring a mail client to use your pull mail server to test the server's behavior. Figure 25.2 shows the relevant dialog box from KMail. To access this dialog box, select Settings O Configure KMail, select the Network icon in the list on the left side of the dialog box, click the Receiving tab, and click the Add button or select an existing account and click Modify. (If you select Add, KMail asks what type of account you want to add. Figure 25.2 corresponds to modifying an IMAP account.) Precisely how you adjust the accounts in other mail clients varies by client; consult your mail reader's documentation for details.

[^j Click To expand

Figure 25.2: Mail clients must be told where to find a POP or IMAP server.

Warning Most mail clients enable you to store pull mail passwords locally. In Figure 25.2, this option is called Store IMAP Password in Configuration File. Such options are convenient, but potentially risky, because your password may be compromised if a miscreant gains access to your account. Indeed, if the configuration file is readable to other users, a miscreant might be able to steal your password from another person's account. For these reasons, I recommend you use your pull mail password only for mail retrieval, particularly if you store it in your mail reader's configuration file.

If you have problems, I recommend you try several diagnostic procedures:

• Try using Telnet to connect to the relevant port (109 for POP2, 110 for POP3, or 143 for IMAP). For instance, you might type telnet 143. You should be greeted by some sort of prompt. If you can connect, you know that the problem is with client/server handshaking, authentication, or the like. If you can't connect, the problem could be a bad super server configuration or interference from a firewall or other security measure.

• Try using a mail client on the pull mail server itself, or at least try the Telnet procedure from the pull mail server. This test will help uncover problems that are due to security settings that affect local and remote systems differently, as is common with firewall security settings.

• Check the pull mail server's log files. Frequently, /var/log/messages, /var/log/mail, or a similar file will hold messages from the pull mail server that may give a clue about the source of the problem, such as an authentication error.

Team LIB

0 0

Post a comment