Subscription= Open [,Confirm]

Subscription= By_Owner[,Confirm]

Subscription= Closed


This keyword defines whether or not new users are allowed to subscribe to the list, and if not, whether their subscription requests are to be forwarded to the list owner or not.  The various options are as follows:

Open:

New users are allowed to subscribe to the list.



Open,Confirm:

Before new users are allowed to subscribe to the list they must confirm their address with an "OK" response. No list owner intervention is required.



By_Owner:

New users are not allowed to subscribe, but their requests will be forwarded to the list owner. This is the default.



By_Owner,Confirm:

Similar to "By_Owner", but before the request is forwarded to the list owner, the would-be subscriber must first respond to an "OK" confirmation request. NOTE CAREFULLY that you MUST specify "By_Owner" rather than "By Owner" -- the underscore is required for this syntax.



Closed:

New users are not allowed to subscribe, and their requests are not to be forwarded to the list owner.  List owner(s) and/or site administrators may use the ADD command to add users manually to the list.

Note that "Subscription= By Owner" (with a space between "By" and "Owner") is still supported, but is deprecated, and as noted, the underscore must be supplied if ",Confirm" is used.

(The ",Confirm" option is used in conjunction with "Subscription= Open" and "Subscription= By_Owner" only. It has no effect with "Subscription= Closed".)

Pre-Subscription Probing

One problem plaguing some mailing lists is one-way or non-replyable addresses. Most of the time this is due to a small number of faulty gateways, which one can just ban from the list until their maintainers address the problem. But sometimes the very topic of the list is bound to attract a large number of people connected through such gateways, and the amount of domains to filter out becomes unmanageable. This is particularly problematic when the gateway keeps quiet for a few days, and suddenly returns hundreds of delivery errors with a promise to keep doing so every day for another 6 days.

This problem can be avoided by probing the return address before accepting the subscription. If the address cannot be replied to, only one delivery error will be bounced to the list owner (perhaps for several days, but there will be a single undeliverable message). With a gateway that waits 3 days before sending its first delivery error, however, there can be hundreds of messages "in the pipe" if the subscription is accepted directly. This probing is activated by specifying "Subscription= Open,Confirm" in the list header. When a user attempts to subscribe to the list, he is mailed a confirmation request with a randomly generated "confirmation code". The procedure for confirming the subscription is simple - you just reply to the message, type "OK", and send. If the return address does not work, the request will never be confirmed and the user will not be subscribed. And since the user cannot guess the confirmation code he will be assigned, he cannot "cheat" by sending the confirmation along with his request.

Similarly, it is possible to code "Subscription= By_Owner,Confirm".  This adds an address probe into the usual procedure for subscriptions that must be approved by the list owner. The behavior with "Subscription= By_Owner" is

      1. User sends SUBSCRIBE command.
      2. LISTSERV forwards to list owner.

and no check is done to verify that the user's address is viable.  Adding the ",Confirm" parameter changes the behavior to

      1. User sends SUBSCRIBE command.                
      2. LISTSERV asks for OK confirmation.     
      3. User confirms.                               
      4. LISTSERV forwards to list owner.

With this setting in place, list owners who run restricted-subscription lists will no longer have to discover for themselves whether or not a potential subscriber's address has been spoofed or is otherwise non-viable, since they will never see subscription requests that have not been confirmed by the subscriber.

Subscription Confirmation Expirations

Subscription requests which are required to be confirmed (i.e., the ",Confirm" option is set with "Open" or "By_Owner") expire after a defined amount of time, as determined by the setting of the "Confirm-Delay=" keyword.  The default is 48 hours.

Template Messages

Depending on which options are set for Subscription=, different messages will be returned to those who try to subscribe to the list.  The default templates and messages are fairly simple and, depending on your needs, may need to be edited appropriately.  These messages are found and can be edited for each individual list via the LISTSERV web administration interface, under List Management / Mail Templates.

    • For lists which are set to Subscription= Closed, the MSG_SUBSCRIBE_ERROR_CLOSED message template is sent.
    • For lists which are set to Subscription= By_Owner, the MSG_SUBSCRIBE_FORWARD_OWNER message template is sent.
    • For lists which are set to Subscription= Open, assuming that the user is allowed to subscribe to the list, the MSG_SUBSCRIBE_SUCCESS message template is sent.  Additionally, the SIGNUP1 template (which includes the $SIGNUP template) is sent, as well as the list's WELCOME file if one is has been provided.  (The WELCOME file is, strictly, not a template, but it can be added and edited via the mail template web interface.)

There are a number of reasons why a given user might not be able to subscribe even if Subscription= Open, and there are message templates for those eventualities as well.  For example, the user may or may not match (as the case may be) more specific criteria found in the Filter=, Service=, and/or Local= keyword settings.  There are also server-level settings which may prohibit a given user from subscribing to lists.

In the second and third cases, if ",Confirm" is added to the Subscription= setting, the template messages indicated are sent after the subscriber successfully completes the OK confirmation.

Site administrators who have access to the Server Administration functions in the web administration interface may edit the default versions of these templates under Server Administration / Mail Templates.  Note, however, that list-level changes to the templates will override the global defaults.

See also: Confirm-Delay=