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.

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.

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

Since the last blog I’ve spent quite a lot of time researching tools to use for our knowledge base, FAQs, etc. I’ve looked at about 5 different CMS systems (Drupal, Mambo, Plone, etc). But they’re all a bit over the top for our needs. So I started looking more into wikis.

We need something that is:

• simple to customise the look and feel
• supports security (so no just anyone can update pages)
• make editing pages and articles easy
• allows our resellers to translate the pages
• needs to be hostable by our provider without a DB

That cuts down the field considerably.

I downloaded and installed about 6-7 different wikis, that were mostly powered by PHP (which we can run on our web servers). I ruled out most due to their dependence on a database, and others because they were hard to customise the look. I also really hate the look of wikis WhenAllTheLinksOnTheirPagesLookLikeThis. In the end I decided that a simple wiki called pmWiki was the way to go. It’s simple, configurable and it works!

Within about 20 minutes I had it up and running and looking just like the main Papercut site. It needs a little bit of tweaking, but not much.

It’s going to make creating great documentation easy, which leads to higher quality docs and satisfied customers. (Hopefully!)

After examining a few different options for blogging software, I’ve decided to choose Wordpress as Papercut Software’s standard blogging tool.

It’s really feature packed and is easy to set up. The only downside at the moment is that you need a separate installation for each blog. That means that when I customise the style to match the website, I have to make those changes in all blogs. Hopefully true multi-blog support will be added eventually so I can avoid this duplication of effort.

The Worpress wiki explains how to setup multiple blogs to use the same MySQL database, so that’s what I’ve done.

We’re also in the process of evaluating products to enhance web site for PaperCut customers. We’re currently looking into a:

1. Forums – to build a community of Papercut users, where questions can be asked and answer by both us and other users
2. Knowledge Base – a searchable list of article, how to guides, FAQs, etc. We might use a wiki as a way to maintain the pages (and possibly even let users help out!)

The current contender for the forum is phpBB2. For the knowledgebase/wiki I’m look at MediaWiki (which is the tool that drives the fantastic wikipedia). It’s is really polished, but given that it’s focus is on building an encyclopedia, it might not meet our needs (i.e. user security, etc).

Maybe we’ll need a proper Content Management System instead? But maybe that’s overkill …

First entry in my web log!