If one is "just" a list-owner, then it is sometimes useful to set the
list to full moderation e.g.,

SEND= EDITOR,HOLD,CONFIRM

EDITOR= list_owner_addy

FREE the list, then you can usually make some sense as to what is
occurring before messages are distributed.

If everything appears to be OK (and you do "OK" the messages) you can
resume your normal SEND= parms.

/Pete

At 09:03 09/15/2003 Monday, Siksai, Anthony N (Noel) wrote:
 >A list gets held for various reasons...I've held lists because of
 >subscriber addresses causing mail loops that only I can release.  Usually
 >it means the list's daily message allotment (threshold) has been exceeded
 >and LISTSERV is now holding messages to the list.  This can be caused by
 >SPAM, virus traffic (i.e. Sobig.F) and other such things.  Before
 >releasing the list, check the LISTSERV spool (/var/spool/listserv on UNIX
 >machines) and check the .jobh listings using jobview.  If they're all spam
 >or virus traffic, it's best to move them out of the queue before freeing
 >the list.  I usually check the queue first, then if I need to flush the
 >queue, I stop LISTSERV (this can take a bit if there are lots of pending
 >jobs), then move the .jobh files for the held list into a different queue
 >(I use /var/spool/listserv.oops) then restart LISTSERV and then free the
 >list.  After LISTSERV restarts, I monitor the log file for a bit so that I
 >can see what's getting distributed to that list so that I can re-hold it
 >if needed.  You should be able to free the list without admin assistance
 >by typing "free <listname>" under the "execute a LISTSERV command" area of
 >the web interface, however, if the hold was placed either by LISTSERV or
 >the LISTSERV administrator, you won't be able to override it and free the
 >list.  If you're not the administrator, I'd strongly caution you to check
 >with the adminstrator prior to trying to free the list yourself.