The "configurable by email" nature of majordomo suggests that Doug is
more on track to this solution than is Abalone. If/when at all possible
you want every element of a majordomo list to be accessible remotely.
Not necessarily to users, but to the admins. While Abalone's method
will get the job done, it causes more work than is necessary IMHO. Why
go to all that work with perl and cron when simply providing both names
on the restrict_post line would work?
Since restrict_post will allow multiple filenames on the RHS of the =
(space or colon separated of course), you have a natural solution built
right in. Majordomo creates *.config files for every file in the lists
directory that does not already contain a (.) in the filename. We can
use this to our benefit. If we call the file listname-additional or
listname-nomail or listname-extra or my favorite, listname-post, we
gain the ability to add and remove users from this file remotely.
All additions and removals from a filename that majordomo knows about
are done with commands to "majordomo". Therefore, no need for an alias.
By not creating an alias for listname-post, only majordomo (but not
sendmail) knows about the list. This is good, because these addresses
never want mail anyway. The key here, is that the listname-post file
must still be created in the lists directory with majordomo ownership
for majordomo to "know" about it.
To tie all this together, you would have a line in listname.config like
restrict_post = listname:listname-post
As a caveat, I would recommend changing the admin and approve passwords
in the listname-post.config as soon as possible after creating the file.
Without using this method, as Abalone suggests, you create a burden on
the admins everytime you want to modify the "post only" file.
For the cost of one additional .config file in a directory, I think it
is a worth while expense keeping the admin's job easier, and putting
the burden on the list-owner/moderator where it belongs.
Dan Liston
The Abalone wrote:
>
> On Wed, 21 Feb 2001, Doug Brewer wrote:
> > What I did was create a new list, listname-nomail, which is really
> > just a list of subscribers, a config and an alias. No mail is sent
> > through the list, and no mail is sent from the list. The subscriber
> > list is then included in the restrict_post line with the regular list.
>
> The solution we're using is a bit more involved, and does not (at this
> time) allow the listowners to directly add or remove no-mail users.
>
> There are three files in place for each list that requests this ability.
> They are [list], [list].additional, and [list].approved. The [list] file
> is the traditional subscriber list. The [list].additional file is a list
> of addresses that would like to post to the list, but not receive messages
> in their boxes. (Work accounts, whatever.) The [list].approved file is
> a generated file (we use a small perl script run from the crontab) which
> is basically the same as:
>
> cat [list] > [list].approved ; cat [list].additional >> [list].approved
>
> The [list].approved file is then set to be the restrict_post value.
>
> The benefits of this approach are less lists to configure/manage, as the
> "nomail" feature becomes a function of config files relative to the
> existing lists. The drawback is that because there is no way for
> listowners to directly edit those files, it increases a burden on your
> sysadmins.
>
> -CA
References:
|
|
