Q: How can I best configure the auto-delete setting in LISTSERV?

By Jacob Haller
Senior Support Engineer, L-Soft

Properly configuring and tuning the auto-delete mechanism in LISTSERV has multiple benefits for list owners and site administrators alike. It reduces the amount of time the list owner needs to spend handling bounces manually; it reduces the resources wasted by the SMTP server attempting delivery to invalid addresses; and it helps to prevent list mailings from being misidentified as spam due to high bounce rates.

Setting up auto-deletion for your LISTSERV lists is as simple as adding a keyword to the list header, but choosing the most appropriate and effective setting for your list can be confusing. In this tech tip, we'll discuss the different Auto-Delete options available and how to choose the best set of options for your LISTSERV list.

The Auto-Delete Keyword

To enable automatic deletion of invalid addresses for your list, you'll need to add a line to the list header. The format of the auto-delete keyword is as follows:

Auto-Delete= Yes|No, [Manual|Semi-Auto|Full-Auto], [Delay(x)], [Max(x)], [Probe(x)]

Setting the first parameter to "No" turns off automatic deletion for the list, and LISTSERV will instead forward all delivery errors to the list owner (or Errors-To) address for manual processing. Setting the first parameter to "Yes" tells LISTSERV that you'd like to use automatic delivery error processing for the list.

Once you've told LISTSERV that you'd like to use auto-delete, you need to specify the type of auto-deletion to use. "Manual" mode doesn't actually delete subscriber addresses. With auto-delete set to "Manual", LISTSERV will automatically process bounced messages and compile a Daily Error Monitoring Report (DEMR) that gets sent to the list owner for action, but LISTSERV itself takes no further action on the bounced addresses.

In "Semi-Auto" mode, LISTSERV will automatically delete invalid addresses from the list per the parameters set forth by the "Delay" and "Max" settings. If LISTSERV can't automatically process the bounce or if the bounce error is a temporary error (like "Mailbox Full"), the bounce gets passed along to the list owner for manual processing.

In "Full-Auto" mode, permanent errors that LISTSERV can't automatically process only show up on the DEMR, and the bounce messages themselves are not delivered to the list owner. Temporary errors are discarded.

Once you've determined the auto-delete mode, you can assign settings for the "Delay", "Max", and "Probe" settings. "Delay" and "Max" are settings that tune the bounce threshold at which LISTSERV will automatically remove invalid addresses. The "Probe" setting determines what portion of list messages get sent in a special "Passive Probe" format. We'll look at each of these settings in some detail below.

Delay and Max: Your Partners in List Hygiene

The "Delay" and "Max" settings work together to determine at what point LISTSERV will delete a bouncing email address from the list. "Delay" tells LISTSERV how many days to monitor a bouncing address before taking action on it. "Max" allows us to tell LISTSERV some maximum number of bounces to allow within that monitoring period. For instance, if you set Delay(8) and Max(10), you're telling LISTSERV that if it sees a bounce for a subscriber, the subscriber should be monitored for eight days. If on the eighth day LISTSERV receives another bounce for that subscriber, the address will be removed from the list. If LISTSERV receives more than ten bounces for the subscriber before the end of the eight day monitoring period, the subscriber will be removed at that point. If, however, no additional bounces are received during the eight-day monitoring period, LISTSERV will stop monitoring that subscriber after the eighth day.

Tuning the "Delay" and "Max" parameters is easiest on lists that receive a large amount of daily traffic. For instance, on a list that receives an average of ten posts each day, you might use something like:

• Auto-Delete= Full-Auto, Delay(4), Max(19)

With the setting above, once LISTSERV has received a bounce for a subscriber, it'll monitor the address for four days. If it receives more than 19 bounces for that address within the four-day period, or if it receives bounces for it on the fourth day, the subscriber will be automatically deleted. Otherwise, if four days pass with no new bounces, then LISTSERV will stop monitoring the address, and it will disappear from the Daily Error Monitoring Report. You can adjust the "Delay" and "Max" parameters depending on how much traffic comes through the list and how zealous you want to be in removing addresses that bounce.

Tuning the Auto-Delete keyword is more difficult for lists that have less traffic. For example, if you have an announcement-style list that only receives postings once each week, the example setting above would mean that invalid addresses never get removed from the list, because there would never be a list posting four days after the initial bounce, and there would never be twenty postings within that four-day period. For a weekly newsletter list, something like the following might be more appropriate:

• Auto-Delete= Full-Auto, Delay(8), Max(1)

With this setting, LISTSERV will place bounced addresses on the monitoring report for eight days. If the address bounces more than once within eight days (two consecutive newsletters), LISTSERV will remove it from the mailing list. If it only bounces once, and the second newsletter gets delivered with no bounce, LISTSERV will take no action, and will stop monitoring the address before the next mailing.

If you want to implement a zero-tolerance policy for bounced email addresses on our list, you can set:

• Auto-Delete= Full-Auto, Delay(0), Max(0)

In this case, subscribers are never monitored, and instead get removed on the first bounced message. With this setting (or any setting using Delay(0)), the list owner is not notified when addresses are removed, though it will be recorded as an AUTODEL event in the mailing list's changelog if it has one.

For mailing lists that only get one or two posts a month, we recommend immediate removal of bad addresses, as continuing to send mail to bad addresses over a long period of time is the sort of thing that will damage your mail server's reputation and is likely to increase the probability that your mail will be flagged as spam.

Passive Probes

There can be situations where the normal automatic bounce processing has trouble interpreting a bounce. For instance, if someone is subscribed to a mailing list under one address and has set up that address to forward mail to a second address, and mail to the second address starts bouncing, then LISTSERV will start receiving bounces for an address that isn't directly subscribed to the mailing list. The address would show up on the Daily Error Monitoring Report, but since it isn't actually subscribed to the mailing list, it would never actually be removed.

To get around this problem, LISTSERV can be configured to send some portion of each list posting as "passive probes". A passive probe is a message with a specially formed return address that allows LISTSERV to tell from the return address what the originally subscribed address was.

If a mailing list is configured with "Mail-Merge= Yes", then LISTSERV is already probing every subscriber any time a message is sent to the mailing list because it is sending customized versions of the messages to each subscriber, so no additional resources are required to also use a customized return path. As a result, probing cannot be disabled for a mailing list that has mail-merge enabled.

For mailing lists that don't have mail-merge turned on, you can control what fraction of the subscribers are probed each day using the "Probe" parameter. For a probe value of "x", LISTSERV will send 1/x of the first post of the day as passive probes, giving preference to new subscribers or addresses that it has not recently probed.

So for instance, on a list with 60 subscribers that averages one post per day and a Probe setting of 30, the first list posting of each day would contain an average of two passive probes (for two individual subscribers or 1/30th of the list membership). The rest of the subscribers would not be probed. You can turn off passive probes entirely, if desired, by setting the Probe parameter to "0". Note, however, that this will have no effect on mailing lists with "Mail-Merge= Yes".

Generally, passive probes are transparent to subscribers. They appear as regular list postings but with a special return address specific to that recipient. If a passive probe bounces back to LISTSERV, the server follows up with a message to the subscriber explaining that the probe failed. If that follow-up message also bounces, LISTSERV will add the address to the DEMR for the period of time specified by the "Delay" parameter. LISTSERV will continue to probe the address with the first posting of each day until it either stops bouncing or is auto-deleted.

Some Examples

Now that you know how each of the auto-delete parameters works, let's look at some real-life examples. For an active discussion list of 60 or so members that gets 10-20 posts per day, you might set something like:

• Auto-Delete= Semi-Auto, Delay(4), Max(20), Probe(30)

This tells LISTSERV to do semi-automatic bounce handling (temporary errors get sent to the list owner), monitor users for four days, delete them if more than 20 bounces are received within that four-day period, and probe each user about once each month (1/30 of the list each day).

For a weekly newsletter with 500 subscribers, you might use:

• Auto-Delete= Full-Auto, Delay(8), Max(1), Probe(12)

Here LISTSERV processes bounces fully automatically, monitors users for just over a week, deletes them on the second newsletter bounce, and probes each user about once every three months (1/12 of the list each week).

Finally, for a monthly newsletter with 2,000 subscribers, you might set:

• Auto-Delete= Full-Auto, Delay(0), Max(0), Probe(12)

In this example, LISTSERV will delete invalid addresses on the first hard bounce and probe each list member address once each year (1/12 of the list each month).

Proper configuration and tuning of the auto-delete feature in LISTSERV can take much of the hassle out of list ownership, with the added benefits of better delivery rates and reduced server load. For more information about the auto-delete mechanism, see the LISTSERV Site Manager's Manual.

Subscribe to LISTSERV at Work.