Wow! You have added so much to mj2. It is really going to need lots of
documentation and "clear examples" to let everyone see what it can do. I
think many will be assuming it is mostly a typical upgrade for majordomo.
I have been going through the source and have been amazed at all the hooks.
(Not that I have a clear idea how to run everything yet).
Thanks again,
Randall
On 7 Oct 1998, Jason L Tibbitts III wrote:
: >>>>> "RSW" == Randall S Winchester <rsw@Glue.umd.edu> writes:
:
: RSW> Say I have a list of 300 people who can post to a list, but only 30
: RSW> people actually want to recieve mail from the list.
:
: There are at least three options.
:
: RSW> Is this easy to manage?
:
: I guess that depends on how you define 'easy', but I think it's pretty easy
: once you figure out how you're going to do it.
:
: Here are your options:
:
: Sign everyone up, but put the people who don't want to get anything in the
: class 'nomail'. (set blah-list nomail address@host.dom). This means the
: people who can post are real subscribers; they just don't get any
: messages. Set restrict_post appropriately:
:
: restrict_post <<END
: blah-list
: END
:
: Sign up the recipient users and put everyone else in a sublist:
:
: auxadd blah-list posters address@host.dom
: `-list `-sublist
:
: then restrict posting to the main list and that sublist:
:
: restrict_post <<END
: blah-list
: posters
: END
:
: restrict-post is complicated because it tries to be backwards compatible.
: The first element can be colon or tab separated, as in 1.94.4, but it's
: really an array variable. Internally Mj2 tries to figure out what you were
: trying to do when it comes to naming the restrict files, only it uses
: sublists instead of files containing addresses. This means that you can
: manage them remotely.
:
:
: Sign up the recipient users, put everyone else in a sublist, make a file
: explaining that only members can post, 'put' it with the name
: 'membersonly', and make an access rule:
:
: access_rules <<END
: post
: deny, mailfile=membersonly
: !@MAIN && !@posters
: END
:
: This rule denies all postings from users who are not in the main list and
: are not in the 'posters' sublist. They will (i.e. should, modulo bugs) be
: sent the named denial message.
:
: The latter is the most flexible; you can change 'deny' to 'consult' if you
: want the list owners to be consulted. Also note that restrict_post isn't
: backwards compatible when it comes to other requests ('who', 'get', etc.)
: because I admit I really don't understand how it all works in 1.94.4 and
: from what I do understand it doesn't really work in a sensible manner.
: With access_rules you can describe exactly what you want.
:
: And a final note: this is getting into less-tested territory. Here be
: bugs. If you find any bizarre behavior, please send some debug logs my
: way.
:
: - J<
:
Follow-Ups:
References:
|
|
