Providing access to stored mail using POP and IMAP

Configuring authentication

While receiving email from the network and placing it in the correct user's mailbox took some configuring we have done nothing at all so far to enable any form of user authentication. If we wish to allow our users to access their stored mail using any kind of user id and password combination then the first order of business must be configure a suitable authentication mechanism.

The Courier POP3 and IMAP servers do not perform any user authentication tasks themselves. Instead they rely on an external library provided by the net-libs/courier-authlib package which was installed automatically as a dependency. As usual this package installed an example configuration file in place of a usable one so our first task is to move the existing configuration file to another location, so that it is still available in the event we wish to examine it at a later date, and open a new blank configuration file which we can fill with our own settings. The commands below can be used to perform these tasks.

Now that we have an empty configuration file open we can configure the connection between the Courier authentication library and the PostgreSQL database we are using to store our account details. As you can see from the configuration example below there are two main blocks of setting we have provided. The first block consists of four lines providing the name of the database host to connect to, the port on which to connect, the user name to use for the connection and the password to use for authentication.

The second block consists of a single long line, which unfortunately has to be presented as such, containing the database query which shall be used to retrieve authentication information. It should be noted that we are providing the user and group numbers assigned earlier when we created the vmail user and the path to the mail store which we created as they are not stored in the database. We also return several empty fields which can contain values that we shall not be using such as clear-text passwords, real names of users and so forth.

PGSQL_HOST          database
PGSQL_PORT          5432
PGSQL_DATABASE      mail
PGSQL_USERNAME      mail_server
PGSQL_PASSWORD      mail_server_password

PGSQL_SELECT_CLAUSE SELECT address, password, '', 5000, 5000, '/mnt/mailstore/' || homedir, maildir, quota, '', '' FROM authentication_view WHERE username = '$(local_part)' AND domain = '$(domain)'

It should be noted that the configuration file parser used by the courier-authlib package is rather unfriendly and has a nasty habit of reading spaces at the end of configuration lines and including them as part of the value. Take care to ensure there are no trailing spaces when you enter your configuration data.

 

Testing authentication

With the configuration of the courier-authlib package complete it is probably a sensible idea to test to ensure that we can successfully authenticate against out database. Before we can test authentication however we need to start the authentication daemon and add it to the default run level so that it automatically starts at boot. To do this use the following commands.

Assuming that the authlib daemon started without a problem we can proceed to test that our database can be queried for authentication information. We shall use the authtest application which is provided as part of the courier-authlib package as shown in the example below.

Authentication succeeded. 

     Authenticated: spamcatcher@hacking.co.uk  (uid 5000, gid 5000) 

    Home Directory: /mnt/mailstore/hacking.co.uk/ 

           Maildir: spamcatcher/ 

             Quota: 0 

Encrypted Password: $1$/g$hfp5Tly0QAzcqhfMUuRwS. 

Cleartext Password: (none) 

           Options: (none) 

If all goes well you should see output similar to that shown below. If not check the system logs for any useful information and check that your configuration matches that shown in the example above with any relevant changes you may require for your particular system.

We can also conduct a negative test for the authentication by intentionally supplying an incorrect password or user id as shown in the example below. It is probably a good idea to conduct a variety of tests at this stage to ensure that the authentication system is working as expected.

Authentication FAILED: Operation not permitted 

Starting the POP3 server

Once we have successfully tested the authentication mechanism which shall be used by the Courier POP3 server all that remains to allow access to our mail store using the POP3 protocol is to start the service, and add it to the default run level as usual, as shown below.

Testing POP3 functionality

Although we can be fairly certain that our authentication mechanism for the Courier services will be working at this stage we have never tested the POP3 functionality. We can do this easily using the telnet application in the same way that we did when we tested SMTP functionality in a previous section. The only difference is that this time we shall invoke the telnet application specifying port 110 instead of port 25 as our destination. Enter the text displayed in white below making sure to replace the email address with whatever address you have been using so far.

Trying 127.0.0.1... 

Connected to localhost. 

Escape character is '^]'. 

+OK Hello there. 

USER spamcatcher@hacking.co.uk 

+OK Password required. 

PASS password 

+OK logged in. 

LIST 

+OK POP3 clients that break here, they violate STD53. 

1 628 

. 

QUIT   

+OK Bye-bye. 

Connection closed by foreign host. 

There are, rather surprisingly given how quickly it was performed, two distinct parts to the above test. The first of these was a test of authentication when we entered our user name and password. The second test was conducted with the LIST command and instructed the POP3 server to provide a list of the email we have waiting for us. As you can see in the above example we have a single message, the test message we sent earlier, waiting for collection. Assuming that you managed to successfully authenticate and received lines like the two below the LIST command then your POP3 configuration is now functional.

As we are storing our passwords in an encrypted form we are unable to offer any of the more advanced authentication methods such as CRAM-MD5 or DIGEST-MD5. We will cover the configuration of SSL/TLS security in a later section so passwords are not sent over the network in clear-text form.

 

Starting the IMAP server

The POP3 protocol, while useful for those of us who wish to simply receive our email from a mail server and store it on our local machine, is not particularly well suited to those of us who prefer have our messages remain stored on the server. For this purpose the IMAP protocol is considered to be the superior choice. If you wish to provide access to email using the IMAP protocol then start the service and add it to the default run level as shown below.

Although we have tested the POP3 server there is no guarantee that the IMAP services are functional. It is therefore a wise idea to test that they are working using a suitable IMAP client such as Evolution.