At 4:48 PM -0600 12/7/96, Terry Kennedy, Operations Mgr wrote:
>  Yes, but...
>
>  Suppose someone is subscribed to the list as [log in to unmask] Now they've
>changed jobs and are now [log in to unmask], but set mail forwarding on
>their [log in to unmask] account so all mail sent there goes to otheruser@new-
>host.com. Now they've left newhost.com and their account there was deleted.
 
OK, a quite usual case so far.
 
>  Mail LISTSERV sends out for this list comes back with a bounce that says
>"[log in to unmask] - no such user". When REVIEWing the list, this address
>doesn't appear, because it's the result of forwarding that LISTSERV doesn't
>know anything about.
 
Right.
 
>  The DISTRIBUTE method that was suggested instead of probes will suffer from
>the same problem, as there isn't any way to identify which list subscriber
>the bounce pertains to, right?
 
Not necessarily.  With Peter's original suggestion, each subscriber is sent
an individual message bearing the subscription address ([log in to unmask])
in the headers.  While some forwarding hosts will mangle that address, many
will leave it alone and it may appear in the error message.  The next step
beyond this sort of manual probe is a manual probe to selected similar
addresses with the address in the body of the email.  Of course, some error
messages don't bother to return either the body or the original header,
much less the Received: header trail, leaving you up the proverbial creek
until you get probe support or the subscriber goes through conventional
renew processing.
 
>  With probes, LISTSERV puts the subscriber address (with things like @'s and
>.'s escaped) in the From: address, so when it gets a probe bounce, it knows
>exactly which subscriber the bounce is for. That's much more useful. That's
>also why wildcard owner-* aliases are needed for probes to work (and hence
>my Sendmail patch to implement same).
 
Yes, I understand.
 
>  Now, what I'd like is a way to tell LISTSERV to probe a list, without having
>to set short renewal periods (which are inappropriate for announcement-only
>lists and some other cases).
 
It wouldn't have to be a short renewal period.  You could add an explicit
date (say, tomorrow) to force a renewal probe, assuming the server and list
were set up for renewal probes.
 
>  Is this clearer now?
 
It was never unclear what you wanted; I was just trying to help Peter
explicate for everybody options available now to address "mystery error
message" problems until and unless on-deman probes are implemented.
 
Mark R. Williamson