Tom Collins writes: > How about this idea. Each domain has a template file (something like > domains/domain.com/dotqmail-template?), or a default template > (~vpopmail/etc/dotqmail-template?)
If we go down that route then I think you need to allow for both, with the domain template over-riding the global one if the domain template is present. > that explains to qmailadmin how to build a .qmail file for a user. This > would be used when adding a new user, or modifying an existing user. But does not apply to existing users that have not been modified. Imagine that you admin a domain with a few hundred users and have to make a pointless change to each user and then reverse that change simply to have things take effect. Imagine you run a server with a few hundred mail domains each administered by people who are bereft of clues and explaining to them that to make the feature work they will have to do this pointless change and reversal on EVERY existing user. Imagine you have to code up something that understands this template format so you can have a tool which goes around adding .qmail files for existing users who do not have them and flags those users who already have .qmail files (because I don't think such a tool could ever be intelligent enough to be trusted to do the right thing on an existing .qmail file created manually). This, I think, is the big flaw of putting this in qmailadmin. It would work fine on new systems but is a major pain on existing ones. > We could also add support to vpopmail's adduser command as well. Yes, you would have to also add it to adduser, moduser, etc. Which means you have now modified several vpopmail tools as well as qmailadmin. That seems like a LOT of work to me. > We'd have to define macros of some sort for a few useful options: > > Username > Domain name > full email address > path to Maildir > insert vacation program delivery here > insert forwarding addresses here > insert spam check here > etc. So now you're adding something to define and expand macros. OK, these days it's pretty much cookbook code, but it's yet extra code added to qmailadmin and those vpopmail tools. My quick and dirty change to vdelivermail ran to about a dozen lines of code (which could have been reduced by factoring out some of the error checking also used elsewhere into a subroutine) and had the bonus that it automatically dealt with existing users as soon as it was installed. Generalizing my patch to handle other delivery methods would require a little extra work in the configure file (OK, I'm doing some hand-waving there). > There might also have to be lines like "if V_USER1 is set, do this" or > "if V_USER2 is not set, do this" to allow for sys admins to customize > QmailAdmin using the USER flags (which is currently possible -- you > have to update the text in the language file to indicate what the flag > is for). This would allow end-users the option to turn on and off > certain features of a .qmail file (as controlled by the sys admin). That sort of functionality might be useful to some. Then again, we already have one file which is used to set limits on things and maybe a slight enhancement to that would handle the "what are users allowed to control" stuff. > After reviewing the moduser page in QmailAdmin, we might need to spend > more time on this subject, and reorg the moduser page as well. If a > user chooses to forward their email to another address and NOT save a > copy, then QmailAdmin will need a way to build .qmail from the > dotqmail-template file and NOT have mail saved in the Maildir... And here you're overlapping the functionality of sqwebmail's mailfilters. So I'd definitely want the ability to disable anything that people can already do in sqwebmail to avoid confusing them (while those running different setups might want the functionality in qmailadmin because their system has no other way of doing it). > I'd really like to find a resolution to the problem that's clean, > simple and flexible. You and me both. > Since I personally won't be using this feature, I'll need help from > everyone that does. If it helps, I can give you a mailbox on the test domain we're using to play with all the new stuff and you can give sqwebmail and its filters a try to get a feel for one particular setup. Mail me if you want it and I'll set it up and give you the details. > Question 1: Would such a system fit your needs? Not as currently outlined. See above. The major flaw is upgrading existing users. > Question 2: What macros would you use in a template (e.g., from the > list above)? Ummm, I can't see a need for any of them, to be honest. But I know that there are many different systems out there with many different needs. -- Paul Allen Softflare Support
