Archiveopteryx FAQ

The short answer: Convert the certificate and private key to a PKCS#15 keyset using pemtrans.

The longer answer:

The TLS server needs both a certificate (a signed public key) and the corresponding private key. OpenSSL typically stores the certificate in a .crt file, and the private key in a .key file.

Cryptlib (and thus, Archiveopteryx) can import and use the certificate as-is. Cryptlib does not, however, support OpenSSL's private key files, because that file format isn't documented or standardized. The only way to support it would be to reverse-engineer OpenSSL and hope nothing changes in the next version.

The pemtrans program links against both OpenSSL and Cryptlib in order to do its work.

The aoximport program can copy mail from several mailbox formats into Archiveopteryx.

Another way to copy mail en masse is mailsync. Mailsync has been packaged for Debian, FreeBSD and others.

There are many other similar programs; most of the ones we've seen work poorly. Suggestions are welcome.

This question crops up in different shapes — «how many users?», «how big?»

Archiveopteryx's bottleneck is the number of deliveries per minute, everything else is irrelevant.

How many messages do you need to inject into the database in the busiest five-minute period of the day? In a business, that's usually in the morning and immediately after lunch. On fast PC hardware, Archiveopteryx currently handles in the neighbourhood of 4000 deliveries per minute.

This error should not normally be encountered with recent versions of Archiveopteryx, but this explanation is retained for the record.

On some systems, Postgres is configured to use ident authentication, and accept connections only if the connecting process is running as a Unix user that has the same name as the database user it wants to use.

Archiveopteryx tries to cooperate with ident authentication (by using setuid, and falling back to SET SESSION AUTHORIZATION), but it may fail under certain circumstances.

The simplest solution is to disable ident authentication in pg_hba.conf (for example, by replacing "ident sameuser" with "md5" or "trust").

Archiveopteryx supports only PostgreSQL, while DBmail also supports MySQL (MyISAM and InnoDB) and SQLite. Archiveopteryx can depend on advanced SQL features (prepared statements, row-level locking, transactions, savepoints, constraints) without having to worry about restricting itself to a portable subset of SQL.

The Archiveopteryx schema is more advanced than DBmail's. For example, it stores each MIME bodypart as a separate row, while DBmail splits messages into 512-byte blocks and stores those.

DBmail is written in ANSI C, using autoconf for portability. Query strings are built using sprintf(), with all its implied problems. The source code isn't impressively well documented, but it's better than some.

Archiveopteryx is written in C++, and does not use ifdef, autoconf or sprintf. It handles all queries using prepared statements and a typesafe query API. The source is fully documented (as an example, see the Query class).

Because of autoconf, DBmail works on practically all Unix systems, whether tested or not, while Archiveopteryx works only where we test it.

Both systems include IMAP and POP servers. Archiveopteryx includes a basic webmail server, as well as command-line administration tools, and a tool to import mail in bulk from existing sources. DBmail has a third-party GUI administration tool written in Perl, by Mike O'Brien. Only Archiveopteryx supports TLS, which is now required for IMAP compliance.

Archiveopteryx is available both as free software and on commercial terms (with a warranty), and is maintained by a full-time team. DBmail is available only as free software. Support may be available from IC&S, although recently DBmail maintenance seems to move more and more from IC&S to Paul Stevens. Support for DBMA (the DBmail administration tool) is available from Mike O'Brien.