For over a year I have been using an 32MB ARM9-based board I designed with a 1GB USB stick as my mailserver. It is powered from a USB port on my firewall box and takes around 1W. I use our Octotux Linux distro with Postfix as the MTA, gps for the greylisting and Dovecot IMAP to provide secure access to the mailstore over SSL. This has worked out really well, the warmcat.com MX record points directly to the external IP here, and the firewall box port-forwards port 25 to the embedded device. It's silent and runs cold 24 hours a day and has never missed a beat. A couple of weeks ago I had to look at the box again because the greylisting software was hanging. I discovered that we were being bombarded with spam, one new spam every two seconds on average, from all over the world. I adjusted the ordering of the filtering in postfix to first reject on an unknown username, that stopped so many concurrent gps sessions being needed. The server weathered that storm and the spam people gave up a few days later without getting a single one through. (They were also targeting the warmcat.com A record IP, I suppose in case it was a backup for the real MX, but they had zero luck with that either). However it reminded me of the one inadequacy of this mailserver... when you wake up your laptop in the morning, thunderbird takes ages to run all the filters and move the new mails remotely into the right IMAP folders. That's pretty annoying when you see the titles of mails you want to read but the USB stick on the server is maxxed out for a couple of minutes sorting eight hours worth of new emails into folders on the server. I have been pondering changing the box to one with USB2 High Speed, but it occurred to me that otherwise, the existing USB 1.1 "Full Speed", that is, 12Mbps is completely adequate. Changing folders and moving to other emails in thunderbird is snappy. It's just the client mail filters under the load of 500 mails in the morning. So I decided to port procmail to ARM9 Octotux, in effect to do the folder sorting as each mail came in, so there would no longer be any processing done at the client for that. Procmail was a little bit of a beast, the sources look horrible and it uses a nonstandard autotools script, which of course does not support crosscompile. After a couple of hours I got it to build nicely in an Octotux RPM (Octotux is entirely crosscompiled RPM-based). Not having used it before, I was surprised to see there was no configuration down /etc in the package, just four small binaries in /usr/bin and some manuals (which I broke out into procmail-docs package so as not to waste space on the target). The binary package only came to 60K all told. The first move was to direct postfix to deliver not to the maildir as before but through procmail. This simply involved editing /etc/postfix/main.cf and adding this mailbox_command = /usr/bin/procmail After some googling I found that procmail is going to look at the unix user's homedir that the mail is directed to, for a file ~/.procmailrc in order to find out what it should do. Now my embdedded mailserver is setup to use Dovecot IMAP with the mailstore symlinked to the USB stick. So my user "andy" on the embedded mailserver has this in the home dir # ll /home/andy lrwxrwxrwx 1 root root 25 Jan 17 2007 Maildir -> /media/usbstick/mail/andy I found looking around in the Dovecot Maildir structure in there that the mail needs to be delivered into /home/andy/Maildir/.(foldername)/new/ in order to get Dovecot to understand that it was given a new mail in a folder. The resulting /home/andy/.procmailrc looks like this: SHELL=/bin/sh PATH="/usr/bin:/usr/local/bin:/bin:/sbin:/usr/sbin" LOCKFILE=/home/andy/lockfile.loc DEFAULT=/home/andy/Maildir/ BITBUCKET=/dev/null LOCKTIMEOUT=10 LOGFILE=/tmp/procmail_log LOGABSTRACT=no VERBOSE=no :0: * ^List-Id: For users of Fedora $DEFAULT/.fedora-list/new :0: * ^List-Id: Development discussions related to Fedora $DEFAULT/.fedora-devel-list/new You simply repeat the last stanzas with some unique identifying header part of mails that are to be filed in a given folder, and give the destination folder name preceded by a '.' and followed by /new as shown. You don't need to run anything or restart anything after making changes here, they will be immediately used on the next email that is delivered. If your folder lives in a hierarchy, the folder on disk looks like, for example, .INBOX.CentOS for a folder CentOS that appears as a child of INBOX. The stanza for that would look like :0: * ^List-Id: CentOS mailing list $DEFAULT/.INBOX.CentOS/new You can also direct procmail to use a central procmailrc file, presumably in /etc, by giving the path to it on the procmail invocation line in /etc/postfix/main.cf. In my case I only take mails for myself, so I stuck with the per-user ~/.procmailrc. No changes were needed anywhere else in the server setup, all I had to do was turn off all my thunderbird filters and enjoy immediate access to the emails via Dovecot IMAP in the morning, without upgrading any hardware.