Gosh, LSTSRV-L is now very very near to be as hectic as MAILBOOK! Oh well...
Drew:
LISTSERV cannot "guess" that [log in to unmask] is CLVM. If you
could send a more detailed description of the problem I might be able to find a
solution. And please let's not start this "To upcase, or not to upcase?"
discussion again... Thanks :-)
Nick:
Actually LISTSERV has two purposes depending on why you installed it. You can
either have installed it for local business only, ie local lists, and in that
case you may want to disable DISTRIBUTE and it would be JUST LOGICAL because
that's not why you use the server. The file server functions can be very very
useful for local node purpose and I got requests from people at our node about
creating a server which could send files only to a certain category of people
for internal use -- just after I had finished 1.5d ;-) Each lab will soon be
able to have his own private files on the server and they'll be automatically
maintained by whomever. We found it to be a hassle to process requests like
"please put this file on our lab's com-disk" -- "oops, bug in the file I sent,
please put this one back" -- "you did a typo in the filename, it's MRE2G3D not
MER2G3D" (not kidding, that's the kind of names for their programs!!!). They'll
soon PUT the stuff themselves et voila. Of course you might not be interested
in the file server functions for local use.
If you've installed LISTSERV to interact with the network it's different. The
main goals become:
1) Provide efficient, reliable, non-looping mailing list functions (including
non-mail file distribution to a list)
2) Provide easy-to-use, powerful remote-control for the above.
3) Provide any kind of thing that may help cutting down on network load, be it
related to mail items or not. This include DISTRIBUTE, file server functions
as used in the NETSERV-cache application, etc.
You can disable the file server functions by (1) not creating any filelist
and (2) disallowing users to define themselves a password. All that they'll be
able to do is request information files/tools which they'd be able to obtain
via the INFO command. If necessary I could add an option to restrict the INFO
command to local users, etc. I perfectly understand the concern of those
people who have installed the server for local use only and are getting a bit
worried about interaction with the network.
Valdis, Harold:
No problem, you'll have a quiesce-distribute command in the next release.
ARPA lists:
Go on and create the lists, I think it could be a good start. We can always
switch to DISTRIBUTE later.
Richard:
Maybe you could locate the culprit by looking into a map and determining
where the file was stopped, more or less, and then looking for nearby servers.
Or maybe resend a dummy 1-line file to the same list with ACK=MAIL. I myself
always use ACK=MAIL and never had any problem so far although the files were
3,000+ records; however it's very easy to run into a problem if one of the
servers gets logged off for some reason and its spool is purged, etc.
Eric
|