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. -------------------------------------------------------------------------