Phil, What you propose has already been implemented, at release 1.5j. Eric announced it on this list on May 24, 1987. Here it is again. Ross ------------------ Start of included file RENEWAL MAIL ----------------- Received: by RUTVM1 (Mailer X1.23b) id 5946; Sun, 24 May 87 09:46:49 EDT Date: Sun, 24 May 1987 12:21 SET Reply-To: The Revised LISTSERV distribution list <LSTSRV-L@RUTVM1> Zender: The Revised LISTSERV distribution list <LSTSRV-L@RUTVM1> X-cc: John Voigt <SYSBJAV@TCSVM>, Dominique Pinse <PINSE@FRPOI11>, Sergueii Soudoplatoff <HARPO@FRPOI11>, Marty Hoag <NU021172@NDSUVM1> From: Eric Thomas <ERIC@FRECP11> Subject: List subscription renewal feature To: Ross Patterson <A024012@RUTVM1> An automatic subscription expiration/renewal feature has been added to 1.5j. The list owner can place a list in automatic expiration mode by providing a "Renewal=" keyword in the list header. The default is NOT to require subscription renewal (this can also be specified by means of "Renewal= None"). The format of the "Renewal=" keyword is the following: Renewal= None | item1<,item2<,...>> Each 'item' can take any of the following forms: - An 'interval' specification, of the form: <factor->period Where 'period' can be either 'Monthly', 'Yearly' or 'Weekly' and the optional factor is a number by which the period will be multiplied. The special factor 'Bi-' indicates that the period is to be halved. Thus, '6-Monthly' and 'Bi-Yearly' both indicate an interval of 6 months. Note that the dash is mandatory. Whenever more than one interval is specified, the most restrictive (ie smaller) one will be retained. It may sound stupid to specify "Renewal= Yearly, Bi-yearly, Monthly", but this allows a postmaster to enforce a stronger renewal period in the local header portion of (future) peered lists if he so desires. - An absolute date, of the form yy/mm/dd, mm/dd or just dd. The first one is just what it is, the second one means "every year on the mm/dd", and the last one means "every month on day dd". This is useful if you know when your students' accounts are going to expire. Whenever more than one expiration date is specified, the most restrictive one (ie 'most recent') is retained. This allows each postmaster to add the expiration dates of his own students' accounts to his local copy of the list. - "Delay(n)", which defines the minimum delay in days between the time the user is asked to confirm his subscription and the time he is automatically removed from the list. The actual kickoff delay might be more than this number (see below), but not less. The default is one week (ie 7 days). The most restrictive value takes precedence whenever more than one occurence of the keyword is found. For each user and each list, the date of the last subscription/change in the subscription (SET) is kept. A new procedure, LSVEXPIR, must be added to the WAKEPARM FILE to check all these values against the "Renewal=" keyword in the list headers. Since this procedure eats a lot of CPU time (each user on each list must be checked), I don't recommend running it more than once or twice a week. It should, however, be invoked at least twice a month. If your CPU is idle at night, then you can probably run it every day without problem. You can also activate it manually ("CMS LSVEXPIR") without problem. Any user that was found to be due for renewal receives a copy of the following mailform: /../ Date: Sun, 24 May 1987 12:15 SET From: Revised List Processor (1.5j) <LISTSERV@FRECP11> Subject: Renewal of your subscription to list TEST To: Network Information Server <NETINFO@FRECP11> Dear subscriber, Your subscription to list TEST is due for renewal. If you wish to remain subscribed to TEST, please issue the following command at your earliest convenience: TELL LISTSERV at FRECP11 CONFIRM TEST You will be automatically removed from the list if you do not send a CONFIRM command within the next 10 days. Virtually, The LISTSERV management /../ And the list owner(s) receive one piece of mail each (I mean one single note for all the lists they might own where people have been warned/deleted). Here is an example (more lists and/or more subscribers just means more entries -- and of course nothing is sent if nobody was warned/deleted): /../ Date: Sun, 24 May 1987 12:15 SET From: Revised List Processor (1.5j) <LISTSERV@FRECP11> Subject: List subscription renewal monitoring To: Eric Thomas <ERIC@FRECP11> The following users have been asked to confirm their subscription to TEST: NETINFO@FRECP11 Network Information Server /../ The user must then confirm his subscription by means of the CONFIRM command, whose syntax is: CONFIRM list1 <list2 <list3...>> <FOR userid<@node>> The 'FOR' form is available only to list owners of course, but does not require password validation. A list owner can waive the renewal requirement for a particular user by means of the 'SET listname NORENEW FOR userid@node', or reinstate it by replacing 'NORENEW' with 'RENEW'. Those options are restricted to list owners of course. A user failing to confirm his subscription within the specified delay is automatically removed from the list and receives the following mailform: /../ Date: Sun, 24 May 1987 12:15 SET From: Revised List Processor (1.5j) <LISTSERV@FRECP11> Subject: Expiration of your subscription to list TEST To: Network Information Server <NETINFO@FRECP11> Dear subscriber, Your subscription to list TEST has expired and you have failed to confirm it in the 10 days delay that you had been imparted. You have therefore been automatically removed from the list. You can re-subscribe, if you so desire, by means of the following command: TELL LISTSERV at FRECP11 SUBscribe TEST Virtually, The LISTSERV management /../ The 1.5j migration exec will automatically initialize the 'subscription dates' for all the lists with a random date between 'today' and 'today - 30 days'. This will avoid concentrating the renewal requirement notices on the same day for all the lists of a given server. A final word about scheduling: it might happen that LSVEXPIR is scheduled "late", for example because it is called only twice a month. For that reason, the "delay before kickoff" is relative to the day the user was actually warned, not to the day he should have been warned; similarly, the actual kickoff date might be later than the one that was announced to the user, but it cannot be earlier than that reference date. Eric ---- and a few days later: ---- Received: by RUTVM1 (Mailer X1.23b) id 6638; Tue, 26 May 87 07:16:18 EDT Date: Tue, 26 May 1987 12:10 SET Reply-To: The Revised LISTSERV distribution list <LSTSRV-L@RUTVM1> Zender: The Revised LISTSERV distribution list <LSTSRV-L@RUTVM1> From: Eric Thomas <ERIC@FRECP11> Subject: Bi-whatever To: Ross Patterson <A024012@RUTVM1> To avoid any possible misinterpretation of its meaning, the "Bi-" prefix in the "Renewal" keyword has been removed. I do not intend to provide a "0.5-" or "1/2-" prefix. Eric ------------------ End of included file RENEWAL MAIL -----------------