Baltasar Cevc wrote:
Hi,
On Jun 22, 2009, at 3:48 PM, Chris Lewis wrote:
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.
For tweaks, this is what you want.
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.
There's an inevitable conflict between those who simply want to be able
to _use_ qpsmtpd, and those who want to expend the effort to understand
it to modify it. Don't know if you were around when there was
discussions about "just having it work out of the box". That's the
exact opposite of "open" as you describe it. Because unfortunately,
it's not useable out of the box. Frankly, it's not terribly usable
without a fair bit of coding.
As an analogy, consider sendmail. sendmail.cf's aren't "hard", but it's
still a place where even almost-gurus fear to tread. Running sendmail
was dangerous because playing around with sendmail.cfs directly isn't
easy. It wasn't until sendmail.mc files became common, based around
"feature" enable/disable, that it really became something most could
tweak with any level of confidence that it wasn't going to blow up in
their face and (least of all) break RFC282x.
[I've been fighting with sendmail.cf's since there was a sendmail.
Still loathe them, despite having written them from scratch, and
believed knowledgeable enough to be given a draft of the first Bat book
to review.]
If you want ordinary admins to be able to _use_ it, you have to reduce
the adhoc nature of configuration. Hide the detail the admin doesn't
need to know (yet). Configure it by _feature_, not implementation.
Have the basic functionality already there to do the necessary things.
Like logging.
This in no way makes it more difficult to treat it as "open". Because
it still is. Just has some discipline and consistency that makes it
possible for people to use without expending the learning curve.
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.
With templating of common interfacing, it becomes easier to understand -
you have to understand _less_ of the internals. "Here's the plugin
template. See the "#add stuff here" comment? That's where you put your
stuff".
I've already shown my template. It does all the interplugin
communication for you. You just have to know enough of the API to get
at the particulars of a given email that you're going to make your
filtering yes/no decision on. You don't have to understand how to
dispose of the email. You don't have to understand how to log.
What I think may be worthwhile doing is to come up with a reasonably
flexible plugin intercommunication protocol, along with a reasonably
generic logging (some variant of logterse) plugin, "disposal" plugin,
and SMTP forwarder. Plus a few filtering plugins (eg: a simple string
filter on HELO plus DNSBL) with a documented template for constructing
new ones.
_Then_ you can make it work just about out of the box with minimal
configuration requirements and have it do something useful. Then all of
the existing plugins become archival samples, which over time get
replaced with ones coded to the template. This reduces the effort
needed to get _something_ working, and also reduces the effort to build
new plugins as needed.
