Thanks for those who took the trouble to educate me - flame or otherwise.
 
I see that confirmation can help on bad addresses.
 
Correct me if I am wrong if the following:
 
User sends subscribe.  Welcome message goes out.
 
If Welcome message bounces, bad address.
If Welcome message does not bounce, good address.
 
With the confirm option, the supposition is that if the user  was  able  to
confirm,  then it was a good address.  Hence a) the confirm message did not
bounce, b) it actually got to the user, and c) the user then knew  what  to
do  with  the  confirm message.  Yeah, maybe that is a bit (or byte) better
than simply looking for the bounced Welcome message.
 
Can't listserv be taught to look for bounces, and automagically unsubscribe
bounced  (or  set nomail or maybe a new set bounced).  Such a feature might
be a bit too automagical, but from the FLAMES back at me, I  would  suspect
that  such  a feature would do a good bit more to helping manage lists than
the confirm feature to reduce the load of bad addresses.
 
Since listserv's inception, ease of use and efficiency of network load have
been  major design goals.  Mabye confirm is a point in the right direction,
but the proof of that would be to know how many 'bounced' it avoids.
 
I suspect that the load of bounces (bad addresses) is far greater due to
 
a) user goes away and account is cancelled (renewal helps quite a lot here)
 
b) some new mailer option/upgrade/etc screws up previously correct addresses
   (confirm certainly would not help on the recent MCI stuff, right?)
 
but a couple of you seem to feel/think/have_facts otherwise.
 
Hence LONG LIVE confirm, and let's make the default confirm.  Then at least
users get used to it.
 
And if confirm is a step in the right direction, maybe we need a few more
steps.
 
Bob
 
P.S.
 
john riehl wrote:
>Second, at USCVM, we have had (and still have) a number of lists of
>interests of groups of people that others love to harass.  Confirmation
>prevents people from subscribing under an alias merely to sending
>harassing mail.  Flame off.
 
I don't see how the alias problem is solved but maybe that is in the
definition of an 'alias' - maybe it does solve it for some 'alias' attempts
but certainly not for *real* harassers.
 
 
--
 
        *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
        #   Economics Working Paper Archive is now operational    #
        #   Send a mail message (empty body)                      #
        #   To: [log in to unmask]                         #
        #   Subject: get announce                                 #
        #                                                         #
        #gopher econwpa.wustl.edu   http://econwpa.wustl.edu/     #
        *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*--------------------------------------------------------------------------*
| Bob Parks                                          Voice: (314) 935-5665 |
| Department of Economics, Campus Box 1208             Fax: (314) 935-4156 |
| Washington University                                                    |
| One Brookings Drive                                                      |
| St. Louis, Missouri 63130-4899                   [log in to unmask]
*--------------------------------------------------------------------------*