Message Exchange Release Notes June 1994 This file contains the release notes for Message Exchange V4.1. 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.1 Hunter Goatley MadGoat Software ________________________ 20 June 1994 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, Western Kentucky University. 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 ©1994 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.1 3-1 _________________________________________________ 3.1 MAJOR I/O REDUCTIONS 3-1 _________________________________________________ 3.2 CURRENT WORKING STATE OF AGENTS NOW REPORTED 3-2 _________________________________________________ 3.3 NETLIB V1.6B 3-2 _________________________________________________ 3.4 NEW LISTSERV SUPPORT 3-2 _________________________________________________ 3.5 AUTO-PURGING OF FINISHED ENTRIES 3-2 _________________________________________________ 3.6 MCP ENHANCEMENTS 3-3 _________________________________________________ 3.7 MX ROUTER ENHANCEMENTS 3-3 _________________________________________________ 3.8 MX SMTP SERVER ENHANCEMENTS 3-4 _________________________________________________ 3.9 MISCELLANEOUS ENHANCEMENTS 3-4 _________________________________________________ 3.10 NEW AND UPDATED [CONTRIB] PACKAGES 3-4 iv Contents _______________________________________________________ CHAPTER 4 NEW FEATURES AND CHANGES IN MX V4.0-1 4-1 _________________________________________________ 4.1 NEW MX QUEUE FILE FORMAT 4-1 _________________________________________________ 4.2 NETLIB V1.6 4-2 _________________________________________________ 4.3 MX INSTALLATION AND STARTUP CHANGES 4-3 _________________________________________________ 4.4 MX MESSAGE QUEUE PROCESSING ENHANCEMENTS 4-4 _________________________________________________ 4.5 MCP ENHANCEMENTS 4-4 _________________________________________________ 4.6 MX LOCAL ENHANCEMENTS 4-5 _________________________________________________ 4.7 MX MLF ENHANCEMENTS AND CHANGES 4-6 _________________________________________________ 4.8 MX SMTP SERVER ENHANCEMENTS 4-7 _________________________________________________ 4.9 MX SMTP ENHANCEMENTS 4-7 _________________________________________________ 4.10 MX MAILSHR (VMS MAIL INTERFACE) ENHANCEMENTS 4-8 _________________________________________________ 4.11 MX SITE 4-9 v Contents _________________________________________________ 4.12 MISCELLANEOUS ENHANCEMENTS 4-9 _______________________________________________________ CHAPTER 5 BUG FIXES 5-1 _______________________________________________________ CHAPTER 6 KNOWN BUGS AND RESTRICTIONS 6-1 _________________________________________________ 6.1 SMTP LOOPING/FORWARDING BUG 6-1 _________________________________________________ 6.2 X.25-SMTP BUG 6-2 _________________________________________________ 6.3 DECUS UUCP UUCP_MAILSHR BUG 6-2 _________________________________________________ 6.4 VMS MAIL BUGS 6-2 _________________________________________________ 6.5 VMS CALLABLE MAIL MEMORY LEAK AND MX LOCAL 6-3 _________________________________________________ 6.6 MXALIAS AND THE MX% ``@'' PATCH FOR VMS MAIL 6-3 _________________________________________________ 6.7 POSSIBLE FORWARDING PROBLEMS 6-3 _________________________________________________ 6.8 REMOTE FORWARDING PROBLEMS 6-4 _________________________________________________ 6.9 BYPASS NEEDED FOR UUCP DELIVERY 6-4 vi Contents _________________________________________________ 6.10 ROUTES IN SMTP ACCOUNTING LOGS 6-4 _________________________________________________ 6.11 MULTIPLE ACCOUNTING LOGS GET CREATED 6-4 _______________________________________________________ CHAPTER 7 PROBLEM REPORTS 7-1 vii _______________________________________________________ 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.1 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.1, 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.1 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.1 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.1. __________________________________________________________________ 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.1 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.1. 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.1. 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.1 This chapter notes the new features added to MX V4.1. Because many sites upgraded from MX V3.3 to MX V4.1, skipping MX V4.0, the release notes for V4.0 are included in the next chapter. __________________________________________________________________ 3.1 Major I/O Reductions This version of MX features queue file I/O reductions that enhance performance as dramatically as the new queue file in MX V4.0 did. The various agents used to scan the file every few minutes looking for entries to be processed. With a lot of agents running, this translated into possibly hundreds of I/O requests for each agent every time they scanned. Each of the agents now maintains an in-memory queue of the entries that are to be processed by that agent. This is, of course, in addition to the queue on disk. As entries are added, updated, and deleted from the queue, the agents are notified so that they can make the appropriate changes to their in-memory queues. When scanning for work to do, the in-memory queue is used instead of the on-disk queue, resulting in tremendous reductions of disk I/O. The only agents that still scan the queue file on a regular basis are MX MLF and MX Router (or MX FLQ Manager). MX MLF will be updated in a future version, and MX Router and MX FLQ Manager still scan the queue file to purge finished entries. 3-1 New Features and Changes in MX V4.1 These enhancements, along with the enhanced MCP STATUS command described below, were contributed by Juan Altmayer Pizzorno, of Gesellschaft für Mathematik und Datenverarbeitung (The German National Research Center for Computer Science). For more info on GMD, use Mosaic or Lynx to access the URL http://www.gmd.de. __________________________________________________________________ 3.2 Current Working State of Agents Now Reported The MCP command STATUS now includes the current state of each delivery agent. For example, each agent will be reported as being ``Idle,'' ``Processing entry #X,'' ``Waiting for entry #X,'' etc. Thanks to Juan Altmayer Pizzorno. __________________________________________________________________ 3.3 NETLIB V1.6B MadGoat Software's NETLIB V1.6B is included with MX V4.1. NETLIB V1.6B corrects a bug in the order of the numbers in an IP address under CMU-IP. Thanks to Matt Madison. __________________________________________________________________ 3.4 New LISTSERV Support A new optional MX agent, MX ListServ, is provided to let MX interface with LISTSERV software from L- Soft International. Documentation is provided in the Message Exchange Management Guide. Thanks to Juan Altmayer Pizzorno. __________________________________________________________________ 3.5 Auto-purging of FINished Entries When an MX queue entry has been fully processed, it is marked as being ``finished'' and is left in the queue for a period of time. The MX Router or MX FLQ Manager scans the file every 15 minutes, by default, and purges ``FIN'' entries. 3-2 New Features and Changes in MX V4.1 Many sites, especially high-volume sites, don't need to keep finished entries in the queue for any length of time, so MX V4.1 now includes optional automatic purging of entries in the queue. To enable the queue autopurge, define the following logical: $ define/system/exec mx_flq_autopurge_fin true When this logical is defined, queue entries and the associated files are automatically deleted when they are marked ``finished.'' __________________________________________________________________ 3.6 MCP Enhancements The MCP command DEFINE REWRITE_RULE now checks that the right-hand side of the rule is RFC821-compliant. Previously, no check was made, resulting in accidental definitions of rules that did not produce valid addresses. __________________________________________________________________ 3.7 MX Router Enhancements o The MX Router now verifies RFC821-compliance with addresses rewritten by MX rewrite rules. Previously, a bad rewrite rule could result in a bad RFC821 address, which exploited a bug in MX SMTP that caused it to generate an access violation. MX Router now returns such messages back to the original sender (and MX SMTP has been modified so that it no longer access violates if it does receive a bad address). o The MX Router now includes support for site- specific rewriting of RFC822 header addresses on outgoing mail and envelope address rewriting on incoming mail. This support allows sites to better control the From: addresses, etc., for their users. Full details can be found in the Message Exchange Programmer's Guide. 3-3 New Features and Changes in MX V4.1 __________________________________________________________________ 3.8 MX SMTP Server Enhancements The MX SMTP Server has been modified to accept MAIL FROM: and RCPT TO: lines that do not conform to RFC821. Specifically, the address is considered valid when the required angle brackets are omitted. __________________________________________________________________ 3.9 Miscellaneous Enhancements The various images used by the MX delivery agents are now INSTALLed /OPEN/HEADER/SHARE. __________________________________________________________________ 3.10 New and updated [CONTRIB] packages The following [CONTRIB] packages have been updated or added: o BASE64-DECODER.ZIP-A basic decoder for BASE64- encoded messages. o DIS-TO-MXALIAS.ZIP-Convert .DIS files to MXALIAS aliases. Updated. o MAIL_EDIT.ZIP-Various MAIL$EDIT procedures for enhanced sending of mail through VMS Mail. 3-4 _______________________________________________________ 4 New Features and Changes in MX V4.0-1 This chapter notes the new features added to MX V4.0 and MX V4.0-1. MX V4.0-1 offered the following improvements over MX V4.0: o The MX MLF agent now correctly handles local bounce messages that are forwarded to owner-listname. A bug in MX V4.0 caused such messages to always be delivered to the MX system users instead of the list owners. o The MCP QUEUE READY command will now always notify the target agent that an entry has been marked READY. Previously, only the MX Router was notified when its entries were marked. o A memory leak in MAILQUEUE has been corrected. o The MCP command SHOW VERSION now reports the version as MX V4.0-1. __________________________________________________________________ 4.1 New MX Queue File Format The major change in this version of MX is that the MX message queue file has been changed from an indexed file to a sequential file. This change will make a major difference in MX performance. With previous versions of MX, performance quickly degenerated as messages were added to and deleted from the message queue as the index headers in the file became more and more fragmented. With some very active sites, MX couldn't even do CONVERT/RECLAIM passes on the file. 4-1 New Features and Changes in MX V4.0-1 With this version, no reclaim passes are needed. The same records within the sequential file are used over and over, resulting in a message file that offers significant performance increases. Note: The new file has a fixed size-the size determines the number of entries that can be in the queue at any given time. THE FILE WILL NOT GROW ON ITS OWN!! You must select a file size large enough to handle your site's requirements. Each entry takes 1 block; to allow for 5,000 entries in the queue, a file size of 5,036 blocks is required. A file that size should be sufficient for most sites. The maximum number of entries is 131,072. New MCP commands QUEUE CREATE, QUEUE EXTEND, QUEUE COMPRESS, QUEUE SYNCHRONIZE, and QUEUE STATISTICS have been added to allow you to manipulate the new queue file. In addition, a number of qualifiers have been added to QUEUE SHOW to let you control the entries displayed. Note: The message queue file has been renamed from SYSTEM_QUEUE.FLQ_CTL to MX_SYSTEM_QUEUE.FLQ_CTL in MX_ FLQ_DIR:. Any automated processes you may have running to do CONVERTs on the message queue file should be disabled, as they will not work with the new format. __________________________________________________________________ 4.2 NETLIB V1.6 MadGoat Software's NETLIB V1.6 is included with MX V4.1. NETLIB V1.6 offers the following enhancements to V1.5: o Wollongong's WIN/TCP and Pathway products are now directly supported by NETLIB. Previous versions of MX supported Pathway using Pathway's UCX emulation. All other products that use NETLIB (NEWSRDR, PACKASM, etc.) can now be used with TWG's products. MX now supports the WIN$TIME_ZONE logical. 4-2 New Features and Changes in MX V4.0-1 o For systems running UCX, the system's FQDN is now created by combining UCX$INET_HOST and UCX$INET_ DOMAIN. Previously, NETLIB expected UCX$INET_ HOST to contain the FQDN, which was contrary to Digital's intended use for the logical. Thanks to Matt Madison for the NETLIB updates. __________________________________________________________________ 4.3 MX Installation and Startup Changes o During MX upgrades, the MX installation procedure now automatically determines which MX components should be installed by default, based on the previously installed components. The installer is still given the chance to select additional components or remove those selected. o The MX installation procedure will now prompt the installer for the number of agent processes to be run on the selected nodes. Thanks to Dan Wing. o When upgrading from an older version of MX, the installation procedure will use the existing information in MX_STARTUP_INFO.DAT as the default values for the nodes and numbers for the MX agents. o MX___STARTUP.COM now checks to be sure the user starting MX has sufficient privileges to do so. o MX_START.COM was modified to: o allow as many as 99 instances of an MX agent; o start the MX agents using /UIC=[1,4] to prevent the accidental running of multiple agents from different accounts; o create log files with names that include the iteration of each agent. 4-3 New Features and Changes in MX V4.0-1 __________________________________________________________________ 4.4 MX Message Queue Processing Enhancements o A new optional agent, MX FLQ Manager, has been added. You can elect to run a separate MX FLQ Manager process to perform the maintenance on the queue (purging FINished entries, for example), freeing the MX Router process to do only routing. Sites that process a lot of mail may find it beneficial to use the separate process. o The file queue maintenance performed by the MX FLQ Manager and MX Router has been enhanced. When an MX agent dies abnormally (for example, during a system crash) or when a VMS Mail user is sending a message and gets disconnected or STOP/IDed, the entry in- progress at that time is left in the INPROG state in the queue. Under previous versions of MX, such entries had to be marked READY or CANCEL using MCP. The MX Router and MX FLQ Manager now automatically READY or CANCEL, as appropriate, any such entries that are found as part of their normal file queue maintenance. __________________________________________________________________ 4.5 MCP Enhancements o MCP now automatically sorts PATH definitions, eliminating previous problems where PATH definitions would appear after ``*'' PATH, for example. o Some sites using the MX_SITE_NAME_CONVERSION feature have encountered problems sending mail to non-RFC822 compliant mailers (IBM) when the Sender: and From: addresses don't match. To aid those sites, the MCP command SET ROUTER now accepts the qualifier /[NO]OMIT_VMSMAIL_SENDER to control the inclusion of Sender: lines for mail originating from VMS Mail. 4-4 New Features and Changes in MX V4.0-1 o New MCP commands QUEUE CREATE, QUEUE EXTEND, QUEUE COMPRESS, QUEUE SYNCHRONIZE, and QUEUE STATISTICS have been added to allow you to manipulate the new queue file. In addition, a number of qualifiers have been added to QUEUE SHOW to let you control the entries displayed. o Copies of all LOCAL delivery error messages can now be forwarded to the local POSTMASTER with the new MCP command SET LOCAL/CC_POSTMASTER. Such messages include those addressed to non-existent local accounts. o The display of the entry size display in MCP SHOW QUEUE/ALL was changed from from 6 digits to 7 digits. __________________________________________________________________ 4.6 MX Local Enhancements o Incoming mail is now delivered with the VMS Mail ``To:'' and ``CC:'' lines containing the addresses from the RFC822 To: and CC: lines. o Incoming MIME QUOTED-PRINTABLE messages are now automatically decoded by MX Local, in addition to BASE64 VMS messages. o The ability to disable local deliveries to users via MM was added with the MCP command SET LOCAL/NOMM_DELIVERY. o The MM delivery code now includes additional access checks. Thanks to Matt Madison. 4-5 New Features and Changes in MX V4.0-1 __________________________________________________________________ 4.7 MX MLF Enhancements and Changes o The hardcoded address LISTSERV was removed from MX. Sites still wanting to use it must define an alias using MCP that equates LISTSERV to MXserver. o Following the convention used by the latest version of Eric Thomas's LISTSERV processor, MX now supports -server addresses as synonyms for - request addresses for mailing lists. For example, YYZ-server and YYZ-request are both recognized as list processor addresses for list YYZ. o All outgoing mailing list mail now shows the sender as ``owner-listname''. When mail is received for such an address, it is automatically delivered to the user defined to receive errors for that list (/ERRORS_TO on the MCP command DEFINE LIST). o The ability to strip ``other'' headers from mailing list postings has been added to MX MLF. Stripping the ``other'' headers eliminates lots of garbage in headers, plus it handily gets around problems with return receipts getting requested by Pegasus Mail. Note that this can cause problems with mailing lists that are gatewayed to newsgroups, depending on the headers the gateway software uses to catch duplicate posts. o MX MLF now checks the list of system users when checking access to a file server, allowing users defined as MX system users to to access file servers that are restricted to members of a mailing list. o Mailing lists can now be set to ignore the case of the username portion of all subscriber addresses. The qualifier /[NO]CASE_SENSITIVE was added to the MCP commands DEFINE LIST and MODIFY LIST. 4-6 New Features and Changes in MX V4.0-1 __________________________________________________________________ 4.8 MX SMTP Server Enhancements o The MX SMTP server is now more lenient with regard to RCPT TO: addresses. Addresses that do not include the ``@node'' part of the address are now accepted. The local node name, as defined by MX_NODE_NAME, is used to create a valid RFC821 address. Both and are accepted. o The MX SMTP server also now accepts numeric IP addresses enclosed in brackets with the HELO command. Previously, though the mail was accepted, the MX SMTP server could not verify the address. o The process name for the SMTP Server has been changed to ``MX SMTP Server'' so that all MX process names begin with ``MX''. __________________________________________________________________ 4.9 MX SMTP Enhancements o The MX SMTP agent for outgoing mail now accepts generic success and failure responses (codes 2xx and 5xx) from the remote server. Previously, the SMTP transaction was aborted if an unknown response code was received. o The MX SMTP agents now return errors in the LISTSERV-friendly format used by MX Local. o The SMTP accounting log now includes the name of the host to which the message was actually sent (for example, mail exchangers, etc.). 4-7 New Features and Changes in MX V4.0-1 __________________________________________________________________ 4.10 MX MAILSHR (VMS Mail interface) Enhancements o The MX VMS Mail interface now checks for the logical MX_SHUTDOWN when a users tries to send mail through MX. If MX_SHUTDOWN is defined /SYSTEM/EXECUTIVE, users will not be allowed to send mail. A message will be displayed indicating that the system manager has temporarily disabled MX. Note that defining MX_SHUTDOWN does not prevent incoming mail from SMTP, etc. o MX V3.2 introduced the ability to resend SMTP files, retaining the original RFC822 headers, using the MAIL command SEND/FOREIGN/TYPE=1. There are two changes to this feature in MX V4.0: o The /TYPE value has been changed to 255 to allow for more options on non-privileged SEND/FOREIGN commands. o In previous versions of MX, the user had to have LOG_IO privilege to resend SMTP files. MX V4.0 now requires that the user hold the MX_FAKE_ RFC822 process rights identifier instead of LOG_ IO. If the user tries to resend an SMTP file and does not hold the identifier, an error message is displayed. o Usage of MX can now be restricted by defining the executive-mode logical MX_RESTRICT_USAGE in the system logical name table (/SYSTEM/EXEC). If the logical is defined, the user must hold the MX_MAIL_ ACCESS process rights identifier in order to send mail using MX. 4-8 New Features and Changes in MX V4.0-1 __________________________________________________________________ 4.11 MX SITE o Multiple MX Site Agent processes can now be executed on a single node. __________________________________________________________________ 4.12 Miscellaneous Enhancements o A standalone program, MX_DECODE, has been provided to decode VMS files mailed using BASE64 encoding. MX_DECODE can be used to decode files passed to the MX Site Agent. It should be invoked via a foreign command: $ MX_DECODE :== MX_EXE:MX_DECODE.EXE It accepts two parameters: the input file, which should contain all of the RFC822 headers, and the output file name. o The MAILQUEUE utility now displays an informational message if there are no queued messages from the user. o The MX accounting logs can now be opened for reading when they are open by one or more agents. o The following [CONTRIB] packages have been updated or added: o DIS-TO-MAIL.TXT-Convert .DIS files to MX mailing lists. o DIS-TO-MXALIAS.ZIP-Convert .DIS files to MXALIAS aliases. o MLF_MAINT.ZIP-A mailing list maintenance utility. o MX-NEWS-GATEWAY.ZIP-Programs to gateway between MX and ANU NEWS. Includes a couple of bug fixes. o MX_HELP_FILE.ZIP-Updated VMS Help files for MX. 4-9 New Features and Changes in MX V4.0-1 o MX_POST.ZIP-An MX to NEWS gateway for use with NNTP servers. o MX_SAS_REPORTS.ZIP-SAS procedures to generate reports for MX SMTP and LOCAL accounting. o MX_MAILSHR_PATCH.ZIP-Updated MAILSHR ``@'' patch for OpenVMS V6.0 and below. o PATCH_MAILSHR_ON_VMS_N_AXP_1_5.ZIP-MAILSHR ``@'' patch for OpenVMS AXP V1.5. 4-10 _______________________________________________________ 5 Bug Fixes MX V4.1 provides the following fixes to bugs in V4.0: o MX_MAILSHR (the VMS Mail interface) now correctly handles blank-separated VMS Mail To: lines. Previously, the following line: To: MX%"x@x" MX%"y@y" would have resulted in an invalid RFC822 To: line. o Bad RFC821 addresses passed to MX SMTP by MX Router (for example, those created by bad rewrite rules) would cause the MX SMTP agent to exit with an access violation. This problem has been corrected. o A memory leak in MDMLIB that could affect all MX agents has been corrected. o A small memory leak in MX Local has been corrected. o A bug in the VAX C RTL caused the MXBITNET.MAILERS file created by MX Jnet to be created with a protection that allowed all access by all users. MX Jnet has been modified to work around that bug. o MX SMTP Server now records its final exit status in its log file. The other agents were modified to do that in MX V3.2, but MX SMTP Server was overlooked. MX V4.0 provided the following fixes to bugs to MX V3.3. 1 The documentation for MX V3.3 was produced using VAX DOCUMENT V2.2. A bug in VAX DOCUMENT V2.2 causes revision bars in .TXT files to overwrite the text that was revised. VAX DOCUMENT V2.1 was 5-1 Bug Fixes used to create the documentation for MX V4.0 to make the .TXT files readable again. 2 Fixed memory leak in MCP. 3 Fixed missing underscores in MCP HELP. 4 Disabled bouncing of mail to DISUSERed accounts. Mail is now delivered to those accounts, as per VMS Mail. 5 Fixed generation of year in MM headers. (Matt) 6 Fixed STR$TRIM bug in MX_SITE_IN.B32. 7 Fixed two bugs in MX_JNET that could cause access violations. 8 Fixed erroneous MCP STATUS display that would list other processes also doing MCP STATUS. 9 Fixed missing quotes on LOCAL bounce messages (xx::uu@node is now "xx::uu"@node). 10 Fixed problem with MXalias keeping records locked. 11 Modified MXALIAS to allow addresses containing quotes to be defined. 12 Corrected handling of MX records in MX SMTP. Previously, depending on how the MX records for a host were defined, MX would not ignore records with a higher preference than the system running MX. (In other words, when the system handling a message was one of the mail exchangers for a remote host, it and all systems with a higher preference should have been ignored; previously, only the system handling the message was ignored, leaving the possibility that the message would get handed off to another system with a higher (lower) preference than the current system). (Tom Allebrandi) 13 Fixed bug in handling group addresses in RFC822 headers. The group comment was improperly removed, leaving an invalid RFC822 address. The comment is no longer removed. Thanks to Donald Buczek. 5-2 Bug Fixes 14 Modified MCP to CANCEL both pieces of an entry if the entry scheduled for retry by an agent was cancelled. Previously, the original ROUTER entry was not cancelled, leaving an IN-PROGRESS orphan entry. 15 Added proper locking of the MM.INIT file when checking for MM delivery to a user. 16 Modified MCP to parse filenames for DEFINE LIST so that invalid names are not allowed. 17 Modified MCP to check to make sure rewrite rules include the ``<>''. 18 Fixed a bug in the decoding of BASE64 files in MX Local. MX was not properly handling quotes in the FDL string. 19 Fixed bug in SMTP_SERVER that could cause the server to die if there was an error opening a debug log file. 20 Fixed bug in MX Jnet that would incorrectly rewrite RFC822 headers if the site is running Jnet V3.6+ and has a default route defined instead of maintaining local tables. 21 Fixed placement of MIME headers with regard to TOP and BOTTOM as defined using SET LOCAL. Previously, the MIME headers were always included at the TOP, regardless of the OTHER setting. 5-3 _______________________________________________________ 6 Known Bugs and Restrictions __________________________________________________________________ 6.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: 6-1 Known Bugs and Restrictions $ DEFINE/SYSTEM/EXEC NETLIB_DOMAIN "." 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. __________________________________________________________________ 6.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. __________________________________________________________________ 6.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. __________________________________________________________________ 6.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. 6-2 Known Bugs and Restrictions __________________________________________________________________ 6.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.'' __________________________________________________________________ 6.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%. __________________________________________________________________ 6.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. 6-3 Known Bugs and Restrictions __________________________________________________________________ 6.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. __________________________________________________________________ 6.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. __________________________________________________________________ 6.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. __________________________________________________________________ 6.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 6-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. 6-5 _______________________________________________________ 7 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.spc.edu in directory [ANONYMOUS.MX]. 7-1