> When I ask anyone who knows about cgi they all say it is because that
> particular bit of data (userid/passwd) is handled by a GET, this drops it
> into the url and hands it as arguements to wa, leaving it able to be
> bookmarked.

That is not correct. I know because I wrote the code in question and, if it
helps, my CV says "security expert" (which is what I was known for when
I last updated it 12 years ago). You can also check for yourself by viewing
the source of the login page. You will find that it says:

<form action="&+SCRIPT;" method=post>

> The real security problem is that I can
> bookmark pages inside the product that I SHOULDNT be able to.

You can bookmark any page from your browser and there is nothing
LISTSERV can do to prevent it. However, bookmarking the page does not
cause any particular problems. Mailing your bookmark file to someone
else before the authentication ticket has expired could be a problem.
Note again that you can configure LISTSERV to only accept authentication
tickets from the IP address at which they were issued, if you do not mind
preventing people behind a firewall from using the service.

> why does this list exist if the
> advice you receive is not based on fact?

Well, none of us knows everything, and those who can best answer a
given question are not necessarily available instantly.

> and the password for the list owner can be gained by
> running that bookmark through a passwd cracker,

Uh? All you need to run a dictionary cracker is the URL to the login
page, which is hardly a secret. The bookmark would not help you crack
the password in any way because it is just a random number with no
relationship whatsoever to the input data. Think of it like a cloakroom
ticket, the cloak attendant gives you a ticket number with which he can
find your cloak again, but the number has no relationship to the number
on your membership card.

> Does the product allow me to bookmark pages that THE PRODUCT
> shouldn't allow me to bookmark?

No. The product was designed so that you could bookmark any page and
get expected results, rather than requiring you to start your journey from a
specific login page and click to the desired destination every time. There are
a few exceptions, for instance you cannot bookmark a login page or a page
in which you input a lot of data, but these are technical restrictions we cannot
do much about. The trade-off between GET and POST is that POST pages
cannot be bookmarked (well you can, but they do not work when recalled).
We could have made the whole interface use POST exclusively and tickets
would not be bookmarked, but you would also not be able to bookmark your
current location to return to it without having to click through all the menus.

  Eric