>Date: Sat, 15 Feb 1997 16:57:52 -0500
>To: listmom-talk@skyweyr.com
>From: Grant Neufeld <gneufeld@ccs.carleton.ca>
>Subject: MailList Specification Headers Proposal 0.0.9
>Cc: list-managers@GreatCircle.COM, net-thinkers@rthumper.vmeng.com,
> mida-mail@list.peter.com.au
>
>Discussion Paper; Version 0.0.9; February 15, 1997
>It is expected that by implementing a standard format for list server
>identifier headers, mail client software developers could implement
>interface features to make mail list control easier for users (when the
>headers are present). For example, GUI mail client could potentially
>offer buttons to un/subscribe, get list info, or switch to digest mode.
>
>For systems requiring mailback authentication to confirm subscriptions
>(and/or other commands), it would be useful to standardize the mailback
>message format - or at least provide a header which gives instructions
>the client application can use to provide a confirmation interface to
>the user (E.g., Dialog saying: "Confirmation request received for
>subscription to MAIL-LIST. Do you wish to accept the subscription?").
>
this would be a gross misfeature.
the whole point (of my lists) using a confirmation is to show that
a) the recipient actually read the instructions, rented 1 or 2 clues
during their lifetime, and demonstrate they can operate their own email
competently enough to create and send a message to a specified address.
(i for instance explicitely state they CANNOT use a reply and send
back a whole copy of the document).
having clients be able to automate the confirmation at the 'push of
a button' places us back into the user-didnt-actually-need-a-clue mode.
b) the confirmation also, in my mind, gives some marginal legal protection in
that they read and understood the disclaimers and copyright notices, etc.
the automation approach would certainly (again in my mind) remove any
legal value of the confirmation.
this whole feature smacks of the 'bulking up' that is claimed to want to
be avoided. creeping misfeaturism.
a general point about the whole approach of using HEADERS. how are forgeries
and spoofing avoided? do HEADERS get PGP or other authentication in most
mail systems?
the whole automation thing smells.
if a person joining an *EMAIL* forum isnt expected to have token competence
at using *EMAIL* then we are about to embrace another round of 'the dumbing
of the internet'
if providers want to give trivial interfaces, that's what web-publishing
is for.
the web is graphical, push-button, fill out this hand-held form type of
interface -- even for email interfaces.
trying to *directly* make email and other tools have the look and feel of
the web is wasted energy, and will ultimately attract the same audience
quality.
yes, i'm an elitist. i believe people should be forced to rub two neurons
together for *some* tools. email is one of them.
just imagine, people not having to read their email to use email.
harumph.
if you insist on this route, make the headers secure and verifiable. giving
spammers and pranksters more automation will just create listmanagers more
work in the long run.
- Ken Dykes, Thinkage Ltd., Kitchener, Ontario, Canada [43.40N 80.48W]
kgdykes@thinkage.on.ca postmaster@thinkage.com
harley-request@thinkage.on.ca metallica-request@thinkage.on.ca
http://www.thinkage.on.ca/~kgdykes/
Follow-Ups:
|
|
