Adam Prime wrote: > The default config probably isn't going to be (and shouldn't be IMO) > that useful to almost everyone on this list. To my mind, it should be > 'a drop in replacement for qmail', which to me reads that at it's base, > it accepts mail, and delivers it locally.
That could be done, but I suspect that people treating qpsmtpd as a "a drop in replacement for qmail" are in the minority. Indeed, as a drop in replacement for qmail, it'd have to have an _outbound_ SMTP sender (you know, MX lookups etc) too. I'm treating it as a replacement for Lyris Mailshield (wha? ;-). And there are no local users ;-) Before expending too much effort on automatic install, I'd like to see the project come up with conventions by which there's a unified view of how filtering occurs. Which means for example, that filtering plugins set notes() on what decisions they've made, rather than (necessarily) returning DENY themselves, common libraries for parsing string filter configurations and pattern matching, logging/quarantine/forwarding tie-ins, and being able to configure overall behaviour. Eg: We hold off issuing 550s until the DATA transaction completes. This means that all filtering plugins have have a mutually agreed to place to stick their results, know what to check before wasting time on redundant filtering when the choice has already been made, and _always_ return DECLINED. Logging knows about this, and generates an easily parsed log record. Quarantine and forwarding all know, and do the right thing. There's only one return DENY in the entire plugin set (well, three, including the "we don't relay" and "no such user" returns). The entire filtering suite is configurable/switchable by per-domain (and potentially per recipient) config.
