At 12:07 AM -0800 1/8/2000, Peter Losher wrote:
> Our organization uses those mailing
> lists as a form of support ("Check the archives, as your question may have
> already been asked, before subscribing/posting to the list itself") The
> problem lies in that we just can't restrict access to these archives to
> subscribers; that negates a valuable resource to the user that may be able
> to get a quick answer to his question via the archives rather than spend
> time subscribing to the list, and then searching (or to ask the question
> on the list itself).
In a case like this, there are a couple of ways you can deal with it.
First, you can do what Apple does with it's Tech Info Library, which
is to have a staff that converts issues into technical articles and
stuff them into a large, searchable knowledgebase. Since it's no
longer unedited e-mail, addresses become a moot point. On the
negative side, there's the cost/staffing issue, but you can end up
with a much higher quality content base (and you can better handle
quality/accuracy/political issues)
Second, the public archives could (or actually, should) be set up
such that e-mail addresses are suppressed. That's the direction I'm
heading for my web archives. The unauthorized space won't have e-mail
addresses available. You could, I guess, go one step further and
remap addresses such that they can be mailed to through your server,
so mailing can be monitored and cut off if needed, and such that a
user is avaialble for mailing but the address isn't disclosed. That'd
be a fun engineering project, similar to what some of the anonymous
remailers have done.
> We have thought
> about just removing the addresses in the header, but there may be
> situations where someone would want to contact someone on the list
> directly (which is why we went the munging direction).
two sets of archives? One for list members only?
> This solution is
> also incomplete - it doesn't take care of the addresses that show up in
> .sig's or in the body of a message.
Yeah. It gets real fun, real fast....
> Thus a
> dynamically-generated URL (w/ cookie) is created and is sent to the email
> address with an expiry date of 2-3 hours.
I know of an organization that's done this, in fact, although for
software distributions, not e-mail, but the concept is the same (how
do you distribute beta software under NDA and know who's downloaded
it and who hasn't? And who's leaked their password to the rumor
boards?)
> But it would be a hard thing to bring together (as an Apache Module
> perhaps?)
I don't think it'd be that tough. At the least, you can put the
archives behind a security realm with a password that updates ever N
time units, and users can request the current password to be e-mailed
them. That way, you'd have a log of everyone who's accessed, and
could log which files they downloaded as well, and they couldn't futz
with the validation in other than the standard ways (AOL screen
names, hotmail accounts, etc...) that you really can't control anyway.
--
Chuq Von Rospach - Plaidworks Consulting (mailto:[EMAIL PROTECTED])
Apple Mail List Gnome (mailto:[EMAIL PROTECTED])
Pokemon is a game where children go into the woods and capture furry
little creatures and then bring them home and teach them to pit fight.
