The mailing lists at Eskimo are run by Majordomo, and I suggested to
one of the sysadmins that procmail might be a handy solution to one
of Majordomo's shortcomings. I've been unable, so far, to convince
him to switch to Smartlist. :) My question for the list is, has
anyone invented this wheel - Majordomo/Procmail - and if so, could
they point me to the most appropriate place to hook in procmail? I
assume it'd be in the aliases that configure Majordomo somewhere.
Or, alternatively, is this a hopeless idea that bears no further
thought?
I've been wrestling with the same problem, but from the side of the
sysadmin. As encouragement to your sysadmin, you might let him/her know
that SmartList (SL) lists can be implemented without using the "-dist"
alias. This avoids the possibility that a mail-hacker/spammer can
discover the members of your lists, unless you allow it through the
archive directory.
In fact, we use only four aliases for each SL list:
somelist: "|flist somelist"
somelist-request: "|flist somelist-request"
owner-somelist: postmaster
owner-somelist-request: postmaster
The latter two are needed only if something goes wrong with the "flist"
invocation.
i've been slowly converting from our 60 or so Majordomo (MD) lists to
SmartList (SL). The MD we're running is an improved version with code
I added to support the notions of:
* local (to the domain), private (not visible) and public lists
* open/closed/proxy subscriptions
* remote put command
I decided to convert to SL because of these reasons:
* MD, being Perl based, consumes way more system resources (memory +
CPU) than SL.
* SL has better control over the distribution list.
* SL *can* be programmed to emulate MD, eventually.
I began working on the infrastructure in SL to make it possible to
emulate MD. Currently, I have the following tools:
showlist script to show the configuration details of
one or more lists. This has been added to
the 3.11pre4 distribution
mindlist script to remind users/owners/moderators of
their list memberships. This, too, has been
distributed with 3.11pre4.
makemetalist script to build "metalist.txt" from each lists
info.txt file and and link into each lists'
archive directory. Not distributed yet (soon!).
getsmartlists script to scan a SL installation and obtain the
information necessary for remote list
management. This is currently a Perl script,
because I could not get a sh + procmail version to
reliably dump variable values (when I release this
script, a small note will explain this problem
in more detail). Perhaps, 3.11pre4 has fixed
this problem.
doxcmd script to generate a SL remote list command, using
a file of information gathered by getsmartlists.
What is left to do is:
* write "rc.majordomo" a procmail recipe file which recognizes the
syntax of a MD command, in the body of the mail, one line at a
time, and invokes "majordomo", a shell script to implement
the command passed to it (along with the mail headers on STDIN)
At this point, I'm not sure whether to try filtering the incoming
mail through the emulator, or make the emulator handle one command
and generate an independent reply.
* write "majordomo" a shell (or Perl?) script which will perform the
majordomo commands, either within the shell script itself, or by
generating the corresponding SL commands. Again, I'm not exactly
sure which is better at this point.
A possibly difficult issue is the "which" command, which must grep
across all lists' "dist" file, but only return *exact* and
*complete* matches, since doing otherwise will allow automatic
scanners to discover memberships covertly.
* Modify rc.init + rc.custum to define a new variable,
check_majordomo, which, if set, allows the "rc.majordomo" to be
included.
* Modify rc.request to invoke rc.majordomo at the appropriate point,
depending upon "check_majordomo"
* Modify rc.submit to possibly recognize MD administrative commands
and redirect them to rc.request, if "check_majordomo" is enabled.
* Modify rc.main to allow the main list address "lists" (or
whatever) to receive MD commands. Currently, command to the
"lists" address generates an "unknown list" error.
Meanwhile, other tasks are burning more brighly, so I've been gradually
migrating to SL, despite not having an emulation done yet.
As I convert a list from MD to SL, I make the following changes:
* if the list was "local", link ".bin/subscreen.$DOMAIN" to
"$list/subscreen", where $DOMAIN is our local domain.
* if the list was "private", touch $list/private, so that the
nightly cron-drive shell script, "makemetalists" doesn't gather
info on this list for the "metalists.txt" file linked into each
lists archive directory.
* if the MD list had restricted access to the archive, set the
corresponding "restrict_archive" variable in $list/rc.custom.
* for lists with restricted access to the archive, we also link the
"dist" file into the archive directory, so these users can see the
other members of the lists.
* copy and clean up the MD distribution list for the "dist" file;
multigram is a little fussier about parsing addresses than were
the Perl scripts in MD.
* Enable list trailers. We do this with an RC_LOCAL_S20 rc file.
Link ".etc/rc.local.s20" to "$list/rc.local.s20", and uncomment
the RC_LOCAL_S20 definition. "Rc.local.s20" looks like this:
# RC file to append a trailer
# If the file "submit-trailer.txt" exists, it will be appended
# to all submitted mail.
# The variables $list, $domain, $listmaster, and $maintainer will
# all be substituted into the trailer.
:0 fb
* ? test -f submit-trailer.txt
| cat - ; \
sed -e "s/\$list/$list/g" \
-e "s/\$domain/$domain/g" \
-e "s/\$listmaster/$listmaster/g" \
-e "s/\$maintainer/$maintainer/g" \
<submit-trailer.txt
This allows a per-list trailer to be created. If the file
"submit-trailer.txt" exists, it gets added; otherwise not.
* If the list is a local reflector for a national list, I then link
".etc/reflector-trailer.txt" to "submit-trailer.txt". It's
contents is appropriate for a national list reflected through a
local list:
--------------------------------------------------------------------------
You are receiving this mail via a local reflector mailing list at
$list(_at_)hub(_dot_)ucsb(_dot_)edu(_dot_) To remove yourself from this
list, send a message
with the subject of "unsubscribe" to $list-request(_at_)$domain(_dot_)
To obtain
additional information send a message with the subject of "help" to
$list-request(_at_)$domain(_dot_)
* If the list is a general discussion list, we link
".etc/submit-trailer.txt" to "$list/submit-trailer.txt", which has
text appropriate for a general discussion list:
--------------------------------------------------------------------------
To remove yourself from this mailing list, send a message with the
subject of "unsubscribe" to $list-request(_at_)$domain(_dot_) To obtain
additional information regarding this list and its archives, send a
message with the subject of "help" to $list-request(_at_)$domain(_dot_)
* convert the MD aliases in /usr/lib/aliases to SL aliases. We are
using "smrsh", so our aliases look like the ones I listed at the
beginning of this mail.
* run "newaliases", so sendmail knows about the new aliases (I know,
the newer sendmail don't need this done).
* run "mindlist" for the users, owners, and moderators (if any);
this reminds them of their membership, and the procedures used to
deal with the software.
Hope this helps with your migration.
_______________________________________
Alan K. Stebbens <aks(_at_)hub(_dot_)ucsb(_dot_)edu>
College of Engineering
University of California, Santa Barbara