> >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.