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

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

Should the RFC822 From: header be trusted for sender.

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

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

The email address for the listserver control account.

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

The friendly name used to identify the listserver.

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

How many lines of the body to check for commands.

Should the administrivia check be enabled.

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.

Should we disable the antispam check for this list.

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

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

Does this list show up as being available.

The name of the list-specific configuration file.

Default flags given to a user when they are subscribed.

Description of the list.

Hostname for URLs/addresses/headers

Should the server ignore commands in the subject line.

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

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

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

Should the messages produced by the server have a footer with version information

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

Maximum number of fatal bounces before action is taken.

Maximum number of transient bounces before action is taken.

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

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

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

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

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

Directory for CGI gateway templates.

URL on the associated web server pointing to the LSG/2 cgi wrapper.

The length of time that cookies for the LSG/2 web form should last.

Does LSG/2 need to run in Microsoft IIS-compatible mode? (Likely breaks other webservers.)

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.

How much logging should be done.

Filename where debugging log information will be stored.

Controls whether to remove queue file after processing.

Perform a minimal validation of [email protected] on all users in the list's user file and log errors.

File on disk used to store digest administrative information.

Should digests use a different datestamp format.

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

Filename for a footer file automatically included with every digest

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

Filename for a header file automatically included with every digest

Maximum size a digest can reach before being automatically sent.

Maximum age of a digest before it is sent automatically.

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

Should digesting be done by forking a seperate process.

Should digests exclude the Table of Contents entirely.

Should posts in the digest not be unmimed.

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).

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

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

Are digests removed completely after they are sent.

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

Should digesting be disabled for this list.

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

Should we never expire the Message-Id's.

Should error reports contain the queue associated with that run

Where are the archives for the list located.

Who is allowed to retrieve the file archives.

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

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

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

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

File on disk containing the list's FAQ file.

Text to append to list messages.

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

File sent to someone unsubscribing from a list.

Text to prepend to list messages.

File on disk containing the list's info file.

File sent to a new moderator when they set MODERATOR.

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

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

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

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'.

File containing list specific customized subscription modes.

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'.

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

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

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

File sent to new subscribers of a list.

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

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

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

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

Should we make all archive files world-readable?

Path to where MBox format archives are stored.

Path to where MH format archives are stored.

Location of the directory containing all the list info.

The path to the listserver configuration files.

The path to the listserver data root.

The path to the directory containing the LPM modules.

The path to the root of the Listserver installation

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).

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

Should HTML attachments be converted to plaintext

Should the server strip out non-text MIME attachments.

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

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

URL corresponding to pantomime-dir

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

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

Should the listserver report when it strips MIME attachments.

Should we assume that all list directories are valid or should we perform checks

Is this list closed to posting from non-members.

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

If this is true and enforced-addressing-to is enabled, posts that fail the check will be simply eaten. Otherwise, they will be marked for moderation.

If this is set, this address must be in the To or Cc field of a post to the list. Usually, you would set the list address here.

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

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.)

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

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

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:.

Who is allowed to view the list membership.

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

Should moderated messages contain the full message that triggered moderation?

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

Is this list moderated.

Address for the list moderator(s).

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

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.

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.

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

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

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

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

Are sitewide passwords allowed.

How quickly to auth-password cookies expire.

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

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

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

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.)

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

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.

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.

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

Should RFC 2369 headers be enabled for this list.

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

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

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

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.

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

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

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

Should bounces contain the full message or only the headers.

The name of the outging SMTP server to use.

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

Controls what the SMTP return path is set to.

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

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

Which socket should the SMTP server be contacted on.

How long should the server wait on reading a socket.

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

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

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

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

Subscription mode for the list.

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.

Unsubscription mode for the list.

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

How long until administrative request cookies expire.

How long until a generated cookie expires.

How long until config file request cookies expire.

How long until a moderated post cookie expires.

How long until an automatic reply expires from the mailbox

How long until subscription verification cookies expire.

How long until unsubscription verification cookies expire.

Should we process this list on-disk instead of in memory? This disables the receipient list sorting and list-merging functionality of Ecartis, in order to prevent large memory footprint operations. It is useful for lists where the receipient list is too large to effectively do memory-based operations on.

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

Do we do per-user processing for list members.

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.

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

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