It does certainly seem like QP is not used as a drop-in replacement for
qmail nearly so much as it's used as platform representing one element
of a larger anti-spam toolbox. That's how we use it here. It is a
shame that many of the tasks that people need QP to do, they can't do
with vanilla QP, and they end up doing work like mine and Steve's which
is not very useful to QP in general. "Un-forking" our QP code, and
making it easier for others to "un-fork", has become a priority for me
and I think it would be a good focus for QP as a whole. I personally
would like to know that the work that I do in my day job is contributing
to FOSS whenever possible; it also pains me to imagine all of the
bugfixes, cleanups, and innovations that other people have probably done
which I will never benefit from because it's not applicable to QP core.
Of course some is contributed anyway, but it's still pretty difficult
to benefit from such contributions when they can't be grafted into the
core. The idea of making QP plugins modules seems like a step toward
allowing developers to take advantage of QP code (and therefore fixes
and enhancements that the flow into QP code) while still making the
changes they need.
For myself I'm still hoping to be able to come up with some changes to
make things like per-domain/recip configuration attainable for system
administrators rather than just plugin authors -- making it possible for
plugins to be more unified and making it less necessary to fork. It's
difficult to say how that will all pan out, but it seems like it has to
come in baby steps if we are to avoid making changes that we regret or
that not everyone is happy to see made. I don't imagine that this idea
of having everything wait for DATA will be adopted: it limits the
usefulness of plugins that could have rejected earlier, and in my mind
it doesn't really simplify the problem much. We already face the
problem that you can't reject specific recipients after DATA; at best
you can accept for all and either silently ignore the recipients that
you wanted to reject or else bounce for them. That problem would be
amplified by making everything happen after DATA rather than allowing us
to reject specific recipients.
I'm currently looking at the custom DSN module that we wrote in order to
allow easy logging of results per-recipient and to consider the action
taken separately from the reason the action was taken. I'm revisiting
the module for our own purposes, and whil I'm at it I want to replace my
completely separate module with patches to Qpsmtpd::DSN that would
increase its ease of use while retaining backward-compatible
functionality. We'll see how that goes, and we'll see whether that
paves the way for more changes toward per-recipient configuration etc.
-Jared
- Unifying QP (was: RE: Install methods) Jared Johnson
-
