Kit Name: ALPMAIL03_071 Kits superseded by this kit: ALPMAIL02_071 Kit Dependencies: The following remedial kit(s) must be installed BEFORE installation of this, or any required kit: None. In order to receive all the corrections listed in this kit, the following remedial kits should also be installed: None. Kit Description: Version(s) of OpenVMS to which this kit may be applied: OpenVMS Alpha V7.1, V7.1-1H1, V7.1-1H2 Files patched or replaced: o [SYSEXE]MAIL.EXE (new image) o [SYSLIB]MAILSHR.EXE (new image) o [SYSLIB]MAILSHRP.EXE (new image) o [SYSEXE]MAIL_OLD.EXE (new image) o [SYSEXE]MAIL_SERVER.EXE (new image) Problems addressed in ALPMAIL03_071 kit o In OpenVMS V6.2, if the MAIL$INTERNET_TRANSPORT logical was defined, the user could enter an address formatted according to the syntax rules of the transport image pointed to by the logical. Then an entry could be done without including the transport name followed by a percent sign or without enclosing the recipient address in double quotes. For example, the address "user%xx@node.domain" could be entered and the message would be successfully delivered. Page 2 In OpenVMS V7.0 and later, if the MAIL$INTERNET_TRANSPORT was defined and the user entered a recipient address formatted as above, the sender would eventually receive an error message that the message was not delivered due to an unknown recipient. o Use of external temporary edit files was restored to the mail user interface. In OpenVMS V7.1 MAIL, in some cases the User Interface (UI) uses the same file for input and output during editing functions. Via the MAIL$EDIT logical, users can have a variety of procedures that modify the file specified in the input argument parameter P1 and attempt to output it to the output parameter argument P2. Using OpenVMS V6.2 MAIL, the write to the output file (P2) succeeded. However, using OpenVMS V7.1, the write to the output file fails with a file locked error. The file name issue is easily reproducible using a command file (eg. MAIL_TEST.COM) which contains: $ SHO SYM p1 $ SHO SYM p2 $ EXIT For a VAX running OpenVMS V6.2: VMSSPT> DEFINE MAIL$EDIT work3:[user1.tests]mail_test.com VMSSPT> MAIL MAIL> REPLY/EXTRACT/NOSELF To: NODE::USER1 CC: Subj: RE: DCL quote parsing rules P1 = "SYS$SCRATCH:MAIL_21E01ECA_EDIT.TMP" <<<<< infile name P2 = "SYS$SCRATCH:MAIL_21E01ECA_SEND.TMP" <<<<< outfile name %MAIL-E-SENDABORT, no message sent MAIL> For a VAX running OpenVMS V7.1: VMSSPT> DEFINE MAIL$EDIT work300:[user1.tests]mail_test.com VMSSPT> MAIL MAIL> REPLY/EXTRACT/NOSELF To: NODE::USER1 CC: Subj: RE: test P1 = "SYS$SCRATCH:MAIL_26204609_SEND.TMP" <<<<< infile name P2 = "SYS$SCRATCH:MAIL_26204609_SEND.TMP" <<<<< outfile name again %MAIL-E-SENDABORT, no message sent MAIL> Page 3 For an Alpha running OpenVMS V7.1: VMSSPT> DEFINE MAIL$EDIT mail_test.com VMSSPT> MAIL MAIL> REPLY/EXTRACT/NOSELF To: NODE::USER1 CC: Subj: RE: ALPHA OpenVMS V7.1 image P1 = "SYS$SCRATCH:MAIL_53E00262__SEND.TMP" <<<<< infile name P2 = "SYS$SCRATCH:MAIL_53E00262_SEND.TMP" <<<<< infile name again %MAIL-E-SENDABORT, no message sent MAIL> Further testing revealed that several other mail commands were using incorrect input and output file names: REPLY/EDIT/LAST REPLY/EXTRACT REPLY/EXTRACT/EDIT ANSWER/EXTRACT ANSWER/LAST/EDIT SEND/EDIT/LAST MAIL/EDIT/LAST FORWARD/EDIT o The OpenVMS V7.1 MAIL DIR command output needed to be directed. Defining the logical SYS$OUTPUT to a file and then executing the command DIR/NEW within the MAIL utility no longer returned a listing of the new file messages as it did in OpenVMS V6.1. o When an application attempts to extract mail from a user's mail files by doing a $SET FILE to point to the target user's mail files, which are 'foreign' documents, the extract fails. The current user's MAIL directory is searched rather than the mail directory of the target user, where the the document files (MAIL$nnnnnnnn.MAI) exist. A sequence of MAIL commands to duplicate the problem are: $ MAIL/FOR LOGIN.COM NODE::USER - then on NODE logged in as say SYSTEM: $ MAIL SET FILE DIA0:[USER] SET FOLDER NEWMAIL READ 1 EXTRACT USER1.DAT $ The above example fails to issue a message (sample expected message below) and no file is created: Page 4 %MAIL-I-CREATED, SYS$SYSROOT:[SYSMGR]USER1.DAT;1 created o Two problems concerned the use of the MAIL$INTERNET_TRANSPORT logical: 1. Defining MAIL$INTERNET_TRANSPORT forced the use of the alternate mail image, even when DECnet should be used. 2. If the user included a different transport on the "TO" line, the mail code treated it as part of the address and passed it on to the image defined by MAIL$INTERNET_TRANSPORT, causing delivery errors. Problems addressed in ALPMAIL02_071 kit o Sending a mail message to a large distribution list (between 200 to 700 local users) intermittently signals a non-fatal SSRVEXCEPTN bugcheck for the sending process. o Enable EDIT/LAST on REPLY and SEND terminated with CTRL-C. When REPLYing to or SENDing a message using the MAIL UI's "line editor", if the user enters CTRL-C to abort the edit (and the send), a problem can occur. That is, if the user then issues a SEND/EDIT/LAST or REPLY/EDIT/LAST as the next mail command, the text of that message cannot be re-edited (and resent) . o After upgrading to OpenVMS V7.1, printing from mail produces an unexpected file flag page in the output. o Message header overwrites and message record truncation occur. Problems have occurred with OpenVMS MAIL users reading mail sent by Quickmail users. The root of this problem was that the Quickmail interface allows a user to compose a long paragraph, without ever hitting the "Return" key. Quickmail will then wrap the text and send the entire paragraph as one long line. OpenVMS MAIL (character cell version), will wrap the text when displaying a long line, but will only display the first 512 characters of the line. OpenVMS users see only part of the paragraph and are confused. The old version of MAIL ($MAIL/OLD) was able to display a line of up to 2048 characters. (A second related problem was that OpenVMS MAIL will sometimes display only the first page of a message. It will say "Press RETURN for more..." at the end of the page, but when you press RETURN, no more is displayed. This problem happens to some Quickmail messages which contain long lines. Again, MAIL/OLD will display it properly.) Page 5 o A problem results when copying mail messages from a sequential mail file into an indexed mail file. From within MAIL, a sequential mail file is opened containing small (less than 3 blocks) and large (greater than 3 blocks) mail messages. These messages are selected and then copied into a folder in an indexed mail file. After reading and deleting a large message, the body of the sample small message shown below is lost. (The header is there, but the body is gone.) The following steps can be used to reproduce the behavior: $ MAIL MAIL> set file seq_mail_file.mai ! Sequential mail file MAIL> copy/all test test.mai ! Copy all messages from ! sequential mail file into ! folder 'test' in indexed ! mail file 'test.mai'. Note ! that 2 messages were copied ! - a large one and a small ! one. The file TEST.MAI was ! created by the copy command. MAIL> set file test.mai ! Point to indexed mail file MAIL> dir test ! See both mail messages ! Read both messages to ensure they exist MAIL> delete 1 ! Delete the large mail message MAIL> purge ! Ensure it gets deleted MAIL> EXIT $ MAIL MAIL> set file test.mai ! Read the second message and the body will be gone This problem with bodies of emails being lost occurs when the following conditions are true: 1. At least 2 emails in the sequential mail file were created within 1 minute. 2. Emails were copied to an indexed sequential access mode (ISAM) mail file. 3. Order of emails in the sequential mail file were such that the first email results in an external EMAIL file being created (MAIL$*.MAI). The second email results in the entire message being saved in the mail file (MAIL.MAI). 4. Email that results in the external EMAIL file being deleted. 5. The body of the remaining email is now lost. Page 6 o Interactively defining a key containing a quoted component fails: MAIL> define/key/if_state=gold kp9 "read/new" %MAIL-E-PARSEFAIL, error parsing DEFINE/KEY/IF_STATE=GOLD KP9 READ/NEW -CLI-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement If this same definition is in a MAIL$KEYDEF.INI file, the key definition parsing is successful. In addition, enclosing the command and qualifier inside a triple set of quotes will work, but this form contradicts the OpenVMS MAIL UI documentation, and is a departure from pre-V7.1 OpenVMS MAIL UI behavior. o MAIL does not provide a correct exit status when invoked as a Command Line Interface (CLI) command and an error occurs. This feature worked in pre-V7.0 MAIL. o When replying to an address of the form node::node::"addressee", the reply fails with "%MAIL-E-USERSPEC, invalid user specification". This problem is most likely to occur with X.400 type addresses and poor man's routing, but can happen with any quoted address using PMR. However, replying to node::"address" is successful. Note: (DECnet) "Poor Man's Routing" can be used between nodes outside of the translation map as long as those nodes have access to nodes that are in the map. For example, in the diagram below, a user on node B could issue the following OpenVMS DCL command: $ DIR A::D::E:: When a PMR connection is made between 2 networks, only the 2 adjacent nodes between the networks will have any direct knowledge about the other network. Application-level network access can then be specified to route through the connection. Poor Man's Routing sample configuration Network 1 19.5 47.1 Network 2 ------------------------------ --------------------------- | | | | | | | | | | | | | | | | | | | --------------- | | | 19.1 19.2 19.3 /E1---->|<----E2\ 50.1 60.1 19.1 A:: B:: C:: | | D:: E:: F:: | Router | `---------------' 19.5 --------> 50.1 19.1 <-------- 47.1 Page 7 For the above configuration, in Network 1, the router is configured at address 19.4 and is a level 1 router. In Network 2, the router is configured at address 50.5 and is an area router. At this point, no routing information is exchanged between the 2 networks. Each network in the router has a separate routing table. Packets in Network 1 sent to virtual address 19.5 will be routed to Network 2, and the destination address will be translated to 50.1. Packets sent to virtual address 47.1 in Network 2 will be routed to Network 1 as 19.1. o A SSRVEXCEPT was caused by an access violation in MAILSHRP. o Two problems are addressed by this checkin: 1. When MAIL.EXE is invoked as a CLI command and then an error occurs on a remote node, the error status is not returned to the user. This error causes problems when MAIL CLI commands are themselves embedded in DCL command files, where the success or failure of the mail command is checked and acted upon. 2. If the symbol MAIL:=="MAIL/EDIT = (SEND,REPLY = EXTRACT,FORWARD) is defined and the user specifies /NOEDIT when replying, the editor is invoked so that NOEDIT is ignored. In addition, when this same MAIL symbol is defined, REPLY/NOEXTRACT does not invoke the editor at all, where on OpenVMS V6.2 and before, REPLY/NOEXTRACT would invoke the editor (without inclusion of the original message). o The second and subsequent pages of a mail message scroll up the screen, which is a departure from previous behavior. o The "ring-buffer" behavior of reading mail appears to be broken. After reading and getting the "no more messages" error, in previous versions of OpenVMS, the next read would show the first record in the folder. Now it continues to give the "no more message" error. o SEND/LAST and SEND/LAST/EDIT do not use the text of the last message sent. o The address of the privileged context was zero, causing any downstream access to any offset within it to access violate. This problem occurred mostly, but not always, when an error was being handled. o On machines running DECnet Phase IV only, sending to a local quoted addressee returned the user to the MAIL prompt without any error message. If this address was in a distribution list, the sender was not informed that the message was not delivered to one (or more) recipients. Page 8 Problems addressed in VAXMAIL01_071 kit o Two SSRVEXCEPTION crashes in MAILSHRP when running lbn disk I/O or UETP, in the context of the image DTWM. o The TO line in a received message can become so skewed that passwords for remote distribution lists may be visible. o In the event of an invalid or nonexistent SYSUAF.DAT, or an error reading SYSUAF.DAT, the user is unaware of any error and MAIL either continues, or exits. If an error is signaled at all, the error message is often meaningless. o Users of some POP servers, as well as a third party MAIL UI (PMDF) were seeing access violations in MAILSHRP. These occurred primarily in the event of a locked SYSUAF record and subsequent signaling of MAIL$_UAFGETERR. Sites typically seeing this to date have been universities where 10,000 to 11,000 simultaneous mail users is the norm. Kit Installation Rating: The following kit installation rating, based upon current CLD information, is provided to serve as a guide to which customers should apply this remedial kit. (Reference attached Disclaimer of Warranty and Limitation of Liability Statement) INSTALLATION RATING: 3 : To be installed by customers experiencing the problems corrected. Installation Instructions: Install this kit with the VMSINSTAL utility by logging into the SYSTEM account, and typing the following at the DCL prompt: @SYS$UPDATE:VMSINSTAL ALPMAIL03_071 [location of the saveset] The saveset location may be a tape drive, CD, or a disk directory that contains the kit saveset. No reboot is necessary after successful installation of the kit. Copyright (c) Compaq Computer Corporation, 1999 All Rights Reserved. Unpublished rights reserved under the copyright laws of the United States. The software contained on this media is proprietary to and embodies the confidential technology of Compaq Computer Corporation. Possession, use, or dissemination of the software and media is Page 9 authorized only pursuant to a valid written license from Compaq Computer Corporation. DISCLAIMER OF WARRANTY AND LIMITATION OF LIABILITY THIS PATCH IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED TO THE EXTENT PERMITTED BY APPLICABLE LAW. IN NO EVENT WILL COMPAQ BE LIABLE FOR ANY LOST REVENUE OR PROFIT, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, WITH RESPECT TO ANY PATCH MADE AVAILABLE HERE OR TO THE USE OF SUCH PATCH.