Ken Dykes wrote:
> >From: Grant Neufeld <gneufeld@ccs.carleton.ca>
...
> >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?").
(note that the above paragraph was in the discussion section of the
proposal, not in the actual implementation or syntax - it was just a point
for consideration)
> 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.
In that case, you would choose to not implement support for such a feature
on your lists.
However, for me the reason for using mail-back confirmation is to confirm
that the subscription request was for a valid email address and that the
user actually intended to subscribe.
Using a system as suggested above would in no way compromise my purposes,
and would make things easier for my end users.
The list specification headers proposal provides a number of individual
tools which can be individually deployed by list hosts (at their
discretion) to make things easier for their end users who may use the
client software which is being enhanced to support the proposal.
> 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.
Again, in such a case you would choose to not implement a protocol as
suggested above.
However, since the paragraph you quote above from the discussion document
was just a note about an idea, there remains a lot of room to shape it to
meet needs such as some of those you describe.
The disclaimers and copyright (etc.) notices could be required to be
presented to the user in a dialogue which gives them the options of either
accepting or not the requirements for use (much like many installer
programs now present the license agreement with an Accept/Decline choice
before installing the software).
> this whole feature smacks of the 'bulking up' that is claimed to want to
> be avoided.
Actually, the "standardize the [confirmation] mailback message" section is
not really part of the proposal - which is why it's in the 'discussion'
section instead of the Syntax or Implementation. It's just an idea that is
somewhat related to the proposal, so mentioned there so it won't be
forgotten in the consideration of the structuring of the list specification
headers.
> 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?
Nope. Spoofing is an issue we're discssing now on the list-header list. A
formal resolution has not been reached, but when it has, it will be
included in the specification.
Do you have any security implementation suggestions (I'm not even remotely
an encryption/signature expert)?
> the whole automation thing smells.
Like a rose to me ;-) (sorry, couldn't resist)
> 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'
This isn't about 'dumbing' the internet. It's about making it smarter so
that humans can spend more time using it as a useful tool than worrying
about getting their command syntax straight.
This is part of making computing accessible and easier for everyone,
including the "elite" and "idiots" and all the rest.
> if providers want to give trivial interfaces, that's what web-publishing
> is for.
(don't get me started on how broken the web is...) Just because the web can
be applied as a useful tool doesn't mean that we should leave email in its
archaic form.
Would you have unix constrained to a text only interface so that only the
'really tough' could use it? Personally, I like the convenience of X, it
shields me from having to issue commandlines all the time when I'd rather
be working (not that I don't get a thrill from a good commandline... )
> 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.
The tools are evolving, as they always have. The secret ways of 'the elite'
are transformed into (hopefully) useful tools for 'the masses'. (sorry, I
should have put a cheeze warning before that last sentence ;-)
> yes, i'm an elitist.
I'm an anti-elitist, but I hope you won't let that prevent you from
continuing to contribute your thoughts on this proposal.
> i believe people should be forced to rub two neurons
> together for *some* tools. email is one of them.
I adamantly disagree. As my roommate just put it, by that reasoning, people
using telephones should have to do the switching manually.
Tools are supposed to make things easier, not harder.
Email is a tool not a test of technical skill.
> just imagine, people not having to read their email to use email.
Sounds good to me - I'd love to be able to escape my daily burden of
trudging through the piles of email :-S (a problem which I foolishly
continue to contribute to by doing things like this proposal which
stimulate more piles of mail in response...)
> 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.
That depends on how we list managers secure our systems. If you don't want
to secure your lists against misuse of the headers, don't use them. If your
users don't want to use them, they can still read the instructions and
issue commands manually.
This proposal won't take away any of your existing "tools for elitism", but
if you choose to use some or all of the headers, they should make it easier
for some of your users to use your lists - giving them more time to focus
on producing content for the list (or doing other productive things).
--
gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*>
Follow-Ups:
References:
|
|
