[In a message on Wed, 17 Jul 1996 00:03:07,
""Alan Millar"" wrote:]
>On 11 Jul 96 at 10:12, Sean Kamath wrote:
>> One thing we have a problem with here is that we run a *LOT* of little
>> project-oriented lists. The "leaders" change on a fairly regular
>> basis. Since the staff here is currently *WAY* under staffed,
>> anything we can do to save a few minutes here and there is a big help.
>> Allowing a list owner to change the list owner to someone else would
>> be a huge win.
>
>I've been doing this for two years by making the -owner a
>non-advertised list. All of my lists have it.
Yeah, we thought of that. We just don't really grok to having a large
aliases file. We have 737 entries as it is, and doing that would
double it. There's got to be a performance hit sooner or later.
>> to do this is to make mailing list for the owner, but then there has
>> to be an owner for *that* list. That doesn't *REALLY* work.
>
>It works fine.
Who's the owner ot the owner list? If list <foo> has an owner of list
<foo-owner>, then who is <foo-owner-owner>?
>> I'm proposing using the "owner" keyword to have a
>> "forward_to_owner" program
>
>So explain exactly how this is any different.
First, a comment. I'm not suggesting much of a change. Right now,
there's no verification that a command being sent in comes from
"list-owner", and I'm not proposing it start. It's merely for list
notification of subscriptions and the like. One thing we want to do
is send mail to all the list's owners, and say "hay, you own this
list. Do you still need it?"-type of thing. So, we need it
reasonably current. Soooo...
Say I'm owner owner of "foobar". But I get transfered to our India
facility, and will now work on the "bar" projects. Joanie, the new
head of the bar command, needs to assume ownership of the foobar
mailing list. I send the command
approve pw newowner foobar joanie@pogo.wv.tek.com
or I send a config command
config foobar pw
owner = joanie@pogo.wv.tek.com
Joanie get's mail saying "soandso just made you the owner" by way of
the mail to list-owner notifying them of the change.
>How can a bad address in a config file be any better than a
>bad address in another list? What is this "forward_to_owner" program
>going to do when it can't deliver to the owner specified in the list
>configuration? How will it even *detect* that it couldn't deliver to
>the owner? Let the system mailer do it? Then you have the exact
>same situation as the owner list.
I know. What I suggest has *nothing* to do with verification, it has
to do with allowing j. random user(jrand@host) to change who the owner
of a list is.
>I think this definitely comes into the creeping featurism category.
There's a pretty good reason, in my mind, for doing this in the
majordomo suite of files.
1) It's a "feature", to be sure, that is not *required*. OK, fine. I
know that. However, we're talking about moving the ownership of the
lists out of the mail transport layer, and into the actual majordomo
domain. This seems a win, in that it allows much easier administraton
of ownership of lists. People are free to add notifications to other
people, or whatnot.
2) doing it in the config file reduces the amount of lists you get
creating the same feature by having mailing lists that have owners as
other mailing lists.
3) by having it dynamic (so you don't have to rebuild a alias file
every 15 minutes), you avoid the "what happens when the root disk
fills up. Sure, I can feel free to hack the bejusus out of our
sendmail.cf file to move the aliases file, or write scripts to parse
the aliases file (oh, and since we run NIS, we'll have to push out the
mail.aliases map as well!), etc etc etc. It just seems like such a
hassle, when a *much* better implimentation is here.
Of course, I may not know of what I spean, but it seem that it can't be
*that* hard to replace the calls to
&sendmail(NOTICE, "$list-approval")
to
&sendmail(NOTICE, $main'config_opts{$clean_list, "owner"));
Having said all that, I suppose I ought to go off and impliment it
myself, eh? ;-)
Sean
Follow-Ups:
|
|
