Dennis Budd wrote: > Same thing is happening to me. I assume that one of my subscribers > has forwarded mail to an account that no longer exists. So the > account that bounces is not subscribed, but that account that is > forwarding mail to it is. How to determine which subscribed account > is responsible for this is the challenge. If you had an actual > bounced message you probably could do it, but you don't. You *can* get the actual bounce messages, and I'm surprised no one, that I have noticed, has mentioned it yet (too busy explaining why the DEMR has errors it can do nothing about (those are ones for the listowoner to take care of, if necessary, part of why there are listowners), I guess). In passing, I will say that I have never used PROBE, active or passive. I have studied it since it was first introduced, and, for my lists, and the way I work, I simply decided (more than once) that I didn't want to use it. Which is not to say, by any means, that I don't use auto-delete, semi-auto; I do, and is a life-saver. To see the actual bounces, to try to track down the source subscription address, if there is one, simply turn auto-delete off (Auto-delete= No in your list header) for the requisite period (until you get an "Ah Ha!" bounce). When you get the error you need, turn auto-delete back on. Since the inception of auto-delete there has not been a single problem error in the DEMR which I have not been able to track down, when I really needed to. Now, I do not do that very often, and am careful to turn auto-delete back on before the midnight maintenace routine so that it does not lose its delay count. I ignore transients in the DEMR, just as I ignore transients in the error messages which are in a format auto-delete does not understand (dealing with error messages in the days before auto-delete was possibly good training for what to pay attention to and what not). One can ususally tell when one has a real problem which auto-delete cannot deal with, due to a subscribed address. If this unsubscribed address racks up exactly the same number of errors per day as there are distributed postings, 99.9% certain there is a subscribed address with an auto relay/forward and the error is coming from the unsucribed relay/forward address. Turn off auto-delete and the header in the error report will likely give you enough info to find the subscribed address. The ones which gradually creep their way up through the DEMR, increasing by one error every day, are usually from DIGEST/INDEX subscriptions which are being auto forwarded/relayed. For those, send in your email list header change at a time when it will not be processed until *after* the daily maintenance and you will have a fair chance of catching the actual error message without disrupting the auto-delete delay count too much. Save the DEMRs so that you can compare error reports from day to day, how many this problem sub racks up, against how many postings were distributed. For each list, the DEMR is saved in the same file as the Subrcription Renewal report (large lists, in existence for years, yearly renewal, there is a Renewal report *every* day). Now, I do not think that anywhere in the documentation does it say the auto-delete reports only on subscrbed addresses. Rather, it reports on error messages which are in a format which the auto-delete program understands. When the number of errors reaches the delay or number count, then auto-delete tries to find a matching address in the subscription list to delete (must be an *exact* match). If it can't find a match, it does nothing, the number of errors mounts (look at the number of errors *and* dates of first last) and only then does the listowner need take action. If auto-delete, semi-auto, reported only on errors for subscribed addresses (sometimes the error is for a close, but not exact match) you would end up with many invalid addresses, forever, in your subscription list. From now until doomsday LISTSERV would try to deliver the mail, and an error would be reported for an address which is not subscribed. Since the listowner doesn't know about it, and auto-delete can't do anything about it (no address to delete), the faulty addresses mount up, clogging the system. If you really don't want to be bothered by these reports you can't figure out, set auto-delete to full-auto and delete the DEMRs without looking at them. Douglas Winship [log in to unmask]