This article will explain what the Daily Error Monitoring Reports signifies and how to interpret it.
The daily error monitoring reports are automatically generated and sent out whenever certain delivery errors occur. These error reports are part of the auto-deletion feature, which can be configured in many ways depending on the level of automatic error handling the list owner wants.
Note: By default the Daily Error Reports are sent to the Owner(s) of the List unless specified in the Error Handling Section of the List settings in the row labeled 'Errors-To'.
Example Daily Error Monitoring report
How to Set up Automatic Error Handling
Log in to listserv.uga.edu. Once logged in, navigate to List Dashboard and find the list you own.
Select the List you want to add Automatic Error Handling to and click List Configuration from the left-hand column.
In List Configuration, with the appropriate List selected, choose Error Handling
In Error Handling, you will see several options.
In the first row, choose Auto-Delete= . This is where we can set up the parameters for the auto-deletion feature. Pro Tip: You can click on the ? symbol to learn more about what each setting does.
Specify whether you want LISTSERV to automatically process bouncing subscriber addresses and delete them when necessary conditions are met, using the following commands.
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.
Delay:
- 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.
Max:
- 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)).
Probe: