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