Here's the original message.
- J<
------- Start of forwarded message -------
Message-Id: <3.0.5.32.19990324154754.007c0dd0@pop.mindspring.com>
Date: Wed, 24 Mar 1999 15:47:54 -0500
To: Jason L Tibbitts III <tibbs@math.uh.edu>
From: Stephen Adkins <spadkins@internetdynamics.com>
Subject: Re: Majordomo 2 workers
References: <Stephen Adkins's message of "Wed, 24 Mar 1999 12:30:14 -0500">
<3.0.5.32.19990324123014.007c0dd0@pop.mindspring.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Hi Jason,
OK. Sorry for being so obscure. I just didn't want to trouble
you with some long story if you were just going to refer me to
someone else.
Majordomo 2 has many of the features needed.
Other features I seek in mailing list software are described below.
All of these features are general purpose and might be desired by someone
else as well.
DESIRED FEATURES
* hierarchy of lists (similar to news) rather than a set of lists
i.e. company
company.finance
company.finance.1999
company.finance.1999.budget
company.personnel
company.personnel.policies
company.personnel.policies.sick_leave
company.personnel.policies.401K
company.marketing
company.marketing.advertising
company.marketing.advertising.tv
etc.
* configuration obeys scoping rules
i.e. config parameters for "company" apply to all subsidiary lists
unless explicitly set.
* node aliasing
different names can exist for a single list, but the permissions are
managed through the node hierarchy. i.e. "company.finance.1999.marketing"
might be the same list as "company.marketing.budget1999" but the
permissions are governed as though they are separate lists.
* security is commercial-strength
i.e. a list may be configured to be "public" (open to subscribers
who have been granted membership in the list immediately above).
Other lists may require a request to be sent to the list administrator
and he may grant membership.
Integrated with PGP or other e-mail encryption/authentication schemes.
* membership in a list obeys a strict hierarchy
i.e. You must belong to the "company" list in order to apply for
inclusion in the "company.finance" list (and so forth).
If a user's membership is removed from "company", his memberships in
all subsidiary groups are implicitly revoked.
* ACL (access control list) level access
i.e. each user has READ/WRITE/ADMINISTER/NONE privilege on each
mailing list. Whatever permission he has at one level
(i.e. "company.finance"), he implicitly has at each lower level
(i.e. "company.finance.1999") unless that permission is explicitly
changed to something higher or lower.
* delegation of admin responsibility
Each node of the hierarchy can be administered by the administrators of
the parent node and by any additional people who have been assigned
administrator privileges. Administrator privileges include
creating sublists, deleting sublists, assigning administrators to
sublists, allowing and disallowing members of the list, setting
configuration parameters of the list, etc.
* individuals can explicitly opt-in (subscribe) or opt-out (unsubscribe)
to any node in the tree. This preference only affects the forwarding
of mail to that user (see web integration below). Each explicit
subscription or unsubscription applies to all subsidiary nodes unless
another explicit preference has been supplied.
* all lists referred to by a single e-mail address, differentiated by
the subject line
i.e. To: postmaster@list_server.com
Subject: [company.finance.1999] Financial goals
rather than
To: company-finance-1999@list_server.com
Subject: Financial goals
* each new message creates its own sub-node
i.e. a message to "company.finance" gets sent out with a message
number appended to the topic. This message number is unique for the
particular node in which it is created "company.finance" and allows
replies to be correlated to the original message. Thus, a user sends
a message in with "Subject: [company.finance]", and the mail dispatcher
assigns a message number to it and sends it out to all on the list as
"Subject: [company.finance.msg1335]". Replies to this message have
all the necessary information to recreate the thread of discussion.
(The mail dispatcher would of course have to replace the message number
in all replies with their own unique message numbers.)
The who point of this is to allow a user to opt-out of any particular
thread of discussion which he finds unhelpful. (i.e. "That was a dumb
question. I don't care to see any of the responses.")
* complete integration of mailing lists with a web site
i.e. all functions which are achievable through e-mail are also
achievable via the web
The same security applies (READ/WRITE/ADMINISTER/NONE).
Searching, browsing, posting all allowed through the web interface.
* supports e-mail authentication
creation of a single userid per user on the web site
users can claim ownership of many e-mail addresses for simple
(not really secure) authentication of e-mails.
i.e. tibbs@morpheus.hpc.uh.edu
tibbs@hpc.uh.edu
tibbs@math.uh.edu
integrated with better (PGP?) authentication schemes
Some technical (non-functional) requirements:
* written in Perl 5 in object-oriented fashion
* can be installed and run with no special privileges on an ISP web
hosting arrangement
That's what I can think of at the moment. Hopefully you can understand the
spirit of what I'm getting at even if you might suggest a slightly different
solution to any one of the features.
* What are your comments?
* Are these dumb ideas?
* Are they in keeping with the spirit and direction of Majordomo 2?
* Given the picture of functionality I am painting, what modifications would
you suggest to keep it more in line with the direction of majordomo 2?
* Should I get involved with majordomo-workers and help make these features
a reality?
* Should I go away and not bother you again?
Thanks for all the work you are doing on Majordomo 2.
Stephen
spadkins@internetdynamics.com
At 12:13 PM 3/24/99 -0600, you wrote:
>>>>>> "SA" == Stephen Adkins <spadkins@internetdynamics.com> writes:
>
>SA> Any thoughts?
>
>Without knowing what you want to do, not really.
>
>SA> To whom should I direct this request?
>
>We coordinate development on the majordomo-workers@greatcircle.com mailing
>list. This list is essentially closed to non-subscribers. You can CC
>things to me if you like.
>
>SA> How should I explore the appropriate level of involvement?
>
>I don't understand what you mean here. I of course welcome all assistance
>and am willing to consider implementation of just about anything. But I
>really can't even hazard a guess as to what you might be trying to do and
>without knowing that I don't know what I can tell you.
>
>If what you want is so specific that nobody else would ever want to use it,
>I would still consider providing an appropriate extension mechanism.
>
> - J<
>
------- End of forwarded message -------
Follow-Ups:
|
|
