thanks Nathan,

>===== Original Message From LISTSERV list owners' forum
<[log in to unmask]> =====
>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.
On a 256K Sparc10 machine we have 4053 maximum processes per userid with a max
number of processes of 4058, at the most there are around 120 - 150 processes
running at any single time (parent and child and probably a few zombies from
ftp sessions) during busy times, the machine is not thrashed and cpu usage is
low, even for a Sparc10. Most processes involve system processes or sendmail,
which usually has a max of about 40 or so at a time. Shared memory settings
are 67108864 max segement size (1 minimum), 128 shared memory identifiers and
16 max attached shm segments per process.

Do any of these settings not match what is required for listserv? Or better
yet, is there any documentation that lists minimum requirements for processes?

Only other thing I can think of is the minimum resident memory and swapable
memory for avoiding deadlock which are both set to 25 (dont know if this is
the area you were thinking of as well though). Most other settings are set to
infinity, including mapped memory, core file size, file size and cpu time.
I am not sure which other setting/s I should be looking at.


>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.
Definitely running full version 1.8d

>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.
It was not so much the setting of subscription options that was of concern,
but the posting to the list of irrelevant spam by people who have obtained a
subscribed e-mail address through whatever means.

I will suggest both setting changes to the list owners, although I can see
where a number of our lists will not support an ok confirmation for their
subscribers for postings due to the nature of the subscribers themselves, but
that should be a minority.


>Nathan
thanks again.

ICoS

------------------------------------------------------------
This e-mail has been sent to  you  courtesy of OperaMail,  a
free  web-based  service  from  Opera  Software,  makers  of
the award-winning Web Browser - http://www.operasoftware.com
------------------------------------------------------------