On 7 Jan 2000, Russ Allbery wrote:
> The scheme of using their e-mail address and checking against the
> subscriber list reduces to using their e-mail address as a password. It's
> not necessary to join a mailing list to know the e-mail address of one of
> the subscribers; there are other ways of obtaining that information, down
> to someone just happening to mention in public that they're on a
> particular mailing list and making some guesses about what address they
> would be subscribed as.
But the dillema faced by some of us of which I haven't seen discussed is
one where you have public mailing list archives (like in support of a
software product, as in my case). 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).
Currently what we have resorted to is munging the headers via a function in
MHonArc to add a string, so that at least you couldn't auto-harvest the
addresses, but it would be easy to compensate <sigh>. 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). 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.
In my head, I have thought of a better solution, to somehow have a "entry
gate where they enter their email addresses and click 'ok' to a notice
saying that they will not harvest the email addresses. Thus a
dynamically-generated URL (w/ cookie) is created and is sent to the email
address with an expiry date of 2-3 hours. Thus the general public can view
the archives with relative ease, and while it's not bullet-proof in the
case of spamming (nothing is, IMO), it at least balances that concern with
public access.
But it would be a hard thing to bring together (as an Apache Module
perhaps?)
I am curious to hear how others have dealt with this, and if they have any
other ideas...
Best Wishes - Peter
| Peter Losher | SysAdmin - Nominum, Inc. | [EMAIL PROTECTED] |
