| Current Path : /compat/linux/proc/self/root/usr/local/majordomo/doc/ |
FreeBSD hs32.drive.ne.jp 9.1-RELEASE FreeBSD 9.1-RELEASE #1: Wed Jan 14 12:18:08 JST 2015 root@hs32.drive.ne.jp:/sys/amd64/compile/hs32 amd64 |
| Current File : //compat/linux/proc/self/root/usr/local/majordomo/doc/FUTURE |
_ _ ____ _ ____ ____ ___ ____ _ _ ____
|\/| |__| | | | |__/ | \ | | |\/| | |
| | | | _| |__| | \ |__/ |__| | | |__|
Release 1.94
FUTURE
--------------------------------------------------------------------------
* Where is Majordomo headed?
----------------------------
In it's current release, 1.94, Majordomo is a stable, yet tangled,
collection of code. As the README says...
Along the way, it has picked up many features and additions
from various authors. Because of this, and due to the initial
design of Majordomo, certain features (archiving, digesting,
and moderated lists) are currently done in a "non-optimum"
fashion. In short, configuring Majordomo to do some of the
advanced features can be confusing. This is a known problem
and is being worked on.
Perhaps it would be enlightening to start with a vision of what
Majordomo should look like in the future, and then expand on the
vision.
1) Interaction with Majordomo should be easier; for the list user,
the list owner, and the Majordomo owner. This means an
integrated Web interface, as well as a better mail interface.
2) Existing facilities should be integrated better. Archiving and
digesting need integration.
3) Access to Majordomo functions and lists should be extensively
configurable, assignable, and easy to control.
4) Improvements to adequately handle large lists, and large numbers
of lists.
5) Majordomo "plugins", configurable down to a per-list basis.
Hooks for pre & post operations to commands. (ie, substitute a
different method of access checking for certain lists.)
6) Reduce, if possible, the morass of aliases needed for a large
Majordomo installation.
7) Consider the potential of integrating bulkmailer, TLB, or another
delivery agent into MD for large lists.
Now, how are we going to get from here to there? That's the tough
question.
The first step is to require perl5. This gives us heaps of good
stuff, and will potentially greatly reduce the tangle of current
code.
Next, abstract, define, and API-ize the core bits. This is where the
hooks to allow custom routines would come in, as well as allowing
drop-in plugins. Archiving and digesting are perfect examples of
this; these are basically post and pre sending operations.
API-izing things basically enables all the rest to be done easily and
coherently, allowing for the seperate development of some quite useful
features:
o using a DBM database, or perl5 file-struct for all list
configs.
o well-integrated pluggable web interface
o a queue mechanism for busy servers.
o fine-grained access control
o customized address matching
o post and pre Majordomo, List, and Command hooks
o subscriber level features, such as digesting and encryption.
Some other ideas that come from brainstorming a bit on the MD vision:
o Group Lists: Define a collection of lists, and manage them
the same way, with the same owners. A 'leader list' would
have 'leader variables' that the other lists 'follow'.
o From a different viewpoint, Group Lists is simply ownership
delegation. Put Majordomo-owner at the top:
Mojo Hierarchy
--------------
Mojo God: All lists
|
Group God: Some lists or commands
|
Command God: Some commands
|
List God: One list
|
Variable God: Some variables
o Command queuing: Either plain, ala sendmail, or 'alarm
clocking' -- queue commands, then process when the requests
stop for a certain period. Or perhaps...
o Majordomo Server. Likely run from inetd, this would be an
interesting way of solving the startup overhead.
Now, will all these happen at once? No, not unless someone spends
some development money. What's far more likely is an incremental
change, creaping up to a fabled Majordomo 2.0 knows all, sees all.
Broken down into manageable chunks, I see the following rough order
happening:
Perl5. APIs, abstraction, and definition of the 'interface
layer' to Majordomo. Perl5 modules replacing bits of
majordomo, and conversion of internal functions to the API.
Hook implementation. Web interface. Integration of archiving,
digesting. Group Lists, ownership delegation. Access lists.
Plugins. Database backend for lists, subscribers. Custom
operators. Backend delivery support.
Now, by all means, this isn't a complete list. Rather, it's a
compilation of the various ideas that have floated around the
majordomo-workers list and the majordomo developers.
What is greatly desired is to have the necessary core bits to allow
development of other features to happen in parallel. This could
follow the perl5 module design, with signup of projects to interested
parties.
Below here is Section 5 of the old README file (1.92), kept as a
placeholder for known bugs as well as random ideas.
----------------------------------------------------------------------
The next major planned release will be majordomo 2.0. The
specification document has been written for it, and is is in the
process of being written. The intent with 2.0 is to have a defined
programmers interface that allows people to develop portable modules
that can be added into majordomo to provide additional
functionality. If you think of majordomo as a stripped down car, and
the addin modules as extra options that you can "buy", then you have
the right idea. Majordomo 1.9x is being released to test the config
file code, and because some of the resend and majordomo features seem
to be needed by people on the majordomo-users list.
Before the next planned release, there may be other releases in the
1.9x series as bugs are found, and as additional functionality that is
currently hinted at in the config file is added.
5.1.1 Bugs/Misfeatures/Todo
The following is a list of things that I want to address at some
point. The items marked with a * imply that patches to implement the
feature have been written, but it is too late in this cycle to apply
the patch and test it. Hopefully some of these items will be fixed
in later versions of majordomo 1.9x.
1) Resend only recognizes an Approved: header as the first line in the body.
The approved header should be recognized if it is the first non-blank
line in the body. [[[ fixed in 1.94 ]]]
2)* Resend should have a separate moderater address to bounce email to
3) Multiple privacy levels have to be provided. yes, no, password protected
4) The number of reported hits from which should be tunable
5) approve has to be extended to handle almost all commands
6) new-list should be part of resend
7)* wrapper.c should use sysexits.h for its error codes
[[[ fixed in 1.94 ]]]
8) auto lists should prevent the list from being subscribed to itself
9)* auto lists should make sure that listserv style addresses aren't used
[[[ fixed in 1.94 ]]]
10) provide the ability to smash case of all incoming addresses under
majordomo administrator control.
11) ability to specify banned users whose posts are ignored.
[[[ fixed in 1.94 with taboo_headers ]]]
12) rework the advertise/noadvertise interface
13) Look at supporting #included/#exploder lists for mail sublists.
14) set up reply to be smart enough to break mail loops
(using received: headers)
15) should -h not be required by resend, or should resend_host keyword go
away?
16) config should return the input file if there is an error.
17) digest needs to strip headers and footers from list info. Maybe there
should be a back channel out of resend that doesn't do any
body massaging.
18) have resend/majordomo check to see if the last Received: line is a
right hand sub/super string of the user's from address.
19) fix help messages to remove syntax diagram info to stop address
subscriptions like: subscribe list [user@site]
20)* Support auto digest creation based on number of lines, and age.
21) Have resend log messages as it sends them through. Can be used to
prevent mail loops as well as provide stats for later use.
22) analyze code to make sure all areas that require locks are in place
23) detect error condition (e.g. out of disk space) and deal with them better
[[[ fixed in 1.94 ]]]
24) add code to support incremental config file changes.
25) add ability to add arbitrary headers to message and check that the
headers are in the proper form.
26) add the ability to do load limiting of majordomo commands
27) RCPT messages shouldn't be bounced as administrivia. They should be
in a different class, and should be user settable.
28) digest always needs to have its archive directory present. Digest
should be rewritten to place its outgoing digest into the
incoming directory, and it should use archive to do archiving if
need be.