Hi,
On Jun 22, 2009, at 3:48 PM, Chris Lewis wrote:
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.
I agree; however, their approach is unlike qpmsptd's. To tweak
Spamassassin, for example, I will first proabably add one or two lines
and never think about how the system works.
Qpsmtpd is different - at least that's my point of view - we chose it
exactly because it leaves all open. It is designed to enable the user
to create its own system with it. That would still be the case with
the change, but the how would be less obvious.
You want the filtering _methods_ to be orthogonal to to email
_disposal_.
I totally agree here. That's why we use a similar thing to what has
been described here in our own system.
My point was not on what is most effective for filtering but on what
makes the system as a whole easily understandable. The core was - to
be honest - dark black magic for me at the beginning (and if I want to
know something I still have to jump around a bit to remember how it
works). With interdependance between the plugins we could move them
towards a similar situation. That would make it more difficult for new
users to add something in between because they'd first have to
understand how things relate to each other.
That said, the current plugin set is somewhat more a kind of
documentation to me than a really ready-to-use system. As I said, I
use something similar to what has been described and I'm the last one
who is against such a system.
Maybe - as an alternative to what I mentioned in my first mail, one
could think about preserving some of the current plugins as
documentation/examples (without the need of keeping them technically
top-notch).
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
)
