For lists coded "
Subscription= Open", you can require confirmation on all new subscription requests, thus ensuring that LISTSERV has a clear mailing path back to the subscriber. In the past, a user could send a subscription for an open subscription list to LISTSERV, which upon acceptance would immediately start sending the user list mail. If the user was located behind a "broken" or one-way gateway, this produced immediate bounced mail until the list owner noticed and deleted the subscription. Note that requiring confirmation at the time of subscription does not guarantee that the clear mailing path will continue to exist permanently.
"Subscription= Open,Confirm" makes LISTSERV send a Command Confirmation Request to the potential subscriber before actually adding the user to the list. The subscriber is requested to reply to the request by sending a validation "cookie" back to LISTSERV (this "cookie" being the hexidecimal number pulled from the subject line).
The Command Confirmation Request, while straightforward, has the potential to cause confusion if users do not read carefully the instructions that make up the request. LISTSERV expects confirmation codes to be sent in a specific way because some mail gateways add lines to the header of the message that LISTSERV doesn't understand. If a user forwards the request back to LISTSERV, or creates a new mail message to send the 'cookie' back, it usually will not work correctly. The sequence should be as follows:
Note: If a list owner adds a user manually, the confirmation process is bypassed.
The LISTSERV maintainer or the list owner may specify subscribe-time defaults for many subscriber options by using the "
Default-Options=" keyword. This keyword takes regular SET options as its parameters. Examples include:
You may have more than one "Default-Options=" line in your header, as needed.
If setting "Default-Options=" for an existing list, you will probably want to issue
QUIET SET commands for existing subscribers, particularly if you are defaulting an option such as
REPRO. Setting "
Default-Options=" will not affect current subscribers.
Any Default-Options that you set are applied to non-subscribers. This is particularly useful if you want to run a public list but disallow non-subscribers from posting, or at least force their mail to go through a moderator first. For the former you could code "
Default-Options= NOPOST", and for the latter, "
Default-Options= REVIEW". These settings would also apply to new subscribers, and the latter particularly can help you ensure that the people who join your list are legitimate and haven't just joined the list so they can spam it.
Note: Any default topics are set with the "
Default-Topics=" keyword. See the
List Keyword Reference document for details on this keyword.
You can code subscription renewal into your lists. This is one method to keep lists "pruned down" and avoid having large lists that are actually distributing mail to only a fraction of the users. For instance, you may have a number of subscriptions set to NOMAIL for one reason or another. NOMAIL user(a) may have forgotten that he has a subscription; user(b) may have set NOMAIL instead of unsubscribing; user(c) may no longer exist because she graduated or no longer works for the service provider; you may have set user(d) to NOMAIL because of recurrent mail delivery errors. Requiring a periodic confirmation of subscriptions is therefore a reasonable course of action for large, non-private lists.
where interval is a period of time such as Weekly, Yearly, 6-monthly, or something similar, and Delay(number) is an integer corresponding to how many days LISTSERV will wait for the renewal confirmation to arrive. (See the
List Keyword Reference document for more information on renewal and delay periods.)
The confirmation request mailing asks the subscriber to send the command CONFIRM listname back to LISTSERV. If the subscriber does not do so within a certain length of time, LISTSERV automatically deletes the subscription. The default delay time is 7 days. If you wish to use the default delay time, it is not necessary to code Delay() into your Renewal parameters.
Note: You may wish to increase the delay time to accommodate users whose subscriptions expire over holidays (such as the Christmas/New Year's week) in order to avoid accidental deletions. Also, be aware that confused subscribers can and will send the CONFIRM command back to the list, rather than to LISTSERV. LISTSERV's default filter will catch these commands and forward them to the userid(s) defined by the "
Errors-To=" keyword.
to LISTSERV. (Remove the brackets around "QUIET" if you want to use the
QUIET option. The brackets indicate that
QUIET is an optional part of the command.) It is most advisable to do this in the case of redistribution lists, as they broadcast the renewal notice to their users, who a) cannot renew the subscription and b) become very confused when they see the notice, often sending "what does this mean?" mail to the list.
LISTSERV creates a daily report on its subscription renewal activities, telling you what users were requested to confirm subscriptions, and what users were deleted for failing to confirm the renewal request. This report is sent to the "Errors-To=" address for the list. A typical subscription renewal monitoring report is reproduced below:
