PC Gen: Summary List of Mail for PC Networks 3.5 Bug Fixes

SUMMARY

Below is a list of bugs fixed in version 3.5 of Microsoft Mail for PC Networks.

For more information on the fix listed, query in the Microsoft Knowledge Base on the article ID or the bug number.

SUMMARY OF FILES UPGRADED FOR MAIL 3.5

All files have been upgraded with version 3.5 of Microsoft Mail for PC Networks. A comprehensive list of all files upgraded due to fixes or otherwise revised is as follows:

Client (version 3.5.2000.4086)

MSMAIL.EXE
MAPI.DLL
MSSFS.DLL
SCHEDMSG.DLL
Microsoft Mail (Macintosh workstation)

Server (version 3.5 for .EXE)

ADMIN.EXE
EXTERNAL.EXE
ASYNC.OVL
X25ATLAN.OVL
X25EICON.OVL
IMPORT.EXE
REBUILD.EXE
SRVMAIN.EXE

SERVER BUGS FIXED IN MAIL 3.5

PC Adm: Microsoft Mail ADMIN.EXE 3.2.17 Update

• With the earlier version of this file, a corrupt .MAI file could be created when you export the address list to a large number of postoffices. ADMIN.EXE has been modified so that the correct .MAI file is created when address lists are exported.
• With the earlier version of this file, a corrupt SRVCONF.GLB file could be created when you add a directory synchronization (Dir- Sync) requestor on a computer that has an EtherExpress(TM) 16 network card and is running the Ethernet_II protocol. ADMIN.EXE has been modified so that it uses a buffer size of 512 bytes instead of 1K for its buffered I/O.
• If a Mail Remote for Windows user forgets his or her password or if the password is changed while the remote driver is in use, the password can now be reset.
  
  NOTE: This password reset only applies to the server files. Local .MMF files will not be affected by this change.
  
  Notes:
  
  
  • To resolve this problem, two files must be updated: the ADMIN.EXE file (included in this update) and the MSRMTUI.DLL file (update included in MSRMTUI.EXE on the MSL).
  • To reset the password, you must ensure that the user's data disk was created using ADMIN.EXE version 3.2.12.
• Local postoffice users added with the ADMIN.EXE utility will no longer be assigned an invalid identification number if the TID.GLB file is locked open. Also, batch creation of local postoffice users with the ADMIN.EXE utility while the TID.GLB file is locked open no longer results in the same invalid identification number being assigned to multiple users.
• When you use ADMIN.EXE to change the routing type defined for a hub postoffice, the routing type definition for any downstream postoffice is also updated to match the routing type of the hub postoffice.
• When you use ADMIN.EXE to remove users from a global group, access to group folders associated with that global group is also removed.
• Correct figures are now reported when you use the Mail Administrator program to create reports that involve multiple postoffices with more than 32,768 users.
• Groups with names 10 characters long can now be deleted successfully on other postoffices. With versions of ADMIN.EXE earlier than 3.2.12, if a group was deleted from a postoffice participating in Dir-Sync and its name was 10 characters long, other postoffices, including the Dir-Sync server, were unable to delete the group from their .USR files.
• When the Admin account mailbox is greater than eight characters in length, the Keep Updates number will no longer change when you change the Administrator's Name in Config, DirSync, Server, Options.
  
  NOTE: To fix this problem, you need ADMIN.EXE version 3.2.13 or later (included in this update) and SRVMAIN.EXE version 3.2.13 or later, LISTDS.EXE version 3.2.1, and SCONFIX.EXE (updates included in SRVUPD.EXE on the MSL).
• When you modify a remote client's account using Admin, Local Admin, Modify, the remote user's Custom View is no longer reset to the Default view.
• ADMIN.EXE will now report an error writing to nnnnnnnn.XTN file, if locked open by another process.

PC Adm: IMPORT.EXE 3.2.18 Update

• The Import utility (with the -A option) no longer adds invalid DGN names to the Postoffice Address List (POL) when those names do not appear in the normal .USR files.
• The Import utility no longer corrupts the MCI.NME file when importing MCI user names. This problem caused the Mail Administrator program to incorrectly display the MCI address information.
• The Import utility no longer stops responding (hangs) when it processes RESYNC.GLB after doing heavy processing.
  
  NOTE: To resolve this problem, two .EXE files must be updated: the IMPORT.EXE file (update included in IMPORT.EXE version 3.2.9) and the SRVMAIN.EXE file (update included in SRVMAIN.EXE version 3.2.10).
• The Import utility now updates FLAG.GLB when it runs, causing the External Mail program to update its address lists on the next cycle interval.
• The Import utility no longer does 1-byte reads of the template files.
• When it is importing modified SNADS template information, the Import utility no longer incorrectly sequences the information.
• When you use the Import utility to modify a user's configuration (any option set with an "&") and that user has remote access, the user's remote access ability is no longer removed.
• When you use the Modify transaction type to update a user in the POL but you do not make any changes to the user's alias, the user's record is no longer deleted.
• When you use the -A command-line option to modify template information, the Import utility no longer increases the size of the associated .INF file on each pass. The Import utility now creates a new .INF file that incorporates the changes rather than appending the changes to the existing .INF file.
• When you use the Import utility to change a user's mailbox name, Error 34--"Could not access log information file"--no longer occurs when you start the MS-DOS client.
• Deleting a local user with Import no longer leaves the user's folder files (.IDX and .FLD) orphaned in the FOLDERS\LOC\0000???? subdirectory of the Mail database.
• A Microsoft Mail Connection 3.2 PROXYNET\PROXYPO postoffice address list is now propagated to a downstream requestor postoffice when the gateway postoffice is also the directory server postoffice. The Import utility now copies FFAPI postoffice address lists from the directory server to the GLB\RESYNC.GLB file to perform a directory synchronization manual import procedure.
  
  NOTE: To resolve this problem, two .EXE files must be updated: the IMPORT.EXE file (included in this update) and the SRVMAIN.EXE file (update included in SRVMAIN.EXE version 3.2.10).
• Local postoffice users added with the Import utility will no longer be assigned an invalid identification number if the TID.GLB file is locked open. Also, batch creation of local postoffice users with the Import utility while the TID.GLB file is locked open no longer results in the same invalid identification number being assigned to multiple users.
• Trap D errors or "An OS/2 program caused a protection violation" error no longer occurs under OS/2 or under the OS/2 subsystem of Windows NT when you use the Import utility with the -ST command- line option.
• The Import utility now creates unique mailbag numbers when you add local postoffice users, even if the CONTROL.GLB file has been reset to zero.
• When you use Import to add a new local user, the Import utility now adds that user's template information to the REQTRANS.GLB. Previously, even if the template information was included in the IMPORT.TXT file, it was not written to the REQTRANS.GLB.
• When you use Import to create a new template for an external postoffice, the Macintosh client can now read the template information after the first user. Previously, the last field was not visible for any user, and the template information for the second and subsequent users would display incorrectly.
• When you use Import version 3.2.14 or 3.2.16, and you add users via an Import batch file, these users can have their TID values reset. This will create problems sending mail, adding to groups, and deleting users.

PC Ext: Microsoft Mail EXTERNAL.EXE Version 3.2.18 Update

• NetBIOS notification does not work when the sender and receiver are on different postoffices and there are multiple External Mail programs running. The only time notification works is if the first External Mail program that was started up dispatches mail between the sender's and receiver's postoffices.
• On Novell networks, the RNETWORK.GLB file is not updated at 4:00 A.M. on any drives that are dynamically attached.
• In low-memory conditions, the External Mail program deletes mail from the outgoing mail queue without returning that mail to the sender. There are error messages in the SESSION.LOG and SYSTEM.LOG, but the mail file is still deleted. In most cases, the sender is not notified that the mail was not delivered. With the updated External Mail program, the mail message is not deleted but remains in the outgoing queue, and the External Mail program still attempts to deliver the mail. Because there is not enough memory to return the message to the sender, there is no entry in the SYSTEM.LOG. The administrator can return the mail from the queue.
• When the EXTERNAL.INI parameter MinKDiskFull is not included in the EXTERNAL.INI file, the default value of 0 is used. This causes the External Mail program to attempt to deliver mail to a postoffice that has no disk space. The default value for MinKDiskFull has now been changed from 0 to 100K.
• When the External Mail program marks a dynamic drive as being full (no disk space), it is not checked again until the External Mail program is restarted. The External Mail program now checks dynamic drives that are full on every cycle and changes their status if disk space becomes available.
• Messages transferred asynchronously or through an X.25 connection do not get time stamped. Therefore, when you view the received message in Mail for Windows, the received date/time is actually the date/time it was composed, not the date/time it was received by External. The External Mail program now time stamps all messages.
• The External Mail program sometimes hangs when CommType=X25EICON. The CommType setting can be specified in the .INI file or on the command line for External.
• Versions 3.2.5 and 3.2.6 of the External Mail program mark a static drive as being full (no disk space) and the drive is not checked again until the External Mail program is restarted. The External Mail program now checks static drives that are full on every cycle and changes their status if disk space becomes available.
• Mail sent to Remote Mail users would not be recorded in the SENT.LOG file if the LogSent option was specified in the EXTERNAL.INI file or if the -ms command-line option was included when the External Mail program was started. Version 3.2.9 of the External Mail program will correctly log mail sent to Remote Mail users in the SENT.LOG file.
• When the Import utility is run with the autocreate function, and the External Mail program is also run against the same postoffice across a wide-area network (WAN) connection or in a high mail traffic situation, the Import utility may report "Fatal [59] Error autocreating postoffice: XXXXXXXXXX." This error occurs because of .XTN file contention between the External Mail program and the Import utility. Under normal circumstances, the External Mail program holds an .XTN file open for a very short interval and file contention is not an issue. Version 3.2.9 of the External Mail program now allows the Import utility to have write access to the .XTN file.
• The External Mail program now determines and uses the appropriate international date format when the MS-DOS country command is used in the CONFIG.SYS file of the workstation running External.
• The MinKDiskFull and MinKDiskNotFull parameters and their specified values are now recorded in the SESSION.LOG file and are displayed on screen in the External Mail program's LAN Postoffice Mail Activity display area when you use EXTERNAL.INI file entries and the undocumented -q1 command-line switch. Previously, logging of these parameters and their specified values would only occur when you used command-line parameters and the undocumented -q1 command- line switch.
• The External Mail program fails to lock the queue when another instance of the External Mail program requests two-way asynchronous communication, including X.25. If a third instance of the External Mail program tries to service the same queue to deliver a message that was already deleted by the second instance, the following message may appear in the SYSTEM.LOG file:
  [16] Message was not sent due to missing message file.
• The External Mail program may hang or create incorrect entries in the SYSTEM.LOG file if External encounters mailbag contention when it tries to deliver a single message to multiple users on a single postoffice. Under these conditions, the External Mail program may add the following entry to the SYSTEM.LOG file
  [008] Failure delivering mail due to mailbag contention.
  Mail item was not delivered to: <Friendly-Name>
  where <Friendly-Name> may list recipients who actually did receive the message, rather than listing only the recipient whose mailbag could not be accessed. It is also possible that no entries will be added to the SYSTEM.LOG file and External may stop responding. Under Windows NT, the External Mail program may return a general- protection fault (GP fault) and exit, or External may continue processing and add the following entry to the SYSTEM.LOG file on the destination postoffice:
  [012] This corrupt message cannot be delivered. Contact your Administrator.
• Multiple message attachments can now be sent successfully over an X.25 connection.
• Two entries are now placed in the SENT.LOG file for each message that is transmitted asynchronously between postoffices.
• The Echo command for modem scripts now works with EXTERNAL.EXE versions 3.2.x and Mail Remote for Windows.
  
  NOTE: The Echo command is restricted to the Send command and does not affect the Display command.
• The System log now returns the name of the Invalid Address user after an error 002 (Unknown Address) occurs.
• In some instances, External would call Mail Remote for MS-DOS or Mail Remote for Windows, make the connection, send mail, but not receive any queued mail for the user. The External Mail program now transmits any queued mail.
• External was generating an extra P1 file when Mail Remote for Windows attempts to receive mail. These extra P1 files were not being deleted properly, and they were locked open until External was stopped. Although mail was still delivered, the P1 directory could have several stranded P1 files. The External Mail program now deletes the extra P1 files.
• If a message is sent to another postoffice via asynchronous communication with the Useful Life of the message exceeded and no connection is made, two entries are added to the SYSTEM.LOG. One has valid information, and the other is a blank entry containing no message information.
• External may report a "Circular route detected" error in the SYSTEM.LOG. This happens when the PO where mail is processed has a 9 character postoffice name that matches the first 9 characters of a 10 character PO name in the hoptrace.
• External stops delivering mail after it receives a NetBIOS datagram (for a priority 5 mail message) from a user on a PO connected using the DrivesWAN option.

PC DirSync: Microsoft Mail REBUILD.EXE 3.2.16 Update

• This replacement file corrects a problem that occurs on MS-DOS and Macintosh workstations when the GALNETPO.GLB file is regenerated while REBUILD.EXE is running.
• In certain conditions, Rebuild would complete its process without failing or returning errors. However, the global address list (GAL) would not contain all the expected names.
• If a network error occurred during the Rebuild process and Rebuild was unable to create or process a temporary file, an error would not be reported.

PC DirSync: Microsoft Mail SRVMAIN.EXE Version 3.2.14 Update

IMPORTANT: When you update to SRVMAIN.EXE version 3.2.14, you need to update ADMIN.EXE to version 3.2.13 or later (update included in ADMUPD.EXE on the MSL) and LISTDS.EXE version 3.2.1 (included with this update). You MUST also run SCONFIX.EXE (included with this update) once. This is required for all users updating to SRVMAIN.EXE version 3.2.14.

• The Import utility no longer stops responding (hangs) when it processes RESYNC.GLB after doing heavy processing. This problem occurred because the heap became corrupted when it was under a heavy load.
  
  NOTE: To resolve this problem, two .EXE files must be updated: the SRVMAIN.EXE file (included in this update) and the IMPORT.EXE file (update included in IMPUPD.EXE on the MSL).
• The SRVMAIN utility no longer does one-byte reads of the template files.
• A Microsoft Mail Connection 3.2 PROXYNET\PROXYPO postoffice address list is now propagated to a downstream requestor postoffice when the gateway postoffice is also the directory server postoffice. The Import utility now copies FFAPI postoffice address lists from the directory server to the GLB\RESYNC.GLB file to perform a directory synchronization manual import procedure.
  
  NOTE: To resolve this problem, two .EXE files must be updated: the SRVMAIN.EXE file (included with this update) and the IMPORT.EXE file (update included in IMPUPD.EXE on the MSL).
• The directory synchronization (Dir-Sync) server now continues to process updates when SRVMAIN.EXE encounters duplicate entries in the system mailbag. Previously, under these conditions SRVMAIN.EXE would quit without processing any additional updates in the system mailbag, and the following entries would be added to the DIRSYNC.LOG file:
  Error [115] Failure to read mail from NULL
  
  Warning [8] Error deleting file: <Network>/<Postoffice>/$SYSTEM.
• Dir-Sync will no longer give error
  Error 156 Invalid Dirsync password from PCM:Network/Postoffice
  during the T2 cycle. Previously, even if the password for the Requestor postoffice was correct, the password of a requestor postoffice would be incorrectly compared against other requestor postoffices listed in the SRVCONF.GLB. Specifically, this occurred when postoffices were registered in a particular order, and the postoffice names were similar to or part of other requestor postoffice names.
• If the DSSERVER.LOG on a requestor postoffice is corrupt for some reason, the SRVMAIN -r process during Dir-Sync will no longer cause a Trap D.
• When the Admin account mailbox is greater than eight characters in length, the Keep Updates number will no longer change when you change the Administrator's name in Config, DirSync, Server, Options.
  
  IMPORTANT: This fix is specifically for users who have an Administrator's mailbox name greater than eight characters, and who want to receive Dir-Sync status messages.
  
  To add the new Administrator's name, you need ADMIN.EXE version 3.2.13 or later. Run Admin, DirSync, Server, Options. Type in the desired mailbox name. If necessary, re-enter the Keep Updates field. This modified SRVMAIN requires a new LISTDS.EXE version 3.2.1 or later for checking the SRVCONF.GLB file.
• If X.400 addresses are included in the very first Dir-Sync cycle, Dir-Sync will no longer fail with a protection violation during the T2 cycle of the SRVMAIN process.

CLIENT BUGS FIXED IN MAIL 3.5

Simple MAPI Version 3.2.0.4081 Update

• The sample Visual Basic Simple MAPI application has been modified to compile when you use Microsoft Visual Basic version 2.0.
• Deleting a message in a shared folder does not function as expected; the message in the folder is deleted, but the header still appears. If you select the header to bring up the message, Mail for Windows returns a dialog box that says "The message cannot be accessed." Also, if you change a message in any way, the message becomes inaccessible.
• Reply, Reply All, and Forward commands on customer messages in shared folders fail if these commands are called from Mail for Windows. This problem occurs because the client hands off the temporary message ID of the shared folder, instead of the permanent shared-folder message ID.
  
  NOTE: For this problem to be resolved, two files must be updated: the MAPI.DLL file (included in this update) and the MSMAIL.EXE file (update included in Application Note WA0889).
• To correctly launch e-forms, Microsoft Electronic Forms Designer requires that the message type it gives to Simple MAPI be preserved in the delivered message. However, the message type is not encoded in WINMAIL.DAT by default, so it is lost across gateways. Therefore, the message is received and displayed as a note rather than as a Microsoft electronic form.
• Custom forms that did not include their own textize maps could not use the provided default print/save functionality.
  
  NOTE: To fix this problem, MSSFS.DLL (update included in MSSFS.EXE on the MSL) version 3.2.4081 or later must be used in conjunction with the MAPI.DLL included in this update.
• When you execute the MAPIAddress() function, an "Out of Memory" error can occur. Thi s problem occurs because a second MAPI session is being started and closed, and the MAPIAddress() function is then executed in the first session.

PC Win: Mail for Windows MSSFS.DLL 3.2.0.4084 Update

• When you send mail to an external postoffice group or gateway group that contains extended characters in the address, Mail for Windows does not convert from code page 850 to the ANSI code page when it reads the records from the NETPO.GLB file or any other gateway address file.
• External postoffices, SNADS DGNs, and nodes for PROFS and OfficeVision are not displayed in alphabetic order because Mail for Windows reads them in one at a time and adds them to the hierarchy. With the updated version of MSSFS.DLL, Mail for Windows reads them in all at once, sorts them, and adds them to the hierarchy.
• An "Unknown user" error may occur when you send a message. Mail for Windows caches only the first 8170 bytes of the NETWORK.GLB file and loses the rest. Postoffices and gateways that are defined past 8170 bytes are ignored; therefore, you cannot send messages to the users on those postoffices or gateways.
• The simple MAPI command MAPILogon() does a case-sensitive match on the user name and password; however, Microsoft Mail is not case sensitive. This problem occurs only if a MAPI session was already established when MAPILogon() is called.
• Incorrect message dates are displayed. When parsing old A.M./P.M. style dates (generated from some gateways), Mail for Windows adds 12 to the time if it is P.M. However, if the message was sent during the noon hour, the time is incorrectly read as 24:xx. Because this is an invalid time, the date is set to the programmer's birthday (12/16/68).
• Mail for Windows may cause a general protection (GP) fault when it encounters a corrupt .XTN file in the database. It does not properly handle .XTN files that are an incorrect size.
• Mail for Windows cannot view templates of SNADS or PROFS users when GALONLY=1 is set in the MSMAIL.INI file.
• When you read a custom message from a shared folder, the wrong date is displayed.
• In version 3.0b of Mail for Windows, the time stamp associated with resolved addresses is not saved correctly: if the Global Address List (GAL) was built twice in the same day, any mail addressed but not sent before the second rebuild could be misdirected. This problem was partially corrected in version 3.2 of Mail for Windows: the time stamp is saved correctly, thus reducing the time frame in which this problem could occur from one day to one clock hour. However, mail may still be misdirected at sites where GAL rebuilds are made within the same clock hour.
• All users running Windows from a shared installation point must use the same postoffice when they use Advanced Security. This problem occurs because the MAIL.DAT file is saved to the Windows SYSTEM subdirectory, which is shared among all users running Windows from the same location. The client now checks both the WINDOWS (user's local directory) and WINDOWS\SYSTEM directories, in that order, for the MAIL.DAT file.
  
  NOTE: To resolve this problem when you are installing Mail for Windows, two files must be updated: the MSSFS.DLL file (included with this update) and the SETUP.EXE file (update included in SETUPD.EXE on the MSL).
• Duplicate addresses are added to the Personal Address Book (PAB).
  
  NOTE: To resolve this problem, two .DLL files must be updated: the MSSFS.DLL file (included with this update) and the PABNSP.DLL file (update included in Application Note WA0887).
• If users are running Mail for Windows from a shared installation point and the NETBIOS=1 flag is set in the MSMAIL.INI file, Mail checks the size, date, and time of the MSMAIL.INI file every 5 seconds. Because the .INI file is on the network, frames are sent to the server to check the size of the file every 5 seconds, thus increasing traffic on the network. These checks no longer occur with this update.
• When an urgent message is sent to an external user with NetBIOS notification in use, Mail for Windows does not send a NetBIOS datagram to the External Mail program. This process does work correctly when an urgent message is sent to a local user. When sending urgent messages, Mail for Windows now sends notifications to the External Mail program when NetBIOS notification is in use.
• MACBinary II attachments are not recognized when originating from external Mail Systems.
• When sending mail such that the number of recipients is greater than 200 (exact number depends on the specific address list), the body of the message will be missing.
• When Add Recipients to Personal Address Book is selected, the GAL.NME file is locked open each time a global address list (GAL) name is added to a compose note.
• In certain situations, viewing details of an external name from a group results in the error message:
  A GLB file on your server is corrupt.
• If a message has more than 22 recipients selected from the GAL and that message is stored in a shared folder, the message appears to be corrupted. Attempting to open the message from the shared folder results in the error:
  Mail system error, Mail could not read the entire message from the Post Office. Some parts of the message may be missing. Ask the sender to resend the message.
• Under certain conditions, a general protection (GP) fault can occur in MSSFS.DLL when the MAPILogon() function is used to begin a session with the messaging system.
• The Check Names function fails to properly resolve partial friendly names and returns several selections when a unique resolution is possible. This behavior is most obvious when the GAL is selected as the default address list and the first and last name of the intended recipient begin with the same letter.
  
  NOTE: To resolve this problem, two .DLL files must be updated: the MSSFS.DLL file (this update) and the MAILMGR.DLL file (update included in Application Note WA1058).
• The Windows client stops responding when it receives a message with an invalid time; that is, a time greater than 23 hours.
• Templates that were created with extended characters will lose their extended characters when they are exported to other postoffices.
• The Windows client cannot display a template field of zero length. These are display fields only and cannot be modified.
• Custom forms that did not include their own textize maps could not use the provided default print/save functionality.
  
  NOTE: To fix this problem, MAPI.DLL version 3.2.4081 (available as MAPIUPD.EXE on the MSL) MUST be used with this MSSFS.DLL.
• When you have more than one friendly name for the same PROFS userid, and you attempt to get details from the GAL in the Windows client, incorrect information is displayed.
• When you add multiple users from the GAL with the same friendly name to the PAB or to Personal Groups, only the first entry gets added. No errors are reported.

PC Mac: Macintosh Client Version 3.0.6 Update

• With the earlier version of this file, the computer could stop responding when sending a message to a personal group under low memory conditions. The Macintosh client file has been modified to correct this problem.
• Some network operating systems will not allow a file to be created in all uppercase letters. The Macintosh client file has been modified for these types of networks to allow the client to create filenames in lowercase letters if LOWRCASE.GLB exists in the GLB subdirectory of the Mail database.
• With the earlier version of this file, when mail is sent to global groups that contain nonalphabetic characters in their names, the recipient field appears blank when the message is viewed by a Mail for Windows user. The Macintosh client file has been modified to correct this problem.
• Extended template information that exceeds 64K is now correctly displayed when you choose the Info button in the Addressing dialog box of the Macintosh client.
• The Macintosh client has been modified to enable you to address mail to an X.400 recipient when the address exceeds 52 characters. Attempting to do this with previous versions of the Macintosh client could produce the following error message:
  The application "unknown" has unexpectedly quit, because an error of type 1 occurred. OK?
• If you attempt to forward a message in the Macintosh client, and you choose not to forward an attachment to that message, the following error message is generated:
  Low on Memory. Unable to complete the operation. Please close some windows.
  The Macintosh client has been modified to forward the message without generating the error.
• On a Power Macintosh, if the check box Open "To" Address Selector (from the Compose menu, select Get Info) is selected, and you attempt to forward or reply to a message, the following error message is generated and can hang the machine:
  The system has closed the following application "Unknown" because of an error type 1".
  The Macintosh client has been modified to forward or reply to a message without generating the error or hanging the machine.

PC Win: Mail for Windows MSMAIL.EXE 3.20.4085 Update

• When an open custom message is deleted from a shared folder, the message header still appears in the folder. Trying to open the message again results in the error
  The message cannot be accessed.
• You cannot do a Reply, Reply All, or Forward on a custom message that is located in a shared folder.
  
  NOTE: For this problem to be resolved, two files must be updated: the MSMAIL.EXE file (included in this update) and the MAPI.DLL file (update included in MAPIUPD.EXE on the MSL).
• An error is now generated when the ACCESS.GLB file is locked open and a user attempts to change his or her password.

PC Adm: Microsoft Mail MMFCLEAN.EXE Utility

Currently, there is no way for an administrator to monitor or manage space consumed by a Windows or OS/2 Mail user on a version 3.0 or later Microsoft Mail postoffice (PO). In versions of Microsoft Mail earlier than version 3.0, the administrator could purge mail messages for all users on the PO. When the mail message file (MMF) architecture of versions 3.0 and later of Microsoft Mail for Windows was introduced, the administrator lost the ability to purge mail messages stored in the MMFs.

The MMFCLEAN utility included in this Application Note is a Windows(TM) based application to be used on Microsoft Mail 3.0 and later postoffices to purge mail from MMFs. MMFs usually exist on the PO and contain the users' private mail messages and folders. There is one MMF per Windows user on the PO. By default, the Windows user will have his or her MMF file stored on the PO, but the user can choose to store the MMF file on his or her local machine. The MMFCLEAN utility matches the capability of the Mail Administrator program. The administrator should run it from a Windows 3.0 or 3.1, or Windows for Workgroups 3.1 or 3.11 local area network (LAN) client connected to the PO over the network.

You can use the MMFCLEAN utility to clean the MMF according to the following criteria:

• Message Age days
• All messages with size greater than XXX
• Message priority

Things to Note Before Running MMFCLEAN

WARNING: Before you use the MMFCLEAN utility to clean the database, make an additional backup copy of your Microsoft Mail postoffice. If an error occurs during a fix, you can restore the backup made immediately before you used the MMFCLEAN utility. In all other circumstances, you should restore the database from your most recent regularly scheduled backup.

• Available disk space should be three times the size of the largest MMF.
• Do not use an active PO; all users should be logged off and the PO should be backed up.
• File Scan is required for Novell networks.
• MMFs not stored on the PO will not be included; any MMFs stored on a user's local drive or on another server will not be cleaned.
• No other Mail application should be running on the workstation when you start the MMFCLEAN utility.
• The Just Compress check box in the Criteria dialog box overrides all other criteria. Remember that when a cleaning is done, a compress is also automatically done.
  
  Important: When MMFCLEAN does comparisons on the aging date, the creation date of the message is used instead of the date the user received the message. This means that if a user was on vacation for a week and then came in and downloaded his new messages to his MMF, the user's message could get deleted right after it is read if the criteria for MMFCLEAN is Read Mail Greater Than 7 Days. We are currently investigating how to change this limitation.

PC Win: Mail SCHEDMSG.DLL Version 3.2.4086 Update

• When an assistant responds to a meeting request on behalf of a Schedule+ for Windows user, who has no .CAL file, the requestor receives the following message:
  Sent on behalf of %S.
  The meeting requestor is unable to determine who the mail was sent on behalf of.