mvmf: mvmtr Design Thoughts

To build up an MTA here, starting by implementing the current qmail-smtpd functions that I am using (local hacks and all) and eliminating all of the functions and quirks of qmail-smtpd that I find useless or annoying or worse. It may happen that I don't like the result and abandon it. qmail-smtpd is so lightweight that a first pass should be relatively simple to do; it's the further passes that will make it interesting. However even the first pass may be worth doing.

The mvmda Mail Delivery Agent was written in a qmail environment. I like many of the features of qmail and continue to use it. However it can't really be used in any non-trivial way out of the box, more so as time goes by. I've hacked on the qmail-smtpd in use here quite a lot, to the point where it probably is quite different from "qmail-smtpd"s in use elsewhere. Whenever I go to look into changing qmail-smtpd for one thing or another I am struck by how non-robust it is, and how little I like working with the code. (The latter is subjective of course; probably people say that about mine too.) So I'm always left with thinking that I'd really like a different code base that does some of the same things that qmail does and that more readily lends itself to modification and improvement. Further, there are just some fundamental changes that I want to make in the way the smtpd agent works. For example, I am not a big fan of the "bazillion individual control files that have to be opened and read at each program invocation" style, and so I want to use a different control interface. There are other popular MTAs that I've avoided for one reason or another, and there are other qmail-smtpd re-implementations that I've looked at and that don't suit the goals here very well. So I figure I'll play around a little and see where I get.

Goals

• Reimplementation of basic qmail-smtpd functionality, minus some things that I don't really want. For example, one of the local hacks here is that we use a fairly elaborate address mapping facility that is consulted at SMTP time: it contains addresses, domain names, indications of primary vs backup MX handling (so that a RCPT TO might get a deferral when handled by one server, but accepted when handled by another, etc). This renders "rcpthosts" et al redundant. I plan to have this kind of unified address mapping in mvmtr;

• Replace many of the little individual control files with fewer files, probably using MFL functions and hooks. There are some controls where you simply want to set a value, or have a list of control values, but in other cases it's really nice to have the ability to apply some logic. MFL hooks would do nicely here.

• Better vetting of incoming dialog and messages (qmail-smtpd out of the box doesn't look at headers at all, heck, it doesn't even do basic syntax checks of SMTP command arguments, hacking some of them into the existing qmail-smtpd has been a chore);

• Ability to do individual recipient status handling in SMTP (either via the trick of 443'ing all but the first RCPT TO, or via multiple-result-code SMTP extension);

• Ability to consult system-wide aliases file and expand aliases during SMTP and SUBMISSION phase (back, IMHO, where it belongs);

• Ability to deliver directly to local agent, bypassing the queue;

• Interface to local agent via LMTP;

• Ability to consult filters (mvmf/MFL by default) at SMTP time, so that individual user filters can be employed to reject or accept email during the SMTP dialog (perhaps exclusively via the LMTP interface, but I also envision some other filter hooks at various SMTP stages);

• Much more flexible controls and throttles over sending sites;

• More attention to making it work properly as a SUBMISSION agent, including

  • SMTP-AUTH based authorizations and controls on a per-sender basis;

  • Ability to scan *outgoing* mail and adjust authorizations and controls based on detection of bad outgoing behaviour;

  • Ability to stand in as (or at least work directly with) a qmail-inject replacement;

  • etc.

• Maybe integrate rblsmtpd facilities into mvmtr -- the existing rblsmtpd is also subpar, perhaps just a replacement of that is also in order.