I wouldn't touch this without first giving it a very thorough security audit. Zed is right that most MTAs in use today are Byzantine horrors, but he misses out on why they were written that way: security. A mail server needs to bind to a privileged port, aggregate every user's mail into a single outgoing queue (which must be stored on disk for reliability), setuid into arbitrary users for delivery, and sometimes execute arbitrary commands given by those users (procmail). This is not an easy thing to get right. The reason for the strange design of Postfix, qmail, et. al. is to allow them to implement privilege separation wherever they possibly can. The thought of throwing all that away, and substituting a lightly-tested, monolithic program written in a dynamic language that permits monkey-patching at runtime and doesn't have Perl's taint checking support, makes me nervous to say the least.
Mail servers, web servers, C compilers, libcs, and crypto libraries all seem to share the common property that their basic functionality seems enticingly easy to implement, inducing the naive to look at the mainstream implementations and think, "Look how stupidly bloated these are! I can do way better", and go on to produce nice elegant, minimalistic implementations that immediately fall over when put into production.
However, as great as Lamson is for processing email intelligently, it isn’t the best solution for delivering mail. There is 30+ years of SMTP lore and myth stored in the code of mail servers such as Postfix and Exim that would take years to replicate and make efficient. Being a practical project, Lamson defers to much more capable SMTP servers for the grunt work of getting the mail to the final recipient.
I wouldn't call the designs of Qmail or Postfix "strange", they're very well designed systems for what they do and given their age. I intimately know the workings of postfix, and while it's not nginx, it does everything it can to be modular and extensible: see how many ways it allows you to access the mail queue before a message is delivered, for example. Yep, THREE different, well documented ways, in increasing levels of ease/performance.
P.S. Is it just me or has Exim declined in popularity? 10 years ago it was hard to choose between Qmail and Exim, and Postfix was the hot new thing.
a lightly-tested, monolithic program written in a dynamic language that permits monkey-patching at runtime and doesn't have Perl's taint checking support, makes me nervous to say the least
lightly-tested - Objection valid. Testing should be heavy for a MTA.
monolithic program - Erlang-style process separation might be useful here, with each part running at different privilege levels.
dynamic language that permits monkey-patching - So what? Dynamic languages are not any less secure. Machine code injection often allowed by many C programs is the ultimate monkey-patching. If you want to make a Smalltalk image secure, you just expunge the Compiler objects and disable the various #perform: messages. No more compiling! No more dynamic evaluating or altering of Smalltalk code of any kind.
doesn't have Perl's taint checking support - Objection could be valid. Taint checking is a very good thing. However, it turns out that there is something along those lines for Python.
One thing that's nice about dynamic languages, is that many of them are immune to buffer-overflow code injection. That, plus taint checking actually makes me feel better about the security of properly architected and deployed applications in dynamic languages.
I do agree that the set of apps you mention are deceptively "enticingly easy." Caution is warranted!
Having read the docs (and talked a bit to Zed at conferences while he was working on this), I think you've made a bad assumption here: Lamson isn't intended to be a general-purpose MTA.
In other words, don't think "sendmail/postfix replacement"; think "tool for building things like Posterous". Or, more clearly, it's not about delivering mail, it's about processing mail. And for that, it appears to be a huge improvement over the traditional state of the art.
sure most MTAs are byzantine horrors as you put it, but it's not like they need constant tweaking either. you set them up, and off they go (both exim, and postfix). we rarely need to touch their configuration once they're up and running. so why would i introduce yet another piece of infrastructure? what do i gain with this exactly?
Mail servers, web servers, C compilers, libcs, and crypto libraries all seem to share the common property that their basic functionality seems enticingly easy to implement, inducing the naive to look at the mainstream implementations and think, "Look how stupidly bloated these are! I can do way better", and go on to produce nice elegant, minimalistic implementations that immediately fall over when put into production.