Mon, 22 Mar 1993 02:09:29 +0100
|
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
|
|
|