Kit Name: ALPMAIL02_071 Kits superseded by this kit: ALPMAIL01_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 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. Page 2 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.) 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 Page 3 ! 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. 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. Page 4 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 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 Page 5 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. 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. Page 6 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: 1 : To be installed by all customers. 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 ALPMAIL02_071 [location of the saveset] The saveset location may be a tape drive, or a disk directory that contains the kit saveset. No reboot is necessary after successful installation of the kit. Copyright (c) Compaq Computer Corporation, 1998 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 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.