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
|
