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