Q: How can I prevent users from unsubscribing from my LISTSERV list?

Answer by Liam Kelly
Senior Consulting Analyst, L-Soft

By design, LISTSERV makes it as easy as possible for subscribers to leave a LISTSERV list. In previous tech tips, we have discussed how to add one-click unsubscribe links to list messages (Issue 4, 2005). Starting with LISTSERV 16.0, LISTSERV does this by default for new lists. But what if we want to prevent users from actually leaving a LISTSERV list? This tech tip discusses how (and why) to accomplish this.

Why Prevent Unsubscribes?

Before we address the "how", we need to spend some time on the "why". In most cases, preventing subscribers from leaving a LISTSERV list is a bad idea. If a recipient no longer wants to receive messages from the list, and if we prevent them from unsubscribing, the most likely result is that they will start reporting the list mail as spam. If they start reporting our messages as spam, not only will it prevent them from receiving our mail, but it will likely prevent other users at the same service provider from receiving our mail. If our LISTSERV server itself gets blacklisted, it will not only result in mail from a single list getting blocked, but probably for all lists on the LISTSERV server. If our LISTSERV server ends up blacklisted with a spam reporting service, the consequences get even more dire and may affect our delivery to other service providers as well. It is always preferable to allow individual recipients to opt out of our list than to have the entire server blocked because of spam complaints.

However, there are exceptional cases in which preventing unsubscribe requests makes sense. For instance, we may be a corporation or other institution that maintains an internal email list for all employees. Or we may be a university that keeps a LISTSERV email list for students registered for each class. In those cases, it may seem like a good idea to prevent subscribers from opting out because we need to know that we're reaching all employees or all registered students. However, even in those cases, proceed with caution. Preventing signoff requests should only be considered if we have ownership over both the LISTSERV server and the destination mailbox. If we have (for instance) employees or students who forward their corporate or university mail to an outside service provider and they start sending spam complaints to that service provider, our server could still end up blacklisted with that provider. We should only consider preventing signoff requests in environments in which any spam complaints would also be handled internally.

Method One: Dynamic Query Sub-Lists

In most cases in which preventing signoffs makes sense, the subscriber list is coming from some external data source: an employee directory, a course registration database, etc. In those cases, the best option is for LISTSERV not to manage the subscriber list at all, but to query the external data source directly to fetch the subscribers. LISTSERV's Dynamic Query Sub-List feature is designed to do just that. Rather than importing the recipient list into a regular LISTSERV subscriber list, LISTSERV can query a DBMS or LDAP data source in a read-only fashion to fetch the current subscriber list every time a message is sent to the list. Because access to the data source is read-only, this has the side effect of preventing both SUBSCRIBE and UNSUBSCRIBE requests via LISTSERV. Subscriptions are managed solely through whatever interface populates the DBMS or LDAP data source. Recipients cannot unsubscribe via LISTSERV.

Method Two: Locking the List

It is also possible to prevent subscription changes by locking the LISTSERV list by issuing a GET command to retrieve and lock the list. For example, you could email the following command to LISTSERV to GET the EXAMPLE list:

This will cause LISTSERV to lock the list and mail the current copy to the address issuing the command. While the list is locked, no changes can be made to it, meaning that nobody can join or leave the list. Anyone attempting to make any subscription changes will instead receive a message stating that the list is locked. Note that this prevents all changes to the list until it is unlocked, including changes to the list configuration or any individual subscriber options.

Method Three: Using a List Exit

It is also possible to intercept SIGNOFF requests via a list exit. List exits are a way to trigger external code in place of (or in addition to) regular LISTSERV events. The DEL_FILTER exit point is called for SIGNOFF commands and for DELETE commands issued by the site administrator (but not the list owner). Writing and using list exits is beyond the scope of this tech tip, but the general idea is that the DEL_FILTER exit is called when a user sends a SIGNOFF request for the list. The exit can call an external script that sends a return code of 0 (to process the SIGNOFF request) or 1 (to reject the SIGNOFF request). The advantage to this method is that it targets SIGNOFF/UNSUBSCRIBE requests specifically, unlike methods one and two above. The disadvantage is that it is a bit more complicated to set up and requires some external scripting.

Modifying the Default BOTTOM_BANNER

Keep in mind that starting with LISTSERV 16.0, LISTSERV will create a default bottom banner for new lists that includes signoff instructions. For any lists on which you implement one of the methods above, remember to modify the bottom banner templates to remove the signoff instructions, possibly replacing them with helpdesk contact information or other instructions more appropriate to your situation.

References

Creating Dynamic Query Sub-Lists:
http://www.lsoft.com/manuals/16.0/htmlhelp/advanced%20topics/DQL.html#2337459

GETting a List:
http://www.lsoft.com/manuals/16.0/htmlhelp/site%20managers/LSCommands.html#2337016

DELETE/SIGNOFF/CHANGE Exit Points:
http://www.lsoft.com/manuals/16.0/htmlhelp/advanced%20topics/ListExits.html#2334209

Modifying Mail Templates:
http://www.lsoft.com/manuals/16.0/htmlhelp/list%20owners/CustomizingTemplates.html

Subscribe to LISTSERV at Work.