[ Chan Wilson writes: ]
> Is anybody seriously attached to these features? I'm having to clean
> up an old existing configuration, and having all these "droppings"
> around that magically override the configuration file seem like a
> baaaaad thing.
> If there's no objections, I'll make mj (ala config_parse)
> transparently update the config file and remove the dropping.
I feel the same way you do about these "droppings", and don't use them
with one exception: listname.passwd. Actually I don't really use it as
it was intended. What I do is have a .MASTER.passwd file that I link all
the listname.passwd files to, and it's read only to Mj so it can't be
changed without root login access to the Mj machine. That way I *always*
have a password to all such lists without having to know the config file
passwords (I allow list owners access to their config file, perhaps
It wouldn't be the end of Mj as we know it if listname.passwd went
away, especially since I consider the way that it works now to be a
security problem (anyone with knowledge of any password could change
listname.passwd; if no one else was using it, i.e. every one else was
using the config file passwords, then the config file passwords could be
changed but that person would retain access to list functions).
That said, what I'd really like to see is a more coherent approach
to Mj passwords, e.g. an approve password in the config file and an
(overriding) admin password that the approve password can't access,
possibly in the majordomo.cf file. Any attempts to grandfather
listname.passwd files should be in the form of a separate conversion
program so as to simplify Mj instead of complicating it further.
Dave Wolfe *Not a spokesman for Motorola* (512) 891-3246
Motorola MMTG 6501 Wm. Cannon Dr. W. OE112 Austin TX 78735-8598