Auto-Delete= No   

Auto-Delete= Yes,Semi-Auto[,Delay(number)][,Max(number)][,Probe(number)]

Auto-Delete= Yes,Full-Auto[,Delay(number)][,Max(number)][,Probe(number)]

Auto-Delete= Yes,Manual[,Delay(number)][,Max(number)][,Probe(number)]

This keyword is available in LISTSERV Lite, but is not full-featured. The behavior in LISTSERV Lite with Auto-Delete= Yes is Auto-Delete= Yes,Semi-Auto,Delay(0),Max(1). Any other settings are ignored. Specifically the passive probing option available in Classic is disabled in Lite.

A LISTSERV Tech Tip discussing best practices for Auto-Delete settings is found here.

LISTSERV includes support for automatic deletion of users whose account has expired or whose system has permanently disconnected. When the delivery error is generated by a mailer compliant with RFC821/RFC2821 and the so-called "Notary" format described in RFC1893, LISTSERV may be able to automatically process the delivery error and take action based on the value of the "Auto-Delete=" list header keyword.  This includes most modern, popular SMTP mailers.

If the list has been coded "Auto-Delete= No", or if the delivery error is not in LMail format and LISTSERV cannot understand it, LISTSERV simply passes it to the list owner. Otherwise LISTSERV processes the message automatically. The algorithm may be refined in a future version, but at present the following steps are taken whenever the auto-deletion feature is enabled:

When auto-deletion is set to "Full-Auto" or "Semi-Auto":

      • LISTSERV looks for "permanent" errors (no such user, no such host, and so on). If the failing recipients are subscribed to the list, LISTSERV removes them and notifies you. No action is required from the list owner.
      • If there are permanent errors for users LISTSERV could not find on the list (for instance because the account subscribed to the list is a totally different one which forwards mail to a dead account), or if there are only "temporary" errors (host unreachable for 3 days, system error, disk quota exceeded, and so on), LISTSERV passes the actual error message to the list owner for further disposition if running in semi-auto mode. If running in full-auto mode, the error messages themselves are discarded and the errors only show up as entries in the daily auto-deletion monitoring report.
      • When running in full-auto mode, LISTSERV never passes back a delivery error unless it took action on it. This means that certain errors may remain unsolved, as LISTSERV presently ignores temporary errors and some of them are virtually permanent (if the owner of the account has left but for some reason his account was not closed, his disk quota is bound to remain exceeded until someone takes action). Full-auto mode should be used only when the list owner positively does not have the time to handle the delivery errors LISTSERV sends every day.

When auto-deletion is set to "Manual": 

      • When running in manual mode, the auto-delete monitor informs the list owner of the error(s) and takes no further action on delivery errors.

Some considerations for configuring the auto-delete monitor parameters:

      • Setting the Delay(number) option. The default is 4. This is the number of days that a subscriber's mail needs to bounce before he's automatically deleted. If "Delay(0)" is coded, LISTSERV won't wait, but will delete on the first bounce.

Most delivery errors occur on weekends when systems are taken down for maintenance, system administrators are not around to reboot after crashes, and the like. Because of this, most delivery errors only last for 2-3 days and may not be "permanent" even if they seem to be at first.

The nature of delivery errors is such that LISTSERV has no way to establish that a problem has been fixed because it receives only negative acknowledgements when a message bounces. This taken together with the transient, "weekend" nature of most delivery errors indicates that it is not a good idea to set Delay() to a value close to 7. For instance, if Delay(7) and a subscriber's mail regularly bounces on the weekend, LISTSERV will wait until the next weekend to decide whether or not to delete him, at which point the subscriber will bounce mail again and start the process all over. The bottom line is that LISTSERV might as well have gone ahead and deleted the subscriber as soon as the first bounce occurred.

      • Setting the Max(number) option. To prevent auto-deletion monitoring from getting out of hand, subscribers are deleted after a specified number of errors regardless of how many days it has been going on. The default is Max(100). This is so LISTSERV won't spend its life monitoring 50 bogus users x 100 messages = 5000 a day. Note that if Delay(0), the setting for Max() is ignored (in effect it is set to Max(1)).
      • Setting the Probe(number) option. This parameter tunes the "passive probing" option (beginning with 1.8d). Passive probing operates by turning a certain percentage of your regular list messages into transparent probes that look like a normal message but also double as a probe, rather than sending out the explicit PROBE1 template as in active probing. You enable (or tune) passive probing by adding a ",Probe(xx)" parameter to the Auto-Delete= keyword setting. For instance,

Auto-Delete= Yes,Full-Auto,Probe(30)

where "30" is the number of days to wait between probes for any given user. Subscribers with working mail systems will not see any difference, subscribers with flaky mail systems will occasionally receive a message showing that their mail bounced and saying that they should report the problem to their ISP, and of course plain bad addresses will go away.

In order to disable passive probing you set the probe parameter to 0, i.e.,

Auto-Delete= Yes,Full-Auto,Probe(0)

If you have users who for whatever reason should not be probed, you can deactivate passive probing (and any other renewal you have set for the list) with the SET userid@host NORENEW command. The default for this parameter is Probe(30) for lists up to ~2K subscribers, and Probe(0) for larger lists (because by its nature, probing can be a non-inconsiderable performance hit).

For more information on passive probes, see the Site Manager's Operations Manual.  The LISTSERV Tech Tip linked at the top of this section also goes into some detail regarding how passive probes are used with Auto-Delete.

Important:  For lists with "Mail-Merge= Yes", it is not possible to suppress auto-delete probing with ",Probe(0)", or by using the "Renewal=" keyword without its ",Probe" parameter, or by using the SET userid@host NORENEW command.


       This is because all LISTSERV mail-merge messages are sent as passive probes, and a bounce back to a list with "Auto-Delete=" enabled will cause the PROBE2 mail template form (an "active" probe) to be sent.


       If this is a problem for your organization, there are only a few options available.


    • Set "Auto-Delete= No" and handle all bounces manually; or


    • Don't use "Mail-Merge= Yes"; or


    • Suppress the PROBE2 mail template form by adding ".QQ" at the top of the template form.  (See the List Owner's or Site Manager's Manuals for more information about using dot commands in templates.)


       The last option is the most fraught with potential for "false-positive" auto-deletion, since if the PROBE2 message is not sent to a user whose mail been bouncing due to a transient or intermittent issue which has since been fixed, the user will not be given an opportunity to confirm their subscription and will likely be auto-deleted after the Delay() or Max() values are reached.  Therefore, L-Soft does not recommend or support suppressing the PROBE2 message, but recognizes some organizations may have internal requirements that prohibit sending the "active" probe.


       Please note that If the objection to the "active" probe is its default wording, or if you need it to be in a language other than English, the PROBE2 mail template form may be modified to say whatever your organization prefers, either at the site level (i.e., globally for all lists that do not have their own customized PROBE2 template) or at the individual list level.
      • When you take a vacation, note that it is best to switch auto-delete to MANUAL. Then do not restore to auto on the day you come back, because you will have a number of subscribers on file ready to be deleted. Wait DELAY+n days before changing back to Full-Auto or Semi-Auto, where n is an adjustment to account for the fact that people don't fix all problems right away at 09.00 on the day your vacation ends. n=2 is a reasonable choice.

The default value is "Auto-Delete= Yes,Semi-Auto,Delay(4),Max(100)" for lists coded "Validate= No" and "Auto-Delete= No" for all other lists.

Note that if you have coded "Delay(0)" and/or "Max(0)", LISTSERV simply deletes any error-generating subscriber it can (generally 95-98%), discards any further errors it does not understand, and does not generate daily monitoring reports. If you want the daily monitoring reports you must code at least "Delay(1),Max(1)".