230 lines
8.7 KiB
Plaintext
230 lines
8.7 KiB
Plaintext
_ _ ____ _ ____ ____ ___ ____ _ _ ____
|
|
|\/| |__| | | | |__/ | \ | | |\/| | |
|
|
| | | | _| |__| | \ |__/ |__| | | |__|
|
|
|
|
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.
|