. Message Exchange Release Notes April 1994 This file contains the release notes for Message Exchange V4.0. 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.0 Hunter Goatley MadGoat Software ________________________ 1 April 1994 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. 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. __________ Copyright ©1994 MadGoat Software. ALL RIGHTS RESERVED. The following are trademarks of Digital Equipment Corporation: DEC ULTRIX VAX VAXcluster VAXstation VMS DECnet VMScluster AXP OpenVMS DECUS Jnet is a registered trademark of Wingra Technologies, Inc. MultiNet is a registered trademark of TGV, Inc. TCPware is a trademark of Process Software Corp. WIN/TCP and Pathway are registered trademarks of The Wollongong Group, Inc. _______________________________________________________ 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 3-1 _________________________________________________ 3.1 NEW MX QUEUE FILE FORMAT 3-1 _________________________________________________ 3.2 NETLIB V1.6 3-2 _________________________________________________ 3.3 MX INSTALLATION AND STARTUP CHANGES 3-2 _________________________________________________ 3.4 MX MESSAGE QUEUE PROCESSING ENHANCEMENTS 3-3 _________________________________________________ 3.5 MCP ENHANCEMENTS 3-4 _________________________________________________ 3.6 MX LOCAL ENHANCEMENTS 3-5 _________________________________________________ 3.7 MX MLF ENHANCEMENTS AND CHANGES 3-5 _________________________________________________ 3.8 MX SMTP SERVER ENHANCEMENTS 3-6 _________________________________________________ 3.9 MX SMTP ENHANCEMENTS 3-7 _________________________________________________ 3.10 MX MAILSHR (VMS MAIL INTERFACE) ENHANCEMENTS 3-7 _________________________________________________ 3.11 MX SITE 3-8 iv Contents _________________________________________________ 3.12 MISCELLANEOUS ENHANCEMENTS 3-8 _______________________________________________________ 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 _________________________________________________ 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 v Contents _______________________________________________________ CHAPTER 6 PROBLEM REPORTS 6-1 vi _______________________________________________________ 1 Installation Notes This chapter contains items of interest pertaining to the installation of MX. __________________________________________________________________ 1.1 MX Message Queue Format Changed The format of the MX message queue file has changed from an indexed file to a direct-access sequential file. If you are upgrading to MX V4.0 from a previous version of MX, your MX message queue will NOT be converted to the new format. Note: A NEW QUEUE FILE MUST BE CREATED. IF THE MX QUEUE IS NOT EMTPY WHEN YOU INSTALL MX V4.0, 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.0 from a previous version, all MX processes on the system or cluster must be shutdown using the MCP SHUTDOWN command. Also, you should 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.0 requires Jnet V3.5 or higher to operate. MX V2.3-1 was the last version to support Jnet V4.0. If you are still running Jnet V4.0, you should not upgrade to MX V4.0. __________________________________________________________________ 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.0 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 V3.3 can be read by MX V4.0. 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.0. 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 This chapter notes the new features added to MX V4.0. __________________________________________________________________ 3.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. 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 3-1 New Features and Changes 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. __________________________________________________________________ 3.2 NETLIB V1.6 MadGoat Software's NETLIB V1.6 is included with MX V4.0. 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. 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. __________________________________________________________________ 3.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. 3-2 New Features and Changes 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. __________________________________________________________________ 3.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 3-3 New Features and Changes READY or CANCEL, as appropriate, any such entries that are found as part of their normal file queue maintenance. __________________________________________________________________ 3.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. 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. 3-4 New Features and Changes __________________________________________________________________ 3.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. __________________________________________________________________ 3.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. 3-5 New Features and Changes 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. __________________________________________________________________ 3.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''. 3-6 New Features and Changes __________________________________________________________________ 3.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.). __________________________________________________________________ 3.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. 3-7 New Features and Changes 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. __________________________________________________________________ 3.11 MX SITE o Multiple MX Site Agent processes can now be executed on a single node. __________________________________________________________________ 3.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. 3-8 New Features and Changes 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. 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. 3-9 _______________________________________________________ 4 Bug Fixes MX V4.0 provides the following fixes to bugs in 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 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. 4-1 Bug Fixes 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. 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. 4-2 Bug Fixes 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. 4-3 _______________________________________________________ 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: 5-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. __________________________________________________________________ 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. __________________________________________________________________ 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-4 _______________________________________________________ 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. BITNET users can subscribe to this list by the method described for Internet users, or by sending an E- mail message to MXserver@WKUVX1, with the command "SUBSCRIBE MX-List" 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]. 6-1