Message Exchange Release Notes December 1995 This file contains the release notes for Message Exchange V4.2. It describes any features, restrictions, changes, or additions made to MX in this release, and includes information that is not provided elsewhere in the MX manual set. Revision/Update Information: This is a revised manual. Operating System and Version: VMS V5.0 or later OpenVMS AXP V1.0 or later Software Version: Message Exchange V4.2 Hunter Goatley MadGoat Software ________________________ 11 December 1995 Permission is granted to copy and redistribute this document for no commercial gain. The information in this document is subject to change without notice and should not be construed as a commitment by MadGoat Software. The authors and MadGoat Software assume no responsibility for any errors that may appear in this document. DISCLAIMER: The software described in this document is provided "as is". No guarantee is made by the authors or the authors' employers as to the suitability, reliability, security, usefulness, or performance of this software. MX was originally written by Matthew D. Madison, formerly of Rensselaer Polytechnic Institute and currently employed by TGV, Inc. The software is currently maintained by Hunter Goatley, formerly of Western Kentucky University and currently employed by The LOKI Group, Inc. The following are trademarks of Digital Equipment Corporation: DEC DECnet P.S.I. ULTRIX VAX VAXcluster VMS AXP VMScluster Jnet is a registered trademark of Wingra Technologies, Inc. MultiNet is a registered trademark of TGV, Inc. TCPware is a trademark of Process Software Corporation. WIN/TCP and Pathway are registered trademarks of The Wollongong Group, Inc. __________ Copyright ©1995 MadGoat Software. ALL RIGHTS RESERVED. _______________________________________________________ Contents _______________________________________________________ CHAPTER 1 INSTALLATION NOTES 1-1 _________________________________________________ 1.1 MX MESSAGE QUEUE FORMAT CHANGED 1-1 _________________________________________________ 1.2 MX MUST BE SHUTDOWN 1-1 _________________________________________________ 1.3 JNET LOGICALS MUST BE DEFINED 1-2 _________________________________________________ 1.4 TGV MULTINET CONFIGURATION NOTES 1-2 _________________________________________________ 1.5 DECUS UUCP NOTES 1-2 _______________________________________________________ CHAPTER 2 UPGRADE INFORMATION 2-1 _________________________________________________ 2.1 JNET V3.5 REQUIRED 2-1 _________________________________________________ 2.2 NEW DATA FILE FORMATS 2-1 _________________________________________________ 2.3 CONFIGURATION FILE CHANGES 2-1 _________________________________________________ 2.4 NEW NETLIB 2-2 iii Contents _______________________________________________________ CHAPTER 3 NEW FEATURES AND CHANGES IN MX V4.2 3-1 _________________________________________________ 3.1 NETLIB V2.0I 3-1 _________________________________________________ 3.2 MCP ENHANCEMENTS 3-1 _________________________________________________ 3.3 MX MLF ENHANCEMENTS AND CHANGES 3-2 _________________________________________________ 3.4 MX SMTP SERVER ENHANCEMENTS 3-3 _________________________________________________ 3.5 MISCELLANEOUS ENHANCEMENTS 3-3 _______________________________________________________ CHAPTER 4 BUG FIXES 4-1 _______________________________________________________ CHAPTER 5 KNOWN BUGS AND RESTRICTIONS 5-1 _________________________________________________ 5.1 SMTP LOOPING/FORWARDING BUG 5-1 _________________________________________________ 5.2 X.25-SMTP BUG 5-2 _________________________________________________ 5.3 DECUS UUCP UUCP_MAILSHR BUG 5-2 _________________________________________________ 5.4 VMS MAIL BUGS 5-2 iv Contents _________________________________________________ 5.5 VMS CALLABLE MAIL MEMORY LEAK AND MX LOCAL 5-3 _________________________________________________ 5.6 MXALIAS AND THE MX% ``@'' PATCH FOR VMS MAIL 5-3 _________________________________________________ 5.7 POSSIBLE FORWARDING PROBLEMS 5-3 _________________________________________________ 5.8 REMOTE FORWARDING PROBLEMS 5-4 _________________________________________________ 5.9 BYPASS NEEDED FOR UUCP DELIVERY 5-4 _________________________________________________ 5.10 ROUTES IN SMTP ACCOUNTING LOGS 5-4 _________________________________________________ 5.11 MULTIPLE ACCOUNTING LOGS GET CREATED 5-4 _______________________________________________________ CHAPTER 6 PROBLEM REPORTS 6-1 v _______________________________________________________ 1 Installation Notes This chapter contains items of interest pertaining to the installation of MX. __________________________________________________________________ 1.1 MX Message Queue Format Changed With MX V4.0, the format of the MX message queue file changed from an indexed file to a direct-access sequential file. If you are upgrading to MX V4.2 from a version of MX prior to V4.0, your MX message queue will NOT be converted to the new format. Note: IF YOU ARE UPGRADING FROM MX V3.x, A NEW QUEUE FILE MUST BE CREATED. IF THE MX QUEUE IS NOT EMTPY WHEN YOU INSTALL MX V4.2, ALL MESSAGES IN THE OLD QUEUE WILL BE LOST!!!! The new format includes information that is not present in the old format, making it impossible for the old file to be converted. __________________________________________________________________ 1.2 MX Must Be Shutdown If you are upgrading to MX V4.2 from a previous version, all MX processes on the system or cluster must be shutdown using the MCP SHUTDOWN command. Also, you should define the MX_SHUTDOWN logical (MX V4.0+) or deassign the MX_MAILSHR system logical to prevent users from sending mail via MX during the installation. 1-1 Installation Notes __________________________________________________________________ 1.3 Jnet Logicals Must Be Defined If you are installing Jnet interface support, the Jnet logical names must be defined before you install MX. If you stop Jnet prior to installing MX, use the WARM stop option: $ @JAN_SYS:JANSTOP WARM __________________________________________________________________ 1.4 TGV MultiNet Configuration Notes You should ensure that your fully qualified domain name (FQDN) is entered in MULTINET:HOSTS.LOCAL as your primary host name. If it is not, messages may go out with invalid return addresses. To check this, edit the file MULTINET:HOSTS.LOCAL and look for the line that reads HOST : x.x.x.x : host-name : system-type : VMS : : where "x.x.x.x" is your IP address and "host-name" is your host name, which should be the FQDN. If it is not, edit the entry with your FQDN and save the file. If you changed HOSTS.LOCAL, you should recompile it and update MultiNet's host table: $ MULTINET HOST_TABLE COMPILE $ @MULTINET:INSTALL_DATABASES __________________________________________________________________ 1.5 DECUS UUCP Notes There is a bug in the DECUS UUCP mailer (pre-V1.3-2) in that it does not correctly handle messages that have a From_ line without a "remote from" clause. This will cause MX messages going out through UUCP to have an incorrect From_ address containing an extra bang character (!). This bug is fixed in V1.3-2 of the UUCP mailer image (UUCP_MAILSHR.EXE). 1-2 Installation Notes The current version of DECUS UUCP is V2.0; it can be obtained via anonymous ftp from ftp.spc.edu in [.DECUS_UUCP] or from FILESERV@WKUVX1.WKU.EDU as package UUCP020. Note that the FILESERV distribution contains only the minimum required UUCP savesets. 1-3 _______________________________________________________ 2 Upgrade Information This chapter contains information of interest to sites upgrading from previous versions of MX. __________________________________________________________________ 2.1 Jnet V3.5 Required The Jnet interface support in MX V4.2 requires Jnet V3.5 or higher to operate. MX V2.3-1 was the last version to support Jnet V3.4. If you are still running Jnet V3.4, you should not upgrade to MX V4.2. __________________________________________________________________ 2.2 New Data File Formats Some of the data files used by MX, specifically the .xxx_INFO and mailing list files, have changed in format from earlier releases of MX. MX V4.2 will read the pre-V3.0-format files, but the new format cannot be read by any previous release of MX. __________________________________________________________________ 2.3 Configuration File Changes Configuration files from MX V2.1 through V4.0 can be read by MX V4.2. However, the format used in this release is not usable with prior releases of MX. Configuration files from releases of MX prior to V2.1 are not usable with MX V4.2. It is strongly recommended that all sites running versions of MX prior to V3.0 use the MXCONFIG command procedure supplied with this release to build a new configuration file that takes advantage of the new routing features that became available in V3.0. 2-1 Upgrade Information __________________________________________________________________ 2.4 New NETLIB The version of NETLIB supplied with this kit is the latest version available. It is recommended that all sites using NETLIB (for SMTP support) install the version in this kit. 2-2 _______________________________________________________ 3 New Features and Changes in MX V4.2 This chapter notes the new features added to MX V4.2. __________________________________________________________________ 3.1 NETLIB V2.0I MadGoat Software's NETLIB V2.0I is included with MX V4.2. NETLIB V2.0I is a C rewrite of the original NETLIB V1.x routines. Thanks to Matt Madison. __________________________________________________________________ 3.2 MCP Enhancements o The MCP commands SHUTDOWN, RESET, and STATUS now accept a /NODE qualifier to limit the affect of the commands to those agents running on specific nodes. o The DEFINE LIST and MODIFY LIST commands now accept a /DIGEST qualifier. o The MCP commands DEFINE LIST and DEFINE FILE_SERVER now check for the existence of a file server or list, respectively, with the same name as the supplied list or file server name. In previous versions of MX, it was possible to define a file server and a list with the same name, but mail would always be routed to the file server, without warning. 3-1 New Features and Changes in MX V4.2 __________________________________________________________________ 3.3 MX MLF Enhancements and Changes o MX MLF was modified to support a new DENY flag for subscribers. The DENY flag can be used to add a subscriber to a closed mailing list (one which does not allow WORLD writes) and still prevent that subscriber from posting to the list, thus denying the subscriber access to the list. Subscribers with the DENY flag set cannot post to the list, will not receive posts to the list, cannot change their subscriber entry, and cannot remove themselves from the list. The MX MLF ADD command supports the /DENY and /NODENY qualifiers. o The MX MLF REMOVE command now supports /NOCASE. o The MX MLF processor now adds a Date: header to mailing list posts without one. This was necessary because some SMTP servers reject messages without a Date: header. o A check was added to the MX MLF processor to detect messages from automated mail daemons. Messages from "Postmaster," "Mailer-Daemon," "uucp," "mmdf," "UCX_ SMTP," "LISTSERV," and "MXserver" are no longer processed by the MX MLF processor. This enhancement was added to prevent mail loops created when an automated mailer sends bounce messages to a mailing list or to the list processor itself. o Support for mailing lists digests was added to MX MLF. This involved adding: o /DIGEST qualifier to MCP DEFINE/MODIFY LIST commands. o Recognition of listname-DIGEST addresses. o SET DIGEST commands for MXserver and -request addresses. o /DIGEST qualifier to MX MLF ADD command. 3-2 New Features and Changes in MX V4.2 o Automatic list forwarding for -digest address. Only a system user or a list owner can post a message to a list-DIGEST address. A message sent to list-DIGEST from any other user is treated as a post to the regular list (which will eventually end up in the daily digest). Note: The MX-DIGEST files are still required. __________________________________________________________________ 3.4 MX SMTP Server Enhancements o By default, the MX SMTP Server listens for incoming connections on port 25. You can now specify a different TCP/IP port by defining the logical MX_ SMTP_PORT. For example, to make the MX SMTP Server listen for connections on port 1025, execute the following command before starting the MX SMTP Server: $ define/system/exec mx_smtp_port 1025 __________________________________________________________________ 3.5 Miscellaneous Enhancements o Error-handling logic in the various MX agents has been enhanced in this version of MX. o The MX Router was modified to perform site-specific header rewrites for all messages, regardless of origin. This was needed to allow site-specific aliases for messages coming from such sources as Eudora (using the ADDRESS_REWRITER feature). o MX now supports the UCX$TZ logical, which was added to Digital TCP/IP Services for OpenVMS V3.2. o The following [CONTRIB] packages have been updated or added: o MX-DIGEST.ZIP-Provides digest support for MX mailing lists. 3-3 New Features and Changes in MX V4.2 o MX_REFEED.ZIP-Provides a means by which entries can be reentered into the MX queue. o MX_WATCHDOG.COM-A command procedure that will help ensure that all MX processes are running. 3-4 _______________________________________________________ 4 Bug Fixes MX V4.2 provides the following fixes to bugs in V4.0: o Fixed bug in MX_START.COM that prevented some log file names from including node names. o Fixed a bug in MCP QUEUE COMPRESS that could cause queue corruption. o Modified the behavior of the MCP command QUEUE PURGE so that ROUTER entries are purged after all non- ROUTER entries. Previous versions of MX deleted entries sequentially. If the PURGE process was interrupted for some reason, agent entries that referenced purged router entries could be left behind, causing confusing QUEUE SHOW displays and other problems. (This same modification was also made to the MX Router and MX FLQ Manager images.) o Fixed a couple of bugs introduced in MX V4.1 that occasionally caused the various agents to die with access violations while attempting to update entry information. MX SMTP processes were especially prone to this problem. 4-1 _______________________________________________________ 5 Known Bugs and Restrictions __________________________________________________________________ 5.1 SMTP Looping/Forwarding Bug When using MX with any TCP/IP package (except CMU-Tek TCP/IP V6.5 or later), and you have a wildcard mail exchanger record registered in the Domain Name System (DNS) for your domain, some SMTP messages may not be sent correctly; they may instead be looped back to your own host, or forwarded to whatever host is host specified in the wildcard mail exchange record. Background The DNS mail exchanger lookup process that MX uses by default automatically adds your domain name to the name being looked up, in order to resolve abbreviated names into their full domain names. This process does not mix well with wildcard mail exchangers, since all references will match the wildcard mail exchanger and will always route mail to the host specified as the exchange. For example, if your host is called HOST1.DEPT.SCHOOL.EDU, and there is a mail exchange record in the DNS of the form: *.DEPT.SCHOOL.EDU. 123 IN MX 10 HOST1.DEPT.SCHOOL.EDU. Then you will see this looping problem. These wildcard-type records are generally used to specify a host as a gateway for handling all mail destined for a domain or subdomain. If your host is acting as such a gateway, and you cannot eliminate the wildcard mail exchanger record, then you may need to add the following definition to your system startup sequence before MX is started: $ DEFINE/SYSTEM/EXEC NETLIB_DOMAIN "." 5-1 Known Bugs and Restrictions This will override the default mail exchanger lookup behaviour used by MX and NETLIB. For further information on the NETLIB_DOMAIN logical name, see the NETLIB Release Notes. __________________________________________________________________ 5.2 X.25-SMTP Bug Messages received via X25_SMTP that contain very long lines may be rejected by the X.25 SMTP server. Currently, the only fix is to wrap the long line before sending the message. __________________________________________________________________ 5.3 DECUS UUCP UUCP_MAILSHR Bug Binary files sent through MX to DECUS UUCP can cause the MX->uucp process to go into a compute-bound infinite loop. This is a bug in the DECUS UUCP UUCP_ MAILSHR's handling of the temporary file created by MX. Attempts to SHUTDOWN the MX uucp intfc will fail; you must use STOP/ID to kill the process, CANCEL the message, then restart the UUCP agent. According to the DECUS UUCP developers, this will be fixed in the next release of DECUS UUCP. __________________________________________________________________ 5.4 VMS MAIL Bugs In VMS V5.0 through V5.1-1, a bug in VMS MAIL parsing code will cause a process to loop infinitely if the trailing quotation mark is omitted from a foreign- protocol address specification, as in: To: MX%"user@domain In VMS V5.2, the infinite loop was replaced by an error condition that is signaled which aborts the VMS MAIL session. This bug remains through VMS V5.5-2. 5-2 Known Bugs and Restrictions __________________________________________________________________ 5.5 VMS Callable MAIL Memory Leak and MX Local The VMS callable MAIL routines do not properly release all the virtual memory that they allocate. This VMS bug can eventually cause the MX Local agent to exit with an ``Insufficient virtual memory'' error or go into an infinite loop. The chances of the bug causing problems depend greatly on the number of messages processed by MX Local and your system configuration. This bug in callable MAIL has been acknowledged by Digital in a DSNlink article. It has ``been reported to VMS Engineering.'' __________________________________________________________________ 5.6 MXALIAS and the MX% ``@'' Patch for VMS Mail If you've installed the VMS Mail patch that lets users leave off the MX% for addresses (found in the [.CONTRIB] directory), MXALIAS addresses must still be prefixed by MX% to be recognized. MX_MAILSHR will try to lookup an ALIAS if the MX address does not include an ``@'' in the address received from VMS Mail. With the VMS Mail ``@'' patch installed, MX aliases are not passed to MX unless they are first prefixed by MX%. __________________________________________________________________ 5.7 Possible Forwarding Problems If, prior to installation of MX, you were running a different E-mail package on your system, and users made use of the SET FORWARD command in VMS MAIL to forward mail through that other package, those forwarding addresses may no longer work after MX is installed. The system manager should review the forwarding addresses used on the system and modify them as needed to use the MX% prefix once MX is installed. The command SHOW FORWARD/USER=* and SET FORWARD/USER commands in VMS MAIL can be used to accomplish this. 5-3 Known Bugs and Restrictions __________________________________________________________________ 5.8 Remote Forwarding Problems Although MX will automatically detect forwarding on the local system, it cannot do so for messages delivered across DECnet. If a remote DECnet user set his or her forwarding across DECnet back into MX, as, for example, with the following command, MAIL> SET FORWARD REMOTE::MX%"""user@host""" and if MX delivers a message to that user via DECnet, the doubled DECnet reference will result in two sets of RFC 822 headers will appear in the message: one set for the original message and one set for the forwarded message. There is no workaround or fix for this problem. __________________________________________________________________ 5.9 BYPASS Needed for UUCP Delivery If you intend to use MX with DECUS UUCP, and you elect to use a separate mailer account, the mailer account may need to have BYPASS privilege. __________________________________________________________________ 5.10 Routes in SMTP Accounting Logs When a default router is specified for outgoing SMTP messages, entries in the SMTP accounting log show the default router in both the HOST and SENT-TO fields of the accounting records. The actual target host information is not available to MX SMTP, so it cannot be written to the log file. __________________________________________________________________ 5.11 Multiple Accounting Logs Get Created When MCP RESET/ACCOUNTING is issued and you have multiple instances of some MX agents, you may end up with multiple copies of the various accounting log files. For example, with three MX SMTP processes running, you may end up with three new MX_SMTP_ACC.DAT 5-4 Known Bugs and Restrictions files. This problem will be addressed in a future version. Note that multiple instances of MX Jnet will also result in multiple copies of MXBITNET.MAILERS being created each time BITEARN.NODES is updated. This, too, will be addressed in a future version. 5-5 _______________________________________________________ 6 Problem Reports An electronic mailing list exists to discuss the MX software and report problems. The address of the mailing list is MX-List@WKUVX1.WKU.EDU. Internet users can subscribe to this list by sending an E-mail message to MX-List-Request@WKUVX1.WKU.EDU, with the command "SUBSCRIBE" appearing in the body of the message. The MX-List mailing list is also gatewayed to the VMSnet newsgroup vmsnet.mail.mx. Archives of the mailing list are available by anonymous FTP from ftp.wku.edu in the directory [ANONYMOUS.LISTS.MX-LIST]. 6-1