"remove the connection / transaction id feature for 0.42 release
- add back in after 0.42 is out? if yes: start implementing in
-prefork" (commit message for rev 809)
I'd seen that note, I was hoping that it was going to be back in by now.
Anyone know what these problems with prefork were? (or what thread or
svn log I should go review on that)
The _intent_ is that our mods could be contributed back in, but since
we've implemented our own inter-plugin notes() communication
conventions, most of the existing plugins have to be overhauled to
match. Secondly, there are operational choices (eg: reject now/defer to
later) that have been hardcoded into our plugins rather than made
parameterizable.
It makes a great filtering and analysis engine. But you'd have to
swallow it's operational conventions in its entirety and customize any
additional plugins you'd want to add to match.
I'm facing similar problems. I think the solution is to examine QP's
own conventions and facilities and identify where they are insufficient,
and to try to fix or enhance them until they're doing what you need --
in a way that is flexible and backward-compatible enough for everyone
else to use it. This doesn't look easy. I recently updated our code
from using QP 0.40 (June 11, 2007) to current trunk, and I was happy to
see a number of performance improvements and bug fixes, but there was
very little change to API -- meanwhile we have all been extending the
API on our own to suit our needs. If Qpsmtpd is a development platform,
it seems like it needs to somehow advance as a development platform would :)
WRT the multi-recip issue specifically, so far I'm seeing three tools in
our various toolboxes that represent complete solutions (correct me if
I'm misrepresenting anything):
0. status quo in trunk: don't deal with per-recip configuration at all,
because the installation's needs are satisfied by site-wide configuration
1. Me: When one recip wants to reject and another wants to accept,
respodn '250', accept for the recipient that wanted to accept, and (1.a)
ignore (or (1.b) bounce or (1.c) quarantine or (1.d) tag or (1.e,f,g?)
frobnicate) for the recipient that wanted to reject
2. Chris Lewis: limit custom preferences to per-domain, and assume that
MTA's are not going to attempt to send to multiple domains in the same
transaction (potentially deferring recipients when they do try this)
3. David Nicol: If we want to accept a recipient for which we could
potentially take a distinct action, defer that recipient instead so that
they come in on a separate transaction
#1 has the advantage of _potentially_ allowing optimal efficiency (e.g.
we can give sending clients a response for every recipient rather than
having to split into a single transaction), and allows optimal
flexibility (nearly all config variables can be customizable down to the
user level). The trade-off is that the implemenation is necessarily
pretty complex -- at any juncture after DATA, we have to decide what
various things we want to do with various recipients, what we actually
can do, and then whether or not that means we're ready to reject or to
move on to the next juncture and repeat.
#2 is simpler to implement, but allows only per-domain configuration,
and potentially results in some inefficiency, as it requires
transactions to multiple domains to be split up per domain
#3 is as flexible as #1, but is potentially the least efficient, as it
could very well split up a single transaction into dozens of transactions.
I think it would be reasonable to try to accommodate all three of these
schemes at the very least, and perhaps other ideas not expressed here,
including Chris Lewis's, which quite honestly I will need to consider
more before I can really grock it enough to summarize it well :)
I'm not quite sure to what extent multiple strategies could be
accommodated while still unifying code. What would it look like if QP's
entire set of plugins supported the sysadmin choosing between mode
0/1.a-z/2/3 above, or even a combination for different types of
configuration? It's difficult to visualize. However I still suspect
that even with the necessary increase in size and complexity, and
perhaps some necessary compromises in each mode, it would still be
worthwhile, as it would allow QP itself to advance itself rather than
everyone separately advancing their forks :)
The unification question also brings up another issue in my mind that
I'm not really qualified to answer: would it be possible at all to
unify async and non-async plugins?
-Jared
