>If the mailers were changed to return mail to the 'Reject-To' field, then
>there would be no need for the global delete.  When the individual users
>are deleted from the individual systems, their entries will get rejected
>by the mailers the next time the individual list sends something out.
>Then LISTSERV will process the rejected mail, delete the entry from the
>list and send a notification to the owners!  Simple?  You bet!  But not
>without problems:
>1: Systems that don't have mailers will have their punch queues fill up.
>   That should encourage these people to get mailers.   :-)
>2: Systems that use old mailers will still bounce the mail back to the
>   list, thus causing a possible loop.  I'm not sure how to fix this
>   one.  (How is it done now?)
>3: Systems that re-use the id's every semester might not have the id's
>   off line long enough for a reject mail item to get bounced to listserv.
>   Or, they might not even nolog the ids.  I can't think of any
>   solutions here, but if the new person does not like the list, he can
>   always unsubscribe to it.
   (If he knows how.)
4. Systems that cause valid users to be unable to receive mail for a while
   (such as until more funds are allocated, or some disk space is freed)
   but are unable to communicate that in the rejection notice for some
   reason (no standard rejection format (yet), no connection to funds
   management system, etc) will cause those users to lose subscriptions
   without notice (since they probably couldn't receive the notice even if
   LISTSERV tried to send it) and have to scramble around getting themselves
   reconnected to all of the lists which might have dropped them.
5. Sites which want to forestall the flood of invalid mail they know will
   arrive after mass user deletions will have no convenient tool to do so.
   (Obviously, there is a tradeoff here, but I haven't seen anybody do the
   analysis to determine when it is better to handle each rejection as a
   separate case and when it is better to broadcast the information that a
   large group of users has been removed.  It might be better to provide
   both tools, which would address problem 3 as well.)
6. LISTSERV has to be prepared to sift out the rejection notices from files
   intended to be commands, if the rejections are directed back to its own
   reader.  Perhaps it would be appropriate to implement a separate mailbox
   (which would be set up like another list) for rejections.  It could be
   called LSVERROR or LSREJECT in general, but should be installation
   settable.
 
--Mark Williamson