From: CRDGW2::CRDGW2::MRGATE::"SMTP::YMIR.CLAREMONT.EDU::POSTMAST" 28-OCT-1989 02:52 To: MRGATE::"ARISIA::EVERHART" Subj: Announcing PMDF V3.1 (press release) Resent-From: postmast@YMIR.CLAREMONT.EDU Received: from HMCVAX.BITNET by YMIR.BITNET; Fri, 27 Oct 89 23:24 PDT Resent-Date: Fri, 27 Oct 89 23:28 PDT Date: Fri, 27 Oct 89 23:16 PDT From: "Ned Freed, Postmaster" Subject: Announcing PMDF V3.1 (press release) Resent-To: INFO-PMDF-LIST2@YMIR.CLAREMONT.EDU To: INFO-PMDF@YMIR.CLAREMONT.EDU Errors-To: postmast@YMIR.CLAREMONT.EDU Resent-Message-Id: <31656A3D653F0000A1@YMIR.BITNET> Message-Id: <31673A32489F8001A9@HMCVAX.BITNET> X-Vms-To: IPMDF Innosoft International is pleased to annouce the release of version 3.1 of PMDF. Despite the fact that this is a "minor release" of PMDF, this new version includes a large number of enhancements and extensions. The motivation for most of the changes made in version 3.1 is simple -- performance. PMDF version 3.1 typically out-performs previous releases by a factor of 2-3 overall. Small configurations will perceive less of a performance improvement, but very large configurations may see a performance increase of a factor of 10 or more. The most important performance enhancement in version 3.1 is the ability to precompile configuration information into a special configuration data image. This image is written in a format compatible with the VMS image activator, making it possible to use the VMS INSTALL utility to install the image for additional performance gains. PMDF has also been brought into compliance with the draft version of the Internet Requirements standard as it applies to SMTP-based mail systems. WHAT IS PMDF? The Pascal Memo Distribution Facility (PMDF) is a general-purpose system for delivering computer-based mail. PMDF provides a uniform distribution environment that can be interfaced to multiple user interfaces and transport mechanisms. This version of PMDF for VAX/VMS, called PMDF-822 V3.1, uses the standard VMS MAIL facility as its user interface and provides support for the PhoneNet asynchronous dialup protocol as its primary transport mechanism. PMDF-822 V3.1 also supports PhoneNet over DECnet, SMTP over DECnet, DECnet-based MAIL-11 MAIL (called DECnet MAIL in this document), JNET (a product of Joiner Associates Inc., this is an implementation of the IBM RSCS networking system using NJE protocols for VAX/VMS), ANJE (an implementation of RSCS and NJE for VAX/VMS written at Argonne National Laboratory and available from the National Energy Software Center), SMTP over TCP/IP (accomodating the Carnegie Mellon University, Excelan, NRC FUSION, TGV Multinet, ULTRIX Connection, Tektronix, and Wollongong implementations for VAX/VMS), SMTP over an arbitrary I/O channel, SMTP over X.25 links (using VAX PSI, a product of Digital Equipment Corporation, to provide X.25 service), PhoneNet over X.25 links (also using VAX PSI), PSIMail, and UUCP (using the DEC/Shell implementation of UUCP), as transport mechanisms. PMDF-822 is used to perform the PhoneNet function of NSF's CSNET on VAX/VMS systems. PMDF-822's interface to JNET or ANJE provides a powerful MAIL interface to the NJE-based BITNET network. ABOUT INNOSOFT PMDF is marketed and distributed by Innosoft International, Inc., of Claremont, California. Founded in 1987 by the developers of PMDF and MATHLIB, Innosoft develops and supports communications and systems software for VAX/VMS as well as high-performance software tools for mathematical analysis. For information about pricing and availability of Innosoft products, please contact: Innosoft International, Inc. 250 West First Street, Suite 240 Claremont, CA 91711 (714) 624-7907 (714) 621-5319 (fax) E-mail: iii@ymir.claremont.edu NEW FEATURES The following new features have been added to PMDF version 3.1: (1) PMDF V3.1 will work under VMS versions 4.4 through at least 5.2. However, PMDF can only be recompiled under VMS version 5.0 or greater; PMDF uses 5.0-specific definitions from the system environment file STARLET.PEN. A 5.0 STARLET.PEN may make it possible to recompile PMDF under an earlier version of VMS, but this has not actually been done and there are no guarantees that it will work. Relinking of PMDF can be done under VMS version 4.4 or later, but is best done with the version of VMS that will actually be used on the system running PMDF. PMDF V3.1 is the last version of PMDF that will work with VMS versions prior to 5.0. Future PMDF releases will only work with VMS 5.0 or later. (2) PMDF V3.1 includes a new precompilation facility which converts the configuration and aliases files into a VMS shareable image. The resulting shareable image can then be installed using the standard VMS INSTALL utility. The performance improvement that comes from not having to read the text files all the time is considerable. (3) PMDF V3.1 uses internal hash tables and binary searches to locate configuration information in its internal data structures. Once again, the resulting performance improvement over V3.0's linear searches is considerable. (4) Code to detect messages caught in infinite loops has been added to PMDF. The code counts Received: lines that contain references to the local system. If too many received lines (controlled by the compile-time constant mm_max_local_received_line, which is set to 10 by default) are detected the message is entered into the PMDF queue area as a held message, which then requires manual intervention prior to further processing. (5) PMDF now attempts to write its temporary files on the disk pointed to by SYS$SCRATCH instead of on the current disk. If this attempt fails PMDF will revert to using the disk pointed to by SYS$DISK as it used to. This fix allows nonprivileged users to send mail while they are SET DEFAULTed to a disk on which they have no disk quota. (6) PMDF now places a Message-id: or Resent-message-id: header line in the headers of messages it processes. If a Message-id: header line is already present PMDF does not add one. PMDF only adds a Resent-message-id: header line if other Resent- header lines are present and no Resent-message-id: header is present. (7) Limited support for Errors-to: and X-Organization: header lines has been added. Users may now set these headers using logical names. An Errors-to: header may be generated automatically on messages distributed on a mailing list (see the previous item). PMDF preserves but ignores the contents of these header lines. (8) The rewrite rule format "a@b@c@d" is now supported. This uses "a" as the new user name, "b" as the new host/domain specification, "c" as inserted as a source route, and "d" as the routing system. (9) PMDF now supports domain literals in addresses. Special rewriting facilities for domain literals are provided. Domain literal support has not been added to all TCP/IP channels; at present it is only available in the Multinet and Wollongong channels. (10) CRDB has been changed so that when it encounters a new entry with the same left hand side as an existing entry it replaces the old entry with the new one. Previously it simply ignored the new entry. PTOREW has NOT been changed in a similar fashion; it still behaves as it always has. (11) PMDF now deletes old temporary files (files with .TMP extensions) left in the log directory PMDF_ROOT:[LOG]. These files are occasionally left by improperly terminated dialin sessions. (12) It is now possible to control all of the wait times used by the PhoneNet protocol from the options file. The new wait time options all default to their previous hard-wired values if no option is specified. (13) The terminal characteristics SPEED (or baudrate), EIGHTBIT, HOSTSYNC, TTSYNC, and PARITY may now be controlled from a PhoneNet channel options file. Parity is generated internally; the line setting is not changed. (14) The RFC822 header parser now imposes a limit of 1000 lines on message headers. This prevents runaway headers from consuming large amounts of memory and possibly exceeding virtual memory limits on PMDF jobs. (15) The PhoneNet master channel program now handles lists of possible devices correctly. If the device name specified is a logical name search list, MASTER will scan the list trying each device until it finds one that is not in use. (16) The PhoneNet master channel program now correctly establishes outgoing LAT communications using the LAT $QIO interface. (17) BN_SLAVE's method of generating an envelope From: address for the messages it processes has been changed. Previously, if the selected header address was not a valid local address (i.e. associated with some channel) PMDF would force the address to a null string. Now PMDF only forces the address to a null string if it is syntactically invalid; semantics do not apply. (18) Support for a X-Envelope-to: header line has been added. This header line is filled with a list of the envelope To: addresses. This header line is specific to each copy of a message. Generation of this line can be controlled on a per-channel basis with the x_env_to and nox_env_to keywords. Currently the X-Envelope-to: is only used to reconstruct envelope addresses that have been truncated by the NJE protocols. However, the availability of the actual envelope contents is often very useful for debugging, and may be used in additional ways in the future. (19) The handling of personal names while building a PMDF From: address from a VMS MAIL From: address has been enhanced. Previously if the address was a PMDF foreign protocol address any personal name information outside the protocol construct was discarded. This has been changed so that the outer personal name will be used if it is present and no personal name appears inside the foreign protocol address structure (e.g. between the IN%" and the trailing "). (20) Include files are now allowed in the configuration file. The special form "