On Sun, 26 Aug 90 18:02:22 O Eric Thomas said:
>>Once again, it's time for me to complain about this ridiculous
>>"Validate= All commands" behavior.
>
>David, this is not the default setting. If you don't like it, don't
I never use this option at my site, but many lists to which I belong do.
And a few times I have waited weeks and sent repeated requests before
being removed from a list.
>specify it explicitly. "Validate= All" means you want your list to be
>safe, which in turn means that a hacker should not be able to add or
>delete people, period. What do you do if, tomorrow morning, you find out
But a hacker CAN add whomever he wishes as things now stand.
>that the 5 most important local lists you had (you know, the ones with
>important people at your site, people at the level of your boss's boss)
>no longer have 50 subscribers but instead point to LINKFAIL@BITNIC, and
>the relatively confidential note your boss's boss posted to it in the
>morning was distributed to the world? You wouldn't like that to happen,
>would you? Well that's what "Validate= All" and "Subscription= Closed"
>are for. It doesn't make sense for all lists, but for some lists it is
>desirable.
I love the "Subscription= Closed" parameter. It will prevent the above
situation. "Validate= All" won't help here at all.
>>I could easily send mail that looks like it comes from ERIC@SEARN, and
>>it would be automatically be distributed to all list members.
>
>That's if the list is "Send= Public", which doesn't match the "profile" I
>have described above.
But Mignon's list (and many others with "Validate= All") DO have it.
>>I could subscribe to the list (and 100 other lists as well) as "Stubborn
>>Mule" <ERIC@SEARN> so that Eric would be flooded with mail.
>
>That's again if the list is "Subscription= Open", which doesn't make much
>sense for "Validate= All".
But that's what many lists have. I would guess that most people who receive
ownership of a list don't understand the impact of many of the list header
keywords. This is probably true of many Listserv postmasters as well. And
so, list headers are probably copied from one list to another at a site
without much attention to the less noticeable parameters such as "Validate".
The "Validate= All" as it now works doesn't do much to stop a nefarious
hacker. Moreover, it creates a situation in which a user may be powerless to
get off a list or stop receiving mail from a list. There must be a better way.
Eric doesn't seem receptive to the idea of adding the personal password as
another legitimate password for making changes in a "Validate= All" list,
so I'll try another idea: in this type of situation, Listserv sends a
request for confirmation:
From: Listserv@XYZ
To: listmember@node
A request to SIGNOFF list ABC-L has been received from your userid.
List ABC-L requires command confirmation. To confirm this SIGNOFF,
send the following to LISTSERV@XYZ:
CONFIRM SIGNOFF ABC-L a86d765
where "a86d765" is some unique string that Listserv has generated and stored
along with the pending command. The only way the hacker could fake this is
by intercepting the person's incoming mail as well. After all, in the present
situation, how does the list owner know if a SIGNOFF request is genuine or
not? If the owner automatically executes all commands, the "Validate= All"
is not needed, otherwise the owner must confirm with the requestor. With my
new suggestion, confirmation is automated.
David
|
