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]