gary’s web sofa

I just rebuilt my mail server and I originally built it without server-side email sorting. Filtering on the client side is fine if you’re pulling email to one PC. Outlook will do it perfectly. It kinda blows when I’m in the middle of nowhere and my Nokia e61 can only get a 14k GPRS connection and have to wade through all my mailing list chatter. Server side filtering is the way to go and Procmail is the tool for the job…

Installing it on Debian is a 2 liner if you read this page. “apt-get install procmail” and adding “mailbox_command = /usr/bin/procmail -a “$EXTENSION” DEFAULT=$HOME/Maildir/ MAILDIR=$HOME/Maildir” to the postfix config file and it’s done! Now all I have to do is dump my old procmail configs back in and I’m in business.

Debian is lovely in all but one respect….. It’s a problem as far as I’m concerned, but I’m probably in the minority. An internet connected server needs constant updating, both for security updates and functionality improvements. The standard release cycle of software vendors doesn’t fit that. OS vendors have a major release (Version X.0), and the only changes they make between releases is for security (version X.1, X.2 etc.). This means that I’ve got major headaches, including significant testing and down time, when version X+1 comes out because several fundamental changes are going on at the same time. This release methodology is primarily driven by the need to sell your software as a box on the shelf of a retailer. Retailers will hate you if you’re constantly changing out software, and the returns would bankrupt you.

Linux shouldn’t be that bad, because the kernel structure is rigidly defined and every application is written and packaged in a way to just work. In fact most major distros release schedules are marketing or QA driven, rather than by a feature addition. Red Hat release a new major version of their Enterprise OS every 18 months, regardless of what new features are added in the mean time by the community. They do this because it means their customers can plan ahead for the major upgrade upheaval.

Because every package comes from a different source, you need to use the built in package management tools to do updates in an efficient manner. If I want to support PHP 5 on my server and I’m running Debian Sarge, I’m out of luck unless I want to remove the packaged PHP 4.4.3 and install version 5.2.0 from source. This now means that I need to keep an eye on Debian’s bug list and PHP’s one, and follow an extra update process.

Debian are the best and the worst of the major distros. Because they’re one of the few non-commercial operators, they can wait to release a version until it’s ready, so when they finally do release Etch, it’ll be rock solid. The down side is that you can be waiting years between versions. You can get around that by using their second release structure. They have a “stable“, “testing” and “unstable” release structure also. “Stable” is identical to their current full release version. If they release a new full version, in theory your server will switch over to this new version overnight, “testing” is their next release. It’s under constant modification until they freeze development to get everything lined up for release. “unstable” is bleeding edge stuff.

Because so many of us need current versions of packages available to us, we have to either install and maintain them from multiple sources or run the “testing” version of Debian. Unfortunately, Debian don’t recommend using anything but “stable” in the real world, and don’t put the “testing” updates through the same QA as the “stable” version. This morning, I ran an update, and saslauthd got broke. Sasl is the bit that provides the glue between postfix, my mail server, and authentication. It allows me to force a password check before allowing my server to relay email from another computer. This way I can have a globally accessible outbound email server so I don’t have to go reconfiguring my email client when I’m out and about. I’m not happy

Debian don’t “sell” their software at retailers. I download the ISOs from debian.org when I need them, so why should I download a disk image that was fixed 12, 18 or even 24 months ago. Why can’t Debian switch to the stable/testing/unstable structure as their primary release framework? Stable can still be a point in time fork of the testing development track, and deliver the the static OS experience that some need. Additional testing resources for the testing version could deliver a slowly evolving, always up to date, modern distro, with the ease of maintenance that Debian is famous for.

I’m throwing in the towel with Scalix. As a drop in replacement to Exchange it’s perfect for 90% of companies. Unfortunately my mail server is a PIII 1GHz which just isn’t up to running Scalix’s Java web interface. The Outlook connector is good, but not perfect. It tends to lock up Outlook on low bandwidth network links, so it’s useless when I’m checking my email on the road over my 384Kbs ADSL link.

I’m back with Postfix/Courier-IMAP, but I’ve still got the original problem of synchronising calendars and contacts.

I’m still sorting out the wrinkles (I might have to read the manual!!!) but it’s looking very neat. The web interface is almost a fully featured as Outlook. The one issue I’m having right now is with multiple inboxes. I want to have a seperate inbox for work and personal emails, and the Outlook connector has a configuration option to have multiple mailboxes connected at the same time, but opening the 2nd mailbox throws a “This set of folders cannot be opened” error….

I get a lot of email, and I have very little time to read it. I also access email from one of several computers, PDAs, phones, web caf????’s, hotels etc. I decided a while ago to setup an email server on my home LAN to consolidate everything. I could also have server based filtering, so when I was on platforms where I pay per MB (GPRS), I would only have important stuff in my Inbox, and all the other stuff would be sorted into folders where I could read it when I got onto a LAN.

I setup courier-IMAP-ssl, postfix, procmail, and clamAV on my Debian Sarge server, used fetchmail to pull emails from Gmail, work and a few other places, and things were good. I had the same consolidated set of virus-free mail folders everywhere, it was IMAP so I had the choice of almost every email client on every platform when it came to reading email. For web caf????s and hotels, I installed RoundCube|Mail as a web front end (very pretty interface and it gets the job done).

That was fine for a while, but I’ve begun to rely more and more on the tasks, calendar, contacts, notes functionality of Outlook on my laptop to manage work stuff, and at this stage it’s key to my daily work. It’s always backed up, but I need a way of accessing it in the same way I access my email. I need the same up to date copy of the data wherever I go, with whatever device I’m using. At one stage I was even thinking of using Exchange! Buying in a server, Windows 2003 and a copy of Exchange was overkill, so I parked it for a while. I played with some Apache/webDAV based stuff that in theory allowed multiple Outlook instances to share data, but it still didn’t fix the problems of accessing the same data on PDAs, other OSs and no OS (web browser only). There are other web based groupware products (like eGroupWare, PHProjekt, Open-Xchange, Zimbra, SugarCRM etc.) but they either don’t connect to Outlook, connect poorly/incompletely, or have a payware connector (I’m cheap!).

A couple of weeks ago I saw a mention of Scalix on a mailing list I subscribe to. It’s a commercial product, but there’s a free, virtually feature-complete version available for sites of <= 25 users. It includes an Outlook connector that provides an almost perfect replication of Exchange’s functionality. It runs on Red Hat and SUSE, so there was a ???????0 cost to me! I don’t fancy running it on Fedora, don’t like SUSE, and don’t want to pay for Red Hat Enterprise Server (they make enough out of me in the office!) so I went for CentOS, which is a free unbranded version of RHES. Scalix needed a bit of persuasion to install. It actually refuses to install on any other distros, even if all the dependancies are there, so I edited the /etc/redhat-release to fool Scalix into thinking I was installing on RHES 4.