I don't know if this has been suggested or not.  This is an idea to help
eliminate problems associated with people who just up and leave without
unsubscribing to lists they have been on.  It may be able to solve other
problems as well.
 
The idea is that a subscription requested by either the user or the list
owner, would have an expiration date established with it.  If that date is
reached without a renewal (another subscription) being received, the user
will be removed from the list.
 
 
                    *** FEATURES ***
 
Within 7 to 10 days prior to expiration, a form notice will be sent out
to the user notifying him that he needs to renew his subscription.
 
Users may renew their subscriptions for lists that otherwise require
being added by owners (closed lists) provided they do so before the
actual expiration.  After that, the owner must add them back.
 
When a renewal is received for user already on the list, the expiration
date will be updated according to the following logic:
    if the subscription is due to expire within 10 days, the expiration
       will be extend the defined period beyond the old expire date.
    if the subscription is NOT due to expire within 10 days, the
       expiration date will be set to the defined period after the
       renewal is received.
This logic keep expiration dates from crawling backwards when subscription
terms are set to common periods like 6 months.
 
The default subscription period can be set different for each list.
A master default will be used for lists having no specific default.
I suggest 6 months to be the master default, and 3 months to be set for
lists with a high traffic volume.
 
The list owner can add a user with a different term, or permanent (never
to expire).  Peers will never expire.
 
 
                    *** IMPACT ANALYSIS ***
 
A new variable needs to be defined for each list to keep the defined
subscription term.
 
A global variable is needed for lists with no defined term.
 
A field is needed to be kept for each subscriber on each list for the
expiration date.  A special value can mean that the subscription is not
to ever expire.
 
A routine needs to be written to scan for users to notify of coming
expiration.  A method is needed to assure only one notice is sent.
It would be run once every day or two.  This program would also notice
actual expirations and remove the subscriptions.  A different message
needs to be sent to the user if he is removed for non-renewal.  If the
list is HELD, no updates are to take place.
 
>>> There may be a problem with users responding with ONE renewal as
>>> a response to a notice of coming expiration, and that renewal being
>>> rejected because the list is held.  Can they be queued?
 
The code that handles subscriptions needs to have logic added to handle
the expiration date update.
 
The code that handles adds needs to also handle expiration dates, including
a new option on the ADD/ADDH command that lets the owner set the expiration
period, specific date to expire, or PERM for no expiring.
 
Two new form letters need to be written.  One tells users of coming
expirations and the other tells users that their subscriptions have
expired and they are no longer going to receive mail from the list.