Description of the changes from release 1.6a to 1.6b of LISTSERV
--------------------------------------------------------------
August 30th, 1989
*********************
* IMPORTANT WARNING *
*********************
A severe security exposure has been discovered in LISTSERV, and fixed in
release 1.6b. In order to protect the integrity of sites which have not
yet installed release 1.6b, and which may be unable to do so in a timely
fashion for local reasons, LISTSERV coordination shall disclose NO AMOUNT
of information regarding that exposure. LISTSERV maintainers are
explicitly asked not to discuss this security problem on the network
(and, in particular, on public lists) in any way that might facilitate
the discovery of the nature of the "hole" by people who were unaware of
it. Technical discussions which would not provide any "hint" to potential
hackers are of course allowed.
****************
* Requirements *
****************
LISTSERV release 1.6b is supported on any hardware/operating system
configuration supporting release 1.6a.
Release 1.6 of LISTSERV is available only to BITNET and NetNorth sites,
for political reasons. EARN sites now receive support for the EARN
version of LISTSERV from Turgut Kalfaoglu <TURGUT@TREARN>, to whom EARN
users should address any and all inquiries regarding LISTSERV.
*****************
* Compatibility *
*****************
Release 1.6b is fully compatible with 1.6a, with the exception of the
behavioural changes noted under the headings "Solution to the problem of
CONCEALed users on DISTRIBUTEd lists", "Handling of moderated lists" and
"Changes in default list header options".
Release 1.6b is to be installed directly on top of the base 1.6a version.
***************
* Minor fixes *
***************
Following a user request, a brief description of all the "small yet not
unimportant worries" that have been fixed in each new release will appear
in the corresponding "Description of changes" document, along with the
affected releases, if known ("All" meaning "any release in which the
facility is available", ie the bug existed since the very beginning).
Releases
affected Description of the problem
-------- --------------------------
All REXX error if user specifies database name > 8 characters.
Fixed.
All Transferred files from RSCS (destination node unknown) not
always detected. Fixed.
All LSVBESTP (called to "allocate" new subscribers to the closest
peer, among other things) does not use the same algorithm as
DIST2, thus causing some problems to sites with local
Internet gateways (user allocated "far away" yet final
distribution done by local server). LSVBESTP updated to use
LSVDIST2 logic.
All Mailing reports that there was no outbound file when several
non-local recipients were present, but all of them with
domain address. Changed message.
All Incorrect output on "Ack=YES" lists when no outbound
recipient. Fixed.
*****************************************************
* Evolution: Changes in default list header options *
*****************************************************
- The default value of the "Ack=" keyword, which controls the type of
acknowledgement sent back as a result of a mailing operation, has been
changed from "Yes" (mail acknowledgement from each peer) to "No"
(single-line message acknowledgement from the first peer only) at the
request of what appeared to be a majority of list owners. Other
possible values are "MSG" (multi-line message acknowledgement from each
peer) and "None" (nothing at all).
- The default value of the "Errors-To=" keyword, defining who is to
receive notification of processing errors related to the list, has been
changed from "Postmaster" to "Owners" at the request of overloaded
postmasters who simply could not handle the load that deleted student
accounts was generating for them, and resent having to spend time
changing the list headers and informing the list owners.
************************************************************************
* Evolution: Solution to the problem of CONCEALed users on DISTRIBUTEd *
* lists (problem introduced in release 1.6a) *
************************************************************************
Concealed users signed up to DISTRIBUTEd lists had complained that, with
the network performance enhancement introduced in the DIST2 command in
release 1.6a, their names would become visible to other recipients of the
same node, which is contrary to the definition of the CONCEAL list
subscription option. This problem could not be "fixed" quickly because it
was a design problem rather than a bug - only the originating server
knows which users are "concealed", whereas it is the distributing server
which builds the mail headers and control their contents.
Rather than restoring the previous behaviour of DIST2 to concealed users,
which, apart from requiring non-trivial changes in the DIST2 protocol for
RFC822 mail, would not have worked properly until all potential
"originating" and "distributing" servers (ie most of the 186 servers
presently in production) have been upgraded, it was decided to deliver
BSMTP-type headers to all concealed recipients of DISTRIBUTEd lists.
These headers, being strictly anonymous, will not disclose the identity
of the subscriber to anybody, and will not require a separate copy of the
message to be prepared and sent to these "concealed" recipients either,
thus not causing any additional load on the network as compared to the
"current" (but unacceptable) 1.6a behaviour.
The QUERY command has been modified to reflect the actual status of the
"Header=" subscription option, depending on the setting of both the
"Conceal=" subscription option and of the "Mail-via=" list header option.
The SET command has been modified to give a warning message when an
attempt to set the "Header=" option to a non-BSMTP value is made by a
concealed user on a DISTRIBUTEd list; the change is accepted, but will be
ignored by the mail exploder, which will automatically treat it as the
corresponding BSMTP value (ie SHORTHDR becomes SHORTBSMTP, FULLHDR
becomes FULLBSMTP).
No action is required from the user, the list owner nor the postmaster to
activate this change.
***********************************
* Enhancement: The new TO command *
***********************************
A new "prefix" command, similar to the MAIL command (which causes the
output from the remainder of the command line to be returned as mail
rather than interactive messages - try MAIL INFO for example), has been
implemented to make it possible to redirect the output of a given command
without having to submit a job file with a "Reply-To=" keyword in the JOB
card. The syntax of this new TO command, which can be freely combined
with the MAIL command, is the following:
TO userid<@node> command-text
or
TO "user1<@node1> user2<@node2>..." command-text
The default nodeid is that of the command originator. For example,
issuing "TO OPERATOR SHUTDOWN" from a service machine with the
appropriate authority will cause LISTSERV to stop, sending the resulting
message to the OPERATOR userid rather than the service machine itself. A
"MAIL TO LISTACNT SHUTDOWN" command would cause the shutdown statistics
to be mailed to LISTACNT, which could be a server whose task is to
collect and process these statistics into daily and weekly reports.
*************************************************************************
* Enhancement: Notification of error conditions in list mail processing *
*************************************************************************
There are two major types of "error conditions" that can be detected when
mail is being processed by LISTSERV:
- Errors causing the note to be rejected, ie its distribution to be
refused, because the note is deemed to be a delivery error
notification; the note will "never" be accepted if re-submitted, unless
it has been previously edited to remove the patterns that triggered the
"detector". These used to cause a small note to be sent to either
postmaster, list owner or originator, with a copy of the mail file in
error sent under separate cover. This made it difficult to correlate
the small messages and actual mail files, especially for non-local
users. All the information is now provided in a single mail file, which
contains both the "diagnostic" message and a copy of the mail file in
error.
- Errors causing the note not to be processed for a cause which might be
transient or correctable (archives disk full, error reading from disk,
maximum mail size exceeded, etc). These used to send a small note to
both originator and postmasters, with the actual file being CP
TRANSFERred to the "main" postmaster. This was doubly inconvenient, as
the main postmaster sometimes had trouble correlating diagnostic
message file and mail file in error, and the originator had simply no
way to know which of the messages he submitted was the cause of the
error, in case he had submitted more than one in a relatively short
period. A single message with both diagnostic and copy of mailfile in
error will now be sent to the originator, while all postmasters get the
same thing and, possibly (depending on the exact nature of the error),
the file is still CP TRANSFERred to the "main" postmaster to make it
easier to "retry" it.
Finally, postings which are rejected because the sender is not authorized
to mail to the list are now returned to the originator along with the
error message, in case he had not kept a copy in his personal files.
******************************************************
* Enhancement/Evolution: Handling of moderated lists *
******************************************************
The handling of moderated ("Send= Editor" or "Send= ...,Semi-Moderated")
lists has always been deemed unsatisfactory by a vast majority of
moderators, although none of them had been able to propose a better yet
general solution, which would benefit the whole moderators community,
BITNET and Internet, "filter-ers" and "digest-ers" alike. Before release
1.6b, mail requiring moderator approval used to be forwarded 'as is' to
the "main" editor in the "preferred" file format for his node, with a
small accompanying message (under separate cover) stating why he had been
sent the mail file. This inconvenient for the following reasons:
1. The small notes, which had no value as far as the moderating process
is concerned, had to be discarded individually.
2. The actual mail file might have been mistaken for private mail, if the
small note was for some reason delayed somewhere in the network.
3. Some mail packages do not handle Netdata input files properly, and
this was the format usually chosen by LISTSERV.
4. Non-BITNET moderators were getting the note enclosed in a mail
envelope, ie with "double headers", which made it difficult to process
as commands like FORWARD or REPLY would not behave as expected.
The logic of moderated lists has been changed in release 1.6b in an
attempt to solve the problems listed above. Mail requiring moderator
approval is now sent via BSMTP as a single message, with original
unchanged headers, and with a descriptive text (the "blurb") inserted on
top of the message body. REPLYing to that message allows the moderator to
ask more information from the sender, and this works for both BITNET and
Internet editors.
In case the editor only acts as a "filter" for incoming messages, rather
than building the messages into a digest, he should simply FORWARD the
message back to the list, without removing the "blurb", after having made
any change he might have deemed necessary. This is now the "official" way
of approving a message for distribution. LISTSERV will automatically
delete the "blurb" from the message when it is received and accepted for
distribution, unless of course the editor has already removed it
manually. This deletion is done in such a way as to preserve any comments
that the editor might have added before forwarding the message (a la Rice
MAIL). That is, LISTSERV will not delete all the text from the top of the
message but only what it has identified as being the "blurb" it had
inserted itself.
Furthermore, if 'Resent-' tags are found in a message sent to a moderated
list and coming from an editor, an 'Approved-By:' tag pointing to the
sender's (editor's) address is added, whereas the generated 'From:' tag
will point to the person listed in the original 'From:' tag, ie the
person who had submitted the message in the first place, rather than to
the editor. Moderators who make digests have no reason to forward their
postings rather than send them directly, and should therefore not be
affected. Finally, the person who had originally submitted the note will
get a copy of the distributed message regardless of the setting of his
REPRO list subscription option, as the editor might have added some
comments, removed a paragraph or otherwise altered the text; even if no
change has been made to the original text, this note will serve as an
acknowledgement of the fact that his contribution has been accepted, and
is consistent with the behaviour of previous versions of LISTSERV
wherein, the origin of the distributed message being that of the editor,
the original submitter would automatically be sent a copy. The editor
will also get his own copy, since the distribution acknowledgement
messages generated by LISTSERV (according to the setting of the "Ack="
list header option) will be sent to the original submitter; the editor's
copy serves as an acknowledgement of the proper distribution of the
message he has approved and forwarded to the list.
Moderators who build digests out of the contributions they receive may be
interested in getting rid of the "blurb" that LISTSERV inserts on top of
the messages, as they would have to delete it manually before inserting
the data into the digest. This can be done through the use of the
"Editor-header= NO" list header option, whose use is not recommended if
you expect to receive any other type of mail in the editor account (ie if
this account is your personal account rather than a special one, set up
for the sole purpose of receiving contributions for the list in
question).
|
