"Mark R. Williamson" <MARK@RICE>
Fri, 29 Jan 88 09:19:29 CST
|
>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
|
|
|