Description of the changes for release 1.2a of LMail(TM)
--------------------------------------------------------
Copyright L-Soft international, 1993
November 11th, 1993
**************
* Highlights *
**************
Version 1.2a introduces the following major enhancements:
- Support for Personal Name Directories (PNDIR), a facility which makes
it possible for your users to be addressed as [log in to unmask]
- Simpler configuration for corporate and non-BITNET customers. See the
updated installation guide for more information.
- Improved PROFS(R) support, including support for delivery of PROFS(R)
compatible mail via IBMMAIL.
- For LISTSERV sites, support for the Global List Exchange (GLX)
introduced in version 1.8a. The GLX is a special mail forwarding system
that lets users write to a LISTSERV mailing list, or to the server that
manages it, without having to know the hostname of the machine running
the list. The GLX will be described in the LISTSERV release notes.
- New <NO>LISTMAIL user preference to selectively turn off receipt of
messages from mailing lists on an individual user basis.
- Support for the RFC1312/MSP "Internet TELL" protocol, which makes it
possible for non-BITNET users to issue commands to LMail. Formerly this
was not possible, as LMail does not support a mail-based interface for
commands (if you send mail to the userid LMail is running under, it is
forwarded to the postmaster under the assumption that it is an error
message from a misconfigured mailer).
- Automatic conversion of delivery errors from IBM (5735-FAL) SMTP
servers to LMail format, for automatic processing through LISTSERV.
****************
* Availability *
****************
Release 1.2a is the first commercial version of LMail. An individual or
collective "service license" is required to receive this update. For
information on individual licenses, write to [log in to unmask] The
following collective licenses were in force at the time of this writing:
- EARN sites receive free access and free upgrades under a collective
agreement valid until July 28th, 1994. Contact the EARN office for more
information.
In general, collective licenses are yearly agreements with volume
discount that are renewed implicitly, but may be terminated at 3 months'
notice. The dates listed above indicate the period for which you are
guaranteed to receive free access to the software, if you qualify under
the agreement, and do not necessarily imply that the agreement will not
be renewed.
Note that, in order to receive free service through a collective license,
you must both qualify under certain criteria defined in the agreement
(such as membership in a particular networking organization) and sign a
contract indicating your acceptance of the licensing terms and
conditions. In other words, you will have to go through some
administrative steps the first time; the software will not be sent
automatically if you have not done the necessary paperwork, even if you
were already running an older version.
Disclaimer: your rights and obligations are defined in the collective
agreements. The summary in these release notes is necessarily incomplete,
and is provided for your information only. The wording of the formal
agreements takes precedence over these release notes.
*******************************
* Supported operating systems *
*******************************
Release 1.2 introduces the following changes to the list of supported
operating systems:
- (1.2a) Support for CMS release 10.
**************************
* External Compatibility *
**************************
Release 1.2a is generally compatible with 1.1d, from the perspective of
the end-user (including postmaster and maintainer), and with the
exception of the changes listed below.
1. The default values of some configuration parameters were changed:
- EXACT_NETDATA_LRECL, changed from 0 to 1.
- SOURCE_ROUTES, changed from 1 to 0.
You can restore the old behaviour by explicitly setting these options
to their old defaults in LOCAL SYSVARS. For more information, refer
to the individual descriptions in SAMPLE SYSVARS.
2. Outbound PROFS(R) compatible mail is now sent with a genuine *MSG
header, rather than a :READ control card. In principle, this change
should improve compatibility with PROFS(R), and in particular fill
the PROFS(R) subject line with the appropriate value. This may,
however, impact customer-written applications that rely on the old
behaviour.
Release 1.2a is to be installed directly on top of the base 1.1d code,
and was relinked with version 1.8a of the LISTSERV library. The following
library fixes and enhancement are included:
17F-0004 93/04/12 Convert the FOR command to PASCAL
17F-0012 93/04/26 Convert the SERVE command to PASCAL
17F-0014 93/05/02 Use new PASCAL pattern-matching routines
17F-0016 93/06/07 Propagate serve off increment to FOR command originator
17F-0018 93/07/07 Convert the DEBUG command to PASCAL
17F-0035 93/07/21 Convert trivial commands to PASCAL
17F-0040 93/07/22 Correct spelling error in '%pv'
17F-0042 93/07/23 Improve address parser diagnostics
17F-0058 93/08/13 Return booleans that survive a double 'not'
17F-0060 93/08/16 Suppress empty '-->' migration messages on console log
17F-0072 93/09/16 Avoid out-of-storage crash with huge junk input files
17F-0080 93/11/11 Fix error with multiple source routes
**************************
* Internal Compatibility *
**************************
The most important internal changes are briefly described below; refer to
the LMAIL-L archives for more information.
1. New source files have been generated for version 1.2, incorporating
all existing updates into the base code. The source files have not
been resequenced. The AUX files shipped with 1.2 will contain only
commented entries. This change was made for legal reasons, so that
there would be no conflict in the copyright statements.
2. The REXX programs LSMCM1, LSMDEBUG, LSMFOR and LSMSERVE have been
removed as the corresponding functions are now provided by PASCAL
code in the version 1.8a LISTSERV library.
**************************
* Compatibility Warnings *
**************************
This new section describes planned changes which may affect compatibility
(both external and internal). The release in which the change is planned
to be introduced is indicated, with the letter 'x' denoting an unknown
release of the specified major version (not necessarily posterior to the
last release explicitly mentioned).
<No planned change to date>
********************************
* Minor fixes and enhancements *
********************************
This section contains a brief description of all the "small yet not
unimportant worries" that have been fixed in release 1.1d, along with the
affected releases, if known ("All" meaning "any release in which the
facility is available", ie the problem was present since the very
beginning).
Minor enhancements which do not warrant a detailed description are also
included; they are all located at the bottom of the list, and can be
identified by the word "New" in the "Affected releases" column.
Affected
releases Description of the bug, problem or enhancement
-------- ----------------------------------------------
All The OVERRIDE files may now reside on any accessed minidisk.
All TELL messages from addresses in the IGNORE list are no longer
counted as one command in the SHOW statistics report.
New The new SOURCE_ROUTES option lets you control whether LMail
should perform the "relaying" function described in RFC821
(3.6), ie add a source route through the local node to the
MAIL FROM: field of relayed messages. By default, LMail will
no longer do that, as many sendmail systems are shipped with
a configuration file (sendmail.cf) that produces incorrect
results with loss of data when there are two or more source
routes in the MAIL FROM: field.
New The new ERRORS_TO configuration variable lets you define an
alternate delivery address for error messages normally sent
to the postmaster when CC_POSTMASTER_ON_ERROR is set to 1.
This can be useful for logging purposes, or to route these
computer-generated messages to a lower-priority mailbox than
messages from end users that were explicitly sent to the
'postmaster' mailbox.
New The SERVE command and associated functions are no longer case
sensitive. The "serve off" threshold was changed from 10 to
20 incorrect commands.
*********************************************************
* Usability: Personal Names Directories (PNDIR) support *
*********************************************************
A Personal Names Directory (PNDIR) is a list of names and e-mail
addresses which LMail uses to implement a kind of forwarding and lookup
system that allows your users to be known via stable, generic addresses
such as [log in to unmask] rather than [log in to unmask]
Apart from being more user-friendly and easier to remember, the address
based on the personal name does not change if the users decide to read
mail on another system, which eliminates the problem of having to change
list subscriptions. Personal names can be abbreviated as long as they
remain unique; for instance, mail for 'J.Smith' will be accepted for
delivery to 'John.Smith' as long as there is no other entry in the
directory with the surname 'Smith' and a firstname starting with 'J'. In
case of conflict, or if no user by the specified name is registered in
the directory, LMail returns a list of "close" matches with similar
spelling, with the corresponding e-mail addresses. You can supply
additional information to be returned together with the e-mail address,
such as "Geology department", or a phone number. The directory can be
queried easily by remote users, without having to install a special
client. For instance, to get a list of all the Smiths one would simply
send mail to '?.Smith' and LMail will return a list of "close matches"
without delivering the message.
The use of personal names directories is of course optional. Refer to the
updated installation guide for more information.
***********************************************************************
* Usability: Support for remote PROFS(R) nodes and IBMMAIL(R) gateway *
***********************************************************************
The DIRECT exit has been modified in order to support remote PROFS(R)
nodes. Previously, the only way to deliver PROFS(R) compatible mail was
to run LMail (or a similar product) on the remote node, and use the BSMTP
exit to route the traffic. This may now be accomplished by a HOST
OVERRIDE entry of the form:
nodeid nodeid - DIRECT PROFS
Note that this option affects all mail going to the specified node. It is
not possible to set user preferences for remote users. If only a subset
of the remote users are to receive mail in PROFS(R) format, you should
install LMail on the remote system and define the appropriate user
preferences on the remote LMail.
With the configuration mentioned above, the NJE origin of the messages
will be the userid under which LMail is running. In principle, PROFS(R)
users will see the correct origin when they open their mailbox. However,
security gateways such as IBMMAIL may reject the message because the
LMail userid is not authorized for the remote address. NJE-level gateways
do not generally have the concept of "mailer" and it is not usually
possible to register LMail's userid as an authorized source for any user
on the LMail system. In order to bypass this limitation, a DIAGD4 option
is available to direct LMail to use diagnose X'D4', for which it must be
authorized in the CP directory, to properly set the NJE origin. The HOST
OVERRIDE entry could be:
IBMMAIL IBMMAIL - DIRECT PROFS DIAGD4
When the DIAGD4 option is specified, the following restrictions are
placed on outgoing traffic to the corresponding target node:
1. Mail coming from a remote system cannot be gatewayed, because there is
no safe and stable interface for LMail to impersonate remote users, or
perform the necessary security verifications. Such messages are
properly rejected with a regular delivery error.
2. When the RFC822 header origin ('From:' or 'Sender:') does not match
the CP spool origin userid, the message is rejected to prevent
possible unauthorized use when the recipient is using an RFC822-based
mail program.
3. LMail must be authorized for diagnose X'D4' or an abend S0C2 will
occur.
See the updated installation guide for more information.
********************************************************
* Usability: Support for RFC1312/MSP ("Internet TELL") *
********************************************************
Version 1.2a introduces support for the RFC1312/MSP interactive message
protocol, through third-party MSP servers only. That is, LMail does not
attempt to take control of the MSP port or deliver MSP messages on its
own, but relies on a separate virtual machine for this function. This
avoids duplication of code and effort, providing a simpler and more
robust interface to MSP for other servers and users.
To enable MSP support, you must install suitable MSP software (see below)
and register the userid of the MSP server (traditionally MSGD) in LOCAL
SYSVARS. The corresponding variable is called MSGD, so the definition
will usually read:
MSGD = 'MSGD' /* MSP server runs under the 'MSGD' userid */
In order to be usable with LMail, a MSP server must provide the following
interface:
1. Incoming messages must be delivered via CP MSG or CP MSGNOH. The text
of the (CP) message must be the following:
From hhhhh(uuuuu): ttttt
Blanks are allowed before the word 'From', and before or after the
message text (ttttt).
2. The server must accept requests to deliver MSP messages via SMSG, with
the following syntax:
CP SMSG xxxxx M hhhhh uuuuu ttttt
3. When possible, it is recommended that the server be configured to
reject messages from users for which no reverse address translation is
available, when the target is a server such as LMail (the MSP protocol
provides a mechanism for rejecting messages with an error code). This
usually happens when a name server is down. LMail cannot process
commands coming from addresses such as [log in to unmask] and will ignore any
such message.
A free MSP server for VM, written by Bert Barbe, is available from
LISTSERV@BLEKUL11 under the name MSGD PACKAGE. At the time of this
writing this was the only MSP implementation known to L-Soft that
complies with points 1 and 2 above.
Disclaimer: L-Soft international ("Licensor") does not represent or
warrant that the foregoing information is accurate, that the MSP
product mentioned above ("Software") will be freely available to
Licensor's customers, that it will remain compatible with
Licensor's products, or that it will operate to the customer's
satisfaction. Licensor will not provide error information or
correction for the Software, or assume any liability whatsoever
concerning its use, including, but not limited to, liability for
consequential damages, even in the event that Licensor had been
notified of the possibility of such damage. The customer's use of
the Software is at his own risk.
Note: the word "Software" in the disclaimer refers to MSP, not LMail.
L-Soft will, of course, accept software trouble reports for LMail from
customers with a valid service license.
***********************************
* Security considerations for MSP *
***********************************
Before enabling MSP support, you should note that the level of security
currently available through MSP is lower than what is available from NJE
interactive messages. In particular, it is very easy for a non-privileged
users to forge messages coming from a different user at the same host.
While SMTP mail can be forged easily as well, LMail does not presently
accept commands via electronic mail and is not exposed to attacks from
the Internet.
*****************************************************************
* Usability: Conversion of SMTP delivery errors to LMail format *
*****************************************************************
Version 1.2a includes code that automatically converts delivery error
notices from VM SMTP servers to the LMail format. The delivery error is
carefully examined to determine a suitable error code (no such host, no
such user, etc). When LMail is not sure that the delivery error came from
a 5735-FAL server, or when the information is not conclusive, it either
leaves the message unchanged or generates a reformatted delivery error
with error code 0 ("unknown"), which is by definition a "soft" error. The
converted delivery error includes a verbatim copy of the original
delivery error text. You can, if necessary, disable this automatic
conversion by adding the following line to LOCAL SYSVARS:
FAL_CONVERT = 0
The converted delivery errors are directly usable by LISTSERV (version
1.7f or higher) for automatic removal of invalid entries from mailing
lists. Since most LISTSERV mail to Internet recipients is gatewayed via
INTERBIT, the benefits of the converted delivery errors will be available
to all BITNET list owners as soon as the INTERBIT sites have migrated to
version 1.2a.
***********************************************
* Usability: New <NO>LISTMAIL user preference *
***********************************************
The new <NO>LISTMAIL user preference controls whether LMail should reject
or deliver mail coming from mailing lists (as opposed to private
person-to-person mail). By default, both personal and list mail is
delivered, unless you specify otherwise in the UOPT_DEFAULT in LOCAL
SYSVARS. Like any other user preference, LISTMAIL can be set on an
individual user basis, and on behalf of general users by privileged LMail
administrators.
LMail attempts to determine whether a particular mail message comes from
a mailing list by inspecting the MAIL FROM: address. If it is of the form
'owner-xxx' or 'xxx-request', LMail assumes the message is from a mailing
list. While there are mailing lists not using that convention, the risk
of rejecting a private message by accident is very low.
When LMail determines that a mailing list message should be rejected, it
issues a delivery error with, by default, an error code of 4. This is a
new error code that indicates that the user is not accepting mail from
mailing lists, but that the address is otherwise valid and operational;
LISTSERV should remove the user from mailing lists, but not from other
registration files such as AFD/FUI lists, as these may still be wanted.
Because this new error code is unknown to version 1.7f, it will not cause
automatic deletion with older servers. To bypass this, a temporary
configuration option, NOLISTMAIL_CODE, has been provided. To force
version 1.7f servers to sign off users with the NOLISTMAIL option, add:
NOLISTMAIL_CODE = 3
to LOCAL SYSVARS. Note that, at present, LISTSERV only supports automatic
removal for mailing lists. As of version 1.8a, there is no difference in
processing between error codes 3 and 4. This however may change when the
file server functions are converted to PASCAL. You should not rely on the
fact that the two codes are treated identically by the current versions.
NOLISTMAIL is an alternative to the obsolete "netwide DELETE" function
for VM userids which, while they are not being terminated, must for one
reason or another be removed from all mailing lists. NOLISTMAIL does not
introduce any CPU or network overhead for users which are not actually
subscribed to any mailing list. In addition, it also filters mail from
most Internet/sendmail mailing lists, which "netwide DELETE" could not
do.
-------------------------------------------------------------------------
LMAIL and L-SOFT are trademarks of L-Soft international.
IBM and PROFS are registered trademarks of International Business
Machines Corporation.
-------------------------------------------------------------------------
|
