MailWorks_for_UNIX____________________________ Release Notes August 1996 This document provides supplemental information about MailWorks for UNIX[R] (formerly DEC OSF/1[R]) Version 2.0. It contains information about known problems and restrictions with MailWorks. This document also provides updated information not contained in the main product documentation. Revision/Update Information: This is a revised manual. Operating System: Digital UNIX Version 3.2C or later Software Version: MailWorks for UNIX Version 2.0 __________________________________________________________ August 1996 Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Digital or an authorized sublicensor. The postpaid Reader's Comments forms at the end of this document request your critical evaluation to assist in preparing future documentation. © Digital Equipment Corporation 1995. All rights reserved. The following are trademarks of Digital Equipment Corporation: Alpha AXP, AXP, DEC, DECnet, Digital, InfoBroker, MAILbus, MAILbus 400, DEC MAILworks, OpenVMS, TeamLinks, TeamRoute, the AXP logo, and the DIGITAL Logo. The following copyrights and notices apply to the xloadimage program, which is supplied as an image viewer with the MailWorks software: Copyright © 1989, 1990 Jim Frost, Kirk L. Johnson, Mark Majhor, Massachusetts Institute of Technology Permission to use, copy, modify, distribute, and sell the xloadimage software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. The authors make no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. The following are third-party trademarks: Motif, OSF, OSF/1, and OSF/Motif are registered trademarks of the Open Software Foundation. Microsoft and MS-DOS are registered trademarks of the Microsoft Corporation. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd. The X Window System is a trademark of the Massachusetts Institute of Technology. PostScript is a registered trademark of Adobe Systems, Inc. Macintosh is a registered trademark of Apple Computer, Inc. SPARCstation and SunOS are trademarks of, and Solaris and Sun are registered trademarks of Sun Microsystems, Inc. This document was prepared using VAX DOCUMENT Version 2.1. ________________________________________________________________ Contents 1 New or Changed Features 1.1 Prerequisite Software........................ 1-1 1.2 New or Changed Features in Version 2.0....... 1-2 1.3 New or Changed Features in Version 1.7-A, ECO#1 and ECO#2.............................. 1-8 1.4 Usage Notes.................................. 1-9 2 Problems Fixed 2.1 Problems Fixed in Version 2.0................ 2-1 2.2 Problems Fixed in Version 1.7-A, ECO#1 and ECO#2........................................ 2-3 3 Known Problems or Restrictions 3.1 Restrictions with DCE........................ 3-3 3.2 DMW-add Script Problem with Remote X.500 Database..................................... 3-4 4 Digital UNIX Patches 4.1 Digital UNIX Version 3.2-C Patches........... 4-1 4.2 Digital UNIX Version 3.2-D Patches........... 4-2 iii 5 InfoBroker Patches 6 Troubleshooting 6.1 Inefficient Directory Lookup................. 6-1 6.2 Working with Exchange........................ 6-4 iv 1 ________________________________________________________________ New or Changed Features This chapter provides information on new and changed features for MailWorks for UNIX Version 2.0 and Version 1.7-A, ECO#1 and ECO#2. 1.1 Prerequisite Software MailWorks for UNIX Version 2.0 requires: o Digital UNIX Version 3.2C or later. At the time MailWorks for UNIX Version 2.0 was released, some of the components that MailWorks depends on did not work on Digital UNIX Version 4.0, so we have not been able to do extensive testing in that environment. While Digital believes that MailWorks for UNIX V2.0 and InfoBroker Version 2.1A-2 will work with UNIX Version 4.0, Digital cannot guarantee that they will work without problems. If it is possible to run UNIX Version 3.2, revision C or greater, Digital recommends that you do so for now. o If you will be using X.400 on a remote machine, you must install at least the MAILbus 400 MTA Base on the machine running MailWorks. You will need Version 1.4A or greater of MAILbus400; Digital recommends Version 2.0. o MailWorks requires that you install InfoBroker Version 2.0 or later. Digital recommends that you install InfoBroker Version 2.1A-2; this is the version that is included on the MailWorks individual product CD. InfoBroker in turn requires X.500 Version 2.0 or 3.0, subset DXDABASE200 or DXDABASE300. New or Changed Features 1-1 o Because some MailWorks processes can grow large, be sure that you have configured sufficient swap space. In a large installation (with hundreds of concurrent users) the mss process can approach a gigabyte in virtual size (it doesn't need this much real memory), and if you use TeamLinks, cc:Mail or Microsoft Mail, the mcs process can approach a half of a gigabyte of virtual space. For a complete list of prerequisite software, see the MailWorks for UNIX Installation Guide. 1.2 New or Changed Features in Version 2.0 Several of the following features, such as MIME and local delivery, will not be enabled until you add the corresponding parameters to the MAILworksrc file. The following features are new or changed for Version 2.0: o MIME support: the MailWorks server will decode received messages that have been encoded in MIME, and will store those messages in decoded form. This allows non-MIME aware clients to read the messages and attachments. When sending mail, if the MAILworksrc parameter sendMime is set to TRUE, the MailWorks server will encode SMTP messages in MIME. If a message is sent to a mixed distribution list (local users, SMTP recipients and X.400 recipients), only the copies sent to the SMTP recipients will be MIME encoded. Since MailWorks does not remember the original filename of each attachment when sending messages, the original filename is not transmitted in the MIME encoding. However, a fixed artificial filename can be inserted into the MIME encoding, by placing a "name=" clause into the appropriate entry in the .dmw_mime_send_map file. For example, Microsoft Word documents have the parameter name="dmw.doc" placed into the MIME encoding. This feature supports MIME and POP3 clients that use filename extensions to recognize the attachment type. 1-2 New or Changed Features When MailWorks receives a MIME message that has been identified as a partial message (using the type/subtype message/partial), it will save the components of the message in a server working area (in the directory /var/opt/DMW/sf/partial). When all of the components arrive, MailWorks will reassemble the full message and place it in the recipient's inbox. If all of the components of the message do not arrive within three days, MailWorks will assemble the components that have arrived, and place them in the recipient's inbox. You can change the default timeout period of three days by setting the parameter partialAge in MAILworksrc; this parameter specifies the number of days to wait before timing out. The parameter partialAge has not been described in the MailWorks for UNIX Workgroup/System Administration manual. When a bodypart encoded in any of the multipart formats is received, the parts of the multipart message will be saved as the bodyparts of an otherwise empty forwarded message. When a Macintosh client sends mail with an attachment, America Online generates bodyparts in the format multipart/appledouble. This means that the data fork and resource fork of the attachment will be stored separately in the enclosed forwarded message. This makes it easier for non-Macintosh users to use documents from Microsoft Word or Powerpoint, for instance. o POP3 support: a new MailWorks POP3 server is included that allows POP3-based clients (such as Eudora or Netscape V2) to retrieve received mail. The POP3 service allows readers to retrieve mail that was received from other local users, remote SMTP users, or remote X.400 users. The system's standard SMTP service is used by the POP3 clients for submission of outgoing mail. New or Changed Features 1-3 o Local delivery: if a message is addressed to a local recipient using either an X.400 address or an SMTP address, the message is now delivered directly by the MailWorks server. It is no longer passed to sendmail or MAILbus 400 for delivery. (Note: messages addressed to local users using a local account name have always been delivered directly.) This will improve performance of your system; the improvement can be particularly significant if your users use X.400 addressing frequently. This feature is optional (controlled by the localSMTPAddresses and localX400Addresses parameters in MAILworksrc). Omit the parameters if you want all messages sent through the MTA. o A bottleneck in the retrieval of messages from MAILbus 400 has been removed. In previous versions, MailWorks could retrieve no more than one message per second from the MTA. Starting with Version 2.0, the number of messages retrieved is limited only by the communications with the MTA and by the processor speed. The local delivery may also mean that fewer messages actually pass through the MTA. o MailWorks now utilizes a shareable image version of the XAPI library used to communicate with MAILbus 400. Among other improvements, this means that MailWorks can now connect to the MTA using the default connection type of LOCAL. This is specified in the file /var/mta/mta_api_server_address. Unlike previous versions of MailWorks, you no longer need to change the default value of the entry in this file if the MTA will be on the same system as MailWorks. o For TeamLinks, cc:Mail and Microsoft Mail users, the performance of opening a folder has been improved. The improvement will be present for any folder, but will be particularly significant for very large folders and folders containing messages with very large attachments. o It is now possible to temporarily disable a user's message stores to allow backups, or to allow the message store to be moved. While a message store is disabled, the user cannot connect to it, and incoming mail cannot be delivered. Because message stores are 1-4 New or Changed Features disabled on a user-by-user basis, it is possible to disable a set of users to do backup of one disk, without disabling the entire mail system. (See the manpages for confddb for more details.) o A new style of server licensing called client access licensing has been implemented. Previously, MailWorks supported either capacity licensing (in which you purchase a license based on the size of the system, and as many users could connect as the system could support), concurrent use licensing (in which you purchase a license for the maximum number of users who would connect at any one time), or personal use licensing (in which a specific user's name is associated with each license unit). For client access licensing, you purchase a license for the number of user accounts you will create on the system, and any number of those users can connect at one time. For Version 2.0, Digital has removed all LMF checks, and has supplied a utility (DMW-count- subscribers) that can be run at any time to report on the number of user accounts that have been defined. Digital request that you run this utility periodically, compare the number of registered accounts with the number of licenses you have purchased; if you have more users than licensed, please purchase additional client access licenses. o MailWorks will now work on systems that implement C2 security. It will not enforce discretionary access controls, but will operate properly in the C2 security environment. Version 2.0 fixes several problems that appeared in prerelease versions of this functionality, including problems resetting a password, and problems that occurred if a user attempted to connect as a nonexistent user. The MAILworksrc parameter enableC2 must be set to TRUE to support C2. o In support of MAPI-based clients, the MAPI message class is now being stored as part of the message in the message store, and will be carried with the message when it is delivered locally or sent over SMTP. New or Changed Features 1-5 o For MAPI clients, the ability to store address types for mail systems other than MailWorks has been improved. This allows a draft or sent message with addresses of many different types to be stored in a MailWorks message store. o The command confpref now supports an option (- redirection) to show or to set a redirection address for received mail. This allows users to use the command line to specify that received mail should be automatically redirected to a different mailbox. o A directory (named "unsupported") has been added to the product to contain sample shell scripts and programs that you may find useful; these programs are provided "as-is" and are not supported (as the name implies). Some examples are a script that will generate a global alias for all subscribers on the system, and another script that will run in the background, and will generate a log of the number of users logged into the system at 20 minute intervals. o The DMW-delete script now offers an option to retain the users's UNIX account, and an option to retain the user's X.500 directory entry. o The install process now checks kernel tuning parame- ters, to ensure that the system tuning will support the expected number of concurrent users. o An SMTP sender's "From" address will now optionally be replaced by their RFC-822 mailbox value (internet address) from their X.500 directory entry on outgoing SMTP messages. Optionally, local recipient addresses will be replaced by their X.500 RFC-822 mailbox values on outgoing SMTP addresses. In both cases, the feature is controlled by parameters in MAILworksrc: lookupSMTPOriginator with a default value of FALSE, and lookupSMTPRecipients with a default value of FALSE. The directory is now used to map addresses for SMTP messages in the same way it is used to map addresses for X.400 messages. 1-6 New or Changed Features If you use this feature, you should be sure that the RFC-822 attributes in X.500 are accurate; otherwise, some very confusing return addresses can result. You should also be careful if you have configured InfoBroker to use both X.500 and the local data file. This can result in lookups returning two entries for each person. If multiple entries are found, an error will be logged, and the address will be constructed from the user's account name and the system name. o The MailWorks for UNIX Workgroup/System Administration manual has been reorganized, and made both clearer and more complete. o The name "MAILworks"has been changed to "MailWorks" throughout the product. You must modify any scripts that specifically look for the "MAILworks" name. o There is a new MailWorks parameter: searchMWUserName. If set to TRUE, a surname value entered during a TeamLinks directory search will also be matched against the MAILworks User Name field. The default value is TRUE. o The installation now asks if you will be using X.400. If you will not be using X.400, the X.400-related processes (x488gsend and x488grecv) will not be run. This avoids unnecessary error messages in the log files, and avoids an error that would otherwise be reported in the installation IVP. o RFC-822 dda values that are longer than the 128- character X.400 limit are now truncated to 128 characters. RFC-822 dda values are used to encode SMTP addresses that are being sent via X.400 and cannot be mapped to an X.400 address using the X.500 directory. This truncation can be turned off by setting the new MAILworksrc parameter truncateDDAValue to FALSE. The default value is TRUE. o MailWorks for UNIX Version 2.0 contains all new and changed features implemented in MailWorks for UNIX Version 1.7-A, ECO#1 and ECO#2. New or Changed Features 1-7 1.3 New or Changed Features in Version 1.7-A, ECO#1 and ECO#2 o The server now supports the ability to set or reset the user's password using the MAPI drivers. (This capability will be available starting with Version 1.2 of the MAPI drivers.) See the documentation for the MAPI drivers for further information, restrictions, and usage features. o The performance of X.400 mail has been improved: the x488gsend process (which submits X.400 messages to the MTA) has been made multithreaded, which will improve the throughput of outbound X.400 messages. It is now possible to manually start more than one copy of the x488grecv process, to improve the throughput of inbound messages. For now, this can only be done manually, and any such processes will not be stopped by the stopMAILworks command; we hope to make this more automatic in a future release. o The default value for the resource trashTempFolders (located in the file MAILworksrc) has been changed to TRUE. Temporary folders created to support queries from the Motif client will now by default be deleted when the connection to the message store is closed. o The default value for the resource replaceNUL has been changed to ""; this means that for inbound X.400 messages any embedded NULL characters in any text bodyparts will be dropped. Previously, when a NULL character was encountered, the text bodypart was truncated at that point. o flushBodyParts is a new parameter that has been defined for the MAILworksrc file. When set to TRUE, this resource causes the message store server to flush bodyparts from memory as soon as it can, to avoid the buildup of large numbers of temp files when clients list the contents of folders. With ECO#2, using this parameter caused performance problems, starting with Version 2.0 that performance problem has been removed. The default for flushBody- Parts is now TRUE. 1-8 New or Changed Features o An additional option has been added to the confpref command, to make it easier to set the default preference values for all users to a common value. 1.4 Usage Notes If your MailWorks users send mixed transport mail (mail messages to a recipient list containing both X.400 and SMTP addresses), you must add the X400ServerAddress resource to the MAILworksrc file. This resource defines an X.400 address for the MAILworks server. This is necessary for the reply-all functionality to work properly when sending a "reply-all" to both X.400 and SMTP (RFC-822) recipients. SMTP addresses in messages sent via X.400 may be encapsulated in an X.400 address. The X.400 address used is the value of X400ServerAddress, plus a domain- defined attribute whose type is RFC-822 and whose value is the SMTP address (converted to printable-string form if necessary). The X400ServerAddress address should match the MTS O/R address for the MailWorks server as defined in the MTA. For example: X400ServerAddress="/c=us/admd=admin/prmd=mynode" For inbound messages, MailWorks uses the following rules to determine whether or not to convert the encapsulated address to an SMTP address: o If the X400ServerAddress entry is defined in the MAILworksrc file and the entry matches the "server" part of the recipient address, MailWorks converts the encapsulated address to an SMTP address. o If the X400ServerAddress entry is null (X400ServerAddress=""), MailWorks converts all RFC-822 addresses to SMTP addresses, not just those that have been encapsulated by MailWorks. New or Changed Features 1-9 2 ________________________________________________________________ Problems Fixed This section provides information about problems fixed in MailWorks for UNIX Version 2.0 and Version 1.7-A, ECO#1 and ECO#2. 2.1 Problems Fixed in Version 2.0 o Memory leaks in several processes have been eliminated. o A problem in which parentheses in some X.400 address fields (such as organization) were improperly being mapped to a sequence of printable string character fallbacks has been fixed. o A problem in which X.400 addresses with personal names containing only a surname and initials were mistaken for personal names containing only a surname and a given name has been fixed. This caused replies to such addresses to fail, and prevented Motif client users from being able to enter addresses containing only surname and initials as the personal name. o A couple of problems in the communication with the MAILbus 400 MTA, in which temporary files in the MTA were not being released, and in which OSI connections to the MTA were not being properly released if an error occurred during the disconnect have been fixed. o Several problems with personal names containing commas have been fixed, so that replies to users with such a personal name will be delivered to that user, rather than some other user or not at all. o Requests for delivery notifications were being lost when a draft message was saved. They are now preserved. Problems Fixed 2-1 o When a message with a large BCC list was submitted from a MAPI client, the deferd process handling the submission would generate a seg fault. It no longer does. o Error handling of communications errors has been improved, in some cases so that the server will retry when a communications error occurs, and in other cases will properly report the error. o Comparisons of the RFC-822 domain defined attribute are now case-blind (so that uppercase and lowercase versions of the string will match). This will improve the ability of MailWorks to recognize a local recipient on the envelope of an incoming X.400 message. o The DMW-delete script now utilizes the disable message store function to prevent possible problems in deleting a user whose message store is still active (for example, if the user is still logged in, or mail is being delivered to that user's account). o mschk has been made even more robust, to properly recover from additional corruptions in a message store. o When an X.400 message has been received with only a Domain Defined Attribute, but no common name, the MailWorks server now constructs an abbreviated sender string for use by TeamLinks clients. o Previously, when an SMTP message containing lines over 1000 characters (as happens with many Postscript files) was passed to sendmail, it would get stuck in the sendmail queue. MailWorks now detects such problems, and will insert line feeds into the message to prevent the problem. The line feeds have been inserted so that they will not disturb the meaning of the Postscript; they should have minimal impact of soft-wrapped paragraph text. (And in any event, the inserted characters are less problematic than stuck messages.) o Fixed the Printable String mapping which will reduce (and hopefully eliminate) Error 26's (invalid syntax) returned by the MTA when MailWorks attempts to send X.400 messages. 2-2 Problems Fixed o Previously, when a message received from X.400 was forwarded using SMTP, the embedded X.400 addresses were corrupted. This has been corrected. o Fixed a problem where forwarded SMTP messages would get stuck in the lsfd queue, failing with an X.400 API error 20. 2.2 Problems Fixed in Version 1.7-A, ECO#1 and ECO#2 The following functional changes have been made since the Version 1.7 release: o The inc command line command would occasionally hang when the -nointeractive option was used and a large collections of messages was imported. o If a user included a comma in his personal name when sending messages through X.400, the MailWorks server would treat the name as a distribution list. This caused problems, such as sending a reply to the wrong recipient. o When a message being transferred to the X.400 MTA fails, resulting in an error in the log file, a stack trace will be placed in the log file to assist the development team in narrowing down the cause of the problem. In this case the stack trace does not indicate a fatal error; it is merely diagnostic information. o On a noisy or congested network, sometimes the server would not retrieve an entire packet of information in one read operation. It now retries until the entire packet is read. o After encountering certain kinds of corruption in a message store while opening a message store through the mcs server, the message store would not be properly closed, leading to additional corruption. o Mschk has been made more robust, so that it no longer needs to be run twice to completely recover a corrupt message store. Problems Fixed 2-3 o If an X.400 message could not be transferred to the MTA, and the clock of the PC that submitted the message was set later than the clock of the server, then the server would mistakenly decide that it had retried sending the message, and generate a nondelivery report. Now, the server will retry submitting the message. If the PC clock is ahead or behind the server clock, the retry period will be correspondingly shorter or longer than normal. You should attempt to keep the PC clocks close to the server time; you may want to keep this in mind when selecting the retry period. The comparison of times is done using local time as reported by the PC. If the PC and the server are in different time zones, the DeliveryTimeOut parameter should be increased accordingly. o Requests for delivery and receipt notification were not being properly saved in draft messages when some forms of X.400 addressing were used. o The lsfd daemon is now being installed with the appropriate privileges to be able to process all messages in its queue. In previous releases, under some circumstances the lsfd daemon would be unable to process some messages, which would then become "stuck" in the queue. o The mcs server now responds properly to lost network connections. This fixes one problem that could cause the mcs server to "spin". o A memory corruption in the mcs server (typically resulting in a seg fault) has been fixed. This corruption was triggered by a TeamLinks for Macintosh user sending a message that was previously saved in the outbox. o X.121 addresses are now being handled properly for PC clients. o ReplyRecipients (otherwise known as Reply-to-users) are now being handled correctly in inbound X.400 messages. 2-4 Problems Fixed o If the server receives an X.400 delivery or nondelivery report that was not requested by the originator of the message, the delivery report is now discarded, rather than being delivered to the originator. o A memory leak that occured on the receipt of messages has been fixed. o A problem that would cause the message store server to record seg fault information in the log files when the server is shut down has been fixed. (The seg fault occurred after the server was completed with its message stores, so no damage was done, in spite of the ominous appearance of the log file.) o Empty temporary folders created by PC clients during a search operation are now deleted. o The inc command is now optionally less verbose when doing an import of message files: it will no longer prompt for the creation of a new folder. This will be useful if and when the command is used to import a large number of messages into the MailWorks message store. o mschk has been made more robust, so that it will no longer fail when it encounters some specific unusual problems with a message store. In rare cases, mschk will finish before it has corrected all of the problems with a message store. If mschk does not complete with the messages "Compacting message store...." and "Completed.", then you should run mschk a second time to correct the remaining problems. o When a message with an expiry date is read before the expiration date, MailWorks used to send a message to the originator that the message was deleted without being read. It no longer does. Problems Fixed 2-5 3 ________________________________________________________________ Known Problems or Restrictions The MailWorks Version 2.0 release contains the following known problems or restrictions: o There are compatibility issues between MailWorks and the Distributed Computing Environment (DCE). See Section 3.1 for details. o If your configuration has MailWorks and the InfoBroker Server installed on one system and X.500 installed on a remote system, the DMW-add script will generate an error indicating that DXIM cannot be found when creating an account. See Section 3.2 for details. o If you use TeamLinks for Windows or TeamLinks for Macintosh to specify Outbox folders, the settings are not saved beyond the current session. o The preference to set your Inbox folder does not work. o If you use TeamLinks for Macintosh to change the "sort message by date" option for a selected folder in the Mail file cabinet, the change affects all folders in the file cabinet, not just the selected folder. o A full /usr file system will cause an mcs segmentation fault and thread spin. o In some POP3 clients, such as Netscape Version 2.0, the option to leave messages on the server does not work with the MailWorks POP3 server. o When the DMW-add script is used to create a new user account, an error of the following form is placed in the msslog: the file /usr/users/foo/foo.po could not be opened Known Problems or Restrictions 3-1 This message can be safely ignored when it occurs during the creation of a new account. o If a message store is disabled after that message store has been accessed by the command line interface (or a script using the command line interface), then the command line cannot be used to access that message store until the command line server is stopped and restarted. For example, if Bob uses the command line interface to read messages on Monday, and his message store is disabled for backups on Monday night, then Bob will not be able to use the command line on Tuesday until the command line server is restarted. If a message store is not accessed through the command line server until after it is disabled, the problem does not arise. Also, the problem affects only the command-line interface; other clients are not affected. To stop the command-line server while logged in as root, use the command ps auxw | grep CLS to find the process number of the server, then use the command kill to stop the server. To restart the server from root, enter the command /usr/opt/DMW/clbin /MAILworksCLS. o The following functionality in the Version 2.7 TeamLinks for Windows client should not be used with the MailWorks Version 2.0 for UNIX server. If you use these client functions when creating a message, it can result in improper tagging of bodyparts, or in some cases, corruption of the message. - Client-based UUEncoding or MIME encoding of messages. If the message being sent has only the cover memo or a single bodypart, the message will be properly encoded, but the type tag may be incorrect. With more complicated messages, attachments may actually be dropped. Because the MailWorks for UNIX server supports both UUEncoding and MIME encoding, it is not necessary to do this encoding in the client. If you allow the server to do the encoding, it will be done only for recipients with SMTP addresses (in a mixed 3-2 Known Problems or Restrictions distribution list, copies of the message delivered locally or over X.400 will not be encoded.) - Plain-text version of rich text cover memos. Because not all recipients can read rich text cover memos, TeamLinks for Windows has provided an option to include a plain text version of a rich text cover memo. When TeamLinks for Windows is used with MailWorks for UNIX, Digital recommends that you do not use this feature since it can cause problems with the message. If you have recipients that cannot read rich text, simply limit yourself to simple text. When a draft message is saved in a MailWorks for UNIX server drawer, and the type of the cover memo is modified from plain text to RTF before the message is sent, the cover memo will be improperly tagged. The consequence is that the recipient will see the RTF itself, rather than the text with the appropriate renditions. The original rich text cover memo can be retrieved by saving it to a file with the extension .rtf, and using Microsoft Word or some other editor to read the file. (Note: if you change the type of the cover memo before saving or sending the message, the message will be properly tagged. Similarly, if you save the draft message in a local drawer, the type of the cover memo can be changed before sending.) 3.1 Restrictions with DCE There is a known problem in which DCE Version 1.3 replaces an important X.500 image used by the InfoBroker Server. After you have completed the DCE installation, InfoBroker refuses to start. The file affected is /usr/lib/shlib /libdxdutil.so. Because MailWorks requires the InfoBroker Server for delivering X.400 mail, MailWorks does not support DCE Version 1.3. Should this DCE restriction apply to your installation, please contact your Digital representative for information about the latest DCE update or patch. Known Problems or Restrictions 3-3 3.2 DMW-add Script Problem with Remote X.500 Database If your configuration has MailWorks and the InfoBroker Server installed on one system and X.500 installed on a remote system, the DMW-add script will generate an error indicating that DXIM cannot be found when creating an account. Follow these steps to work around the problem: 1. When you run the DMW-add script, answer "N" to the following question: Does your site use X500 n 2. After creating the accounts, you should move either the /var/opt/DMW/DAXdatafile or the individual user files, username.dax, located in /var/opt/DMW/admin, to the system licensed to run the X.500 Administration tools. 3. On the system running X.500, issue the following commands where filename is the name of the file you copied: # dxim -c dxim> do filename dxim> exit For example: dxim> do username.dax 3-4 Known Problems or Restrictions 4 ________________________________________________________________ Digital UNIX Patches To ensure that MailWorks runs correctly, you must apply the Digital UNIX patches described in these sections. Contact your Digital Customer Support Center for a complete list of patches required for Digital UNIX. 4.1 Digital UNIX Version 3.2-C Patches The following patches are required for Digital UNIX Version 3.2C: o Patch ID: OSF350-225 Fixes a problem where multiprocessor systems using the AdvFS file system, particularly systems also using AdvFS for the root and usr file systems, may experience intermittent freezing of interactive processes when the system has a moderate to heavy I/O load. The freezing of interactive processes may last from a few seconds to many minutes but will eventually return to normal. This problem may also occur on multiprocessor systems using the NFS client or graphics sub-systems. o Patch ID: OSF350-108 Fixes a problem that occurs in code that is linked against or dlopen()'s libc_r and makes calls to functions whose names match the pattern get*_r. A program exhibiting this problem would often core-dump with a stack trace that showed it was in one of the get*_r functions. o Patch ID: OSF350-105 Fixes a problem where applications linked with DECthreads behave as if they have no more memory available when they are not close to the operating system limit. Digital UNIX Patches 4-1 o Patch ID: OSF350-126 Fixes a problem that occurred when a multithreaded process was killed, stopped, or otherwise caused to stop or exit asynchronously. The process would go into an uninterruptible wait state, typically indicated by a "U" in a ps output. o Patch ID: OSF350-133 Fixes a problem where the strncat() function may fail with a SEGV if the second argument (source array) to strncat() points to a location in memory where there is no null terminator between that location and the 'n'th (3rd argument) subsequent byte, and the memory immediately following the 'n'th byte is not mapped. o Patch ID: OSF350-151 Fixes a problem that may occur when an SMP machine runs a large number of web server daemons, for example, ns- httpd or httpd. If the web server daemons all accept incoming sockets on the same head socket, the system would panic. o Patch ID: OSF350-168 Fixes a problem where a call-shared application which overloads a shared library procedure with an additional implementation of the procedure in the main executable can "Segmentation fault". 4.2 Digital UNIX Version 3.2-D Patches The following patches are required for Digital UNIX Version 3.2D: o Patch ID: OSF360-350108 Fixes a problem that occurs in code that is linked against or dlopen()'s libc_r and makes calls to functions whose names match the pattern get*_r. A program exhibiting this problem would often core-dump with a stack trace which showed it was in one of the get*_r functions. o Patch ID: OSF360-350133 4-2 Digital UNIX Patches Fixes a problem where the strncat() function may fail with a SEGV if the second argument (source array) to strncat() points to a location in memory where there is no null terminator between that location and the 'n'th (3rd argument) subsequent byte and the memory immediately following the 'n'th byte is not mapped. o Patch ID:OSF360-350145 Updates FDDI driver to include these fixes: - Major rework of fta_reinitialize to fix stuck interface after halt. - Display source and destination address on bad incoming packets (CRC, Illegal length, etc.). - Fixed up the bumping of some DECnet counters so they could latch to their max values. o Patch ID: OSF360-350151 Fixes a problem that may occur when an SMP machine runs a large number of web server daemons, for example, ns- httpd or httpd. If the web server daemons all accept incoming sockets on the same head socket the system would panic. o A problem exists with the version of sendmail that has been included with the Version 3.2D kit; until a patch is issued, remove the copy of sendmail and binmail installed with the Version 3.2D kit, and use the copies included with the Version 3.2C kit. Digital UNIX Patches 4-3 5 ________________________________________________________________ InfoBroker Patches To ensure that MailWorks runs correctly, you must install a mandatory patch for InfoBroker Version 2.0 and Version 2.1 that fixes a memory corruption problem when doing an X.500 lookup from any of the MailWorks clients. Contact your Digital Customer Support Center to obtain the patch. We recommend that you install Version 2.1A-2 of InfoBroker. InfoBroker Patches 5-1 6 ________________________________________________________________ Troubleshooting 6.1 Inefficient Directory Lookup Digital MailWorks Version 1.7A and later can occasionally generate a message warning that an inefficient directory lookup has been performed. A warning message similar to the following example is logged in the file /var/opt/DMW/logs/msrlog: Mon Feb 12 15:47:56 1996, Program: /usr/opt/DMW/bin/msr, User: root, Type: Err, Sev: Warning Version: 1.7-A, Version Date: Tue Oct 3 01:22:45 EDT 1995 Module: 12, Error: 34 Inefficient directory lookup performed because a directory entry is missing common name or personal name information. X.400 address for this entry is . This is just a warning. In all probability the message has been delivered successfully. Background When Mailworks receives a message from the MAILbus 400 MTA, it has to discover which local UNIX user it is addressed to, so it can deliver to the correct message store. It does this by reading the O/R address of the recipient on the message, and looking up the corresponding entry in the X.500 Directory. In previous versions of Digital MailWorks for UNIX (Version 1.7 and earlier), the lookup was done by matching the full O/R address with the mhs-or-addresses X.500 Troubleshooting 6-1 attribute. When MailWorks found an entry that matched, it could then read the decMAILworksUserName attribute. This lookup was extremely slow because the mhs-or- addresses attribute is not indexed by X.500. In addition, many entries have multiple mhs-or-addresses values in order to specify all of the O/R addresses that apply to a person (for example, to show different spellings of names, or to give full or partial personal name information.) In Version 1.7A and later, MailWorks no longer uses the mhs-or-addresses attribute to do this lookup. It now uses either the common name or personal name parts of the O/R Address and uses these attributes to find the entry. These attributes (commonname, givenname, surname, initials, generation) are indexed by X.500, so the lookup is much faster. If MailWorks cannot find a match on these attributes, it reverts to the original method of using the mhs-or-addresses attribute; this second lookup causes the Warning message to be logged. Solution You can improve MailWorks' performance by modifying your users' entries in the X.500 Directory. In general, each user entry should have only one value in the mhs-or-addresses attribute. This should be the user's preferred O/R address. The entry should then also have as many common name and personal name attributes as may occur in an O/R Address. For example, consider a MailWorks user Jim Thompson. Before Version 1.7A, it is likely that his X.500 entry would have looked something like this: dxim> show entry /C=CO/O=ORG/OU=OU1/CN="Jim Thompson" /C=CO/O=ORG/OU=OU1/CN="Jim Thompson" Object Class = Person = organizationalPerson = decMailUser X400 Mail Address = C=co; A=admd; P=prmd; O=org; OU1=ou1; CN=Jim Thompson 6-2 Troubleshooting = C=co; A=admd; P=prmd; O=org; G=Jim; S=Thompson; OU1=ou1 = C=co; A=admd; P=prmd; O=org; G=James; S=Thompson; OU1=ou1 rfc822Mailbox = jim@ou1.org.com MAILworks User Name = jim Preferred Mail Type = mhs-or-addresses Common Name = Jim Thompson Given Name = Jim Surname = Thompson Consider the following example, when a message arrived addressed to: C=co; A=admd; P=prmd; O=org; G=James; S=Thompson; OU1=ou1, Earlier versions of Mailworks searched for entries that had this address as one value of mhs-or-addresses. This would be time-consuming. It would also fail if the third mhs-or-addresses attribute were not present in the preceding entry. If this same message arrives at a Version 1.7A or later system, MailWorks will extract the G=James; S=Thompson; terms and use these indexed attributes in an attempt to find the entry. In our example, this will fail; although there is a Surname attribute of Thompson, there is no Given Name attribute of James. So MailWorks will revert to the pre-Version 1.7A behavior and will also generate the Inefficient Lookup Warning message. To remedy this situation, you should add the alternative personal name attribute to the X.500 entry. In this example, you would add a Given Name of James and perhaps a common name of James Thompson to cover the situation of a message addressed to: C=co; A=admd; P=prmd; O=org; cn=James Thompson; OU1=ou1 You could also consider adding other variants such as: Surname = Thomson, Thomsen Troubleshooting 6-3 There is no longer a requirement for the multiple mhs- or-addresses attributes. You should decide which is the most appropriate attribute, and remove the others. In our example, perhaps most messages are addressed using personal name terms, so the mhs-or-addresses value that is the best one to keep is: C=co; A=admd; P=prmd; O=org; G=Jim; S=Thompson; OU1=ou1 This will also ensure that if the sender of a message uses the X.500 Directory (via Infobroker for instance) to discover Jim Thompson's O/R address, only the single, preferred one is available. In summary: o Identify the O/R address which should be used for each entry. o Remove the other mhs-or-addresses values. o Add commonname, givenname, surname, initials, and generation values to represent all of the variants of the user's name. 6.2 Working with Exchange If you will be exchanging mail between a Microsoft Exchange server and a MailWorks for UNIX server, we recommend that you use SMTP and the Exchange Internet Mail Connector to interface the two mail systems. When configuring Exchange's Internet Mail Connector, you should select the Message Content Panel, and select the following options: o Send messages using MIME. Messages will be transferred more accurately, and attachment types will be handled more conveniently than if you select UUEncode. o Under Interoperability, Select "User" or "Never" for the "Send Microsoft Exchange Rich Text Formatting" option. 6-4 Troubleshooting If you select "Always", then Exchange will always generate a TNEF attachment to carry the rich text formatting. This will be partially handled by the combination of the Exchange client and the MAPI driver, but it will be confusing to users of any other client. Also, any attachments will be encoded in the TNEF file, and will therefore be invisible to all users of the MailWorks server. Selecting "User" or "Never" will drop any rich text formatting in the cover memo, but will otherwise preserve the integrity of the message. Troubleshooting 6-5