On 17 Jul 96 at 13:21, Sean Kamath wrote:
> 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.
It's not going to double it. If you have extremely simple aliases
(no digests, etc), you'll add a third more. If you have complicated
aliases (digests and archiving and whatever else) the increase will
be even less.
As to performance, there's going to be a performance hit when you
invoke resend an *additional* time for each message to -owner.
Performance is exactly one reason I *wouldn't* use resend a second
time for every piece of -owner mail.
In either case, I would recommend that people consider a moderately
recent version of sendmail and hashing the alias file. Non-issue.
> >> 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>?
Who is the owner of
$main'config_opts{$clean_list, "owner")
supposed to be? You need an owner for this thing just as much as you
need a foo-owner-owner (actually owner-foo-owner). Who will it be?
Make it whoever you want. I make it majordomo-owner. You still
have to have it. In your scenario, where will you configure that?
Given the two alternatives:
foo-owner: :include:/usr/local/mail/lists/foo-owner
or
foo-owner: |/usr/local/majordomo/wrapper resend -o foo
what's the difference? You *still* need owner-foo-owner.
> 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...
Yes, and using a list for -owner already does this.
> 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.
Or you send the command
approve password subscribe foo-owner joanie@pogo.wv.tek.com
and Joanie gets the message. The only reason that I'm bothering to
post is because this *already* works.
> >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.
Right, and all I'm trying to tell you is that using a -owner list
*already* allows jrand@host to change the owner of a list.
If you're not worried about verification, why care about
foo-owner-owner above? Answer is that practically speaking, we do
have to worry about the list owner address being usable.
I think you and I are discussing two different comparisons. You are
comparing a modified majordomo with a config'ed owner versus a
hardcoded owner alias. I'm comparing a modified majordomo with a
config'ed owner versus a -owner list. It sounds like you've
discarded the -owner list idea out-of-hand without looking at how it
already answers your desired functionality.
> 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.
I disagree that moving it from a -owner list to the config file is
"easier administration". I have five lists whose owners can manage
subscriptions to the -owner list but still can't figure out the
config file. Easier for who?
> 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.
This is what it all comes down to. Not features, not functionality,
not capabilities, but how many lists you have. The question is which
is uglier: more lists in your list directory, or another
modification to majordomo, the config file, and yet another command
line option to resend?
> 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.
You're still comparing to a hardcoded owner alias. Reconsider these
hassle items with a -owner list.
I know I'm sounding like a real pain in the neck on this subject, and
I apologize for that. I'd just like to see people's time and energy
go into solving problems that don't already have answers. Of course,
everyone's situation is different and different people like some
answers better than others. If you do decide to implement it anyways,
I'm sure people will appreciate it.
- Alan
----
Alan Millar amillar@bolis.com
Owner, System Admin http://www.bolis.com
-> bolis.sf-bay.org is now bolis.com <-
If only we were all weiner dogs, our problems would be solved! -Brave Little Toaster
|
|
