. Message Exchange Release Notes May 1993 This file contains the release notes for Message Exchange V3.3. 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 V3.3 Academic Computing and Research Services Western Kentucky University Bowling Green, Kentucky ________________________ 7 May 1993 The information in this document is subject to change without notice and should not be construed as a commitment by Western Kentucky University (WKU). WKU assumes 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 ©1993 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 trademark of SRI International and TGV, Inc. TCPware is a trademark of Process Software Corp. _______________________________________________________ Contents _______________________________________________________ CHAPTER 1 INSTALLATION NOTES 1-1 _________________________________________________ 1.1 MX MUST BE SHUTDOWN 1-1 _________________________________________________ 1.2 JNET LOGICALS MUST BE DEFINED 1-1 _________________________________________________ 1.3 VMS/ULTRIX CONNECTION NOTES 1-1 _________________________________________________ 1.4 TGV MULTINET CONFIGURATION NOTES 1-2 _________________________________________________ 1.5 WOLLONGONG PATHWAY CONFIGURATION NOTES 1-3 _________________________________________________ 1.6 DECUS UUCP NOTES 1-3 _______________________________________________________ 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 iii Contents _________________________________________________ 2.4 NEW NETLIB 2-2 _______________________________________________________ CHAPTER 3 NEW FEATURES AND CHANGES 3-1 _______________________________________________________ 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 iv Contents _________________________________________________ 5.8 REMOTE FORWARDING PROBLEMS 5-4 _________________________________________________ 5.9 BYPASS NEEDED FOR UUCP DELIVERY 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 Must Be Shutdown If you are upgrading from MX v3.1C or below to MX V3.3, all MX processes on the system or cluster must be shutdown using the MCP SHUTDOWN command. The format of the MX system file queue has changed and, in order to automatically convert the existing file queue to the new format, the installation procedure requires exclusive access to the MX system queue file. If any process has the file open, the installation will fail. __________________________________________________________________ 1.2 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.3 VMS/ULTRIX Connection Notes If you are using DEC VMS/ULTRIX Connection (UCX) V1.2 through V2.0, you should review your UCX configuration to ensure that you are using your fully-qualified domain name (FQDN) as your primary local host name in your UCX host table. If you followed the UCX documentation when configuring UCX with UCX$CONFIG, 1-1 Installation Notes it is highly likely that you did not specify your FQDN as your primary host name. If your abbreviated host name is listed as the primary in your UCX host table, then messages sent from the local system will go out with an unreplyable return address. To check your local host name, use the UCX utility: $ UCX UCX> SHOW HOST/LOCAL x.x.x.x ! use your IP address here To ensure that your FQDN is the primary host name for your address, use the UCX commands: UCX> SET NOHOST x.x.x.x ! use your IP address here UCX> SET HOST "full.qual.dom.name"/ADDR=x.x.x.x/ALIAS="abbrev" You will be asked for confirmation on the SET NOHOST command. Substitute your FQDN and IP address in the SET HOST command, and if you would still have your shortened host name in the host table, use the /ALIAS qualifier, as shown. Once you have updated your host table, you should review the file SYS$MANAGER:UCX$INET_SET_ INTERFACES.COM and replace all instances of your abbreviated host name with your FQDN. Note: Remember that UCX is case sensitive with regard to host names! __________________________________________________________________ 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 : : 1-2 Installation Notes 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 Wollongong PathWay Configuration Notes MX works with the current release of Wollongong's PathWay TCP/IP software, which supplies UCX emulation in its Runtime component. To use MX as the PathWay SMTP mailer, install the UCX v1.3+ version of NETLIB during the MX installation and enable PathWay's UCX emulation. Thanks to Fred LaForest for supplying the PathWay information. __________________________________________________________________ 1.6 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). 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.BITNET 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 V3.3 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 V3.3. __________________________________________________________________ 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 V3.3 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.0A can be read by MX V3.3. However, the new 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 V3.3. 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 V3.3. As of MX V3.3, OpenVMS AXP v1.0 or later is supported in addition to OpenVMS VAX (VAX/VMS) V5.0 or later. The following new features were added in MX V3.3: 1 MX now supports OpenVMS AXP V1.0 for the following components: MX base software, NETLIB, SMTP, SMTP- over-DECnet, MLF, and SITE. Support for Jnet, DECUS UUCP, and some SMTP flavors will be added whenever those third-party products have been ported to OpenVMS AXP. 2 VMS binary files can now be mailed via MX to other VMS sites running either MX V3.3 or higher, PMDF V4.1 or higher, or MultiNet V3.2 or higher. Binary files are mailed using the undocumented VMS Mail command SEND/NOEDIT/FOREIGN. The message is encoded using BASE64, as specified in the MIME RFC (RFC 1341, ``MIME (Multipurpose Internet Mail Extensions): Mechanisms for specifying and describing the format of Internet message bodies,'' by N. Borenstein and N. Freed, June 1992). The resulting message is MIME-compliant. The contents are specified as ``APPLICATION/VMS-RMS'', which is recognized my MX, MultiNet, and PMDF. Incoming ``VMS-RMS'' messages encoded using the BASE64 algorithm are automatically decoded by MX before they are mailed via VMS Mail to the recipient(s). The files are mailed from MX as ``foreign'' files that maintain all of the VMS file attributes. 3-1 New Features and Changes Note that MX correctly encodes RMS indexed files, which are not properly encoded by PMDF V4.2 and MultiNet V3.2. Those products can, however, correctly decode such files, so indexed files can be mailed to other VMS sites using MX. The ``VMS-RMS'' format was first defined and implemented by Innosoft for PDMF. Matt Madison added the capability to MultiNet's VMS Mail interface and provided a description of the specification to Hunter Goatley, who implemented it in MX. 3 The MX Jnet agent now supports sending mail files over BITNET as NETDATA files in addition to PUNCH. Lines in files sent as NETDATA are not wrapped at 80 characters as they are with PUNCH, allowing long lines to be more easily mailed between BITNET sites. MX automatically determines the format based on the preferred format as specified in the BITNET list of nodes, BITEARN.NODES. The information is not available in XMAILER.NAMES. If the MX Jnet agent finds BITEARN.NODES in MX_JNET_DIR:, it will use it to construct its own file called MXBITNET.MAILERS. This file contains only mailer information for the BITNET sites. To register your mailer as supporting NETDATA (which Jnet does allow), your :serversN tag for your node entry in BITEARN.NODES should be modified to resemble this: :servers1:MAILER@node(MAIL,ND PU,,,P_user) The ``ND PU'' indicates that your node can accept mail in either NETDATA or PUNCH format, with NETDATA preferred. Thanks to Eric Thomas , who supplied the code for parsing BITEARN.NODES. 3-2 New Features and Changes 4 MX now allows multiple addresses on the VMS Mail From: line on incoming messages delivered through VMS Mail. If an RFC822 From: or Reply-To: header includes more than one address, as many of them as will fit on a VMS Mail From: line will be placed there. This means that MX users subscribed to an MX mailing list that is configured for replies to go to both the list and the sender can now reply to both the list and the sender. This feature is enabled by default. A new qualifier, /MULTIPLE_FROM, has been added to the MCP command SET LOCAL to allow site control of this feature. To disable multiple From: addresses, simply execute the command SET LOCAL/NOMULTIPLE_FROM in MCP. 5 MX now supports local delivery of mail to users of the MM mail user agent supplied with MultiNet. Incoming mail is delivered to MM if the MM user has defined DELIVER-TO-MM as 1 in his MM initialization file. As of MultiNet V3.2, MM does not support MX for outgoing mail. However, an upcoming MultiNet release will include such support. Thanks to Matt Madison of TGV, Inc., for supplying the MX to MM interface. 6 A new qualifier, /BRIEF, was added to the MCP QUEUE SHOW command. When /BRIEF is specified, brief information about all of the entries in the MX system queue are displayed. The output is virtually identical to that produced by the old FLQU utility. 7 The MCP command DEFINE LIST now accepts /[NO]PRIVATE. A list that is defined /PRIVATE is not displayed in the output resulting from a LIST command sent to ListServ. 3-3 New Features and Changes 8 MXALIAS now creates the MX_ALIAS_DATABASE.DAT file with a protection of (S:RWE,O:RWE,G,W) to prevent accidental deletion. Existing files can be modified using a command like the following: $ SET FILE/PROT=(S:RWE,O:RWE) MX_ALIAS_DATABASE.DAT 9 The SMTP server agent for incoming mail was modified to allow leading blanks on the addresses for MAIL FROM: and RCPT TO: commands. Though the blank is not allowed by RFC821, some mailers (notably some versions of Charon) include a blank between the commands and the addresses. 10 MX now checks for the existence of time zone logicals for some other products in addition to the old MDM_* logicals. The value of the first logical defined in the following ordered list is used with no time-zone calculations. (If you define MX-specific logicals, you should use the new MX_ TIMEZONE and MX_TZ_PREFIX logicals instead of the obsolete MDM logicals.) MX_TIMEZONE MX MDM_TIMEZONE MDMLIB SYS$TIMEZONE_NAME DECdts SYS$TIME_ZONE DEC TCP/IP Services MULTINET_TIMEZONE TGV's MultiNet JAN_TIME_ZONE Wingra's Jnet UUCP_TIME_ZONE DECUS UUCP If none of those are defined, the following logicals are checked. The value should be ``P'', ``M'', ``C'', or ``E''; the time zone will begin with the specified letter. MX_TZ_PREFIX MDM_TZ_PREFIX If none of the logicals above are defined, US Eastern standard time is assumed. 3-4 New Features and Changes 11 The MultiNet and TCPware logicals no longer need to be defined before MX is installed. Thanks to Matt Madison. 12 The MX MLF LISTSERV address has been changed to MXSERVER. The MX Router does still recognize LISTSERV, but all outgoing messages from MLF will feature the address MXserver@node. 3-5 _______________________________________________________ 4 Bug Fixes MX V3.3 provides the following fixes to bugs in V3.2: 1 If MX was started from an account that had its default MAIL transport set to MX%, local messages would cause an infinite loop passing the messages from the MX Local agent back into MX (since the default transport was MX). This has been corrected. 2 MX delivery agents were creating multiple .*_INFO files when a message delivery had to be retried. This problem has been fixed. 3 The MX MLF agent did not correctly send out responses to mailing list REVIEW and LIST commands if there were no system users defined. This has been corrected. 4 The MXALIAS utility was modified to not accept alias names beginning with an underscore. When VMS Mail parses an address that has a leading underscrore, it strips the underscore and does not check forwarding for the address. To avoid user confusion, MXALIAS now rejects such aliases. 5 The MX UUCP interface and the SMTP servers (SMTP, DNSMTP, and XSMTP) stripped trailing blanks off of lines on incoming messages from MX. The blanks are no longer removed. 6 The From_ line outgoing UUCP messages included the Reply-To: address, not the Sender: address. This resulted in some UUCP bounces being redirected to mailing lists instead of the list owner. This has been corrected; either the Sender: or the From: address is used as the sender on the From_ line. 4-1 Bug Fixes 7 MX Local did not check to see if an account has been set to DISUSER, thus allowing incoming messages to be delivered to disusered accounts. This has been corrected so that incoming mail to a disusered account is now returned to the sender. 8 Repeatedly executing the MCP command QUEUE SHOW could exhaust a process's virtual memory if there were a lot of entries in the MX system queue. This has been corrected. 9 The ListServ software returned a null message in response to a LIST command when no lists were defined. An informational message is now returned if there are no lists defined or if all lists are marked private. The message states that there are no public lists defined. 10 The MX documentation states that the ListServ commands ADD and REMOVE accept the /NOTIFY and /NONOTIFY qualifiers. Previous versions of MX did not actually support them. This feature has been added to the ListServ processor. 11 The MX Router was not using a default of Postmaster@localnode for file server ``-mgr'' addresses as was documented. This problem has been corrected. 12 The MX Jnet Intfc process was only performing BSMTP line wraps on the RCPT TO: lines. The MAIL FROM: line is now wrapped as well, if necessary. 13 MXCONFIG.COM did not prompt for LOCAL path information if DECUS UUCP was the only specified transport. This has been corrected. 14 MLF_CONFIG.COM incorrectly omitted the /MAILING_LIST qualifier to the DEFINE FILE_SERVER command. This has been corrected. 4-2 _______________________________________________________ 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 ``Insufficent 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.BITNET. Internet users can subscribe to this list by sending an E-mail message to MX-List- Request%WKUVX1.BITNET@UKCC.UKY.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 LISTSERV@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