I'm back from vacation and all caught up with work, so it's time for
another snapshot. Look in
ftp://ftp.hpc.uh.edu/pub/majordomo/Majordomo-0.0199801091.tar.gz. As
usual, there are probably piles of bugs but I've fixed everything that I've
seen.
First off, to use this you absolutely must get and install MIME-tools 4.107
from http://www.zeegee.com/code/. Eryq has given me permission to let
folks here know where the development versions of MIME-tools go. Also,
note that make test will fail because of an error in the test. Everything
is fine with the module itself, though. All other module requirements are
the same as previous snapshots (I think) and everything except the
MIME-tools is available from CPAN.
The new MIME-tools has given me access to several good features and I'm
using them. (Preambles and epilogues are only two of many.) There's no
longer any need to patch the MIME modules.
There are too many new things since the last snapshot to enumerate; some of
them are:
Almost all functions can generate confirmation or consultation tokens; you
can consult majordomo-owner for which requests and the list owners for who
requests, for example.
Notices about messages and requests which are stalled for approval can be
sent. These messages are of course configurable per list, remotely, by
uploading new files using the put command. Lots of embedded variables are
provided; the stalled post message can include a list of reasons why the
owner had to be consulted.
Users are informed when their requests are approved.
Users can choose to hide their address (showing their name) or hiding
themselves entirely from a who command. Approved who commands of course
show everything.
Old-style approval now works and has been extended to work around and make
use of MIME. Six examples (one for each method) are included in the misc
directory, called approve[1-6]. These have all been pretty well tested.
The Approved: line can also contain a token; if present it is deleted.
(This provides a convenient mutual exclusion mechanism for multiple
moderators, and has not been well tested.)
The approval methods are (briefly):
Approved: in the header.
Approved: as first non-blank line of body, followed by blank line and
body (single part message).
Approved: as first non-blank line of body, followed by headers (single
part message).
Approved: as first non-blank line of the preamble of a multipart
message.
Approved: as first non-blank line of first part of multipart message,
followed by blank line and body.
Approved: as first non-blank line of first part of a multipart message
containing exactly two parts, the first of which is text/plain and
contains only the Approved: line, the second of which is of type
message/rfc822 and contains the approved message.
If anyone can make a strong case for any other methods (like, "Hey, I'd use
it if it did this one") let me know and I'll try to add it.
The basic default access restrictions are now there. The defaults are
(IMHO, of course) reasonable and backwards compatibility is provided so
that *_access, (no)?advertise and subscribe_policy variables work like
they've always worked. (restrict_post isn't there yet.) The defaults are
also not documented anywhere, sigh.
There is a bit more documentation; I've lightly described what happens to a
message as it travels through the system and the various things that have
to be updated to add a new command.
Piles of bugs have been fixed. I now develop on Linux and test on Solaris.
Note that I have taken out most of the autoloading code, so expect pretty
horrible compile times. My development is now really, really fast so it's
easier for me to leave the code out. Expect a 3X decrease in compile times
once I've put it back in, though..
Please check it out and let me know what you think.
- J<
Follow-Ups:
|
|
