Baltasar Cevc wrote:
What should be considered, when talking about switching to such a (even if only slightly) more complicated model: it makes the start with Qpsmtpd more difficult. I consider the simplicity of the plugin scheme one of the major strengths of qp. I can just install it and tweak one or two examples and have a first running system. Interdependence would add complexity and make that more difficult.
It makes it simpler, not more complicated. It even makes filter plugin coding simpler - you have a template that contains all the glue, and you just have to worry about the filter trigger code itself - don't have to do anything about "what to do if there's a hit".
If all the filtering plugins were solely concerned with configuring what they were supposed to filter _on_ (eg: regexps for MAIL FROM, From:, Subject, HELO, rDNS etc), and a single plugin did the configuration for reject, blackhole, quarantine, where in SMTP session to reject etc., you have to read far less to figure out how to use it, and you don't have to worry about the myriads of conflicting configuration syntaxes.
Most _other_ decent filtering environments work like this. Mailshield, SpamAssassin, etc.
You want the filtering _methods_ to be orthogonal to to email _disposal_.
One could however offer a alternate standard set of plugins implementing the discussed ideas, I think.
One could. I've been considering it, but mine's not as configurable (in terms of handling mailer behaviour on a hit) as I'd like. Probably wouldn't be hard to rework that bit.
