Tomorrow I will  distribute what I hope will be  the last beta-test issue
of 1.7f. A  number of problems were found with  the new confirmation code
added in -7,  mostly "human factor" things but they  required a number of
changes in internals. Here is a list of the main changes.
 
MAXGET/K changed from 20/256k  a day to 50/2M a day.  This of course only
takes effect if you use the default LSV$GETQ.
 
When  you send  a  command  that requires  confirmation,  the command  is
ultimately executed under the initial origin, and not the origin you used
to confirm it. Both behaviours would be equally logical or illogical, but
having the original address take  precedence makes it possible for people
whose  mail user  interface is  configured to  use Internet  addresses to
subscribe with their BITNET address via TELL or SEND. Users simply expect
a subscription made via TELL to use the BITNET address.
 
When the  SUBSCRIBE command  is sent via  mail and you  did not  send any
other  command,  the  job  log  is   suppressed  and  you  only  get  the
confirmation request. If there are  other commands or messages (including
"Job FOO  started on..." if it  was requested), the job  log is generated
normally  and says  a  confirmation  request is  being  mailed. This  new
library call may  in the future be  used for other commands,  but for now
I'd like to close 1.7f.
 
When no name is specified on  the SUBSCRIBE command but your mail program
provided one  in the 'From:'  header, it  will be used  automatically. If
there is  no name  in the 'From:'  field of an  incoming message  but the
sender is  signed on to the  list, the name  from the list entry  is used
when generating  the 'From:' address  sent to the recipients  (except for
IETFHDR). And to  provide some relief to unfortunate  list owners plagued
with large  populations of Quickmail  or All-in-one users,  LISTSERV will
accept  10  incorrect  commands  before flushing  the  remainder  of  the
message.
 
  Eric