Many virtual appliances want to communicate by e-mail: mostly by sending. The standard solution for that is to use some off-the-shelf mailer, write a process that communicates user-configuration to the mailer configuration file, and be done with it.
There is just one problem: all mailers suck, big time. I thought it was just true for mail user agents (MUAs) but apparently it is true for MTAs too. Let’s go down the list, shall we?
- qmail: more or less impossible to distribute in compiled form, and so useless for virtual appliances
- postfix: IPL has the obnoxious patent clause which is an unacceptable legal risk for companies
- sendmail: Ideally, you’d like whoever is writing the configuration generator to keep his sanity
- smail: too weak, the first page warns about an exploit that existed since 1992
- exim: complicated configuration, random bugs (bad recovery from unresponsive DNS servers, e.g.) Best of a pretty poor bunch
I don’t think I’m missing any big competitor. Now, for appliances, you do not need things like relaying (unless the goal of the appliance is to be a mail server, in which case, man, good luck with that). You do not need things like mailboxes, and usually no way to get mail would be fine. (Anyone who would like to reply to mail from an appliance would usually prefer the mail to go to a specialized mail server, and for the appliance to be able to access its mail via POP/IMAP.)
So, the ideal mailer for a Virtual Appliance would have
- An easy way to use the two most popular configuration: “send all e-mails through a relay” or “use MX”
- Accessible way to report problems with sending: either permanent errors or giving up on retry attempts (the standard solutions, replying by mail, are not useful in the case of the appliance). Ideal would be a parseable logfile (in addition to the usual developer/adminstrator logfile).
- No open port 25 from the outside
- It’s an appliance — let’s make it easy to control the outgoing queue with a simple configuration
- Easy way to configure retry attempts
- Ideally, as few bugs as possible
For that much configuration, we basically need the following configuration variables:
- “Use Smart Host”, boolean
- “Smart host” (IP/Name, irrelevant if “Use Smart Host” is False)
- Log files “prefix” (use suffix of _main and _parsed)
- Queue place
- Queue max size
- retry_attempts = (list of numbers, seconds to wait between retry attempts)
- SMTP listening port
Next, we’ll need the sendmail executable so programs can, indeed, send e-mail. It’s best to make this compatible with the regular sendmail — it will make porting code to the appliance easier. So, as long as we open the listening port for localhost only (the only option), our sendmail executable can parse, connect to the local port, and deliver the message via SMTP.
Note that most appliances do not need to support a high load of ourgoing mail. Therefore, it is perfectly reasonable to write this in a high level language, such as Python. It would be nice to support the kill -HUP functionality to reread the configuration file.
I think this is a nice design document — and I think there’s a good chance I’ll be working on this in the near future. Anyone with me? 🙂