>There is just no way to prevent auto-deletion (on a per subscriber
basis) for bouncing as long as a subscriber's mail server is throwing
permanent errors, which are recognized by LISTSERV®.
>
>In the case of this Webtv user, I see the server is throwing a
permanent error for a temporary problem (mail box full). If it were
using a temporary error code, this wouldn't be happening. I see more
and more ISPs doing this these days.

The RFC definition of a "permanent error" is not that the mailbox is
permanently unavailable, but that if you resend that particular email it
will in all likelihood be rejected again. This means that spam, if it gets
through a list's defenses, can trigger auto-deletion. (This is not a
criticism of LISTSERV; there's no other reasonable basis for deciding which
errors count.) The conventional code for a full mailbox is 552; the first 5
puts it in the permanent error class.

A full mailbox is all too often really a permanent state; I get lots of
cases where subscribers abandon an email account, and I find out they're
gone only when the mailbox fills up. (Or, in the case of one U.K. service,
starts returning everything as it hits 30 days without being picked up.)

There IS one way to prevent auto-deletion, but it might be more than you can
stand, depending on the size of your list. If you change to Auto-Delete=
No, you will probably find the error reports unbearable. But if you change
to Auto-Delete= Yes, Manual, you will still get most errors reported in
summaries, but LISTSERV will leave the decision to delete up to you.

On a large list, that might be too much work, too. It works for me, with
nearly 900 subscribers on a discussion list, and posts averaging 5 or 6 per
day (but with peaks near 50). One way to keep the error summaries manageable
is to NOMAIL anyone whose email is failing, and follow up with test
messages, informing them of the suspension, until they either respond or run
your patience to its limit.

I don't think there is any way to provide this level of service only to
selected subscribers on a single list; it's the whole list, or none.
However, you could set up a second list, relaying mail from the first, with
a different Auto-Delete= setting, and move your subscribers with known
problems to it.

Any list with 20-30 posts per day is going to fill up a mailbox pretty
quickly unless it has a decent capacity, so this WEbTV user does have
inadequate facilities just to keep up. But sometimes the desire to
accommodate those less endowed with expensive facilities is measured in a
different dimension from the need to handle large, active lists with
large-scale methods. I salute the effort to handle this subscriber's problem
on an individual basis, and I hope it works out.

Hal Keen