Your first question probably relates to the 'listserv' user not having
enough process quota to handle what it's doing.  The likelihood is that
a malloc() call requested more memory than was available, failed, and
LISTSERV crashed.  In such a case it is unfortunately not possible to
write anything more to the log, and unless you have a core file to
run dbx against, it would be impossible to find out exactly what happened.
So I would check the process quota limit for the 'listserv' user and
raise it if necessary.

There were also some changes in the release code for 1.8d that would
address the "dying without a trace" problem.  These changes came relatively
late and if you are still running a beta, you should definitely upgrade
to the release version.  But you should also check the process quota
limit.

Your second question can be answered fairly simply--even if someone <does>
masquerade as someone else, and makes changes to their settings, the
command response goes to the legitimate user, who is immediately aware
that something has happened.  So note carefully that such a hack would
not occur in a vacuum.  You could also set "Validate= Yes" in the list
header so that SET commands would require either a password or an OK
confirmation.  I don't really see how checking the Received: headers
for relay information would help much; for instance I send a lot of
LSOFT.COM mail through an offsite mainframe, and some other LSOFT.COM
mail through a local ISP.  If you were to check the headers on my mail
it would look like almost all of it was masqueraded, unless you happened
to know that I regularly mail through those particular sites.

Nathan