Tom Collins writes: > I've thought a lot about this problem, and the simplest solution I can > come up with is to scan through the old file and copy unrecognized > program delivery lines (like maildrop or tmda) into a temp file, add > the qmailadmin generated entries and then replace the old .qmail file > with the tmpqmail file.
I remain unconvinced that this is the cleanest solution, although it may be the only solution that works with everything (so far) known to use .qmail files for special purposes. It certainly appears to fall short of what is required. As I understand your proposal, qmailadmin is essentially going to pass-through program delivery instructions like maildrop. That stops it corrupting maildrop stuff but provides no way for maildrop delivery instructions to be entered into the .qmail file in the first place. We have several hundred virtual domains used by clients and NONE of those clients have shell access or any other means of creating a .qmail file with maildrop delivery instructions. Logically, IF you're going to use the .qmail file to do the maildrop delivery then qmailadmin OUGHT to create the appropriate instruction when a user is added. Anything else is a horrible kluge, like me manually adding the instruction upon request (which defeats the purpose of having qmailadmin to let clients admin their own domains) or me writing a script that goes around checking every user in every domain to see if that user's .qmail file has a maildrop instruction. That means that qmailadmin has to know about every possible delivery program and be able to add the appropriate instruction. It's no good letting users enter the instruction because most of ours are too stupid to own a computer and it's a major security hole. So qmailadmin has to have buttons saying "enable maildrop," "enable TDMA," etc. Except that on my system I do not want an "enable TDMA" button. So better is a series of configure options that turn on the appropriate stuff automatically without the user having to know anything about what happens behind the scenes or have to puzzle out why he or she might want maildrop. So in the end, I think the proposal I made to modify vdelivermail is cleaner. An "enable-delivery-program=maildrop" or whatever would then tell vdelivermail that if it does not find a .qmail file then it should behave as though it had found one containing the delivery instruction appropriate to that program. It still needs to have a list of supported devlivery programs, but so does qmailadmin (if you wish to have things enabled automatically, which I believe is normally the case). Alternatively, vpopmail configuration could take the name of a file (relative to user's directory holding the Maildir to look for which is processed and the name of the program to use to deal with it: "enable-delivery-program=maildrop" and "enable-delivery-file=.mailfilter". Arguably you could add those same two configuration options to qmailadmin so that it uses them to add a delivery instruction to the .qmail file when the user is created, but the code has to jump through extra hoops to not display that instruction to the user. Or it has to check each time the user is modified and add the instruction if missing. And even then you have the problem of UPGRADING an existing system where .qmail files have never been used. You might have many thousands of existing users without .qmail files which will not get .qmail fies until the user or the admin makes a minor change (then changes it back because the only point of the change is to force the creation of a .qmail file). It looks particularly messy to me, particularly when considering upgrades. Whereas the vdelivermail mod I suggested automatically takes care of existing users. With the qmailadmin method then somebody somewhere will have to create a tool that goes through all existing accounts creating the .qmail files. -- Paul Allen Softflare Support
