procmail
[Top] [All Lists]

Re: Integrating Procmail with Majordomo

1995-12-12 19:19:31
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

<Prev in Thread] Current Thread [Next in Thread>