Blog / News

Monthly Archives: August 2004

Posted on by Matt

New mail server (debian + exim4 + dovecot IMAP)

I spent quite a bit of time over the weekend configuring the new Papercut mail server. We’re running Debian Linux on our servers. It’s a great distribution that makes it damn easy to get almost any linux application working…

apt-get install app-name

… wait a few seconds while apt-get downloads the package and any of it’s dependencies and installs and you’re done.

Choice of mailbox format

The key decision you need to make before choosing the IMAP server is the mail folder format. Each IMAP server has a preferred mail box format, so choosing the right format first time, could save you a lot of time down the track. You have the choice of:

  • mbox — the traditional UNIX format. One file contains all mail in the folder
  • mbx — an updated version of mbox that make some common operations faster
  • maildir — each message is stored in a separate file within a directory

To me the idea of storing all mail in a single text file sounds a horrible. When you delete a single message from a huge mail folder, the whole file could have to be rewritten. Care must also be taken so that 2 processes don’t try to update the mail folder at once, otherwise corruption could occur. The mbox/mbx vs. maildir issue seems to be fairly contentious, but to me maildir seemed the more natural way to go. It also allows us to write simple scripts to move mail between folder (… something we do when setting up the spam filtering below).

Choice of IMAP server

Now that we’ve chosen maildir as the mail box format, we need to choose an IMAP server. The main choices are:

  • Courier — very popular but complex
  • Dovecot — simple and uses indexing to make folder and message access fast

Simple and fast sounded good to me … so Dovecot got the nod.

The MTA — Exim4

The server started it’s life as a Debian 3 “Woody” which used Exim3 as its MTA. Exim3 was doing a fine job, but given that Exim 4 is the default for the upcoming Debian release and Exim3 was no longer developed I chose to upgrade.

apt-get install exim4

… answer a couple of questions … and it’s working perfectly! Lovely.

The only thing we need to do to tell Exim to deliver to a maildir instead of the mbox default. In Debian it’s just a matter of setting the LOCAL_DELIVERY=maildir_home in the exim config file. The result of this is that an exim router for local mail is configured to deliver mail to the following transport:

maildir_home:
debug_print = "T: maildir_home for $local_part@$domain"
driver = appendfile
directory = $home/Maildir
delivery_date_add
envelope_to_add
return_path_add
maildir_format
mode = 0600
mode_fail_narrower = false

Make sure you restart exim …

~$ /etc/init.d/exim4 restart
Restarting MTA: exim4.

To test that things are working correctly try something like this:

~$ sendmail localuser
hello
.

If all went well, a maildir should be created for the user you sent the mail to in . The new/ subdirectory should contain a file containing the message you just sent.

If that didn’t work, you might have to look through some logs to see what went wrong. On Debian, look for:

/var/log/mail.info
/var/log/mail.err
/var/log/exim4/exim4.log

OK, now for the IMAP setup…

Installing Dovecot IMAP

Some more Debian magic …

apt-get install dovecot

… connect to the server with Mozilla Thunderbird using IMAP. Hey, presto … it works!! I can see the test email in the inbox.

OK, so local mail delivery is now working. But that’s not very exciting. All our mail gets delivered to POP accounts on the hosting service. To deliver the mail locally I use fetchmail which periodically polls one or more POP inboxes and delivers the mail to local users via the local MTA. (I actually have more than one POP account … but fetchmail can handle that with ease.

Setting up fetchmail

Once fetchmail is installed it’s a simple of matter of telling it where to fetch the mail from. Create a file in your home directory called .fetchmailrc, and for each POP account you want to collect mail from add a line:

poll mail.myisp.com protocol pop3 user "username" pass "password"
is "localuser" here keep

The keep option tells fetchmail to keep the mails on the POP server. This is recommended until you’re sure it’s all working. Otherwise an incorrect mail server setup my cause you to lose mail.

To test that it’s working ok type:

~$ fetchmail
fetchmail: No mail for username at mail.myisp.com

It will output details of the connection to your mail server(s) and whether it retrieved any mail. It’s probably a good idea to send some test mail to your account and then re-run fetchmail. If all goes well the mail will end up in the ~/Maildir/new directory. (NOTE: Try to send mail from a different account … because if something goes wrong you won’t be able to easily see the delivery failure message.)

If you call fetchmail with the -F option it will delete any messages that it’s already downloaded. So I’ve set up a crontab to call fetchmail every 5 mins and leave the mail on the server. Then once a day I call fetchmail -F to clear mails from the POP account. This way if something goes wrong with the mail server, then the mail will be stored safely on the POP server for 24 hours. So nothing will get lost.

Posted in General | 10 Comments


Posted on by Chris

A new era for PaperCut

PaperCut is undergoing a make over. Not only are we reworking the code base for version 5, we’re also changing/evolving the way we interact with our end-users and customers. This Weblog is part of this change; a change towards transparency; adding a human face to our website.

PaperCut developers will now maintain a Weblog or Blog. We hope this will help our users get to know us on a personal level, make us more approachable, and allow our customers to follow our progress in real time.

All software applications are under constant evolution and can never be considered “perfect”. They contain bugs, design deficiencies, or lack features in some way shape or form. Unfortunately for software developers, it’s often the end-users that know more about these issues than the developer. The key to the problem is communication – to tap your end-user’s knowledge. I can class feature enhancements requests sent to PaperCut into two classes:

  1. Users you don’t know, think you’re a big company, and think they’ll be lucky to receive a reply or have the email read.
  2. Users you know personally or have had correspondence with in the past.

The first group send emails along the lines of “Dear Sir, This feature sucks� fix it.”. The second group send something like “Hi Chris, I have a great idea for a new feature� it goes like this� if you need a beta tester or would like any further input please just email.”. I hope our Weblogs help generate more emails like the second.

Posted in General | Leave a comment


Posted on by Matt

Oooh, my first blog comment!

The blog’s been up for a couple of days and I’ve got my first comment … how exciting! Thanks Gunther Dippe.

Posted in General | Leave a comment


Blog Categories & Archives