LSTOWN-L Archives

LISTSERV List Owners' Forum

LSTOWN-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Thu, 16 Sep 1999 20:14:56 -0400
text/plain (43 lines)
Thought I might run both of these concerns past the list:

Listserv v.1.8.d
SunOS 5.5.1 sun4m Sparc10
Sendmail v.8.9.3

There have been a number of occassions where the lsv process has stopped for
no apparent or tracable reason.
There is no record of a stop command being issued in ~/listserv/listerv.log.
There is no unusual activity associated with mail or the server at or around
the time of the stoppage.
Each time, the last record in the log is a distribution from another list to
subscribers here. Checks on the maillog indicate that the mail was
successfully distributed to those subscribers:
            15 Sep 1999 21:38:39 Distributing mail ("PLANT-TC")
this list also produces a fair bit of traffic and as such it being recorded as
the last action taken by listserv prior to dying could be mere coincidence.
The only difference in behaviour that I have noted over the past few weeks is
that the secondary child process for lsv is often delayed in starting, but I
am not sure why this child process starts at all so I am not sure if this is
connected to the problem or not.
I am going to script a check to restart if the lsv process is missing. But I
would like to know if anyone else has such problems on occassion, and if so,
did they ever find the cause.

Secondly, it seems that listserv will only check the From: field in the SMTP
envelope on any message for subscriber validation. This makes it relatively
easy to masquerade an address on any mailer program that will allow you to
manipulate the header, allowing actions to be taken on someone else
subscription regardless of whether the list is open or closed. It is not
secure enough. Is this the only field that listserv checks in the header for
subscriber validation? And, is there any means to force a check on the relay=
section of the header instead to identify this kind of attack?

Thank you.
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
------------------------------------------------------------

ATOM RSS1 RSS2