Binc IMAP is an Internet Mail Access Protocol server package written by Andreas Aardal Hanssen. The Binc here is one of those self-recursive names meaning "Binc is not Courier", a reference to the popular Courier-IMAP server by Sam Varshavchik.

Binc is under active development. As it stands now, it is a pretty good fit for qmail and the djb way:

• runs under daemontools and tcpserver
• modular authentication, using /bin/checkpassword (or similar)
• supports Maildir mail-store

Binc also introduces "IMAPdir", an useful alternative to Courier's "Maildir++" semantics for the server-side mail-store. For compatibility, Binc supports "Maildir++" as well (and by default).

At this writing, there are just a few rough spots:

• "yet another configuration file" format
• possibly some performance issues

The author is aware of these issues, and we will be watching for improvements in the near future.

The package uses GNU autoconf, for the familiar ./configure then make && make install build/install routine. Grab the latest tarball for the package, unpack it into a build directory, take a look at the README files and the output from ./configure --help.

Before building, decide on the arguments you want to use with ./configure. The default installation paths are designed for Linux systems, with binaries in /opt/bincimap/bin, run time configuration files in /etc/opt/bincimap. BSD users will find these hideous, of course, and will probably use --prefix=/usr/local and --sysconfdir=/usr/local/etc instead.

The other ./configure options we used were --enable-static and --without-ssl. We chose a static build for chroot/jail use, and --without-ssl since we enable SSL operation through other tools.

After configuration, use GNU make. The source is slow-to-compile C++, so may take several minutes to complete.

After studying the package for use on an OpenBSD system, we decided to forego the make install step altogether. On a djb way system, you don't need the xinetd pieces, and you will redo the daemontools run scripts altogether. So all we really need to install here are the two binaries, bincimap-up and bincimapd:

# cd src
# install -s -m 0755 bincimap-up /usr/local/bin/bincimap-up
# install -s -m 0755 bincimapd /usr/local/bin/bincimapd

Our binc-imapd service will also make use of Bernstein's checkpassword package for login authentication, as described on the poppin' with qmail page.

Installing Binc as a daemontools service is itself a straightforward exercise. The only twist is becoming familiar with the configuration options of Binc.

As usual, set up an unpriveleged user named "bincimapd", group "nofiles", homeless, disabled password, nologin shell. Then create the local service directories:

# mkdir -p /var/svc.d/binc-imapd/log

Here's a "run" script we use for /var/svc.d/binc-imapd/run:

#!/bin/sh
# binc-imapd/run
# daemontools run script for binc imap service
# ===
CONLIMIT=51
IMAPDIR="MAIL.IMAP"
exec 2>&1

echo "*** Starting binc-imapd service..."
echo "*** >> configured for mailbox-path: ${IMAPDIR}" 
exec envuidgid bincimapd softlimit -m3500000 \
  tcpserver -vHRP -l0 \
  -c ${CONLIMIT} \
  -x /etc/tcprules/imap.cdb \
  0 143 \
    /usr/local/bin/bincimap-up \
    --conf="/usr/local/etc/bincimap.conf" \
    --logtype="multilog" \
    --ip-variable="TCPREMOTEIP" \
    --mailbox-type="maildir" \
    --mailbox-path="${IMAPDIR}" \
    --allow-plain="yes" \
    --disable-starttls="yes" \
    -- \
      /bin/checkpassword \
        /usr/local/bin/bincimapd

# note: command-line options override bincimap.conf

### that's all, folks!

Refer to the discussion of configuration options below and edit to suit. Note that it is necessary to mark the end of the options to bincimap-up with a double-hyphen, "--". Then make sure the file is executable, chmod 755.

The multilogger run script is same ol', same ol':

#!/bin/sh
# binc-imapd/log/run
# multilogger for binc-imapd service
exec setuidgid multilog multilog t /var/multilog/binc-imapd

### that's all, folks!

Install and make executable, chmod 755. Prepare the multilog directory:

# mkdir -p /var/multilog/binc-imapd
# chown multilog /var/multilog/binc-imapd

Now define the tcprules you want for the service in /etc/tcprules/imap.rules:

# imap.rules
127.:allow
10.0.:allow
:deny

This permits access only from the local network, 10.0.0.0/16; adjust to suit your requirements, then compile the rules:

# (cd /etc/tcprules; make imap.cdb)

When everything is all set the way you want, link the service into /service to bring it up:

# ln -s /var/svc.d/binc-imapd /service/binc-imapd

Check it out with an ucspi-tcp mconnect dialogue, the stuff we type is in bold:

$ mconnect 127.0.0.1 143
* OK Welcome to Binc IMAP Copyright (C) 2002-2004 Andreas Aardal Hanssen at 2004-01-19 10:35:27 EAT
A001 login clove h0le
A001 OK LOGIN completed
A002 select INBOX
* 165 EXISTS
* OK [UIDVALIDITY 1074405815]
* OK [UIDNEXT 171] 171 is the next UID
* FLAGS (\Answered \Flagged \Deleted \Recent \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft)]
* Limited
A002 OK SELECT completed
A003 logout
* BYE Binc IMAP shutting down
A003 OK LOGOUT completed

The login dialogue above is possible because the --disable-starttls and --allow-plain options are set to "yes". Once you have completed testing the server, you can change these options for an encrypted authentication dialogue.

Binc IMAP is configured through:

• a global configuration file, usually bincimap.conf
• command-line options to bincimap-up
• local configuration file $HOME/.bincimap

Each of the above overrides the preceeding. The arguments to bincimap-up and global configuration file settings are subsequently passed to bincimapd as environmental variables. A user may then change some of these settings, such as the mailbox-path, with a local configuration file named .bincimap in her home directory.

The syntax of configuration files is described in the man page bincimap.conf(5). Another document to review is doc/manual/bincimap-manual.ps in the source distribution.

The configuration file format is not especially difficult, but it is not quite like anything else, either. Users of the djb way --who find elegance in filesystem-as-database solutions, such as qmail's control files and daemontools' envdir utility-- are especially likely to find bincimap.conf annoying. Meanwhile, Unix shell hackers will prefer the tried-and-true keyword="value", to Binc's stanzas, braces, and commas.

The fact that bincimapd receives its configuration through environmental variables encouraged us to investigate the possible use of envdir in the service run script. (We built a test-harness service for this purpose, named binc-test, using this "run" script.) Unfortunately, the environmental variables are encoded in such a way as to be unusable for humans wishing to support and maintain an envdir configuration.

We also investigated the use of a pure command-line configuration, (as another, indirect means to support an envdir setup), without using a configuration file. Unfortunately, it seems that not all configuration file settings are supported by command-line equivalents. The most notable ommission for us is the "depot" option.

We expect these issues to be addressed in releases to come in the near future. Until then, we will defer further description of Binc's configuration options here, and let you refer to the existing documentation shipped with the release.

Despite all this whingeing here about Binc's configuration file format, it's not a huge deal, certainly not a show-stopper. Fact is, even now, Binc is one of the easiest IMAP servers you will ever setup and configure.

We think one of the best uses for IMAP is as an interface between mail clients and local Maildirs.

That is, for those of us who prefer to work directly on Unix workstations, a Maildir-based IMAP is a great way to enable the use of Maildirs with clients such as Pine and Sylpheed, which otherwise don't provide built-in Maildir support. Standardizing on an IMAP interface also allows Unix users to work/play with alternative mail clients, all accessing the same mail store.

Binc offers a flexible and practical way to present a collection of Maildirs to IMAP, through what is called "IMAPdir". This is an option that can be set in the "Mailbox" stanza of the bincimap.conf configuration file:

# /usr/local/etc/bincimap.conf
...
Mailbox {
  depot = "IMAPdir",
  type = "Maildir",
  path = "MAIL.IMAP",
...

As an example of using "IMAPdir" that could correspond to the above, create a normal directory named MAIL.IMAP in your home directory, with symlinks or subdirectories to as many other Maildirs as you want:

$ cd ~
$ mkdir MAIL.IMAP
$ cd MAIL.IMAP
$ ln -s ../MAILDIR.POP INBOX
$ /var/qmail/bin/maildirmake Sent
$ /var/qmail/bin/maildirmake Trash
$ /var/qmail/bin/maildirmake Queue
$ /var/qmail/bin/maildirmake Drafts
$ ln -s ../MAILDIR.SPAM SPAM
etc.

(The example here also demonstrates how one could set up a Maildir for both POP3 and IMAP service.)

Subfolders are represented by Maildirs named with "dot" extensions, to any level:

$ /var/qmail/bin/maildirmake Lists.qmail
$ /var/qmail/bin/maildirmake Lists.BincIMAP.dev
$ /var/qmail/bin/maildirmake Lists.BincIMAP.user
etc.

That is, as many Maildirs as you want, to represent whatever folder organization you want for filtering, archival, etc.

In actual usage with clients, you may need to fiddle with such options as "subscribe" (Mozilla), or "Rebuild folder tree" (Sylpheed), to make new folders and sub-folders visible to the application.

Note: the "IMAPdir" specification itself is not limited to Maildirs; other mail-store types may also be represented. The specification thus provides a clean way of tying in several different types of mail-stores into a single IMAP folder hierarchy. At this writing, however, the Binc IMAP server recognizes only Maildir.

In our experience, at least some bulk operations with Binc IMAP, with at least some clients, are slow.

For example, moving approximately 165 messages (4mb total) from Inbox(IMAP) to Trash(IMAP) takes about 4 minutes (P-III, Sylpheed-claws 0.90, Binc configured with default 1k transfer buffer), where both the client and server are running on the same host.

In another Sylpheed test, moving 165 messages/4mb from a local MH inbox to local IMAP folder, took about the same time, 4 minutes.

Although the default transfer buffer is only 1k, increasing it to 128k did not measurably improve performance. Nor was performance improved by eliminating softlimit constraints.

Mozilla Mail (1.4) was much faster on IMAP to IMAP folder moves, and on IMAP to local folder, both practically instantaneous. But moving the same body of 165 messages/4mb from a local folder to IMAP folder took about the same time as Sylpheed, that is around 4 minutes.

These same operations with Sam Varshavchik's Courier-IMAP and Timo Sirainen's Dovecot IMAP server were substantially faster, each running in less than a minute for both Sylpheed and Mozilla clients. (Dovecot had other anomolies though, involving corrupted indexes.)

These tests are preliminary and incomplete, and do not specifically identify any problems with Binc IMAP itself. YMMV. Some recent traffic on the Binc mailing lists indicates that other users are experiencing issues with performance, though, and the author is currently working to identify and correct any problems.

Do you have Binc IMAP feedback? Mail to: wcm@guinix.com.

Thanks to Stefano Rivera for the original pointer to Binc IMAP!