From: "Esther Feldman" <[log in to unmask]>
>
> We've also experienced where our listserv messages have been marked as
spam.
> Warn your users to unmark them. We've also had a recent experience where
> some of our members are being kicked off the list for no apparent reason.
We
> had to change the Auto-Delete option from semi-manual to manual. Has
anyone
> else had this problem?

I think you mean "semi-auto"; I tried it and reverted to manual some time
ago, because it's risky if you set a high value on avoiding arbitrary losses
of subscribers. Those with larger lists may have to set their priorities to
cope with the scale of their problems.

Partly, this is an RFC issue: there is no very clear way to categorize
"permanent errors" as pertaining to the state of the destination mailbox or
merely to a locally objectionable characteristic of a particular message. A
permanent error means that any attempt to re-transmit the rejected message
will probably fail. The cause could be a full mailbox or a match to a spam
filter as well as a discontinued email address or a short-term problem in
the destination domain.

(Actually, it's often possible to determine more than that from the precise
code or message returned, but that's not necessarily reliable and often
requires a human reader.)

Thus, there are practical issues with trying to determine from a sample of
rejections whether an address is really useless. LISTSERV really has no way
to tell for sure whether any of the mail is getting through, so as far as I
can tell [subject to elaboration and correction by others on this list who
may know more of its innards] it simply does the following:
(1) start tracking with the first permanent error returned;
(2) if more than Delay() days have elapsed after tracking began, consider a
permanent error grounds for deletion; and
(3) if tracking has continued for Delay() days without a permanent error,
stop tracking for that subscription.

This means that the longer the coded Delay(), the higher the vulnerability
to even infrequent errors. But the shorter the delay, the more likely that a
short-term disruption will cause a deletion. The extreme case of
Delay(0),Max(1) was used when our hosts transferred lists from Majordomo,
and because most of these were public and suffered occasional spam attacks,
many immediately started losing subscribers (everyone who had company spam
filters that sent rejections back). One owner reported losing 20% the first
day.

Hal Keen