New Code!
Postoffice has been pushed up to version 1.4.0 with the addition of usermap (personal alias files) support.
A usermap is simply a personal alias file (formatted like the aliases(5) file) which is placed in a home directory, and which is referred to by a usermap option in postoffice.cf(5).
The usermap option is formatted as pattern:target{,target}; the pattern is a shell-style wildcard, with the addition of using the ~ to match any valid user in the domain. A match is either an alias or the special token ~/filename, which is the address of a personal alias file. When a usermap is called, postoffice will try each target, stopping when it matches one.
For example, the usermap *-~:~/.alias,bounce will match any mail address of the format something-user. If it matches an address, postoffice will first see if the address is in ~user/.alias, and then if it doesn't find a match there it will map to the fixed address bounce.
There are also a couple of trivial bugfixes in 1.4.0
Postoffice wraps smtp sessions in several layers of timeout. There were some cases where an alarm would fire when the default signal catcher was running, so you'd end up with a core dump and a crash warning for a completely normal timeout.
A second, and more annoying, bug was discovered when testing the new usermap code. Postoffice is fairly relaxed about the order of MAIL FROM and RCPT TO commands and will accept them in any order as long as both of them have been issued when a DATA command arrives. But some of the sendmail filters (milters) I use are not so forgiving, and if they get a RCPT TO prior to a MAIL FROM, they will freeze and lock the mail session. This is bad programming, to say the least, but it's broken in a sendmail-compatable fashion so it's not likely that it will ever change. So I've crippled postoffice (if built with --with-milter) to whine bitterly about RCPT TO without a prior MAIL FROM.
A super-trivial bugfix is a tweak to configure.sh to test for the existance of malloc.h so I can only include it on machines that actually have it. This is a generalization of the OS_DARWIN support that Andras Salamon contributed for 1.3.8c, and should make the code a little bit more portable to other machines that use C compilers that blindly follow the whims of the (break-all-of-the-)standards committees.
WARNING: This code is still very new, and may still need more work. It's running on Pell and Downbelow right now, but nowhere else, so use caution when playing with it. Oh, and it's not documented yet, except in this release note.