The best value for "Loopcheck=" is no  value, ie edit the list header and
remove the string "Loopcheck= Nobody". Any other value apart from "Full",
which  is the  default,  means that  some  or all  of  the loop  checking
routines are  disabled. "Nobody"  means that LISTSERV  is not  allowed to
look  into the  message body  to  decide whether  or not  something is  a
delivery error; it is to rely solely  on the 'Subject:' field. As you can
imagine, this  is a very dangerous  option: it means that  any mailer not
using one of the "standard" subjects known to LISTSERV will cause a loop.
"None" is  even worse,  it tells LISTSERV  that, by  definition, anything
that reaches its reader is NOT a delivery error. These two options should
never be used unless the list is moderated. Even if the list is moderated
they are  not recommended, especially  if the  moderator is not  the list
owner  (ie administrator).  I  actually regret  having implemented  these
options, it really scares me to  think that people are using them without
knowing what they do.
 
"Notocount" means that LISTSERV should not  count the 'To:' fields in the
message body and decide  it is seeing a delivery notice  if there are too
many; "MaxTo(nnn)" orders it to allow up to the specified amount of 'To:'
fields, the default is 10. This  is the one sub-option of the "Loopcheck"
keyword that can be useful - for  digests. The code that counts the 'To:'
field  is here  as a  kind  of "last  resort" action  anyway, to  prevent
infinite loops, but  it won't stop the redistribution of  the first 'nnn'
nastygrams.  If  you disable  this  routine  it  means loops  can  become
infinite, but it  doesn't have any effect on the  actual detection of new
loops.
 
Finally, the latest  addition, "NoCRC", means you don't  want to suppress
duplicate messages on the list, ie if RSCS at FOO becomes crazy and sends
you 200 copies of the same posting, as it happened for LSTSRV-L, INFO-VAX
and many other lists about 6 weeks ago, you will happily redistribute the
200 copies. I added  this option as a kind of  "emergency bypass" in case
the  new  code  that  detects  such duplicates  should  break  and  start
rejecting  all postings.  Fortunately this  did  not happen,  so you  can
forget about it.
 
  Eric