Providing Web-Based Email Access

Providing Remote Access to Email

Postfix makes up only part of the mail server picture. Although Postfix handles sending and receiving email on the server side, it does not have any provisions for the client software, such as Eudora or Outlook Express. To provide email for remote clients, Tiger needs an additional server components such as an IMAP server, a POP3 server, or a web-based email client or a combination of any/all of these.

In this section, we will look at how to provide the end-user interface to the Postfix email server and also an easy-to-use technique to provide additional protection against unauthorized relaying.

Adding IMAP Support with University of Washington imapd

The UW imapd server is capable of handling both IMAP (Internet Message Access Protocol) and POP3 traffic, and it is already Mac OS X aware, so it takes very little work to install. Even better, there is absolutely no configuration file for the software, so after it has been installed, it's ready to use.

NOTE

If you're wondering what POP3 and IMAP are, refer to Chapter 3, "Using the Tiger Internet Application Suite." These two mail delivery protocols are explained during the introduction to the Mail application.

A straightforward comparison between POP3 and IMAP can be found at the IMAP Connection: http://www.imap.org/imap.vs.pop.brief.html.

Installing UW imapd

Installing imapd is straightforward but requires a few additional modifications to be able to perform smoothly on your OS X computer. To start, fetch the current sources from ftp://ftp.cac.washington.edu/imap/. Unarchive the source and enter cd to move to the distribution directory:

 brezup:jray jray $ curl -O ftp://ftp.cac.washington.edu/imap/imap.tar.Z brezup:jray jray $ tar Zxf imap.tar.Z brezup:jray jray $ cd imap-2004a/ 

Before compiling, an important change must be made to the file src/osdep/unix/env_unix.c. By default, the IMAP server attempts to create all mailboxes in the user's home directory. In fact, it assumes that any directory in the home directory is an IMAP folder; this results in potentially hundreds (or thousands) of folders being downloaded and displayed. To get around this, the env_unix.c file must be adjusted so that a directory other than the main home directory is used. This can be any directory, as long as it exists in every user's account. For our purposes, we'll use ~/Library/Mail/Mailboxes just remember to create the directory name you choose in each account that will access the IMAP server.

Edit the src/osdep/unix/env_unix.c file to add the mailbox directory name you've chosen. Look for the line

 static char *mailsubdir = NIL; /* mail subdirectory name */ 

Change the text to include the directory you've chosen. For example:

 static char *mailsubdir = "Library/Mail/Mailboxes"; /* mail subdirectory name */ 

One final change is to make symbolically link /usr/include/pam to /usr/include/security so that the proper headers will be found during the compile:

 brezup:jray imap-2004a $ ln -s /usr/include/pam /usr/include/security 

The source code is now ready to compile by typing make osx PASSWDTYPE=pam SSLTYPE=unix. This builds a partially noncompliant IESG (Internet Engineering Steering Group) version of the software. This simply means that the software does not force the use of SSL encryption for transferring mail/passwords.

 brezup:jray imap-2004a $ make osx PASSWDTYPE=pam SSLTYPE=unix make sslunix +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Building in PARTIAL compliance with RFC 3501 security + requirements: + Compliant: ++ TLS/SSL encryption is supported + Non-compliant: ++ Unencrypted plaintext passwords are permitted + + In order to rectify this problem, you MUST build with: ++ SSLTYPE=unix.nopwd +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Do you want to continue this build anyway? Type y or n please: y Applying an process to sources... tools/an "ln -s" src/c-client c-client tools/an "ln -s" src/ansilib c-client ... 

The compile process takes only a minute or two because the server application is really quite small. Unfortunately, installation of the compiled software is not automated, so you will have to copy the binary files (imapd and ipopd) to an appropriate directory.

A proper Unix location for user-installed interfaceless server binaries is /usr/local/libexec/, so that's where we'll pop our daemons. You'll have to create the libexec directory within /usr/local, and then copy the files imapd and ipop3d (created within the imapd and ipopd directories of the source distribution) to the new directory:

 brezup:jray imap-2004a $ sudo mkdir /usr/local/libexec brezup:jray imap-2004a $ sudo cp imapd/imapd /usr/local/libexec/ brezup:jray imap-2004a $ sudo cp ipopd/ipop3d /usr/local/libexec/ 

NOTE

Depending on what additional BSD software you've installed, you might already have the /usr/local/libexec directory on your system.

Configuring imapd Startup

Now that the binaries have been installed, you'll want to configure xinetd to automatically start the POP and IMAP servers when there is an incoming request. To do this, add two files (pop3.plist and imap.plist) to your /Library/LaunchDaemons directory.

The file /Library/LaunchDaemons/pop3.plist should read

 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs /PropertyList-1.0.dtd"> <plist version="1.0"> <dict>         <key>Label</key>         <string>edu.washington.pop3</string>         <key>Program</key>         <string>/usr/local/libexec/ipop3d</string>         <key>ProgramArguments</key>         <array>                 <string>ipop3d</string>         </array>         <key>Sockets</key>         <dict>                 <key>Listeners</key>                 <dict>                         <key>SockServiceName</key>                         <string>pop3</string>                 </dict>         </dict>         <key>inetdCompatibility</key>         <dict>                 <key>Wait</key>                 <false/>         </dict> </dict> </plist> 

Similarly, the file /etc/xinetd.d/imap should read like this:

 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs /PropertyList-1.0.dtd"> <plist version="1.0"> <dict>         <key>Label</key>         <string>edu.washington.imapd</string>         <key>Program</key>         <string>/usr/local/libexec/imapd</string>         <key>ProgramArguments</key>         <array>                 <string>imapd</string>         </array>         <key>Sockets</key>         <dict>                 <key>Listeners</key>                 <dict>                         <key>SockServiceName</key>                         <string>imap</string>                 </dict>         </dict>         <key>inetdCompatibility</key>         <dict>                 <key>Wait</key>                 <false/>         </dict> </dict> </plist> 

Reboot the computer or force the launchd process to load your new configuration files using launchctl load /Library/LaunchDaemons/pop3.plist and launchctl load /Library/LaunchDaemons/imap.plist. You're now very close to being able to use your new services, but one final step remains: enabling authentication.

Enabling PAM Authentication

To authenticate with your system, you must create the appropriate PAM (Pluggable Authentication Module) settings in /etc/pam.d. To do this, create two files /etc/pam.d/pop3 and /etc/pam.d/imap with the following contents:

 auth       sufficient     pam_securityserver.so auth       sufficient     pam_unix.so auth       required       pam_deny.so account    required       pam_permit.so password   required       pam_deny.so session    required       pam_permit.so 

You can use the /etc/pam.d/cups file as a template if you like. After the files have been saved, the imapd and ipop3d servers will be able to authenticate with your Tiger system. You're now ready to test your server.

Testing the imapd Installation

Test to make sure that the services you want to run are running by telneting into port 110 (POP3) and port 143 (IMAP):

 brezup:jray jray $ telnet localhost 110 Trying 127.0.0.1... Connected to localhost. +OK POP3 client1.poisontooth.com 2004.88 server ready Escape character is '^]'. Connection closed by foreign host. 

and

 brezup:jray jray $ telnet localhost 143 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. * OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS STARTTLS AUTH=LOGIN]  localhost IMAP4rev1 2004.352 at Wed, 29 Dec 2004 20:33:36 -0600 (CST) 

Both services are running, just as we intended. As a rule, remember that less is more when it comes to servers. If you aren't going to use the IMAP or POP3 servers, don't activate them in your configuration.

The UW imapd server is now ready for use. You can connect to the machine to pick up email that has been received by the Postfix SMTP daemon.

TIP

The IMAP and POP3 servers are both installed and configured to use TCP Wrappers. TCP Wrappers, as you'll learn in Chapter 28, "Implementing Server Security and Advanced Network Configuration," can be used to limit access to any inetd-controlled services. It is recommended that you use TCP Wrappers to block mail services except for those domains that must have access these servers offer hackers an excellent entry point for their activities.

Providing Relay Protection with POP Before SMTP

Common problems with mail servers are that many require you to enumerate the networks that can send email (which is difficult for mobile users) and don't include built-in support for SMTP authentication methods. As a result, SMTP servers are stuck with either having to act as an open relay in cases where they shouldn't or force restrictions on mobile users.

A clever way around this is to allow your IMAP/POP server software to approve connections to your SMTP server. Because both IMAP and POP require a username and password, these servers can authenticate a user and then pass on the authenticated IP address to the SMTP server, which can temporarily allow messages to be sent from that IP address. One easy solution that works with the Postfix and UW imapd software you've installed is Pop-before-smtp (http://popbsmtp.sourceforge.net/).

Written entirely in Perl, this utility watches your POP/IMAP server logs for a valid login and then authorizes that IP address to send email through Postfix for 30 minutes. Because this software requires no changes to the Postfix or imapd applications, you can install and use it with a minimum amount of configuration. If you're comfortable with installing Perl modules, you can jump right in at http://popbsmtp.sourceforge.net/quickstart.shtml. Otherwise, you might want to review Chapter 18, "Using Scripting Languages," first.