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