Hi everybody,
I've one little thought to add to the plugin model discussion:
On Jun 20, 2009, at 12:29 AM, Chris Lewis wrote:
Jared Johnson wrote:
The following general model for all my filtering plugins looks like
this.
[...detailed description...]
The model works by setting the notes "reason" for _why_ you want to
block the email, and once set, it shuts off all subsequent filtering.
You really can't get much simpler than that.
I use the exact same model for whitelisting, except that it uses a
different note.
Then, a subsequent plugin decides to DENY or not by something like
this:
if ($transaction->notes{reason} && !$transaction->notes{whitelist}) {
return DENY;
}
One log line for every email that contains everything there is to
know about the email. Since the reasons are a common format, post-
processing the logs to derive reason effectiveness (right down to
which entry in which config file triggered it) is trivial.
You can design more complex systems that allow you to parameterize
the "behaviour on hit" stuff. Eg: all the stuff about rejecting,
when to reject, whether to include the reason note in the reject,
quarantine, forwarding, marking, etcetera.
What it would take would be coming up with a model, perhaps some
library support, and converting all of the plugins to it. Most
plugins would become much simpler. They generally wouldn't need
their own whitelisting mechanisms at all, and you don't have to
configure their hit behaviour either.
I strongly believe that one of qpsmtpd's biggest impediments to
broad deployment is the adhoc/inconsistent nature of the plugin
suite, particularly all the inconsistent configuration directives.
Another thing is the essentially useless logging (the released
qpsmtpd doesn't even include logterse I think).
You can't build an "enterprise level" MTA out of the current plugin
suite. You have to recode them all for consistent behaviour and
construct your own logging. The qpsmtpd _core_, on the other hand,
is just fine as is ;-)
I completely agree, most notably with the last point. We have started
to implement a completely new set of plugins ourselves that uses a
quite similar model.
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.
Thus, while I agree that it would be nice to have a common model
(however, I would opt for a slightly more sophisticated one as
mentioned, e.g. something as what policyd-weight does for postfix, for
example), I would leave the basis of the current plugins untouched.
That keeps the barrier for newbies low.
One could however offer a alternate standard set of plugins
implementing the discussed ideas, I think.
Cheers,
Baltasar
((( Baltasar Cevc
) World wide web:
# http://www.openairkino.net/ (a project for the local youth;
German only)
# http://technik.juz-kirchheim.de/ (programming and admin projects)
# http://baltasar.cevc-topp.de/ (private homepage)
) Phone:
+49 178 691 22 33
)
