• Introduction
• Why IMAP-SSL?
• Why Maildir?
• Authenticated mail
• Webmail
• About SPAM
• Changes for users
• References

"I don't even have an e-mail address. I have reached an age where my main purpose is not to receive messages."
--- Umberto Eco, quoted in the New Yorker

1. Introduction

Early 1998 our traditional email environment was replaced by a more modern one. Besides the introduction of the by that time brand new sendmail replacement Postfix, the most important change was the introduction of the Imap protocol. This environment has been used until this summer and is described on the page Mail Architecture 1998-2002.

Now it is time for another change. The combination of the old POP protocol with an elderly server created a sense of urgency. POP can be a hassle when users have lots of megabytes in a mailbox which is in fact one file on a disk. So now we want to shut down POP completely and we also introduce in new format for mailboxes: the so called Maildir format. But there is more. SSL, a method of implementing secure internet connections, has grown up. With SSL we can safely provide external access to our imap server and thereby eliminate the need for our APOP solution. Finally we want to extend our ways of fighting SPAM and to provide a webmail solution, also by means of SSL of course. Webmail seems to be very popular these days.

( Note that our new emailserver runs Linux on Dell hardware )

2. Why IMAP-SSL?

It is possible to host a secure IMAP server because IMAP-SSL is around a while and most major mailclients have incorporated this way of doing things. We can and will support the following mailclients: Mutt, Pine, Eudora (>= 5.1), Netscape and Mozilla. We never supported Microsoft Outlook, and we still don't, but rumors have it that this client also supports SSL.

We did already support IMAP but now there's nothing else but IMAP. IMAP stands for Internet Message Access Protocol. It is a method of accessing electronic mail or bulletin board messages that are kept on a (possibly shared) mail server. In other words, it permits a "client" email program to access remote message stores as if they were local. Let's repeat some of the nice things about IMAP for those who missed that before:

• IMAP is a means of retrieving received emails from a server, as is POP3, but it uses a secure challenge and response authentication protocol, while POP3 sends the password in the clear over the Net.
• IMAP enables the creation of mailboxes on the server.  So the email client need not save sent, received, draft etc. emails on itself - but can use the server. (Typically email applications which use IMAP make it possible to store emails locally and on the server, with easy moving emails between the two.)
• The server can be told to copy, move, search and delete emails on and between mailboxes on the server, including the Inbox and all mailboxes created by the user. This means that if a remote user logs in and receives a bunch of long emails, only the headers are sent to the client program - and the client can tell the server what to delete and where to move or copy individual emails.Of course, to read an email, it must be sent to the client. All this makes a lot of sense for users who are connected via a dial-up modem, or even worse, through a flaky, supposedly 9.6 kbps, connection via a GSM or other type of cell-phone.
• The last part even goes further: One can also transport only parts of a message to the client. With multimedia or multipart MIME messages, transferring selected parts of a message can be a huge advantage, as when one is in a hotel room and has just received a short text message with a 10MB video clip attached. Efficient processing of MIME messages is a significant advantage of IMAP over POP. (MIME stands for Multipurpose Internet Mail Extensions. It is the Internet standard method for sending arbitrary files as attachments to SMTP and RFC-822 compatible Internet mail messages.)
• A web mail application is intended to run on a server, and send pages to a web browser, to enable the remote user to do all the things they want with email.This means that the user (say, at a library or Internet cafe) cannot store their email on whatever machine they are using. Therefore, the mail should be stored on the mail server.
• IMAP supports concurrent updates and access to shared mailboxes. This capability is useful when multiple individuals are processing messages coming into a common inbox. Changes in mailbox state can be presented to all concurrently active clients via IMAP.

The IMAP server we selected for our mailserver is the Courier-IMAP daemon. One of the reasons was it was written for the specific purpose of providing IMAP access to Maildirs instead of the traditional mailbox files.

3. Why Maildir?

4. Authenticated mail

To be clear: we are talking about using a username and password to log in to the smtp daemon, the thing which sends our mail. Besides this, we also use a username and password to log in to the imap daemon, the thing which lets us retrieve our mail from the mailstore. The authentication of those two daemons have to be configured separately in our mailclients.

A nice thing about being able to connect to our smtp daemon with your mailclient from non-local networks, is the fact that you can configure for instance your laptop in one way and use it all over the world to send mail without having to worry about your provider settings. You can use authenticated mail both on the standard port (25) as on the so called delivery port (587).

Sending AUTH data (username/password) over an unencrypted channel poses a security risk. Therefore we require TLS layer encryption (the thing formerly known as SSL) for authenticated mail. This does not mean that our smtp server listens to TLS connections (it would be hard to use for other mail servers which want to send us mail) It means that when a smtp client (your mailclient) wants to authenticate, it can only do this using TLS. Using TLS also introduces yet another server certificate. In our case at the moment this is a self-signed certificate, so your mailclient should probably be told to accept this certificate.

5. Webmail

This is why we installed SquirrelMail, webmail for nuts. SquirrelMail is a standards-based webmail package written in PHP4. It includes built-in pure PHP support for the IMAP and SMTP protocols, and all pages render in pure HTML 4.0 (with no Javascript) for maximum compatibility across browsers. SquirrelMail has all the functionality you would want from an email client, including strong MIME support, address books, and folder manipulation.

You can find our SquirrelMail installation at https://mail.cs.uu.nl/webmail/ or https://mail.students.cs.uu.nl/webmail/. Note that this webserver is using SSL (https) using a certificate signed by the Utrecht University Certification Authority (CA). Your browser will probably warn you about this. You can simply ignore the browserwarnings and accept the certificate or you can add the needed root certificates to your browser, as is explained on our UU SSL certificate installation page.

6. About SPAM

Of course the methods we already used to block SPAM are still in place. See our SPAM-policy page.

7. Changes for users

• You have to use a new name for the incoming mailserver: imaps.cs.uu.nl or imaps.students.cs.uu.nl (This used to be imap.cs.uu.nl or pop.cs.uu.nl)
• You have to specify that you want to use IMAP so if you used POP before, you have to change it.
• Make sure your client knows that it should use SSL. Our imap daemon listens on port 993 instead of the former port 143.
• You have to accept our local SSL certificate. Some clients simply ask for this but Eudora for example expects that you confirm our certificate in its Certificate Information Manager

The gory details such as mail services naming scheme, configuration hints for various clients, filtering using procmail and e-mail tips may be found in our Using E-mail doc page (work-in-progress).
Additionally, you might want to take a look at our E-Mail FAQ.

8. References

• Postfix
• Courier-IMAP.
• The IMAP Connection
• Squirrelmail.
• Open SSL
• Maildir format
• Our Using E-mail page
  
• Our local email FAQ
  
• Our E-Mail Anti-Spam Policy
• Mail Architecture 1998-2002.
• AMaViS, SpamAssassin.