Since nobody else has answered this part, I'll tackle it.  All of these
should be in the LSTSRV-L archives as part of the announcements of the
LISTSERV releases that introduced them, but I'm doing it from memory
and examination of the code, so please forgive (and correct) me if I get
any of them wrong.
 
>9. I need a short description of each of the following headers:
>   DAILY-THRESHOLD: (default value 50)
 
This sets a limit on the number of messages that may be sent to the list
during a single day (by all users combined).  It can be useful if a list
gets into a loop that bypasses LISTSERV's extensive loop-detecting
heuristics, or just to throttle back the volume.
 
>   EDITOR-HEADER: (default value yes)
 
This controls whether mail sent to the editor (for Send= Editor lists)
includes some prose at the top like the following.
  'This message was originally submitted by' fromid 'to the' listname 'list at'
  node'. If you simply forward it back to the list, it will be distributed with
  the paragraph you are now reading being automatically removed. If you edit
  the contributions you receive into a digest, you will need to remove this
  paragraph before mailing the result to the list. Finally, if you need more
  information from the author of this message, you should be able to do so by
  simply replying to this note.'
If the list is merely moderated, you probably want this heading prose.
If it is digested, you probably don't.
 
>   INDENT: (default value 40)
 
This is the number of columns allowed for list addresses in the response
to the REVIEW command.
 
>   LIST-ID: (default value userid of list)
 
This allows users to refer to a list with a name other than the real name
of the list.  For example, there is a group of peer lists redistributing
the Internet list Info-IBMPC.  Most of the peer lists are named IBMPC-L,
but our peer is named $$INFOPC (for historical reasons).  All carry the
List-ID INFO-IBMPC, so a potential subscriber may send SIGNUP INFO-IBMPC
to any LISTSERV and have the request sent to the appropriate LISTSERV
even though a list literally named INFO-IBMPC could not exist on any
VM/CMS system (since it's over 8 characters).
 
>   LOOPCHECK: (default value FULL)
 
This controls which of the loop-detecting heuristics are used for this
list.  Sorry, I don't have time to compile a complete list of options.
The important ones are FULL and NONE, with meanings that should be
obvious.
 
>   MAIL-VIA: (default value DIRECT - what is the difference btw DIST and DIST2)
 
There are really only two meaningful values, anything starting with DIST
and anything not starting with DIST.  The former send mail along the
LISTSERV backbone with the DIST2 protocol to be dropped off along the
way.  The latter sends mail directly to each destination site.  DIST...
is almost always more efficient for lists with significant non-local
subscriber lists.
 
>   NEWSGROUPS:  (default value bit.listserv.userid of list)
 
This has meaning only if the list is gatewayed to the usenet/netnews
system, in which case it controls where the messages appear there.
 
>   PRIME: (default value YES)
 
This controls whether mail for the list is processed during "prime time"
(which is locally definable) or waits for "non-prime time".  This can
be useful for controlling the load placed on your system by LISTSERV's
handling of the list during periods of heavy local use.
 
>   SENDER: (default value LIST)
 
This controls what value (if any) is placed in the Sender: header field
of messages from the list.  This is one of the most controversial "knobs"
in LISTSERV.  If you leave it at the default value LIST, error messages
will be sent back to the list (by properly operating mail systems).
 
Usually, LISTSERV's heuristics will catch the messages and send them to
the Errors-To= address(es) for the list.  Unfortunately, due to the
endless inventiveness of mail system authors, some error messages may
be missed by the heuristics and sent back to the list, including the
address which caused the error, thereby causing another error, another
missed error message to the list, and a mailing loop which is visible
to every subscriber.  When that happens, the Internet purists point out
that the rules say that Sender: should always point to a human who can
fix the problem, not to an automated process like a list.
 
On the other hand, if you set Sender= (and thus Sender:) to some other
value, you will alienate the many users of Rice MAIL/MAILBOOK (and quite
probably other mail reading systems) who may be relying on Sender: to
determine which list sent the mail (and perhaps where to save it).
I know you will alienate me, especially if you set a number of lists to
point to the same address.
 
>   SIZELIM: (default value taken from sysvar mailmaxl - can this be greater
>             than mailmaxl?)
 
I'm not sure what will happen in this case.  The originating LISTSERV
will allow SIZELIM>MAILMAXL at the point it checks for a SIZELIM, but the
mail may fail at some later point.
 
I hope the above is of some help.
 
Mark R. Williamson, Rice U., Houston TX; [log in to unmask] or @RICEVM1