On Wed, 7 Feb 2001, Good, Donald wrote:

> Just to show that these "wish" features are never quite so simple:

Strictly speaking, what is being requested is not a new feature; it is a
request to manually initiate an existing Listserv process.  I hope Lsoft
will seriously consider it.

> What should happen to a pending subscription where the confirmation request
> is successfully delivered to an alternate but valid address (maybe thru
> forwarding), and the subscriber replies OK with the confirmation reply
> returning the true address, different from the original subscription
> address?

The same thing that happens now.  No request for confirmation can be
confirmed from a different e-mail address (with the only exceptions being
the List Owner and Postmaster).

> Should the subscription fail or should the original subscription address be
> changed?

It should fail regardless of whether the request to confirm is initiated
by a list header (Subscription= Open,confirm), as it is now, or manually
by a List Owner.

If Lsoft granted access to List Owners to initiate an ADD-confirm, I would
insist that it be the default method to be used by all List Owners when
manually adding subscribers to a mailing list -- I hope they would
provide a list header (Add-confirm= Yes|No) or make "add-confirm" part of
the existing Default-Options.  Some advantages:

1. I would get less complaints from off campus sites when a faculty member
comes back from a conference with his or her list of a few thousand e-mail
address to add to a mailing list; many of which aren't even readable and
get guessed at anyway.  The list owner would be far less frustrated as
well.

2. Reduction of bounces/errors. Bad addresses that cannot be confirmed
just don't get added period and don't get *any* subsequent list mail (that
currently waits for the auto-delete or list owner to take action). This
seems to me to be far more efficient.

3. The list header or default-option above could turn the confirmation off
for internal course mailing lists or in cases where subscribers are added
from an internal database with valid addresses.

4. Reduction of complaints from on and off campus; this isn't listserv's
job, but the side benefit would be that our policy of not adding
subscribes to mailing lists without their explicit permission would come
closer to a reality. Currently, they get added, receive much list mail,
and need to complain before they are removed.

5. Reduce bounce/error traffic significantly as more listserv sites used
add-confirm when adding subscribers manually.

6. It would reduce the trouble shooting time spent by list owners who do
currently add incorrect addresses which are forwards to correct addresses;
it puts the onus on the subscribers for providing correct addresses that
they can indeed confirm.

My thoughts in support of this access.

--Trish

> -----Original Message-----
> From: Landy Manderson [mailto:[log in to unmask]]
> Sent: Wednesday, February 07, 2001 2:56 PM
> To: [log in to unmask]
> Subject: Re: Forcing a confirmation email with SUBSCRIBE command
>
>
> I agree with this, from a slightly different angle.  Even if the addresses
> that the owners have are valid as far as getting mail *delivered* to the
> recipients, they do not always match up with the From: address actually
> emitted by those recipients' clients.  This inevitably causes problems
> down the road when they try to send or reply to the list, and we end up
> having
> to resubscribe them or add their alter-ego address separately with NOMAIL.
>
> On Wed, 7 Feb 2001 15:34:58 -0500 Kevin Parris said:
> >I think it would be nice if the ADD command had an option to trigger the
> > "confirmation" process rather than simply placing the user on the list and
> > sending a notification.  For some lists being setup here, the owner wants
> to
> > ADD everybody rather than sending out subscribe instructions, and
> sometimes
> > their collections of email addresses have some inaccuracies - and as the
> LSMTP
> > postmaster I wind up getting the delivery error reports.  Not a really
> great
> > big huge deal, I suppose, since the owner gets a report too - but having
> only
> > the confirmation item failing instead of all the list traffic (since some
> bad
> > addresses don't 'fail' until the 5-day retry expires) would reduce the
> scope
> >of
> > my annoyance somewhat.
>