I manage a list of moderate size (fewer than 1000 subscriptions), with
subscribers able to send freely and outsiders subject to review. On advice
from this forum, I do this using

     Send= Public,Confirm,Non-Member
     Default-Options= review

which works with our current LISTSERV version, 14.3. Thus, the list has a
mix of subscriptions with MAIL and NOMAIL, allowing subscribers the option
of sending to the list and receiving mail from it at different addresses.
Some of the receiving addresses cannot be used for sending, because the
subscribers use aliases.

I would like to clean out the accumulation of NOMAIL subscriptions from
defunct addresses. I would also like to clean out bad addresses which can't
be identified because the error is reported back from a different address. I
would have thought these ought to be possible with a Renewal setup, but
after testing it, I can't see how to make it work.

The renewal notices contain two options for responding with a CONFIRM
command: either by email or using a link. Neither option is usable by all
subscribers. The email response depends on the user being able to send the
command from the subscribed address; as noted above, not all can do so.

The link depends on the user NOT being logged in to LISTSERV with some other
address. If the user does happen to be so logged in, it looks as though the
renewal worked, but then the user gets dumped off the list when Delay is
reached.

Avoiding disrupting the working subscriptions is an important consideration.
It would therefore seem much better to use Renewal= Probe, which does not
require any response from the subscriber.

The problem is that, although the default template for a Probe message
clearly describes error detection as taking place, it doesn't. When a Probe
is sent to a nonworking address, the error goes undetected. A normal renewal
notice does lead to an error report in that situation. (I have compared the
headers for a Probe and a normal renewal notice, and they appear to be
equivalent.)

The only benefit from Renewal= Probe (other than reminding people that they
are subscribed) appears to be that making the subscription renewable makes
Auto-Delete= Probe applicable as well. However, that would only help with
subscribers actually receiving mail; the NOMAIL subscriptions never sent
anything other than the probes, so all errors are ignored.

Of course, most errors can be identified with a subscriber, but I've got a
case that can't: over 600 bounced messages in just under five months. I
could eventually identify that one with Auto-Delete= Probe if I set up a
renewal protocol (using Renewal= Probe to avoid trashing other subscribers),
but that still won't provide an effective renewal setup for those subscribed
with NOMAIL.

Is there a general solution to this problem?

Hal Keen