If you don't mind stopping ALL the prospective deletes for the
particular list, change the Auto-delete= list header keyword first
parameter to NO for a little while. To be really sure, leave it set to
NO from at least before midnight until after six the next morning local
server time (this should cover the review-status-and-issue-report and
send-new-probes events).

When the root cause of the address being on the DEMR is solved, and you
change it back to YES, I believe it will have forgotten all the prior
probe failures, but I'm not absolutely certain.

You might also (if site administrator) look in the local filesystem for
a listname.AUTODEL file - that's where the memory of failed probes is
kept.  If you delete the file then the next probe cycle won't know about
prior cycle failures.

Of course, this all depends on correcting the root cause of the address
errors being reported, which is presumed here to be a temporary problem
and the list owner will know when it has been solved.  I don't believe
any GOOD workaround is available for a subscriber on an email service
that persists indefinitely in causing probe failures when delivery does
not actually fail.

On 10/16/2012 12:14 PM, Greg Dietrich wrote:
> How does one STOP an e-mail address on the DEMR from being deleted by
> LISTSERV subsequent to the Delay period or after (Max) number of
> bounces?In some situations, List Owner has knowledge about a particular
> subscriber that would preclude deleting them. Most of our lists are
> configured Semi-Auto - there’s no enthusiasm for changing this method to
> one where List Owners have to do all of the work.
>
> Greg Dietrich
>
> SCO ListServ Administrator
>
> California State Controller's Office (SCO)
>
> Email: GDietrich @ sco.ca.gov

############################

To unsubscribe from the LSTOWN-L list:
write to: mailto:[log in to unmask]
or click the following link:
http://peach.ease.lsoft.com/scripts/wa-PEACH.exe?SUBED1=LSTOWN-L&A=1