Newsgroups: bit.listserv.lstsrv-l
Date:         Fri, 17 Apr 1992 08:37:27 EDT
From:         "Duane D. Weaver" <WEAVER@OHSTVMA.BITNET>
Subject:      Re: Bounced mail

Here is the documentation on the Renewal process, taken from the archives
of this list.  This is not documented any where else.


  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<,...>>,Delay(n)

  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
z SPONSELL AKRONVM. 10/27/87
' Gary Sponseller     Duane Weaver         5/24/87 List subscription renewal fea
Received: from OHSTVMA.BITNET by OHSTVMA.ACS.OHIO-STATE.EDU (Mailer R2.08
 R208004) with BSMTP id 5568; Thu, 27 Feb 92 15:03:47 EST
Date:         Tue, 25 Feb 1992 10:40:11 EST
Reply-To:     ListServ list owners <LSTOWN-L@INDYCMS.BITNET>
From:         DOUGLAS COFFMAN <lefty@MTU.EDU>
Subject:      Re: Little use of the keyword Renewal
Comments: To: LSTOWN-L%INDYCMS.bitnet@UICVM.UIC.EDU
To:           Multiple recipients of list LSTOWN-L <LSTOWN-L@INDYCMS>

The RENEWAL Keyword will send you (as listowner) a notice of who it sends
 renewal notices and who it deletes the FIRST time it passes through the list of
 subscribers.  This will "catch up" everybody on the list who subscribed at
 least one year before you issued the RENEWAL keyword.  After that, it
 periodically updates the subsriber list.

In other words:

1.  This keywork applys to EVERYONE subscribed to your list (old and new) except
 of course, those
    who are set at NORENEW.

2.  The list owner will only receive the massive "I have send renewal notices
 to:" the first time.


If I'm wrong, Eric, please correct me.

On the Air,

Douglas J. "Lefty" Coffman, Owner
DJ-L Campus Radio Disk Jockey Discussion List

**************

Duane D. Weaver
LISTSERV Postmaster
Senior Systems Programmer
Ohio State University
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU