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