ListServer (V 2.14) ~~~~~~~~~~~~~~~~~~~ Format: rx ListServer.rexx [SERVER ] Template: NAME/A,PASSWORD,SERVER/K,LOOP/K ~~~~~~~~~ Purpose: Run any number of mailinglists and handle ~~~~~~~~ subscribe/unsubscribe-requests. Specification: ~~~~~~~~~~~~~~ A "mailinglist" is a special email address: all mails to this address are automatically forwarded to a list of other users, its "subscribers". The Reply-To of the forwarded mails is set to the mailinglist so that replies also reach all subscribers. Thus a mailinglist can be used much like a newsgroup. Compared to a newsgroup, a mailinglist has some advantages: + everybody with an email-connection can take part in mailinglists + it's easy to create mailinglists, whereas creating new newsgroups usually involves some adminstrative effort and bureaucracy + the list of subscribers is centrally maintained and can be easily controlled However there are also some drawbacks: - many mail-readers are not very well-suited to deal with mailinglists, thus making it uncomfortable to read the larger numbers of messages that mailinglists generate. - if mailinglists exceed a certain number of subscribers they become much more costly than newsgroups (in terms a overall network bandwith) - once a newsgroup is established it's easier for new users to join the group or to just check it out. So, whether it's better to create a mailinglist for a certain topic or a newsgroup really depends on the number of users you want to address and whether it needs to be a public or a private forum. "ListServer.rexx" is a mailinglist-driver for UMS. It can drive any number of mailinglists, maintains the list of subscribers for each list, and allows remote subsription to mailinglists. It can also transparently gate each list into a newsgroup, fully preserving message threading. Function: ~~~~~~~~~ ListServer must be started with the name and password of a special UMS-user in the commandline. It first obtains its configuration from the umsserver, including the list of all mailinglists to drive and all their subscribers. Then it looks for new mails addressed to a "server" username, usually called "request". These messages are searched for commands that allow users to subscribe or unsubscribe, or obtain useful information about the lists. It also generates answers to all processed mails and notifications to users that are added or removed from mailinglists. Finally the real work is done: for each mailinglist incoming mails are processed and forwarded to the subscribers. If a newsgroup is configured for the mailinglist, the mails are also sent to the newsgroup and new postings in the newsgroup are sent to the subscribers. Special care is taken to remember all message-ids so that future follow-ups or replies are given the correct references on each side. If a follow-up or reply is received, the reference-ids to be used are looked up in the message-base. This only succeeds if the referred to message still exists. Configuration: ~~~~~~~~~~~~~~ ListServer needs one UMS-user-entry for all mailinglists. All the configuration is done via UMS config variables in this user-entry. That UMS-user must be an EXPORTER, i.e. it must have an "EXPORT" pattern. This can (and should) be "%" though, meaning that it actually exports nothing. The reason for this is the heavy magic used to remember the mail-message-ids for follow-ups in the newsgroup and vice-versa. Some IMPORT-access is needed since ListServ must be able to use all subscribers addresses as a FromAddr when creating new messages. This can be "#?", allowing any address to be used. Several ALIASes are needed. One must be "request" or whatever username will be used to process request-mails (see below: "mailinglist.server"). Another one must be the "username" useed for answering the requests, e.g. "listserv" (That must also be placed in "uucp.username" if UMS-UUCP is used). It's strongly recommended to use different usernames for addressing and answering the requests, since otherwise simple errors may cause infinite loops of bounce- and error-mail. Daemons on other systems and the ListServer would play ping-pong, not understanding each other. Two additional ALIASes are needed for each mailinglist. One must be equal to the name of the mailinglist and one must be "Mailinglist ''", resembling the mailinglist's "username" and "realname". Obviously ListServer needs READACCESS and WRITEACCESS to the newsgroups it deals with. However, having more access than needed won't hurt. As stated above, all the configuration is done with UMS-config vars in ListServ's user-account. There are some general variables and some for each mailinglist. General variables: mailinglist.hostname -- the name of the host. This is used to build the reply-to address for mails. Only the part after "@", is needed, since the username and "@" are prepended by ListServer.rexx. Yes, this means it only works for RFC (usenet) for now. At least you need to have a usenet-address you can use. Also a working "Reply-To:" field is required in the used network. mailinglist.server -- the username that request-mails are addressed to. Usually "request". mailinglist.helpfile -- complete path to the help-file. This file is sent to a user of the ListServer whenever he requests help, or proves to have trouble with ListServers request-commands. The helpfile is optional, but recommended for your users convenience. It should explain the available commands offered by ListServer (You may use the supplied helpfile). mailinglist.lists -- the list of all mailinglists. All mailinglists you want to run must be listed in this variable, it's a multi-line variable with each line containing the name of one mailinglist. Mailinglist-specific variables exist for each mailinglist. The name of the mailinglist is used in the variable-name: mailinglist..group -- (optional) the name of the newsgroup to be connected with the mailinglist. No newsgroup for this mailinglist will be used if this var doesn't exist. mailinglist..descfile -- (optional) complete path to a file containing a description for the mailinglist. This may incude a FAQ-list. Users can order this file from within request-mails. mailinglist..alias -- (optional) alternate username for that mailinglist. Mails to this username also are sent to the mailinglist (and newsgroup). Not usually needed. mailinglist..users -- the list of all subscribers of that mailinglist. This is a multi-line variable. Each line specifies one subscriber in the format: name "," address This is used as UMS "ToName" and "ToAddress" when sending mails. mailinglist..access -- an AmigaDOS-style pattern that specifies the users that are allowed to add new subscribers to the list. Whenever a user requests a new subscription, his name and address is matched against that pattern (name and address given in the same format as in the subscriber-list). If the match doesn't succeed, his request is rejected. This is used to protect closed "private" mailinglists. Use "#?" to make the mailinglist public. Use "%" and the only way to add users is to directly modify the config variables. Example configuration: ~~~~~~~~~~~~~~~~~~~~~~ This is an example ListServer entry for UMS V10 (not tested): User Name = "UMS Mailinglist Server" Alias = list Alias = Request Alias = listserv Alias = testlist Alias = "Mailinglist 'testlist'" Alias = "Ums-Intl" Alias = "Mailinglist 'Ums-Intl'" Password = "secret" READACCESS = "(Fidonet.UMS-INTL|test.test)" WRITEACCESS = "#?" NETACCESS = "#?" IMPORT = "#?" EXPORT = "%" DISTRIBUTION = "(%|#?,)(mailinglist|list|UMS|N|Net|world)(,#?|%)" uucp.username = "list" mailinglist.helpfile = "wb:ums/mlist/helpfile" mailinglist.hostname = "umshq.dfv.rwth-aachen.de" mailinglist.lists = "Ums-Intl*Ntestlist" mailinglist.server = "Request" mailinglist.testlist.access = "(SYSOP|Martin Horneffer)," mailinglist.testlist.descfile = "wb2:ums/mlist/testlist.desc" mailinglist.testlist.users = "Martin Horneffer,umshq umsadm,umsadm@wowbagger.pc-labor.uni-bremen.de Test User,test@test.do.main" mailinglist.Ums-Intl.access = "#?" mailinglist.Ums-Intl.descfile = "wb2:ums/mlist/Ums-Intl.desc" mailinglist.Ums-Intl.group = "Fidonet.UMS-INTL" mailinglist.Ums-Intl.users = "Matthias Scheler,tron@lyssa.owl.de Karl Skibinski,charly@p42.swb.de Bill Holder,bill@yarrow.wt.uwa.edu.au Ian Moran,ianm@icsbelf.co.uk Dale E. Reed Jr.,daler@crnstn.spk.wa.us Randy Schnedler,UMS-List@fcircus.sat.tx.us Bernhard Seefeld,seefeld@amiga.icu.net.ch Christian Ruetgers,chr@quack.ms.open.de Christopher Aldi,aldi%phantm@uunet.uu.net Marc Jackisch,mtj@tron.gun.de Michael K Greene,mgreene@holonet.net Mario Kemper,magick@delbox.zer.de Johan Billing,johan_billing@kcc.ct.se Andreas Schildbach,p7003df@sun1.lrz-muenchen.de Stefan Stuntz,stuntz@informatik.tu-muenchen.de James McOrmond,ab207@freenet.carleton.ca Stefan Becker,stefanb@yello.ping.de Bernhard Moellemann,zza@rz.uni-karlsruhe.de Iain Hibbert,ums-intl@skate.demon.co.uk hartmut Goebel,hartmut@oberon.nbg.sub.org Thomas Schwarz,blacky@bmagic.mayn.sub.de Markus Stipp,corwin@pixar.owl.de Arthur Choung,achoung@kaiwan.com sjohnson,sjohnson@godzilla.uucp Maus-Mailbox Bremen-2,Gruppe_UMS-INT.ML%hb2.maus.de@oytix.hb.north.de ums-dev-list,ums-dev-list%light.fipnet.fi@zruty.dfv.rwth-aachen.de Klaus 'kamel' Melchior,kmel@eifel.oche.de olio,olio@Informatik.Uni-Bremen.DE Raymond Penners,raymondp@sphinx.stack.urc.tue.nl Stefan Gybas,cab@studbox.uni-stuttgart.de kmel,kmel@cwg.fido.de Tommy V. Hansen,ums_list@fan.ping.dk Erik Bystrom,erikb@chiba.augs.se" EndUser And this is the same in V11 syntax: ( Exporter ( Alias list Request listserv testlist "Mailinglist 'testlist'" "Ums-Intl" "Mailinglist 'Ums-Intl'" ) ( Name "UMS Mailinglist Server" ) ( Password secret ) ( READACCESS "(Fidonet.UMS-INTL|test.test)" ) ( WRITEACCESS "#?" ) ( NETACCESS "#?" ) ( IMPORT "#?" ) ( EXPORT % ) ( DISTRIBUTION "(%|#?,)(mailinglist|list|UMS|N|Net|world)(,#?|%)" ) ( rfc.username list ) ( mailinglist.helpfile "wb:ums/mlist/helpfile" ) ( mailinglist.hostname "umshq.dfv.rwth-aachen.de" ) ( mailinglist.lists "Ums-Intl\ntestlist" ) ( mailinglist.server Request ) ( mailinglist.testlist.access "(SYSOP|Martin Horneffer)," ) ( mailinglist.testlist.descfile "wb2:ums/mlist/testlist.desc" ) ( mailinglist.testlist.users "Martin Horneffer,umshq\n" "umsadm,umsadm@wowbagger.pc-labor.uni-bremen.de\n" "Test User,test@test.do.main" ) ( "mailinglist.Ums-Intl.access" "#?" ) ( "mailinglist.Ums-Intl.descfile" "wb2:ums/mlist/Ums-Intl.desc" ) ( "mailinglist.Ums-Intl.group" "Fidonet.UMS-INTL" ) ( "mailinglist.Ums-Intl.users" "Matthias Scheler,tron@lyssa.owl.de\n" "Karl Skibinski,charly@p42.swb.de\n" "Bill Holder,bill@yarrow.wt.uwa.edu.au\n" "Ian Moran,ianm@icsbelf.co.uk\n" "Dale E. Reed Jr.,daler@crnstn.spk.wa.us\n" "Randy Schnedler,UMS-List@fcircus.sat.tx.us\n" "Bernhard Seefeld,seefeld@amiga.icu.net.ch\n" "Christian Ruetgers,chr@quack.ms.open.de\n" "Christopher Aldi,aldi%phantm@uunet.uu.net\n" "Marc Jackisch,mtj@tron.gun.de\n" "Michael K Greene,mgreene@holonet.net\n" "Mario Kemper,magick@delbox.zer.de\n" "Johan Billing,johan_billing@kcc.ct.se\n" "Andreas Schildbach,p7003df@sun1.lrz-muenchen.de\n" "Stefan Stuntz,stuntz@informatik.tu-muenchen.de\n" "James McOrmond,ab207@freenet.carleton.ca\n" "Stefan Becker,stefanb@yello.ping.de\n" "Bernhard Moellemann,zza@rz.uni-karlsruhe.de\n" "Iain Hibbert,ums-intl@skate.demon.co.uk\n" "hartmut Goebel,hartmut@oberon.nbg.sub.org\n" "Thomas Schwarz,blacky@bmagic.mayn.sub.de\n" "Markus Stipp,corwin@pixar.owl.de\n" "Arthur Choung,achoung@kaiwan.com\n" "sjohnson,sjohnson@godzilla.uucp\n" "Maus-Mailbox Bremen-2,Gruppe_UMS-INT.ML%hb2.maus.de@oytix.hb.north.de\n" "ums-dev-list,ums-dev-list%light.fipnet.fi@zruty.dfv.rwth-aachen.de\n" "Klaus 'kamel' Melchior,kmel@eifel.oche.de\n" "olio,olio@Informatik.Uni-Bremen.DE\n" "Raymond Penners,raymondp@sphinx.stack.urc.tue.nl\n" "Stefan Gybas,cab@studbox.uni-stuttgart.de\n" "kmel,kmel@cwg.fido.de\n" "Tommy V. Hansen,ums_list@fan.ping.dk\n" "Erik Bystrom,erikb@chiba.augs.se" ) ) LOOP-mode: ~~~~~~~~~~ The LOOP parameter allows the ListServer to run continuously in a loop. This can be used to run ListServer parallel to a "uucico" and allows it to return mailinglist-mails in the same phone-call. When using the LOOP-mode, you must specify a "LOOP-command" after the "LOOP" keyword in the command-line. ListServer will run as usual, read its config and process requests and lists, but instead of terminating it will start the LOOP-command. This command can be used e.g. to export mails, wait for new incoming mails and import them. ListServer will look at the command's return-code. If this is zero, i.e. the command was completely successful, ListServer will immediately look for new mail again, process requests and lists and start the LOOP-command again. When the command returns any other return-code, ListServer will terminate. Setup LOOP-mode for fast mailinglists: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the ListServer-archive you should find one directory called "s" with some scripts that show an example of how fast mailinglists could be setup. To use them, the following steps are required: - rename the (real) uuxqt-binary to "uuxqt-bin". - move "s/uuxqt" to some place in your path. This replacement uuxqt is supposed be started by uucico. instead of importing news and mail itself it merely signals the ListServer-process to look for new files. - start the uucp-session with the "s/uupoll" script. You might want to customize it to suit your needs and setup. E.g. change the ListServer password, add flags to uucico etc. With this script a "slave" process is started before uucico. It's a ListServer with a special LOOP command: the supplied "s/listslave" script. This script does the exporting, importing, waiting for new files and detecting when to terminate the ListServer loop. You'll also need a uucico that starts "uuxqt" during the phone-call, everytime files are received. eg with wUUCP, "UuxqtInterval 2" in your UULIB:Config file will do the job. Martin Horneffer, 26.8.1994