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