Auto-Delete Keyword

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 is disabled in LISTSERV Lite.

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 SMTP mailers.

If the list has been coded "Auto-Delete= No", or if the delivery error is in a format that LISTSERV cannot understand, then LISTSERV simply passes it to the list owner. Otherwise, LISTSERV processes the message automatically.

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 who 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 errors and takes no further action on delivery errors.

Some considerations for configuring the auto-delete monitor parameters:

• For 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 so on. 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.

• For the Max(number) option, the default is 100. 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. This is so LISTSERV won't spend a lot of resources 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)).

• The Probe(number) parameter tunes the "passive probing" option. 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)

In this case, "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, for example:

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

The default for this parameter is "Probe(30)" for lists up to 2000 subscribers, and "Probe(0)" for larger lists (because by its nature, probing can be a noticeable performance hit).

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.