Listar

Modular Mailing List Manager

http://www.listar.org/

 

Current as of Listar release 0.129a

 


Table of Contents

1.0 Introduction. 2

1.1 What is a Mailing List Manager?..... 2

1.2 A Brief History of MLMs.......... 2

1.3 History of Listar............. 3

2.0 Installation 4

2.1 Introduction 4

2.2 Source Tarball Installation... 4

2.3 CVS Installation... 4

2.4 Compiling Under UNIX 5

2.5 Compiling Under Windows..... 6

3.0 Getting Started........ 7

3.1 Introduction 7

3.2 Listar and Mail Filters.. 7

3.3 Sendmail. 7

3.4 Exim......... 8

3.5 Postfix..... 9

3.6 qmail....... 9

4.0 Configuring the Server.. 11

4.1 Primary (Global) Config File.............. 11

5.0 Setting up a List............ 12

5.1 Creating the List.............. 12

5.2 Editing the List Configuration..................... 12

6.0 Interacting with Listar.. 13

6.1 Concepts 13

6.2 Normal Mode.......... 13

6.3 Secure (Administrator) Mode.......... 15

6.4 Web Interface..... 16

7.0 List Moderation 17

8.0 Modules 18

9.0 Example List Configurations................. 19

10.0 Writing Modules.... 20

Appendix A: Config Variables... 21


1.0 Introduction

 

1.1 What is a Mailing List Manager?

 

A mailing list manager is a piece of computer software which accepts a piece of e-mail from a single source and distributes it to a number of recipients.  Possible uses for such a piece of software include a monthly newsletter for customers of a business, a way to distribute information to users of a particular software package – for example, notification of a security fix – or a way for people who share a common interest to communicate with each other.

 

How people choose to implement mailing lists can vary widely.  The simplest method involves setting up a single address on an e-mail domain you control, and forwarding it to a number of people.  This has a number of disadvantages, however; users have no way to add themselves to the list, or remove themselves from it, there are no ways to restrict who can send mail to a distribution list, and other such headaches.

 

Most people, therefore, choose to use a piece of software to manage such lists for them; hence the term mailing list manager, or MLM for short.  Many people also refer to such packages as “listservers,” as they are server software for managing lists.  There are an ever-increasing number of MLMs available out there, but almost all share certain common traits; the ability for users to subscribe or unsubscribe themselves from a distribution list, the ability for an administrator to manually remove a user, the ability to restrict posting to a small number of individuals, and so on.  In addition, some MLMs support many additional advanced features, such as the ability to filter out unsolicited commercial e-mail (UCE, also known as “spam”).

 

1.2 A Brief History of MLMs

 

Back in the mid-1980’s, the system of interconnected computers we know as the Internet was not yet around.  While in the United States, there was some interconnection between colleges and the government’s ARPAnet, the only way any other machines – such as those at different universities – communicated was over a system called BITNET.  BITNET machines let messages for each other pile up, and then would call each other over the phone lines and send the messages.

 

BITNET had a central control post, a Network Information Center (or NIC) called “BITNIC.”  BITNIC kept a number of distribution lists for BITNET users.  However, the BITNIC’s lists were set up in the primitive way mentioned in the first section; a single address with no way for users to add themselves or remove themselves.  If you wished to be on a mailing list, you had to contact the BITNIC staff and have them add you by hand.

 

Unfortunately, as BITNET grew larger, managing the lists by hand was no longer feasible.  Additionally, since all mail for BITNIC was affected by the traffic of the lists – which by now were quite large – even private BITNET e-mail was affected.  It may be hard for users of today’s Internet to imagine, but try to picture things becoming so slow that when someone sent you an e-mail, it took over a week to arrive in your mailbox.  Clearly, something needed to be done.

 

Since the source of the problem was the traffic on BITNIC’s mailing lists, a computer science student named Eric Thomas decided to write a piece of software to replace the manually-managed mailing lists.  It also used a number of alternate paths to send e-mail to the list recipients, to keep it from clogging BITNET’s mail pathways, but what was more important to the future of MLMs was the fact that this software allowed users to add and remove themselves from the lists, instead of relying on a BITNIC system administrator to do it for them.  When it went online in July 1986, a piece of software was managing a mailing list for the first time – Eric Thomas had created the first MLM.  Soon thereafter, others created similar packages for other systems, such as the LISTSERV imitation for UNIX, Listproc.

 

As time went on, Eric Thomas’ LISTSERV developed into a commercial product beyond BITNET and was ported to other systems, and is still widely used on the Internet today.  However, as the days of BITNET faded into the past and the Internet became a reality, students who wished to run their own lists and did not have access to the funds necessary to purchase a license for LISTSERV began to look at developing their own MLMs to meet their particular needs.

 

Perhaps one of the most popular is Majordomo, which has been worked on by a variety of people over the years.  Majordomo is written in the Perl scripting language, which is perhaps its greatest failing as it makes Majordomo rather inefficient.  However, Perl is very powerful for text processing, and thus Majordomo is readily extendable by those who know Perl and are willing to learn Majordomo’s source code.

 

A good – if somewhat biased – summary of the history of MLMs is available online from Lyris Technologies (who are themselves the authors of a commercial MLM called Lyris, which is targeted specifically at business users) at http://www.lyristechnologies.com/historyls.html

 

1.3 History of Listar

 

Listar was born as a simple little project called ‘uList’ (microList) in October 1997.  The original author, Rachel Blackman, had been using the Majordomo mailing list package but wished for one that was more efficient and did not require any special system permissions to run.  Additionally, Rachel wanted a server that would allow the individual subscribers to change their subscription options – one of the more desirable features of LISTSERV.

 

The original design for uList was simple enough; users needed to be able to set a few simple options on themselves as well as perform all the standard operations that most MLMs provide.  However, Rachel got tired of having to constantly rewrite the core processing code as new functionality was added, and changed uList over to a modular system, where almost all of the system was added to a changeable table of information.  Suddenly, the system could be easily changed; a new command could be added with only a few lines of code, or a new step in processing a message to be sent.  The small uList program suddenly had more potential.  And to go with the new design, the software got a new name: Listar.

 

Listar developed into a more stable piece of software, and a mailing list was set up using it called listar-dev, for those who were interested in the ongoing development of the project.  On January 12, 1998, Joseph (JT) Traub began to work on the project as well.  JT’s first contribution to the project was the development of a ‘dynamic module’ system.  Since Listar was already based entirely around a dynamic model, this allowed new Listar plugin modules (or LPMs) to be installed and immediately provide new commands, subscription flags, or functionality.

 

The first public release of Listar came in February of 1998, and it was used only by a few curious parties.  However, many provided good feedback on features and functionality they wished to see in such a project, and Listar grew rapidly into a more mature program.

 

Then, tragedy struck.  In October of 1998, the machine that Listar’s main development resources were housed on was cracked into by a malicious individual, and the mailing lists were destroyed.  The Listar source code remained safe in backup copies, but the lists themselves were no longer available.  The recovery from this event took a while, and development on Listar was slow again afterwards at first, until users discovered the site was back and resubscribed to the lists.

 

Once past the recovery, however, 1999 proved to be a year full of rapid development for Listar.  It became even further fleshed out, and began to be used by some large organizations, such as the Internet Software Consortium.  The developers eagerly accepted suggestions and created new LPMs to add custom functionality, while folding additional functionality into the core module.

 

As of this writing, Listar approaches the second anniversary of its birth as uList, and has a growing userbase as well as a budding external developer community.  Some of the features that appeared first in Listar are now being borrowed for other MLMs.  Listar is an Open Source project, so users are encouraged to join in creating code for it.


2.0 Installation

 

2.1 Introduction

 

There are several ways that Listar can be obtained, and thus several methods of installation.  Perhaps the most common is as a collection of source code; which will compile on any number of UNIX-type platforms, as well as Microsoft Windows 95/98 or NT.

 

The package can also be obtained as an RPM (Redhat Package Manager) installation, either from the Listar FTP site, or from RedHat’s PowerTools collection or the RedHat Contrib|Net.  It can also be obtained as a .deb file for Debian GNU/Linux from the Listar FTP site or a local Debian mirror.  Or lastly, for those more inclined towards living on the edge of development, the source repository for Listar is available for read via CVS.

 

This document makes the assumption that if you choose to download either the .rpm or .deb versions of Listar to install, you already know how to use that package manager to install it, and will thus only cover compiling from source tarball, and compiling under Windows.

 

2.2 Source Tarball Installation

 

The Listar source tarball will unpack into a directory called listar-version, where version is the version of the tarball you are unpacking.  Fairly straightforward.  Feel free to explore the directory tree before moving along to section 2.4 or 2.5.

 

2.3 CVS Installation

 

CVS stands for “Concurrent Versions System,” and is a method of allowing multiple programmers to work on source code simultaneously, from a single repository of source code. The Listar installation is designed to be able to work from a CVS installation, to make it easy to keep an installation up-to-date.  To access the Listar CVS tree, you need a CVS client capable of CVS-pserver access.

 

Find the location that you wish to have your ‘listar’ tree, and enter the following command:

 

cvs –d :pserver:guest@cvs.listar.org:/var/cvs login

 

When it prompts you for a password, enter guest.  Then type:

 

cvs –d :pserver:guest@cvs.listar.org:/var/cvs checkout listar

 

You will see a list of filenames scroll by as CVS retrieves the current Listar source tree, and then you will have a source tree as if you’d unpacked it from the source tarball, except that it has a ‘CVS’ subdirectory in each directory; this allows your installation to remain synched with CVS.  Now, any time you wish to get the latest version, go into the Listar directory and do:

 

cvs update –P –d

 

For information on CVS and CVS servers, visit Cyclic Software, the authors of CVS, at http://www.cyclic.com/ - there are graphical CVS clients available for several operating systems as well as binaries for various systems.


 

2.4 Compiling Under UNIX

 

To compile under a UNIX-style system (such as Linux, FreeBSD, SunOS, etc.), Listar needs GCC or EGCS.  While it is technically possible that Listar would compile under the GCC for Windows that Cygnus provides, it is unlikely.  Listar has a specific Windows port; see section 2.5 for more information.

 

The first step under UNIX is to go into the ‘src’ directory under where you unpacked the tarball (or did a CVS checkout to).  Make a copy of Makefile.dist as Makefile.  Now you’ll want to pull Makefile up in your favorite text editor.  There are a variety of comments about what you’ll need to tune for specific operating systems; tweak the file as appropriate for your operating system and then save it.  Now type ‘make’.

 

Listar uses the GNU Make program to handle the build process.  Some operating systems, like Linux, provide this as the default ‘make’ program, while others, like FreeBSD, have it available as ‘gmake’.  If you have BSD Make, when you run ‘make’ in the Listar src directory, you will get a string of errors that look like:

 

"Makefile", line 114: Need an operator

"Makefile", line 116: Need an operator

"Makefile", line 118: Need an operator

"Makefile", line 129: Need an operator

 

If this is the case, you will need to run ‘gmake’ instead of ‘make’.  If the build process is going correctly, you will see output like this:

 

gmake[1]: Entering directory `/home/loki/src/listar/src/modules/bouncer'

gcc -fPIC -DDYNMOD -Wall -Werror -I../../inc -I. -DGNU_STRFTIME   -c bouncer.c

gcc -shared   -o bouncer.lpm bouncer.o

cp bouncer.lpm ../../build

gmake[1]: Leaving directory `/home/loki/src/listar/src/modules/bouncer'

[Build: bouncer] Built module successfully.

gmake[1]: Entering directory `/home/loki/src/listar/src/modules/listarchive'

gcc -fPIC -DDYNMOD -Wall -Werror -I../../inc -I. -DGNU_STRFTIME   -c archive.c

gcc -shared   -o listarchive.lpm archive.o

cp listarchive.lpm ../../build

gmake[1]: Leaving directory `/home/loki/src/listar/src/modules/listarchive'

[Build: listarchive] Built module successfully.

 

…and so on.  The actual text of your output may vary slightly depending on the system.  Assuming no build errors occur, you should end up with a final line that looks something like this:

 

gcc   -o listar alias.o command.o user.o parse.o list.o core.o forms.o smtp.o io.o regerror.o regsub.o regexp.o flag.o cookie.o file.o module.o fileapi.o variables.o internal.o cmdarg.o modes.o dynmod.o unmime.o codes.o hooks.o tolist.o mystring.o lma.o userstat.o snprintf.o moderate.o mysignal.o unhtml.o liscript.o submodes.o lcgi.o upgrade.o

 

If there are no linker errors, you now have all the binaries you need.  Type make install (or gmake install) and it will place all the Listar binaries into the appropriate places.  If you wish to run Listar directly from this location, it is now ready to go.  Otherwise, you need to copy things elsewhere.  If you are using the dynamic module mode (Listar’s recommended configuration), there is a directory under where you unpacked Listar which is called ‘modules’, and contains a number of files with an .LPM extension.  And in the directory where you unpacked Listar is a binary executable called listar.  The listar binary should be placed wherever you intend to have your Listar installation, along with the listar.cfg file.  The modules should be placed into a modules directory, which by default is a subdirectory called modules under wherever the listar binary is.  It is possible to split up Listar into a number of separate directories, however, as the Debian installation does.  At this point, you should have enough information to move along to section 3, Getting Started.

2.5 Compiling Under Windows

 

Listar can be compiled under Windows, but there are a few caveats.  First, it still functions as a mail filter, so you need a way to feed the mail to it; many Windows mail servers do not function in this way.  Secondly, it requires Microsoft Visual C++ 5.0 or higher to compile.

 

If these still meet your criteria, Listar is fairly easily compiled.  When you unpack the source tree, or do a CVS checkout, you will want to go to the top-level directory, and load the listar.dsw file.  Then you can simply go and do a batch build of all the targets.  In the end, you will have a debug and a release listar.exe, in src\debug\Listar.exe and src\release\Listar.exe.  You will also have src\modules\debug and src\modules\release, which will contain debug and release builds of all the LPM modules.  From here on out, Listar is configured like any of the UNIX installations.

 

There is also a commercially supported mailing list package for Windows which is based on Listar.  It is called SLList and is sold and supported by Seattle Lab, at http://www.seattlelab.com/.


3.0 Getting Started

 

3.1 Introduction

 

Most MLMs function as a mail filter – in other words, a program that is invoked when a piece of mail arrives for a specific address, and which is fed the mail that arrived.  How individual mail servers function with this varies; the widely-used package sendmail uses a file called aliases to determine things like this, while other packages such as qmail handle it differently.  We’ll cover a few generic pieces, and then a few specific mail servers.

 

3.2 Listar and Mail Filters

 

A list running on Listar has several addresses associated with it.  The list address itself (for example, foolist@domain.com), the list administrators (for example, foolist-admins@domain.com), and so on.  In addition, Listar has an address for itself (listar@mydomain.com).  Each of these addresses is represented by an alias.  The listar@mydomain.com address calls the Listar program without any parameters, while the individual list ones have various parameters.

 

Hence, when you set up the Listar aliases for your system, you’ll probably have a number of things looking like this:

 

# Listar address

listar:           |/home/listar/listar

 

# Testlist aliases

testlist:         |"/home/listar/listar –s testlist"

testlist-request:      |"/home/listar/listar –r testlist"

testlist-admins:      |"/home/listar/listar –admins testlist"

testlist-repost:      |"/home/listar/listar –a testlist"

testlist-bounce:      |"/home/listar/listar –bounce testlist"

 

This means that when some e-mail comes in for the ‘listar’ address, the mailserver would run the program /home/listar/listar and pass the contents of that e-mail to the program.  The ‘testlist’ address, for example, will also run the program, but it will have some additional parameters.  If the aliases look a bit confusing, don’t worry; Listar will generate them for you when you make a new list, but if your mailserver isn’t sendmail, you may have to edit the way the aliases look slightly.  Most mailservers use an alias format similar – or identical – to the sendmail format, so for most servers you will be able to use the aliases that Listar generates directly.

 

3.3 Sendmail

 

Sendmail (http://www.sendmail.org) is perhaps the widest used mail server on the Internet, and comes preinstalled on most UNIX-type systems.  Sendmail is extremely configurable – almost too configurable, as it is possible to get lost in the configuration options – and is more than capable of using Listar as a mail filter.

 

There are several ways to handle setting up Listar under Sendmail.  Perhaps the easiest is simply to copy and paste the aliases that you get from a Listar newlist.pl script into the Sendmail /etc/aliases file, and run the newaliases program.  Others may prefer to create a separate aliases file for Listar; the method to do this depends on how you’re setting up your sendmail config file.  The direct method is to go into the /etc/sendmail.cf file, find the line referring to /etc/aliases, and add AliasFile line below it for the Listar aliases file.

 

Perhaps the most common pitfall of people setting up new Listar installations – or indeed, any new mail filter under Sendmail – is the fact that many Sendmail installations come with a program called SMRSH already enabled.  SMRSH, or the SendMail Restricted SHell, is a program that increases system security by making sure that Sendmail only allows programs in a certain directory to be run as mail filters.  What this directory is varies depending on your Sendmail installation, but a common one is /etc/smrsh.

 

If any attempt to mail Listar meets with a bounce message like the following, you are using SMRSH.

 

----- The following addresses had permanent fatal errors -----

"|/home/listar/listar -s mylist"

     (expanded from: <mylist@mydomain.com>)

 

    ----- Transcript of session follows -----

sh: listar not available for sendmail programs

554 "|/home/listar/listar -s mylist"... Service unavailable

 

The solution is to locate the directory that SMRSH is using for its programs, and write a shell script like this, placing it there.

 

#!/bin/sh

/home/listar/listar $@

 

Of course, /home/listar should be the path where you installed the Listar binary.  It is also vitally important to make sure that this wrapper script is set executable so that smrsh can run it.  Also make sure that the directory leading up to the Listar binary has execute permissions for whatever user or group your mail server runs as.

 

Then you’d want to go and change the aliases so that they had the path to the shell script wrapper.  For example, changing

 

mylist:           |"/home/listar/listar –s mylist"

 

To

 

mylist:           |"/etc/smrsh/listar –s mylist"

 

Then Sendmail should allow Listar to be used as a mail filter.

 

3.4 Exim

 

Exim is another of the mail servers out there, though it doesn’t come preinstalled on many – if any – systems.  Information on it can be found at http://www.exim.org/.  Exim was developed at the University of Cambridge over in England.  To make Listar work with Exim, you could take the simple approach like with Sendmail and paste the Listar aliases into the existing Exim aliases file, or you can go into exim.conf and add the following lines:

 

listar_aliases:

  driver = aliasfile

  file_transport = address_file

  pipe_transport = address_pipe

  file = /usr/lib/listar/aliases

  search_type = lsearch

  user = listar

  group = listar

 

Other than that, Listar should function correctly with Exim out-of-the-box.


3.5 Postfix

 

Postfix (http://www.postfix.org) is another mail server, designed with the goal of creating a package as secure and fast as sendmail, while still providing as much backwards compatibility as possible.  For Postfix installations, you can once again take the simple route and paste the Listar aliases into the default aliases file and then run the postaliases program any time you change it.

 

If you wish to have a separate Listar aliases file, you will need to pull  /etc/postfix/main.cf up in your favorite text editor.  Find alias_maps line, and add the listar aliases file to it.  The resulting line will look something like:

 

alias_maps = hash:/etc/aliases, hash:/etc/mail/listar.aliases

 

Then run postalias /etc/mail/listar.aliases every time you add aliases to the Listar file.  Of course, /etc/mail/listar.aliases should be replaced by the path to where you keep your Listar aliases file.

 

3.6 qmail

 

The qmail (http://www.qmail.org) program is perhaps the second most widely used UNIX mail server on the Internet, being considered to be small, fast and secure.  However, the method of setting up qmail aliases is far different from setting up aliases under any other mail package.  Instead of a single file that contains multiple aliases mapping through to Listar, you need to create what are called dot-qmail files in the home directory of the qmail system user (often “alias”).

 

If the line in a normal aliases file would be:

 

mylist:           |"/home/listar/listar –s mylist"

 

then you would need to create a file in the home directory of the qmail system user.  This file would be named .qmail-mylist and which will contain the text |"/home/listar/listar –s mylist"

 

You could create such a file by going to the appropriate directory and typing:

 

echo "|/home/listar/listar –s mylist" > .qmail-mylist

 

In other words, for a line like:

 

address:          command

 

You want

 

echo "command" > .qmail-address

 

Unlike most mail servers, you do not need to run a program to rebuild aliases under qmail.


 

Listar’s internal newlist command can create dot-qmail files for a given list; to set up your Listar installation to do so by default, pull listar.cfg up in your favorite text editor, and add the following line:

 

newlist-qmail = yes

 

Then, when you create a list, it will have a subdirectory called qmail-aliases, and in that directory will be all the dot-qmail files you need to copy over to your qmail global aliases directory.

 

You can force this feature on by adding the command-line argument –qmail when creating a new list.

 

It is also worth noting that there is an optional add-on package for qmail by Dan Bernstein called FastForward (http://www.pobox.com/~djb/fastfoward.html) which allows qmail to use /etc/aliases.


 

4.0 Configuring the Server

 

4.1 Primary (Global) Config File

 

 


5.0 Setting up a List

 

5.1 Creating the List

 

Listar contains a set of commands internally to make it easier to create a list. This entire process can be invoked from the command line and easily controlled, and the various installed modules are responsible for generating the configuration file and documenting it, as well as any other custom handling for new list creation.

 

To begin this process, you will want to run the Listar binary with the command-line argument –newlist; this takes one parameter, the name of the new list. In addition, if you’re creating a list for a virtual host, simply put the virtual host config file at the beginning of the line. Listar determines what path to put in the aliases by what path you use when invoking it, so in this case be sure to run it with a full path name. Here are two examples:

 

/home/listar/listar –newlist testlist

/etc/smrsh/listar –c virthost1.cfg –newlist testlist2

 

Listar will prompt you for the e-mail address of the list administrator; this should be an address from which mail can be sent as well as received. Do not use a forwarding address for the primary administrator of the list. Once you’ve entered this information, the script will create the basic list configuration and basic list directory. Then it will give you a block of information that looks something like this:

 

# Aliases for list 'testlist'

testlist: "|/home/listar/listar -s testlist"

testlist-request: "|/home/listar/listar -r testlist"

testlist-repost: "|/home/listar/listar -a testlist"

testlist-admins: "|/home/listar/listar -admins testlist"

testlist-moderators: "|/home/listar/listar -moderators testlist"

testlist-bounce: "|/home/listar/listar -bounce testlist"

testlist-owner: joe@mydomain.com

 

You will want to put this information into your mail server’s alias file, and you may need to run a program to rebuild the aliases database (for example, Sendmail users will need to run the newaliases program).

 

As a side note for advanced users, all the output Listar gives in this mode OTHER than the aliases is on stderr, while the aliases are printed to stdout, thus making it easy to simply redirect output and append it to your aliases file.

 

If you have Listar set up to use qmail instead (see section 3.6), you will not get the block of aliases, but will instead find that in the directory of your new mailing list is a subdirectory called qmail-aliases; in this directory are the dot-qmail files you will want to copy over to your qmail global aliases directory.

 

5.2 Editing the List Configuration

 

Now, you doubtless want to go tune a few of the default settings in the list configuration file.  Go to the directory where you have your Listar lists stored, and go into the directory with the name of the list you just made.  Bring the config file up in your favorite editor, and edit to taste.  There is an appendix of configuration variables at the end of this document.

 

Section needs more detail.

 

Once you have things configured to your taste, you’re ready to move on to your first interaction with Listar!


6.0 Interacting with Listar

 

6.1 Concepts

 

Unlike many MLMs, Listar has something called a ‘list context.’  What this means is that, much like someone in a conversation, Listar remembers what the previous command in a session referred to.  If you tell it to do a command on list1 and then don’t give it a list name for the next command, it will assume you are still talking about list1.  If, however, you tell it to refer to list2 in the second command, it will do so.  How this works will become clearer as we move along.

 

Listar also has what is called a ‘secure’ mode.  Certain commands – such as administrative functions – must be performed through a method that prevents people from pretending to be you.  Some MLMs only check the address a message comes from before allowing administrative commands, leaving them open to easy hacking by a mail-spoofer.  Other MLMs use passwords, which could be discovered.  Listar uses a unique method which secures it in any situation but that where either the machine that Listar runs on has been compromised, or the e-mail account of an administrator has (something out of the realm of control of an MLM).  This method is referred to as “cookies.”

 

Listar’s cookies are used for more than just administrative modes, as well.  When a cookie is “baked,” (created by Listar) it has a specific “flavor.”  A cookie of one flavor cannot be used for a task requiring a different flavor – for example, a cookie for a user to confirm their subscription could not be used to authorize administrative commands.  If a cookie is used, it is “eaten” and cannot be used again.  If a cookie remains unused, eventually it goes stale and is removed from the cookie jar.  And lastly, a cookie can be baked for a specific person, and then only that person can use it.

 

It is the cookie system that allows Listar to have much of the security and power it does.

 

6.2 Normal Mode

 

Normal mode is how the majority of users interact with Listar.  This is where you send e-mail to the Listar server itself with a set of commands.  For example, a user might send a message like this.

 

Date: Tue, 28 Sep 1999 23:26:32 -0700 (PDT)

From: Joe Q. User <joe@someisp.com>

To: listar@mydomain.com

Subject:

 

lists

which

end

 

And Listar would send back a message like:

 

Date: Tue, 28 Sep 1999 23:27:27 -0700 (PDT)

From: Listar <listar@mydomain.com>

To: joe@someisp.com

Subject: Listar command results: lists

 

>> lists

Listar lists available on this machine:

 

testlist

          A test list.

 

>> which

Retrieving list subscriptions.

 

joe@someisp.com is subscribed to the following lists:

      testlist

 

>> end

Command set concluded.  No further commands will be processed.

 

---

Listar v0.126a - job execution complete.

 

In other words, each line of the message is parsed by Listar, which tries to find a valid command in it.  If there is a valid command in the subject line, it will use that instead of parsing the body (unless configured to ignore the subject line).  What commands are available vary depending on the Listar installation, since an LPM can add new commands.

 

Additionally, if you enclose what is called a “job/eoj wrapper,” Listar will ignore everything except what is between the beginning and ending of the wrapper.  (Multiple job/eoj wrappers can be used per message.)  This is useful for administrative functions, as you will see later.

 

// job

commands

// eoj

 

When a command takes a list as one of the parameters, it turns that into the list ‘context,’ and if you omit a list from the next command, it will assume you mean the same list as before.  When a command finally has another list given, it will change the context for following commands.  Whenever a command changes the list context, you will be told in the results list:

 

List context changed to 'testlist' by following command.

>> who testlist

Membership of list 'testlist’:

        joe@mydomain.com (ADMIN)

        jane@mydomain.com (ADMIN)

        joe@someisp.com

 

>> stats

Current account flags for 'joe@mydomain.com' on 'testlist':

 

        REPORTS

        CCERRORS

        ECHOPOST

        MODERATOR

 

List context changed to 'testlist2' by following command.

>> stats testlist2

Current account flags for 'joe@mydomain.com' on 'testlist2':

 

        ADMIN

        SUPERADMIN

        ECHOPOST

        REPORTS

        CCERRORS

 

 

>> who

Membership of list 'testlist2:

        joe@mydomain.com (ADMIN)

        joe@someisp.com

 

In the above example, the user (joe@mydomain.com) sent the commands:

 

who testlist

stats

stats testlist2

who

 

Now you know how to issue commands to Listar, but what commands can you issue?  Well, there are a great many of them, and they vary from installation to installation because of customization.  Luckily, there is a way to query Listar for what commands it supports.  If you send Listar the command commands, it will send back a list of what commands it supports on a given installation.  Some commands are only ever useful in messages Listar generates, such as for secured-mode messages.

 

6.3 Secure (Administrator) Mode

 

Obviously, there needs to be a way to issue administrative commands to Listar; it isn’t feasible to expect every user to have access to the files on disk that control a list they might potentially be an administrator on.  But it is equally obvious that it’s undesirable to have random unauthorized users able to issue administrative commands.  Clearly, some sort of authentication is needed.  Listar achieves this authentication with cookies, as mentioned before.

 

There are two ways to handle administrative commands, but they have the same end result.  The first method is to send Listar the command admin list.  If you are a valid administrator for list, Listar will send you what is called an admin wrapper.  This is something that looks like:

 

// job

adminvfy testlist 37F1C6FC:58BB.1:ybxvznvfbabgnxharg

 

adminend

// eoj

 

You want to fill out any administrative commands (things like getconf, or setfor, which require administrative permissions) between the adminvfy and adminend lines, and send the wrapper back to Listar.

 

The second method was added in a later version of Listar, and is more convenient in most cases.  Instead of sending the command admin list, send the command admin2 list, and then give it the commands you want in the wrapper followed by adminend2.  That will send back the wrapper already filled out, and you can simply hit ‘reply’ to approve it.  This is also where job/eoj blocks come in handy!  Picture receiving a note from a user (say, joe@someisp.com) which says that they need to be unsubscribed and can’t remember how.  You could simply reply and carbon-copy Listar, saying something like:

 

> Hey, sorry... I know I should know how to unsubscribe myself

> But...

> Could you unsubscribe me for me?

 

Sure!

 

// job

admin2 testlist

unsubscribe joe@someisp.com

adminend2

// eoj

 

Then you would receive back an already filled-out administrative wrapper such as:

 

// job

adminvfy testlist 37F1C6FC:58BB.1:ybxvznvfbabgnxharg

unsubscribe joe@someisp.com

adminend

// eoj

 

Listar can parse reply-formatted messages in many cases (the exceptions being the putconf command and moderated messages), so when you use the admin2 command, you can simply hit reply to the wrapper it generates.

 

Any commands that are listed with an (ADMIN) after them in the commands list that Listar will generate will only work between an adminvfy line and an adminend line.  Normal commands will also work between those lines, but some have different uses; for example, the stats command normally functions as stats list, to allow a user to view statistics on themselves for a list.  But in admin mode, you are locked to a specific list – the list you validated administrator permissions for – so the command you would enter instead is stats user, to allow an administrator to view stats for a specific user on that list.

 

6.4 Web Interface

 

Information on LSG/2 needs to go here (after LSG/2 is finished).


7.0 List Moderation

 

Information on moderating mailing lists.


8.0 Modules

 

Will give a listing of the default Listar modules (administrivia, etc.) and what they provide.

 


9.0 Example List Configurations

 

Some useful list configurations, like an announcement list or a connected set of lists like the nwcpp-discuss and nwcpp-announce lists, or the listar-support/listar-dev/listar-announce setup.

 


10.0 Writing Modules

 

Instructions on how to write a Listar module.

 


Appendix A: Config Variables

 

Note: The 'valid' field describes the Listar config files where that variable is valid. 'G' means the global config file, 'V' means a virtual host configuration file, and 'L' means individual list files.

ADMINISTRIVIA

Variable

Type

Valid

Description

administrivia-body-lines

integer

GVL

How many lines of the body to check for commands.

Example:
  administrivia-body-lines = -1

Default value is 6

administrivia-check

boolean

GVL

Should the administrivia check be enabled.

Example:
  administrivia-check = false

Default value is true

administrivia-regexp-file

string

GVL

File containing regexps used to detect if a user is sending list commands to the list instead of the request address, and bounce those messages to the moderator for handling.

Example:
  administrivia-regexp-file = admin-regexp

Default value is admin-regexp

ANTISPAM

 

 

 

 

Variable

Type

Valid

Description

allow-spam

boolean

GVL

Should we disable the antispam check for this list.

Example:
  allow-spam = false

Default value is false

antispam-blackhole

boolean

GVL

If we receive spam, should we simply eat it? (If 'no', then it is moderated.)

Example:
  antispam-blackhole = yes

Default value is false

spamfile

string

GVL

The file on disk which contains the regular expressions used to detect if a given sender is a spammer.

Example:
  spamfile = spam-regexp

Default value is spam-regexp

BOUNCE

 

 

 

 

Variable

Type

Valid

Description

bounce-always-unsub

boolean

GVL

Should the user be unsubscribed when more than max transient bounces have occured.

Example:
  bounce-always-unsub = false

Default value is false

bounce-max-fatal

integer

GVL

Maximum number of fatal bounces before action is taken.

Example:
  bounce-max-fatal = 10

Default value is 10

bounce-max-transient

integer

GVL

Maximum number of transient bounces before action is taken.

Example:
  bounce-max-transient = 100

Default value is 30

bounce-never-unsub

boolean

GVL

Should the user be unsubscribed when more than max fatal bounces have occured, or just set vacation.

Example:
  bounce-never-unsub = off

Default value is false

bounce-never-vacation

boolean

GVL

Should the user ever be set vacation for exceeding the maximum number of bounces.

Example:
  bounce-never-vacation = yes

Default value is false

bounce-timeout-days

integer

GVL

Length of time (in days) during which the maximum number of bounces must not be exceeded.

Example:
  bounce-timeout-days = 7

Default value is 7

bouncer-unsub-file

string

GVL

File under the list directory to send to a user when they are automatically unsubscribed by the bouncer.

Example:
  bouncer-unsub-file = text/bounce-unsub.txt

Default value is text/bounce-unsub.txt

bouncer-vacation-file

string

GVL

File under the list directory to send to a user when they are automatically set vacation by the bouncer.

Example:
  bouncer-vacation-file = text/bounce-vacation.txt

Default value is text/bounce-vacation.txt

CGI

 

 

 

 

Variable

Type

Valid

Description

cgi-template-dir

string

GVL

Directory for CGI gateway templates.

Example:
  cgi-template-dir = <$listserver-data>/templates

Default value is <$listserver-data>/templates

lsg-cgi-url

string

GVL

URL to the CGI script for the web interface.

Example:
  lsg-cgi-url = http://www.mydom.com/listserver

Default value is

COOKIES

 

 

 

 

Variable

Type

Valid

Description

expire-all-cookies

boolean

GV

Should we expire cookies for all lists on initial run? Should only be set to 'no' on installations with a huge (multi-thousand) number of lists.

Example:
  expire-all-cookies = yes

Default value is true

DEBUGGING

 

 

 

 

Variable

Type

Valid

Description

debug

integer

GVL

How much logging should be done.

Example:
  debug = 10

Default value is 0

logfile

string

GV

Filename where debugging log information will be stored.

Example:
  logfile = ./server.log

preserve-queue

boolean

GVL

Controls whether to remove queue file after processing.

Example:
  preserve-queue = yes

Default value is false

validate-users

boolean

GVL

Perform a minimal validation of user@host.dom on all users in the list's user file and log errors.

Example:
  validate-users = true

Default value is false

DIGEST

 

 

 

 

Variable

Type

Valid

Description

digest-administrivia-file

string

GVL

File on disk used to store digest administrative information.

Example:
  digest-administrivia-file = digest/administrivia

Default value is digest/administrivia

digest-alter-datestamp

boolean

GVL

Should digests use a different datestamp format.

Example:
  digest-alter-datestamp = on

Default value is false

digest-altertoc

boolean

GVL

Should this list use an alternate form for the digest Table of Contents.

Example:
  digest-altertoc = false

Default value is false

digest-footer-file

string

GVL

Filename for a footer file automatically included with every digest

Example:
  digest-footer-file = text/digest-footer.txt

Default value is text/digest-footer.txt

digest-from

string

GVL

Email address used as the From: header when the digest is distributed.

Example:
  digest-from = listname@host.dom

digest-header-file

string

GVL

Filename for a header file automatically included with every digest

Example:
  digest-header-file = text/digest-header.txt

Default value is text/digest-header.txt

digest-max-size

integer

GVL

Maximum size a digest can reach before being automatically sent.

Example:
  digest-max-size = 40000

Default value is 0

digest-max-time

duration

GVL

Maximum age of a digest before it is sent automatically.

Example:
  digest-max-time = 24h

Default value is 0s

digest-name

string

GVL

If digests are kept, what do we use as the name template for the stored copy of the digest.

Example:
  digest-name = digests/%l/V%V.I%i

digest-no-fork

boolean

GVL

Should digesting be done by forking a seperate process.

Example:
  digest-no-fork = true

Default value is false

digest-no-toc

boolean

GVL

Should digests exclude the Table of Contents entirely.

Example:
  digest-no-toc = TRUE

Default value is false

digest-no-unmime

boolean

GVL

Should posts in the digest not be unmimed.

Example:
  digest-no-unmime = off

Default value is false

digest-send-mode

choice

GVL

Mode used when sending digests daily via a timed job (usually around midnight of the host machine's time). 'procdigest' means that when that happens, the digest will be sent regardless of your time and size settings (which are still honored for normal posts). Time and size are self-explanatory; time means that it will only send if there's been more than digest-max-time elapsed, while size will only send if digest-max-size has been exceeded. digest-max-size and digest-max-time DO still apply when individual posts come across the list, even if procdigest is set; having digest-max-size set to 50000 and this variable to procdigest would mean that the digest would be sent when it exceeded 50k, or during the midnight automated run (perhaps the day's digest only reached 20k; it would still be sent).

Example:
  digest-send-mode = time

Default value is procdigest:|procdigest|time|size|

digest-strip-tags

boolean

GVL

Should subject lines of the messages in the digest have the list subject-tag stripped.

Example:
  digest-strip-tags = on

Default value is false

digest-to

string

GVL

Email addres used as the To: header when the digest is distributed.

Example:
  digest-to = listname@host.dom

digest-transient

boolean

GVL

Are digests removed completely after they are sent.

Example:
  digest-transient = off

Default value is true

digest-transient-administrivia

boolean

GVL

Should the digest administrivia file be removed after the digest is next sent.

Example:
  digest-transient-administrivia = true

Default value is false

no-digest

boolean

GVL

Should digesting be disabled for this list.

Example:
  no-digest = yes

Default value is false

FILEARCHIVE

 

 

 

 

Variable

Type

Valid

Description

file-archive-dir

string

GVL

Where are the archives for the list located.

Example:
  file-archive-dir = files

file-archive-status

string

GVL

Who is allowed to retrieve the file archives.

Example:
  file-archive-status = admin

Default value is open

GENERAL

 

 

 

 

Variable

Type

Valid

Description

error-include-queue

boolean

GVL

Should error reports contain the queue associated with that run

Example:
  error-include-queue = yes

Default value is true

no-command-file

string

GV

This is a global file to send if a message to the main listserver or request address has no commands.

Example:
  no-command-file = helpfile

Default value is listar.hlp

GLOBAL

 

 

 

 

Variable

Type

Valid

Description

config-file

string

GV

The name of the list-specific configuration file.

Example:
  config-file = config

Default value is config

deny-822-bounce

boolean

GVL

Should the RFC822 Resent-From: header be trusted for sender.

Example:
  deny-822-bounce = yes

Default value is false

deny-822-from

boolean

GVL

Should the RFC822 From: header be trusted for sender.

Example:
  deny-822-from = no

Default value is false

form-cc-address

string

GVL

Who should be cc'd on any tasks/forms that the server sends.

Example:
  form-cc-address = user2@host1.dom

global-blacklist

string

GV

Global file containing regular expressions for users who are not allowed to subscribe to lists hosted on this server.

Example:
  global-blacklist = banned

Default value is banned

hostname

string

GV

Hostname for URLs/addresses/headers

Example:
  hostname = lists.mydomain.com

ignore-subject-commands

boolean

GV

Should the server ignore commands in the subject line.

Example:
  ignore-subject-commands = false

Default value is false

listserver-address

string

GV

The email address for the listserver control account.

Example:
  listserver-address = listserv@myhost.dom

Default value is listar@localhost

listserver-admin

string

GV

The email address of the human in charge of the listserver.

Example:
  listserver-admin = user1@host2.dom

Default value is root@localhost

listserver-full-name

string

GV

The friendly name used to identify the listserver.

Example:
  listserver-full-name = List Server

Default value is Listar

reply-expires-time

duration

GV

How long until an automatic reply expires from the mailbox

Example:
  reply-expires-time = 3 h

Default value is 1 d

socket-timeout

duration

GV

How long should the server wait on reading a socket.

Example:
  socket-timeout = 5 m

Default value is 30s

LIST-SPECIFIC

 

 

 

 

Variable

Type

Valid

Description

admin-approvepost

boolean

GVL

Are posts by an administrator to a moderated list automatically approved.

Example:
  admin-approvepost = false

Default value is true

admin-silent-subscribe

boolean

GVL

If set true, when an admin subscribes a user to a list they will receive no subscription notification AND no welcome message.

Example:
  admin-silent-subscribe = no

Default value is false

administrivia-address

string

GVL

Address to which subscription/unsubscription attempt notifications should be sent.

Example:
  administrivia-address = mylist-admins@host.dom

administrivia-include-requests

boolean

GVL

Should the mail which caused the (un)subscription action be included in the message to the administrivia address.

Example:
  administrivia-include-requests = on

Default value is false

adminreq-expiration-time

duration

GVL

How long until administrative request cookies expire.

Example:
  adminreq-expiration-time = 3 h

advertise

boolean

GVL

Does this list show up as being available.

Example:
  advertise = false

Default value is true

allow-setaddy

boolean

GVL

Allow the use of the setaddy command to replace the subscribed address.

Example:
  allow-setaddy=no

Default value is true

approved-address

string

GVL

Address to which approved/rejected/modified moderated posts should be sent.

Example:
  approved-address = mylist-repost@myhost.dom

Default value is <$list>-repost@

blacklist-mask

string

GVL

Per-list file containing regular expressions for users who are not allowed to subscribe to the list.

Example:
  blacklist-mask = blacklist

Default value is blacklist

blacklist-reject-file

string

GVL

File sent to a user when their subscription or post is rejected because they are blacklisted.

Example:
  blacklist-reject-file = text/blacklist.txt

Default value is text/blacklist.txt

body-max-size

integer

GVL

Posts with a body larger than this in bytes will be moderated.

Example:
  body-max-size = 10000

cc-lists

string

L

A colon seperated list of local lists which recieve copies of all posts to this list.

Example:
  cc-lists = mylist1:mylist2

Default value is

closed-file

string

GVL

File sent to message author when the post is rejected because the list is closed.

Example:
  closed-file = text/closed-post.txt

Default value is text/closed-post.txt

closed-post

boolean

GVL

Is this list closed to posting from non-members.

Example:
  closed-post = true

Default value is false

closed-post-blackhole

boolean

GVL

Do messages submitted to a closed-post list by non-members get thrown away.

Example:
  closed-post-blackhole = yes

Default value is false

closed-subscribe-file

string

GVL

Filename of file to be sent if a user tries to subscribe to a closed subscription list.

Example:
  closed-subscribe-file = text/closed-subscribe.txt

Default value is text/closed-subscribe.txt

cookie-expiration-time

duration

GVL

How long until a generated cookie expires.

Example:
  cookie-expiration-time = 3 d 6 h

Default value is 1 d

default-flags

string

GVL

Default flags given to a user when they are subscribed.

Example:
  default-flags = |NOPOST|DIGEST|

Default value is |ECHOPOST|

description

string

GVL

Description of the list.

Example:
  description = This is my special list

faq-file

string

GVL

File on disk containing the list's FAQ file.

Example:
  faq-file = text/faq.txt

Default value is text/faq.txt

filereq-expiration-time

duration

GVL

How long until config file request cookies expire.

Example:
  filereq-expiration-time = 3 h

footer-file

string

GVL

Text to append to list messages.

Example:
  footer-file = text/reflector-footer.txt

Default value is text/reflector-footer.txt

force-from-address

string

GVL

If specified, this will be used as the RFC 822 From: address.

Example:
  force-from-address = list-admins@myhost.dom

form-show-listname

boolean

GVL

Should we use the list name (or RFC2369 name) instead of the listserver-full-name for forms on a per-list basis? (Like admin wrappers and such.)

Example:
  form-show-listname = yes

Default value is false

goodbye-file

string

GVL

File sent to someone unsubscribing from a list.

Example:
  goodbye-file = text/goodbye.txt

Default value is text/goodbye.txt

header-file

string

GVL

Text to prepend to list messages.

Example:
  header-file = text/reflector-header.txt

Default value is text/reflector-header.txt

header-max-size

integer

GVL

Posts with headers larger than this in bytes will be moderated.

Example:
  header-max-size = 2000

humanize-mime

boolean

GVL

Should the server strip out non-text MIME attachments.

Example:
  humanize-mime = true

Default value is true

humanize-quotedprintable

boolean

GVL

If set to true, attempt to remove any and all quoted printable characters from subject and body replacing them with their actual character.

Example:
  humanize-quotedprintable = true

Default value is false

info-file

string

GVL

File on disk containing the list's info file.

Example:
  info-file = text/info.txt

Default value is text/info.txt

list-owner

string

GVL

Defines an email address to reach the list owner(s).

Example:
  list-owner = list2-admins@hostname.dom

megalist

boolean

GVL

Should we process this list on-disk instead of in memory.

Example:
  megalist = true

Default value is false

moderated

boolean

GVL

Is this list moderated.

Example:
  moderated = yes

Default value is false

moderator-approvepost

boolean

GVL

Are posts by a moderator to a moderated list automatically approved.

Example:
  moderator-approvepost = false

Default value is true

moderator-welcome-file

string

GVL

File sent to a new moderator when they set MODERATOR.

Example:
  moderator-welcome-file = text/moderator.txt

Default value is text/moderator.txt

modpost-expiration-time

duration

GVL

How long until a moderated post cookie expires.

Example:
  modpost-expiration-time = 2 h

no-administrivia

boolean

GVL

Should the administrivia address be notified when a user subscribes or unsubscribes.

Example:
  no-administrivia = on

Default value is false

no-dupes

boolean

GVL

Should we track the Message-Id headers from incoming traffic to prevent duplicate posts to the list. Message-Id's expire after 1 day.

Example:
  no-dupes = off

Default value is true

no-dupes-forever

boolean

GVL

Should we never expire the Message-Id's.

Example:
  no-dupes-forever = yes

Default value is false

no-loose-domain-match

boolean

GVL

Should the server treat users of a subdomain as users of the domain for validation purposes.

Example:
  no-loose-domain-match = on

Default value is false

nopost-file

string

GVL

File sent to users flagged NOPOST if they submit a post to the list

Example:
  nopost-file = text/nopost.txt

Default value is text/nopost.txt

outside-file

string

GVL

File sent to message author when post is accepted to list but author is not a subscriber.

Example:
  outside-file = text/outside.txt

Default value is text/outside.txt

overquote-file

string

GVL

Filename under the list directory of the file sent to a user who fails an overquoting check. (See 'quoting-limit'.) This is the file retrieved with 'getconf overquote'.

Example:
  overquote-file = text/overquote.txt

Default value is text/overquote.txt

owner-fallback

boolean

GVL

Should the list-owner be used if administrivia-address is not defined when notifying of (un)subscribes.

Example:
  owner-fallback = true

Default value is false

paranoia

boolean

GVL

Are the various list config files allowed to be edited remotely for this list.

Example:
  paranoia = yes

Default value is false

password-failure-blackhole

boolean

GVL

If true, a post to a password list that doesn't have the correct password will be eaten. If false, it will be sent to the moderators.

Example:
  password-failure-blackhole = yes

Default value is true

password-implies-approved

boolean

GVL

If true, a correct use of X-posting-pass automatically preapproves the message. Useful if you want to have a moderated list and allow preapproved functionality through the use of the password.

Example:
  password-implies-approved = yes

Default value is false

per-user-modifications

boolean

GVL

Do we do per-user processing for list members.

Example:
  per-user-modifications = false

Default value is false

post-password

string

GVL

If specified, all incoming messages must have an X-posting-pass: header with this password in it.

Example:
  post-password = NeverBeGuessed

post-password-reject-file

string

GVL

File sent to submitters to a password protected list if they don't include the posting password header.

Example:
  post-password-reject-file = text/postpassword.txt

Default value is text/postpassword.txt

precedence

string

GVL

The precedence header which will be included in all traffic to the list.

Example:
  precedence = bulk

Default value is bulk

quoting-limits

boolean

GVL

If true, posts to the list will be checked for overquoting.

Example:
  quoting-limits = yes

Default value is false

quoting-line-reset

boolean

GVL

If quoting-limits is on, should the count of quoted lines be reset if the user places their own text in the message? (This has the effect of making it so that quoting-max-lines is the total number of lines that can be quoted at once IN A BLOCK, instead of in the entire message.)

Example:
  quoting-line-reset = yes

Default value is true

quoting-max-lines

integer

GVL

If greater than 0 and quoting-limits is true, this is the maximum number of lines allowed to be quoted from a previous message.

Example:
  quoting-max-lines = 10

Default value is 10

quoting-max-percent

integer

GVL

If greater than 0 and quoting-limits is true, this is the maximum percent of the message allowed to be quoted from a previous post.

Example:
  quoting-max-percent = 15

Default value is 0

quoting-tolerance-lines

integer

GVL

If greater than 0, this is the number of lines that must be exceeded in the total message before the quoting percentage limit will be applied. It would be silly to have a 25% quoting limit and have a three-line message be rejected because two lines were quoted.

Example:
  quoting-tolerance-lines = 7

Default value is 7

reply-to

string

GVL

Address which will appear in the Reply-To: header.

Example:
  reply-to = list@myhost.dom

reply-to-sender

boolean

GVL

Forcibly set the Reply-To: header to be the address the mail came from.

Example:
  reply-to-sender = false

Default value is false

rfc2369-archive-url

string

GVL

The URL for use in the List-archive: RFC 2369 header.

Example:
  rfc2369-archive-url = ftp://ftp.myhost.dom/lists

rfc2369-headers

boolean

GVL

Should RFC 2369 headers be enabled for this list.

Example:
  rfc2369-headers = on

Default value is false

rfc2369-list-help

string

GVL

URL to use in the RFC 2369 List-help: header.

Example:
  rfc2369-list-help = http://www.mydom.com/list/help.html

rfc2369-listname

string

GVL

The name of the list to use in the RFC 2369 List-name: header.

Example:
  rfc2369-listname = Mylist

rfc2369-minimal

boolean

GVL

Should only the minimal set of RFC 2369 headers be emitted.

Example:
  rfc2369-minimal = true

Default value is false

rfc2369-post-address

string

GVL

The mailto to be used in the RFC 2369 List-post: header. The special value of 'closed' will show the list as closed in that header.

Example:
  rfc2369-post-address = myname@myhost.dom

rfc2369-subscribe

string

GVL

If specified, this overrides the default generated RFC2369 List-subscribe value.

Example:
  rfc2369-subscribe = mailto:listar@listar.org?subject=subscribe%20listar-support

rfc2369-unsubscribe

string

GVL

If specified, this overrides the default generated RFC2369 List-unsubscribe value.

Example:
  rfc2369-unsubscribe = mailto:listar@listar.org?subject=unsubscribe%20listar-support

send-as

string

GVL

Controls what the SMTP from is set to.

Example:
  send-as = list2-bounce@test2.dom

strip-headers

string

GVL

A colon seperated list of headers to remove from outgoing messages.

Example:
  strip-headers = X-pmrq:X-Reciept-To

strip-mdn

boolean

GVL

If true, strip all read-reciept (mail delivery notification) headers from mail before sending out.

Example:
  strip-mdn = on

Default value is true

subject-required

boolean

GVL

If set to true, then any post sent to the list without a subject will be made moderated.

Example:
  subject-required = yes

Default value is false

subject-tag

string

GVL

Optional tag to be included in subject lines of posts sent to the list.

Example:
  subject-tag = [MyList]

submodes-file

string

GVL

File containing list specific customized subscription modes.

Example:
  submodes-file = submodes

Default value is submodes

subscribe-acl-file

string

GVL

File containing regular expressions against which a user's address will be matched when they try to subscribe to a list. If an address does not match at least one, subscription is denied. Can be gotten with 'getconf acl'.

Example:
  subscribe-acl-file = subscribe-acl

Default value is subscribe-acl

subscribe-acl-text-file

string

GVL

Textfile to be sent to a user who fails the ACL subscription check. Can be gotten with 'getconf acl-text'.

Example:
  subscribe-acl-text-file = text/subscribe-acl-deny.txt

Default value is text/subscribe-acl-deny.txt

subscribe-mode

choice

GVL

Subscription mode for the list.

Example:
  subscribe-mode = open

Default value is closed:|closed|confirm|open|open-auto|

subscription-acl

boolean

GVL

If 'true' and the file given in 'subscribe-acl-file' exists, a subscription access list check will be performed when users attempt to subscribe to the list.

Example:
  subscription-acl = true

Default value is true

subscription-expiration-time

duration

GVL

How long until subscription verification cookies expire.

Example:
  subscription-expiration-time = 5 d

tag-to-front

boolean

GVL

If set to true and there is a subject tag for the list, it will be removed and moved to the beginning of the line (before any 'Re:'s). If not set, any duplicate Re:'s will still be removed, and the subject-tag will be moved after the Re:.

Example:
  tag-to-front = no

Default value is true

tolist-send-pause

integer

GVL

How long (in milliseconds) do we sleep between SMTP chunks.

Example:
  tolist-send-pause = 30

Default value is 0

union-lists

string

L

A colon seperated list of local lists whose members can post to this list even if it is closed.

Example:
  union-lists = mylist1:mylist2

unsubscribe-mode

choice

GVL

Unsubscription mode for the list.

Example:
  unsubscribe-mode = closed

Default value is open:|closed|config|open|open-auto|

unsubscription-expiration-time

duration

GVL

How long until unsubscription verification cookies expire.

Example:
  unsubscription-expiration-time = 5 d

verbose-moderate-fail

boolean

GVL

When a moderator approves a message but it is rejected, should the message in question be included in the rejection note?

Example:
  verbose-moderate-fail = yes

Default value is true

welcome-file

string

GVL

File sent to new subscribers of a list.

Example:
  welcome-file = text/intro.txt

Default value is text/intro.txt

who-status

choice

GVL

Who is allowed to view the list membership.

Example:
  who-status = admin

Default value is private:|admin|private|public|

LISTARCHIVE

 

 

 

 

Variable

Type

Valid

Description

archive-world-readable

boolean

GVL

Should we make all archive files world-readable?

Example:
  archive-world-readable = yes

Default value is true

mbox-archive-path

string

GVL

Path to where MBox format archives are stored.

Example:
  mbox-archive-path = archives/mylist/mbox

mh-archive-path

string

GVL

Path to where MH format archives are stored.

Example:
  mh-archive-path = archives/mylist/mh

LOCATION

 

 

 

 

Variable

Type

Valid

Description

lists-root

string

GV

Location of the directory containing all the list info.

Example:
  lists-root = lists

Default value is <$listserver-data>/lists

listserver-conf

string

G

The path to the listserver configuration files.

Example:
  listserver-conf = /usr/local/mylists/configs

Default value is <$path>

listserver-data

string

GV

The path to the listserver data root.

Example:
  listserver-data = /usr/local/mylists/data

Default value is <$path>

listserver-modules

string

G

The path to the directory containing the LPM modules.

Example:
  listserver-modules = /usr/local/lists/modules

Default value is <$path>/modules

listserver-root

string

G

The path to the root of the Listserver installation

Example:
  listserver-root = /usr/local/listserver

Default value is <$path>

LSG/2

 

 

 

 

Variable

Type

Valid

Description

lsg2-cgi-url

string

GV

No description

lsg2-cookie-duration

duration

GV

No description

Default value is 15 m

MAINTENANCE

 

 

 

 

Variable

Type

Valid

Description

listserver-bin-dir

string

G

When creating a new list, what directory do we prepend to the binary name when we make the aliases (if not set, defaults to the path the binary was run with).

Example:
  listserver-bin-dir = /home/list

newlist-qmail

boolean

G

When creating a new list, do we need to make dot-qmail aliases?

Example:
  newlist-qmail = no

Default value is false

MIME

 

 

 

 

Variable

Type

Valid

Description

humanize-html

boolean

GVL

Should HTML attachments be converted to plaintext

Example:
  humanize-html = no

Default value is true

pantomime-dir

string

GVL

Directory on disk to store binary files placed on the web via PantoMIME.

Example:
  pantomime-dir = /var/www/listar/html/pantomime

pantomime-url

string

GVL

URL corresponding to pantomime-dir

Example:
  pantomime-url = http://www.listar.org/pantomime

rabid-mime

boolean

GVL

Should ABSOLUTELY no attachments, EVEN text/plain, be allowed

Example:
  rabid-mime = no

Default value is false

unmime-forceweb

boolean

GVL

Should all attachments (even text/plain) be forced to the web (pantomime-dir and pantomime-url must be set or all will be eaten)

Example:
  unmime-forceweb = yes

Default value is false

unmime-quiet

boolean

GVL

Should the listserver report when it strips MIME attachments.

Example:
  unmime-quiet = no

Default value is false

MODERATION

 

 

 

 

Variable

Type

Valid

Description

moderate-include-queue

boolean

GVL

Should moderated messages contain the full message that triggered moderation?

Example:
  moderate-include-queue = yes

Default value is false

moderate-notify-nonsub

boolean

GVL

Should posts from non-subscribers be acked if they are moderated.

Example:
  moderate-notify-nonsub = true

Default value is false

moderator

string

GVL

Address for the list moderator(s).

Example:
  moderator = foolist-moderators@hostname.dom

PASSWORD

 

 

 

 

Variable

Type

Valid

Description

allow-site-passwords

boolean

GV

Are sitewide passwords allowed.

Example:
  allow=site-passwords = false

Default value is false

password-expiration-time

duration

GV

How quickly to auth-password cookies expire.

Example:
  password-expiration-time = 2 d

Default value is 1 h

SMTP

 

 

 

 

Variable

Type

Valid

Description

full-bounce

boolean

GVL

Should bounces contain the full message or only the headers.

Example:
  full-bounce = false

Default value is false

mailserver

string

GV

The name of the outging SMTP server to use.

Example:
  mailserver = mail.host1.dom

Default value is localhost

max-rcpt-tries

integer

GV

How many times to attempt reading a RCPT TO: response.

Example:
  max-recpt-tries = 3

Default value is 5

sendmail-sleep

boolean

GV

Should we attempt to sleep a short time between message recipients.

Example:
  sendmail-sleep = on

Default value is false

smtp-queue-chunk

integer

GVL

Maximum recipients per message submitted to the mail server. Larger lists will be split into chunks of this size.

Example:
  smtp-queue-chunk = 25

smtp-socket

integer

GV

Which socket should the SMTP server be contacted on.

Example:
  smtp-socket = 26

Default value is 25

sort-tolist

boolean

GVL

Should the recipients be sorted by domain before sending. This is memory expensive and is a bad idea if your SMTP server already does this sorting. If you SMTP server doesn't do this, it can really improve outgoing mail performance.

Example:
  sort-tolist = off

Default value is true

TEMPBAN

 

 

 

 

Variable

Type

Valid

Description

tempban-default-duration

duration

GVL

If an administrator issues the tempban command without a duration, this default will be used.

Example:
  tempban-default-duration = 7 d

Default value is 7 d

tempban-end-file

string

GVL

Filename of file to be sent to a user who was tempbanned when the tempban expires.

Example:
  tempban-end-file = text/tempban-end.txt

Default value is text/tempban-end.txt

tempban-file

string

GVL

Filename of file to be sent to a user when an admin issues the tempban command on them.

Example:
  tempban-file = text/tempban.txt

Default value is text/tempban.txt

VACATION

 

 

 

 

Variable

Type

Valid

Description

vacation-default-duration

duration

GVL

If a person sends the vacation command without a duration, how long they will be set vacation.

Example:
  vacation-default-duration

Default value is 14 d

Miscellaneous Settings

 

 

 

 

Variable

Type

Valid

Description

task-no-footer

boolean

GVL

No description

Default value is false

 

 


Appendix B: Common Files

 

Useful Listar files; config files, etc.

 

 


Appendix C: Useful Resources

 

Links to useful things; the Listar mailing list archives, RFCs, etc.