>
>Thanks to all for the comments and detailed explanations.
>Subscription by
>owner is not going to be as simple as I thought -- I'll
>discuss it with my
>other list owners and see if we want to undertake it.
>

I beg to differ with most of the others on this issue.  I've actually found
a way to have pretty much the best of both worlds.  It's a bit lengthy so if
you're not interested in reading a long post I suggest you switch off now.
If you ARE interested, please read on....

I use LISTSERV 1.8d on NT and have a list that is set up for access via
email or the web interface.  I've coded into the header SUBSCRIPTION=BY
OWNER and VALIDATE=YES.  When a user attempts to subscribe via email I
receive the notification and the user is *not* asked to confirm it, which is
the normal course of events.  However, if they were to do the same thing
through the web interface, they *are* sent an 'OK' confirmation.  Once they
confirm it, then I get the notification of their request.  If they don't
confirm it I don't get notification.  (Note: if you want the same thing to
happen it may be affected by what you have set in the option
WEB_BROWSER_CONFIRM= in the site.cfg file.)  This has the fortunate effect
of verifying the that the user has a valid email address even before I see
their request to join.

Now, having followed this discussion with great interest I did some further
investigation and testing.  The keyword VALIDATE= is the important one to
look at here.  Appendix B (List Keyword Parameters, p.243) of the Site
Managers manual states that VALIDATE can be used to force an 'OK'
confirmation for various commands that don't normally require them.  The
combinations of VALIDATE=ALL,CONFIRM and VALIDATE=ALL,CONFIRM,NOPW *will*
force an 'OK' confirmation on a regular SUBSCRIBE command sent via email.
In testing this proved to be the case and also had no effect on the
subscription via web interface I described above.  The thing to keep in mind
is that both VALIDATE=ALL,CONFIRM keyword combinations will force 'OK'
confirmations on *any* command that causes a change of state to a
subscription (SET, CHANGE, SUB, SIGNOFF, etc).  Considering the context of
this discussion, that isn't such a bad idea to have anyway.

So, this means that I can still have absolute control over who subscribes to
my list *and* I can verify their email address before they join.

That's my two bob's worth.

Chazzozz!!

Michael Shannon
Webmaster
[log in to unmask]

"Before you can grow old and wise you must first survive being young and
stupid." - Ancient Proverb

Note: Opinions expressed on this list are my own and do not reflect the
views, opinions or position of my employer.  If swallowed, seek medical
advice.