on 7/19/05 9:20 AM, Tom Collins <[EMAIL PROTECTED]> wrote: > On Jul 18, 2005, at 11:30 PM, Kurt Bigler wrote: >> Maybe I shouldn't try to get to specific at this point, but one thing that >> comes to mind as a possible ingredient in generalizing vpopmail's .qmail file >> functionality in a helpful way might be the ability for a .qmail line, >> perhaps one ending in the "|" symbol to be a filter line whose presence would >> alter the input received by all subsequent lines in the .qmail file. I'm not >> sure if this is a good idea, especially taken alone. In general I tend to >> envision that somehow the .qmail file capabilities might somehow support a >> more general control-flow and pipelining model. This then might permit >> QmailAdmin enhancements on the modify user page to flow more freely and for >> separate features to interact with each other in more well-behaved ways. > > We could definitely start to stray from the .qmail model, but I'd want > to make sure there isn't already another program out there (say > maildrop) that could accomplish those goals.
I'm guessing you mean that QmailAdmin might make use of maildrop (or whatever), perhaps as an alternate mode of operation in which it would add a maildrop reference to the .qmail file and then implement additional QmailAdmin interface functionality through maildrop itself? Or were you thinking of trying to replace the .qmail file functionality in its entirety as an alternate mode at configure time? > Note that QmailAdmin does allow for editing of the V_USER0 through > V_USER3 flags on user accounts. Ah, ok. That took a bit of detective work. Apparently the INSTALL file does not mention this feature, although the CHANGELOG does. So I modified mod_user.html by hand and re-ran make install-strip. Is that the recommended way? Not enough interest in the feature to justify a configuration flag? (Or maybe just no time to do it yet. ;) Or maybe this makes sense because admins will want to customize the html to make the flags meaningful anyway? The flags are indented under the Spam Detection checkbox. But apparently there is no restriction that the flags should only be used if spam detection is enabled, right? Also it would be good if you could confirm that these flags have no existing meaning in a standard installation, so that I don't do something silly in turning one of them on. I saw something about a flag that enables admin privileges. > An external delivery program could use > vuserinfo to see which flags are set, and act accordingly. We could > even modify vdelivermail to set environment variables with those names, > in addition to setting all of the typical environment variables > typically set by qmail-local. Yes, I'd love to see an environment variable. But for some purposes this solution makes me a little nervous. I'm paranoid about code going live, and modifying code that is live is something I try to avoid. This is why I like to substitute filter scripts in their entirety on a test user account. Adding a flag to use the untested version would either mean adding more layers of wrapper (and so slowing things down) or modifying a single filter script containing both the old and the untested code. I just worry about shutting the whole script down because of a syntax error and causing important mail to be bit-bucketed. That's why I still like the idea of being able to select from a list of multiple filters. Thanks, Kurt
