ECO NUMBER: VAXMAIL06_061 ----------- PRODUCT: OpenVMS VAX Operating System -------- UPDATED PRODUCT: OpenVMS VAX Operating System 6.1 ---------------- APPRX BLCK SIZE: 1990 ---------------- UPDATE PRODUCT: OpenVMS VAX OPERATING SYSTEM 6.1 COVER LETTER 1 KIT NAME: VAXMAIL06_061 2 KITS SUPERSEDED BY THIS KIT: VAXMAIL05_061 3 KIT DESCRIPTION: 3.1 Version(s) of OpenVMS to which this kit may be applied: OpenVMS VAX OpenVMS VAX V5.5, V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1 3.2 In order to receive the full fixes listed in this kit the following remedial kits also need to be installed: None 3.3 Files patched or replaced for OpenVMS VAX V5.5, V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF o [SYSEXE]MAIL.EXE (new image) o [SYSLIB]MAILSHR.EXE (new image) o [SYSLIB]MAILSHRP.EXE (new image) o [SYSEXE]MAIL_SERVER.EXE (new image) 3.4 Files patched or replaced for OpenVMS VAX V6.0 o [SYSEXE]MAIL.EXE (new image) o [SYSLIB]MAILSHR.EXE (new image) o [SYSLIB]MAILSHRP.EXE (new image) o [SYSEXE]MAIL_SERVER.EXE (new image) o [SYSLIB]SECURESHRP.EXE (new image) -- COVER LETTER -- Page 2 8 November 1996 3.5 Files patched or replaced for OpenVMS VAX V6.1 o [SYSEXE]MAIL.EXE (new image) o [SYSLIB]MAILSHR.EXE (new image) o [SYSLIB]MAILSHRP.EXE (new image) o [SYSEXE]MAIL_SERVER.EXE (new image) o [SYSLIB]SECURESHRP.EXE (new image) 4 PROBLEMS ADDRESSED IN VAXMAIL06_061 KIT FOR V5.5, V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF V6.0, V6.1 o This kit is being issued to update the SECURESHRP.EXE image to avoid installation conflicts with the VAXLOAD01_070 kit which also contains the SECURESHRP.EXE image. There are no new fixes in this kit. If you have installed the VAXMAIL05_061 kit you do not need to install this kit. 5 PROBLEMS ADDRESSED IN VAXMAIL05_061 KIT FOR V5.5, V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1 o In the MAIL user interface, if a user asks for a directory of a nonexistent folder, the signaled message is: %MAIL-E-NOTEXIST, folder !AS does not exist The actual message should contain the name of the nonexistent folder rather than !AS. This problem is corrected in OpenVMS VAX V6.2. 6 PROBLEMS ADDRESSED IN VAXMAIL05_061.RNO KIT FOR OPENVMS VAX V6.1 o The SECURESHRP.EXE image is common to the VAXMAIL04_061 and VAXLOAD01_061 kit. In order to eliminate a possible image regression problem, this kit updates the SECURESHRP.EXE image to the same level as the image in the VAXLOAD01_061 kit. -- COVER LETTER -- Page 3 8 November 1996 7 PROBLEMS ADDRESSED IN VAXMAIL04_061 KIT FOR V5.5, V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1 o Report Mail status code rather than system status code o Applications that use the MAIL$ callable mail API can exhaust virtual memory and cause system crashes due to insufficient virtual memory. o The $GETUAI and $SETUAI services may return RMS record locked errors when attempting to access the SYSUAF. These errors will happen if the caller uses these services with a context block supplied (which keeps the SYSUAF open), and encounters a locked record for other than the initial call (because the RMS structures aren't correctly re-initialized after the initial call). o When two processes are accessing the same folder in the same mail file (one writing messages to it, the other updating message headers as in a mail delete operation), the program that is updating message headers will occasionally ACCVIO. 8 PROBLEMS ADDRESSED IN VAXMAIL03_061 KIT FOR V5.5, V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1 o When two processes are accessing the same folder in the same mail file (one writing messages to it, the other updating message headers as in a mail delete operation), the program that is updating message headers will occasionally ACCVIO. This can occur using either callable MAIL or MAIL commands in a DCL command procedure. o Occasionally, when reading mail, an error message is received: %MAIL-E-OPENIN, error opening DEV:[USER.MAIL]MAIL$1234567800050098.MAI; as input -RMS-E-FNF, file not found The mail message does exist, but it exists under a slightly different filename. In this case, the actual message that is logged in the mail directory is one digit off from the filename in the error message: MAIL$1234567900050098.MAI;1 ^ this is the difference -- COVER LETTER -- Page 4 8 November 1996 9 PROBLEMS ADDRESSED IN VAXMAIL03_061 KIT FOR V6.1 o Under certain circumstances, if MAIL$SEND_ADD_ADDRESS is called with a TO address that is a local recipient's address referencing an alternate transport image that is not installed, it appears that the call to MAIL$SEND_ADD_ADDRESS is hung, and control is never returned to the calling program. Example: XYZ%"USERNAME" is the value of the MAIL$_SEND_USERNAME item used in the call to MAIL$SEND_ADD_ADDRESS, and the XYZ mail transport image is not installed. In order for MAIL$SEND_ADD_ADDRESS to fail like this, the failing address must be a local one, and an UNWIND has to be initiated once the call to LIB$FIND_IMAGE_SYMBOL fails. This is done by either: 1) including MAIL$_NOSIGNAL in the input item list for the call to MAIL$SEND_ADD_ADDRESS, (causing MAIL$$HANDLER to call $UNWIND) or 2) LIB$SIG_TO_RET (which calls $UNWIND) is either enabled as a condition handler in the calling program, or is called in the calling program's condition handler, or 3) the caller calls the $UNWIND service on it's own These events will cause MAILSHR's TRANSPORT_HANDLER to be executed, which did not test for an UNWIND in progress; it simply resignalled the ERRACTRNS (error activating transport) error, causing it and the other 2 MAILSHR condition handlers on the stack to recursively call each other. o If sending mail to a user on the same machine or on the same cluster, both the broadcasted new mail notification message and the FROM line contains only the username, not the node::username of the sender. 10 PROBLEMS ADDRESSED IN VAXMAIL02_061 KIT FOR V6.1 o The VAXAUDI01_061 and VAXMAIL01_061 contain different versions of MAILSHRP.EXE. If a user installed the VAXAUDI01_061 and then installed the VAXMAIL01_061 kit, image regression would occur. This kit combines the VAXMAIL01_061 and VAXAUDI01_061 with the latest version of MAILSHRP.EXE to prevent this regression. -- COVER LETTER -- Page 5 8 November 1996 11 PROBLEMS ADDRESSED IN VAXAUDI01_061 KIT FOR V6.1 o Correct a security problem involving process auditing. 12 PROBLEMS ADDRESSED IN VAXMAIL01_061 KIT FOR V6.1 o The FROM field, and the mail notification message broadcast to a user's terminal, uses the DECnet phase 5 fullname in the node specification instead of the cluster alias or simple name. o If a file containing a message is sent repeatedly to a recipient with a logical name in the disk portion of the mail file directory spec (the SYSTEM account, for example, using SYS$SYSROOT:[SYSMGR] MAIL.MAI), the sends will eventually fail, when the MAIL image is not restarted, with: %MAIL-E-SENDERR, error sending to user SYSTEM -MAIL-E-OPENOUT, error opening SYS$SYSROOT:[SYSMGR]MAIL.MAI; as output -SYSTEM-F-IVDEVNAM, invalid device name o OpenVMS VAX V6.1 MAIL does not preserve the pre-OpenVMS VAX V6.1 avoidance of DECnet connections when sending inter-cluster MAIL. o If a user enters an address of the form IN%"FRED@BC (foreign protocol, mismatched quoted address) LIB-F-SYNTAXERR is signaled and the user is returned to DCL. Other kinds of errors generated by an address in the TO line will either return the user to the MAIL> prompt, or the user is asked if he/she wants to send anyway. o Sending mail to a user from more than 1 source within a 10ms interval returns the following errors: %MAIL-E-SENDERR, error sending to username USERNAME -MAIL-W-WRITERR, error writing DISK:[USER_DIRECTORY]MAIL.MAI;1 -RMS-F-DUP, duplicate key detected (DUP not set) o An access violation occurs within MAIL$MESSAGE_SELECT when selecting messages from a mail folder, and occurs when two processes are accessing the same mail folder. 13 PROBLEMS ADDRESSED IN VAXMAIL02_060 KIT FOR V6.0 o The VAXAUDI01_060 and VAXMAIL01_060 contain different versions of MAILSHRP.EXE. If a user installed the VAXAUDI01_060 and then installed the VAXMAIL01_060 kit, image regression would occur. This kit combines the VAXMAIL01_060 and VAXAUDI01_060 with the latest version of MAILSHRP.EXE to prevent this -- COVER LETTER -- Page 6 8 November 1996 regression. 14 PROBLEMS ADDRESSED IN VAXAUDI01_060 KIT FOR V6.0 o Correct a security problem involving process auditing. 15 PROBLEMS ADDRESSED IN VAXMAIL01_060 KIT FOR V6.0 o MAIL.EXE will honor a process' enabled EXQUOTA privilege for SEND/NOEDIT, only if issued after SEND/EDIT. o When a mail file is COMPRESSed, if the COMPRESS fails, the MAIL_xxx_COMPRESS.TMP file will be left in the MAIL directory. This prevents that process from being able to successfully re-attempt the COMPRESS until the MAIL_xxx_COMPRESS.TMP file is manually unprotected and deleted. o If a message is moved or filed from one MAIL folder to another, and the user attempts to EXTRACT that message without first SELECTing the new folder, then READing the message, the file create fails but MAIL does not notify the user. o Some MAIL commands fail after SET MAIL_DIRECTORY [.NEW_DIR] is issued by the user. Depending on the order of MAIL commands issued: - DIR/FOLDER fails on a file open error attempting to open MAIL.MAI in the old directory - READ fails on a file open error attempting to open a message file in the old directory - SHOW FILE (or SHOW ALL) reports the location of the MAIL file, and the name of the MAIL directory incorrectly - COMPRESS fails trying to open a MAIL file in the old directory o If a user does not provide either a mail file name or a default mail file name in the call to MAIL$MESSAGE_COPY, MAILSHR creates SYS$LOGIN:MAIL.MAI, and copies the message there. o If an error is incurred during processing of a call to MAIL$SEND_MESSAGE, for example, if an attempt is made to send to an address containing an invalid device, the calling program hangs. -- COVER LETTER -- Page 7 8 November 1996 o Two user routines, MAIL$USER_BEGIN and MAIL$USER_GET_INFO, will return the length of an output itemlist item to a user supplied address if requested. The two routines MAIL$$USER_RET_INFO_OLD and MAIL$$USER_RET_INFO_NEW actually return the length. The MAIL documentation states that the return length address item in the output itemlist is "a longword containing the user-supplied address of a word in which the routine writes the actual length in bytes of the information it returned." MAIL$$USER_RET_INFO_OLD and MAIL$$USER_RET_INFO_NEW are writing a longword into the user-supplied address of a word, thereby overwriting any adjacent field(s). o If a file containing a message is sent repeatedly to a recipient that has a logical name in the disk portion of the mail file directory spec (the SYSTEM account, for example, using SYS$SYSROOT:[SYSMGR] MAIL.MAI), the sends will eventually fail, when the MAIL image is not restarted. The error message seen is: %MAIL-E-SENDERR, error sending to user SYSTEM -MAIL-E-OPENOUT, error opening SYS$SYSROOT:[SYSMGR]MAIL.MAI; as output -SYSTEM-F-IVDEVNAM, invalid device name o If a user enters an address of the form: IN%"FRED@BC, (foreign protocol, mismatched quoted address), LIB-F-SYNTAXERR is signaled and the user is returned to DCL. Other kinds of errors generated by an address in the TO line will either return the user to the MAIL> prompt, or the user is asked if he/she wants to send anyway. o Sending mail to a user from more than one source within a 10ms interval returns the following errors: %MAIL-E-SENDERR, error sending to username USERNAME -MAIL-W-WRITERR, error writing DISK:[USER_DIRECTORY]MAIL.MAI;1 -RMS-F-DUP, duplicate key detected (DUP not set) o If the node name portion of an address is a logical name, MAIL displays the logical translation in the TO: and CC: lines (if present). o When two processes are accessing the same mail folder, an access violation occurs within MAIL$MESSAGE_SELECT when selecting messages from the folder. o When DECW$EXAMPLES:CLOCK.DDIF is sent, with or without the /FOREIGN switch, the receiver does not see any message indicating that the file must be treated differently from other MAIL messages when extracted. When foreign files are "read", the following message is displayed: %MAIL-E-FORMSG, you cannot read this foreign format message -- COVER LETTER -- Page 8 8 November 1996 Use the EXTRACT command to copy the message to an external file While MAIL does send CLOCK.DDIF correctly, the absence of this "flag" may lead the user to believe it is an empty file, a message consisting of nothing but the message header, and it could be mistakenly deleted. If the MAIL command DIR/FULL is issued, the message containing CLOCK.DDIF has "Foreign" listed as a message attribute. Some other .DDIF files, as well as other files sent with the /FOREIGN switch, do cause the %MAIL-E-FORMSG message to be displayed. 16 PROBLEMS ADDRESSED IN VAXMAIL06_U2055 KIT FOR V5.5, V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF o Sending mail to a user from more than 1 source within a 10ms interval returns the following errors: %MAIL-E-SENDERR, error sending to username USERNAME -MAIL-W-WRITERR, error writing DISK:[USER_DIRECTORY]MAIL.MAI;1 -RMS-F-DUP, duplicate key detected (DUP not set) o When two processes are accessing the same mail folder, If a user attempts to select messages from one of the folders, an access violation occurs within MAIL$MESSAGE_SELECT. 17 PROBLEMS ADDRESSED IN VAXMAIL05_U2055 KIT FOR V5.5, V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF o MAIL hangs when attempting to send mail to two users on a remote node when one has his mail forwarded to the other. o MAIL current message number getting set incorrectly, or to nonexistent message numbers as a result of BACKUP or NEXT commands which result in a "No more messages" error. o ACCVIO when attempting to send binary files or other files with records larger than what MAIL is willing to deal with. o Copying large mail messages to a drawer/directory accessible by ACL will get a protection failure trying to create the external message body file. This happens because the SYSTEM UIC is still hanging around in the (recycled) XABPRO used to create the file. Zeroing the UIC before the create fixes the problem. o RMS$_DUP errors when sending local messages from STREAM files with odd length of 3 blocks plus 465 to 511 bytes. -- COVER LETTER -- Page 9 8 November 1996 o MAIL doesn't know how to send a DDIF or DTIF compound document. Attempts to do so will successfully send the base file itself (if /FOREIGN, which isn't supported, is used), but none of its inclusions. DECwindows MAIL already knows how to do this. This edit is simply bowing to all the external pressure to make MAIL do it, too. This was made even easier when someone who works on CDA took the trouble to write the code for MAIL to do that. o System manager discovers that the disk volume used by the MAIL_SERVER process has lots of lost MAIL.TXT files on it. o User-written applications need SYSPRV to connect to the remote node. o A program which invokes callable mail works without extraordinary privileges, but that same program, when invoked with SYSPRV set in the process privilege mask will fail with an insufficient privilege message. o When TPU is the selected editor (either explicitly or by default) and the user attempts any MAIL command which invokes the editor on a terminal which is not an ANSI-compliant CRT (such as a hard-copy terminal), TPU exits with TPU$_NONANSICRT, but the message is discarded. The user sees the next MAIL> prompt without any indication of what is wrong. o When a user enters the DCL command $ MAIL filename, without specifying an addressee, MAIL prompts for the addressee with "To:". If the user merely hits RETURN without supplying an addressee, MAIL exits without comment and with success status. o The description of how the logical name MAIL$EDIT is used in MAIL is out of date and incorrect in MAILEDIT.COM, the example file of a command procedure suitable for assigning to MAIL$EDIT. o MAIL can't handle ACL protected MAIL.MAI files Attempting to COMPRESS a MAIL file, where access to that file and parent directory are granted via an identifier ACE on a RESOURCE owned by the user, fails due to privilege violation while attempting to rename the new file to MAIL.MAI. This occurs because MAIL isn't aware of the ACE created by the file system for the user doing the creation, and therefore, MAIL doesn't know to change that ACE to grant itself DELETE access so that it may perform the RENAME. o If a received mail message contains lines longer than the terminal's width (either as part of the message header, or as part of the message text), the message display will scroll the top few lines off the screen before prompting "Press return for more". o A user program, after having discovered that error messages cannot be trapped with an error handler (see previous MAILSHR bug) tries to disable all error signaling by turning on the -- COVER LETTER -- Page 10 8 November 1996 "NOSIGNAL" option in the call to MAILSHR. MAILSHR responds to this by mostly not working. In particular, calling MAILSHR to compress a mail file, specifying "NOSIGNAL" in the call, will result in the operation aborting just after the .TMP file is created. o User A does a SET FORWARD PSI%mumble::UserC. User B sends mail to PSI%mumble::UserA. The mail happens to be a STREAM_LF file (or something else that isn't "normal" text file format). Somewhere along the way, someone forgets about that STREAM_LF business, and User C ends up with a useless (unreadable) mail message. o Selecting a folder after a SEARCH command causes the search string to be lost. Previous behavior was to retain the search string so that another SEARCH command without a new search string would attempt to locate the same string in the newly-selected folder. o A user written program that calls MAILSHR's callable interface to compress his MAIL file cannot reliably detect whether the compress fails. While MAILSHR displays error strings to the user's terminal, it does not signal anything of consequence to the user's program. Furthermore, the routine status returned by MAILSHR is garbage. o User says "DELETE n-m", where the highest selected message number is less than "n". What he gets for his efforts is the deletion of all the messages in the currently selected folder, even though all are outside the selected deletion range. o While attempting to send mail, the sender sees a "Signal with no arguments" error. This happens when sending to a mail file that's broken. o NEXT_ITEM isn't init'd in this module. In some instances can cause a system crash because of it. o Mail occasionally neglects to display the first line of a mail message. The line is in fact there, and displayable on subsequent attempts to display the message. o Even though explicit access is ignored by Mail, when an addressee spec has explicit access; e.g., To: REMOTE"USER CORRECTPASSWORD"::USER2, the specified password arrives in the clear at all destinations. o When DECW$EXAMPLES:CLOCK.DDIF is sent, with or without the /FOREIGN switch, the receiver does not see any message indicating that the file must be treated differently from other -- COVER LETTER -- Page 11 8 November 1996 MAIL messages when extracted. When foreign files are "read", the following message is displayed: %MAIL-E-FORMSG, you cannot read this foreign format message Use the EXTRACT command to copy the message to an external file While MAIL does send CLOCK.DDIF correctly, the absence of this "flag" may lead the user to believe it is an empty file, a message consisting of nothing but the message header, and it could be mistakenly deleted. If the MAIL command DIR/FULL is issued, the message containing CLOCK.DDIF has "Foreign" listed as a message attribute. Some other .DDIF files, as well as other files sent with the /FOREIGN switch, do cause the %MAIL-E-FORMSG message to be displayed. o If the node name portion of an address is a logical name, MAIL displays the logical translation in the TO: and CC: lines (if present). o Some MAIL commands fail after SET MAIL_DIRECTORY [.NEW_DIR] is issued by the user. Depending on the order of MAIL commands issued: - DIR/FOLDER fails on a file open error attempting to open MAIL.MAI in the old directory - READ fails on a file open error attempting to open a message file in the old directory - SHOW FILE (or SHOW ALL) reports the location of the MAIL file, and the name of the MAIL directory incorrectly - COMPRESS fails trying to open a MAIL file in the old directory o MAIL.EXE will honor a process' enabled EXQUOTA privilege for SEND/NOEDIT, only if issued after SEND/EDIT. o The user tries to COMPRESS his MAIL file, and for whatever reason (valid or otherwise), the COMPRESS fails. This leaves a MAIL_xxx_COMPRESS.TMP file in the user's MAIL directory, which prevents that process from being able to successfully re-attempt the COMPRESS until the user manually unprotects and deletes the .TMP file. o If a message is moved or filed from one MAIL folder to another, and the user attempts to EXTRACT that message without first SELECTing the new folder then READing the message, the file create fails but MAIL does not notify the user. o If a user does not provide either a mail file name or a default mail file name in the call to MAIL$MESSAGE_COPY, MAILSHR creates SYS$LOGIN:MAIL.MAI, and copies the message there. -- COVER LETTER -- Page 12 8 November 1996 o Two user routines, MAIL$USER_BEGIN and MAIL$USER_GET_INFO, will return the length of an output itemlist item to a user supplied address if requested. The two routines MAIL$$USER_RET_INFO_OLD and MAIL$$USER_RET_INFO_NEW actually return the length. The MAIL documentation states that the return length address item in the output itemlist is "a longword containing the user-supplied address of a word in which the routine writes the actual length in bytes of the information it returned." MAIL$$USER_RET_INFO_OLD and MAIL$$USER_RET_INFO_NEW are writing a longword into the user-supplied address of a word, overwriting any adjacent field(s). o A user program was hanging on a call to MAIL$SEND_MESSAGE when attempting to send to an address containing an invalid device. o If a file containing a message is sent repeatedly to a recipient with a logical name in the disk portion of the mail file directory spec (the SYSTEM account, for example, using SYS$SYSROOT:[SYSMGR] MAIL.MAI), the sends will eventually fail, when the MAIL image is not restarted, with: %MAIL-E-SENDERR, error sending to user SYSTEM -MAIL-E-OPENOUT, error opening SYS$SYSROOT:[SYSMGR]MAIL.MAI; as output -SYSTEM-F-IVDEVNAM, invalid device name 18 PROBLEMS ADDRESSED IN VAXMAIL03_U2055 KIT FOR V5.5, V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF o A user application using callable mail establishes a condition handler which unwinds the stack when Mail signals an unreachable node (and presumably, other errors as well). This results in their associated mailboxes not being deassigned, and hence, the application uses up the BYTLM quota. 19 PROBLEMS ADDRESSED IN MAIL$03_U1055 KIT FOR V5.5, V5.5-1 o MAIL_SERVER's code assumes that nothing's going to go wrong between the time it creates the temporary MAIL.TXT file and the time it delivers that mail and subsequently deletes the temporary file. This is, of course, a bad assumption. If, for any reason, the mail message delivery is aborted, MAIL_SERVER will neglect to delete the MAIL.TXT file it created, leaving a lost (not pointed to by any directory) file on the disk. -- COVER LETTER -- Page 13 8 November 1996 20 PROBLEMS ADDRESSED IN MAIL$01_U1055 KIT FOR V5.5, V5.5-1 o The user EXTRACTs a foreign message, and finds the extracted mail in a file allowing all access from everywhere. 21 KIT INSTALLATION RATING: The following kit installation rating, based upon current CLD information, is provided to serve as a guide as 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. 22 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 VAXMAIL06_061 [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) Digital Equipment Corporation, 1996 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 Digital Equipment Corporation. Possession, use, or dissemination of the software and media is authorized only pursuant to a valid written license from Digital Equipment 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 DIGITAL 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.