ECO NUMBER: DMWOSF_E07020 ----------- PRODUCT: MailWorks for UNIX -------- UPDATED PRODUCT: MailWorks for UNIX 2.0 ---------------- APPRX BLCK SIZE: 129000 ---------------- Cover Letter for DEC MailWorks for Unix, Version 2.0, ECO DMWOSF_E07020 Problem Description -------------------- ECO Number 7 for MailWorks for Unix, Version 2.0 is primarily focused on providing Year 2000 support, and on providing official support for Digital UNIX 4.0. In addition, ECO7 fixes some problems with support for ISO-Latin2, and fixes problems which can result in illegal instructions being reported in the log files. In support of Year200, this ECO includes an updated copy of the SunOS and Solaris Motif clients. Please see the Release notes below and in the kit for more detailed description of the problems fixed with ECO7. Installation Overview --------------------- The ECO kit is distributed on media as a tar file or electronically as a compressed tar file. As a general precaution, we recommend that you install this ECO after performing a suitable backup of your system. The tar file contains kits for the MailWorks server, plus the clients for Sun Solaris and SunOS. You should start by unpacking the ECO tar file into a suitable directory. This will result in four files: mailworkskit.tar - this contains the server kit. mailworks-solaris-client.tar - as the name suggests, this contains the motif client built to run on Sun Solaris. mailworks-sunos-client.tar - this contains the motif client for SunOS release_notes_eco7 - The detailed release notes. At this point, select the tar file containing the component you want to install and unpack that tar file. After unpacking the tar file, you will have a full installation kit for MailWorks for Unix server, or the appropriate Sun client. You can now install the server and/or the motif client using the original installation instructions supplied with the V2.0 MailWorks server kit. ***************************************************************************** Release Notes MailWorks for UNIX, V2.0, ECO7 4/17/98 MailWorks for UNIX V2.0, ECO7 includes all of the changes incorporated into ECO1-ECO6. The release notes for those ECOs are included at the end of this document. The changes introduced in ECO7 are described below. IMPORTANT: Because of internal changes in Digital UNIX version 4, the requirements for operating system tuning are different from Digital UNIX version 3.2. Please use the following table of parameters instead of the table printed in the MailWorks manual: Users maxusers vm-vpagemax vm-mapentries 0-63 200 64000 400 64-199 512 131072 1024 200-499 1024 214748 1024 500-999 1800 322122 2048 1000+ 2048 322122 4096 maxusers is set in /usr/sys/conf/YOURHOSTNAME vm-vpagemax and vm-mapentries are set in /etc/syscofigtab, with an entry of the following form: vm: vm-vpagemax = 322122 With ECO7, MailWorks has been made Year 2000 compliant. ECO7 will now be supported on Digital UNIX Version 3.2C-3.2G, or 4.0B and later, although we strongly recommend 4.0D (build 878) or later. If you use 4.0B or 4.0C, you should install the latest patches, since they resolve some problems with the threads system which could affect MailWorks. MailWorks has been tested with the following versions of other components, and we recommend that you upgrade to these versions: X.500, version 3.1-2 MAILbus400, version 2.0-1 InfoBroker Version 2.2 (To be available on the April Layered Products CD) Note that a few minor problems were found with MailWorks on UNIX 4.0, so if you are still running an earlier ECO of MailWorks, we recommend that you upgrade to ECO7. MailWorks now handles ISO Latin-2 character sets as follows: * For outbound X.400 messages, MailWorks now properly declares ISO-Latin2 in the character set repertoire, and properly maps ISO-Latin2 characters in Teletex fields. * For inbound X.400 messages, General Text bodyparts encoded in ISO-Latin2 will be recorded as MailWorks PlainText bodyparts, so that they will be readable by ordinary message viewers * For inbound MIME messages, MailWorks now accepts messages that declare ISO-Latin2 in header fields. ** Note: if your system normally operates with ISO-Latin2, and if you routinely generate MIME messages, you may want to change the mapping of PlainText in the file /usr/opt/DMW/Enclosures/.dmw_mime_send_map A few problems were fixed that could cause the mcs or x488 processes to report illegal instructions and/or segmentation faults in the log file. In rare circumstances, it is possible to receive a heavily forwarded message (often from the internet) which will cause the mss server to fail. To combat this problem, we recommend that you place the following line into the file /usr/opt/DMW/MAILworksrc: set RMESOCK_THREAD_STACK_SIZE=84480 Starting with ECO7, when submitting a message to X.400, MailWorks will no longer supply the MTS_ID (envelope ID), but will rely on MAILbus 400 to generate this ID. This will insure unique Local Identifiers on all X.400 messages. Release Notes MailWorks for UNIX, V2.0, ECO6 12/9/97 MailWorks for UNIX V2.0, ECO6 includes all of the changes incorporated into ECO1-ECO5. The release notes for those ECOs are included at the end of this document. The changes introduced in ECO6 are described below. The msr process has been made multi-threaded. This means that some operations (such as the receipt of an X.400 message with a large distribution list), will no longer cause the entire system to pause. Under unusual circumstances, it was possible for the mcs process to stop responding for 2 minutes while waiting for a lock to free up - after the 2 minutes the server would begin operating normally. This 2 minute "smoke break" has been eliminated. The MIME encoding logic now properly handles equal signs when the bodypart is encoded with quoted printable encoding. Eliminate the corruption of text bodyparts in draft messages and revisable text documents which are updated in place. A number of changes designed to increase the reliability of the server, including the elimination of a problem that would cause the mcs to "spin", i.e. consume large amounts of CPU time. The server processes have improved the handling of signals from the operating system reporting that a child process had completed. The handling of the signal will no longer cause corruption of the parent process (usually the mcs or the mss process). MailWorks now properly handles forwarded messages received from SMTP where the embedded message is encoded differently from the enclosing message; this had been seen in messages forwarded from ALL-IN-1 through the SMTP gateway. Release Notes MailWorks for UNIX, V2.0, ECO5 6/16/97 MailWorks for UNIX V2.0, ECO5 includes all of the changes incorporated into ECO1-ECO4. The release notes for those ECOs are included at the end of this document. The changes introduced in ECO5 are described below. * When a user with read-only access opened an Excel spreadsheet in a shared drawer, the server would continuously make a copy of that spreadsheet in the MailWorks temporary directory, which in turn would exhaust space on that file system. Note that this occurred *only* with Excel, and *only* if the user did not have write privileges to the drawer containing the spreadsheet. Starting with ECO5, the server will leave only one or two copies of the spreadsheet in the temporary directory - these files will be cleaned up when MailWorks is stopped and restarted. (IPR 1694) * Additional file types have been added to the MIME send and receive maps, and a number of file types (including Office 97 documents) have been added to the /usr/opt/DMW/Enclosure/DB file. * The mss process correctly handles a timeout situation when attempting to open a message store. Starting with ECO3, if a timeout occurred opening a message store, the message store would become corrupted. (IPR 1700) * The mcs process will no longer allow a client to open a folder if there was a problem attempting to open a drawer. Previously, the mcs process would log a segmentation fault. * The mcs process now properly handles a NULL value for an ldap attribute. Previously, the mcs process would log a segmentation fault. (IPR 1695, 1702) * If the server is configured to send messages using UUEncoding (i.e., sendMime is FALSE or is not present), and if a MIME message is received then forwarded, the server now removes the MIME version header from the forwarded message. This was making the forwarded messages unreadable. (IPR 1693) New Features ------------ * A new MAILworksrc parameter, addUuencodeFileName, has been added. The default value, TRUE, indicates that when MIME is not being used, and when a filename is availble from the client, that filename will be used in UUEncoded attachments placed on outgoing messages. The value of FALSE indicates the form Enclosure1 will be used as a name in UUEncoded attachments. * When using TeamLinks clients, find by a range of dates is implemented. * ECO3 introduced a timeout on opening a message store. By default, this timeout is 10 seconds, which is a reasonable value when all message stores are private message stores. However, if your configuration uses one or more shared drawers, then users are much more likely to encounter a conflict opening a message store. In this case, you should set the MAILworksrc parameter lockMSTimeout to 30 or even 60. * ECO5 introduces a change to the handling of lines of text that begin with hyphens. Prior to ECO5, MailWorks implemented the behavior specified in RFC934, specifically: 1) If a message was received containing a text bodypart with a line that began with exactly two hyphens, those two hyphens were considered a bodypart separator, and MailWorks would generate two (or more) separate bodyparts. 2) Because of that, in an outgoing message, if a line that began with more than one hyphen was encountered, a single hyphen and a space were inserted at the beginning of that line. 3) Conversely, if an incoming message contained a line that began with a hyphen followed by a space, the hyphen and the space were stripped from the line. (Note that this behavior took place only when the message was not MIME encoded, and did not include an Encoding header.) Starting with ECO5, this behavior is optional, and by default, it does not take place. If the behavior specified in RFC934 is important to you, it can be restored by entering the following line into the file /var/opt/DMW/MAILworksrc: splitBodyparts=TRUE Performance Useage Notes: ------------------------ MailWorks for UNIX uses standard TCP connections for communication among the different processes that make up MailWorks for UNIX. It is possible to configure TCP to handle that communication more efficiently when two processes communicating are in the same system. If your node address is 16.99.16.99, then you should add the following entry to the file /etc/routes: 16.99.16.99 localhost This will take effect on the next system restart; to have this take effect immediately (but only until the next restart), you can also enter the UNIX command: route add 16.99.16.99 localhost Note that in some cases when the network is busy or noisy, this change can reduce the number of communications-related errors reported in the log files. By default, most MailWorks processes locate the msr process using a TCP broadcast mechanism; this consumes a small amount of network resources, and can introduce a small delay in starting processes. For the best performance, edit the MAILworksrc file, and replace the following line: #msrHost= with an entry of the form msrHost=my.host.name.com As with the localhost optimization above, this can reduce the incidence of errors in the event that your network is busy or noisy Finally, whether you use SMTP or X.400 primarily, we strongly recommend that you configure MailWorks to perform optimized local delivery; look in the MailWorks Admin guide for the description of the MailWorksrc parameters localSMTPAddresses and localX400Addresses. This will reduce both the elapsed time to deliver a message, and the CPU time required to deliver the message. For messages sent over SMTP, it will eliminate an invocation of sendmail and inetgrecv for every message sent - this also reduces the load on your server system. Release Notes MailWorks for UNIX, V2.0, ECO4 4/10/97 MailWorks for UNIX V2.0, ECO4 includes all of the changes incorporated into ECO1-ECO3. The release notes for those ECOs are included at the end of this document. The changes introduced in ECO4 are described below. * A problem in which the mss server could become unresponsive when the user of a MAPI-based client successively deleted nested folders has been fixed. * Several problems that could lead to the mcs or the mss server becoming unresponsive or to crash have been fixed. (Problem 3900, 4884, 5197, 5008, IPR 1664, 1673, 1681) * When a corrupted message store is encountered by the mss server, it now properly closes the message store file. Prior to this, it was possible for the system to report "too many open files". Often this report would appear in the lsfd log file, when lsfd continued to attempt to deliver a message into the corrupt message store. * Occasionally, the command line command resend would send the message to the original recipients of the message rather than the newly specified recipient - this has been corrected. (Note that this affected only the command line command resend - the forward command has always worked properly from all clients. (Problem 3121) * x488grecv now properly handles messages with bodyparts with a length of zero. (IPR 1660) * When the MAILbus400 MTA is disabled, or otherwise unavailable, x488grecv will now check whether the MTA has become available every 30 seconds rather than every microsecond; this will significantly reduce the number of log entries while the MTA is unavailable. If you would prefer to adjust the 30 second retry interval, set the parameter mtaRetryInterval in MAILworksrc. For example, to set it to 10 minutes, include the line: mtaRetryInterval=600 (IPR 1655) * When sendMIME is not set, or is set to FALSE, binary attachments are UUEncoded. Prior to ECO4 the filename incorporated into the UUEncoding was of the form Enclosure1. Starting with ECO4, the original file's filename will be included - this means that the recipient will see the full filename, including extension, and most PC clients will properly recognize the type of the attachment. * The utility mschk has been made more robust, to handle some additional forms of message store corruption. (IPR 1683) * Previously, if a user of the motif client performed a folder query, then selected a query field, but did not provide a value for that field, the motif client would crash. It now processes the query as though the field were not selected. ECO4 introduces another change that is the first of two steps to fixing another problem. We discovered that the SMTP header fields in the file /usr/opt/DMW/Enclosures/DB had been constructed incorrectly. (This is the field used by MailWorks to construct the encoding header used in SMTP messages when MIME is not used.) To ensure interoperability among different systems using MailWorks, the version of the DB file in this release has defined synonyms for those fields, so that when the correct values (introduced in a future release) are received by a system using ECO4, they will be recognized and handled properly. We strongly recommend that you install this DB file on all of your systems, even if you do not update every system to ECO4 (simply copy the file /usr/opt/DMW/Enclosures/DB from the newly installed system to replace the same file on all of your older systems). In the next release or ECO, we will provide a version of the DB file that uses the correct version of the SMTP headers, but recognizes and properly handles the version of the headers used in ECO4 and prior releases. So, what problem are we fixing? When a user of a MailWorks system that is *not* using MIME sends a message with binary attachments to a user of the Microsoft Exchange server or selected other mail systems, the other mail system may not recognize that the binary attachment has been UUEncoded. The recipient will see the attachment as a text file containing the UUEncoding rather than as the decoded binary file. If you are seeing this problem, rename the file /usr/opt/DMW/Enclosures/DB that is currently installed on your system, and replace it with the file usr.opt.DMW.Enclosure.DB.new that is included in this kit. If you have multiple MailWorks systems, and if you are not using MIME, you will want to install this file on all of your systems simultaneously. (Note that while you will need to restart MailWorks, it is *not* necessary to install this full ECO on all systems simultaneously.) ============================================================================ Release Notes MailWorks for UNIX, V2.0, ECO3 2/21/97 MailWorks for UNIX V2.0, ECO3 includes all of the changes incorporated into ECO2. The release notes for ECO2 are included at the end of this document. The changes introduced in ECO3 are described below: * Under rare circumstances, when the mss server had problems opening one message store, it could get "stuck" and prevent all users from opening any other message store. The symptoms were that users who were already connected could continue to work, but other users could not make new connections to the server. ECO3 introduces a timeout on the opening of a message store, so that if it fails, an error will be reported to that user, but no other users will be locked out of their message stores. A message of the following form will be placed in the msslog: ----- Sat Feb 15 15:58:12 1997, Program: ./mss, Pid:31422, User: root, Type: Err, Sev: Error Version: 2.0-FT1, Version Date: Sat Feb 15 15:36:30 EST 1997 Module: 15, Error: 47 The message store: mail4u.zko.dec.com:/mailworks/test_users/test103/dmw/test103.po is currently locked and cannot be accessed (Error MSMutexLocked). If this condition persists, your system administrator may need to restart MailWorks. ----- Under some circumstances, this condition may clear itself (for example, if a background thread is emptying someone's wastebasket, they cannot make a new connection until the process is complete). If it does not clear itself, it may be necessary to restart MailWorks to clear that user's problem. * The startMAILworks and stopMAILworks scripts fix some minor problems. If the lsfd process is running, it no longer prevents the stopMAILworks script from completing. If the lsfd process is running when startMAILworks is run, startMAILworks will simply allow the lsfd to continue. (Note that it is perfectly normal for the lsfd process to be running while MailWorks has been shut down - once MailWorks is restarted, lsfd will re-establish its connection to the other processes. While MailWorks is shut down, lsfd may be started up if new internet mail arrives - the inetgrecv process will use lsfd to ensure that the incoming mail will be delivered when MailWorks is restarted. * Inetgrecv now properly handles some MIME messages that previously caused a segmentation fault in inetgrecv. * The table used to identify attachment types in MIME have been updated to correct an omission (Powerpoint version 7), and to correct an error (Excel version 5). This is the file .dmw_mime_send_map. * ECO2 introduced a harmless error message that appeared in the inetgrecv logs (erroneously reporting an invalid Internet Header) - this has been corrected in ECO3. * The script suppscr.sh, located in the unsupported directory has been updated to collect more complete information. This script should be used if you need to report a problem to engineering - simply run the script from the root account, and include a copy of the script's output (a file named session.out) in the problem report. Useage notes ============ Using filenames on attachments ----------------------------- Now that the MailWorks server will carry file names for message attachments, it is possible to enounter problems with names that are too long. In particular, the default behavior of TeamLinks for Windows when attaching a file is to include the full path spec of the file. Depending on where you have the file, this can result in a fairly long file specification. In many cases, when the recipient extracts this bodypart from the message to the native file system the long name will be truncated, in the process losing what may be the most important part of the name: the extension. If this becomes a problem, or more precisely, if this problem becomes more significant than the benefit of having a full path spec in the message, TeamLinks for Windows can be modified to use only the filename without the full path. In OFFICE.INI under [TeamLinks Mail] add the entry FullSpecAttachmentTitle=0 Note that as of this writing, this feature is not documented in the TeamLinks documentation. UUEncoded bodyparts in MIME --------------------------- Eudora Pro 3.0 has an option to UUEncode attachments. Unfortunately, it does not do what you might expect it to do - the message as a whole is still sent MIME encoded, but the individual attachments are sent using a transfer encoding of x-uuencode. (This is a non-standard encoding for MIME, and MailWorks does not yet support it.) The effect is that when a sender uses this option, the recipient sees an attachment that is apparently of the right type (e.g. it appears to be a word document, and when the TeamLinks user tries to read it, Word is invoked), but the content is actually the raw UUEncode. Alternatives for the receiving user: 1) Talk to the sender, and ask him/her to resend the message with either MIME or binhex selected as the encoding method under attachments in the Eudora client. 2) Save the file to disk and use a stand-alone UUDecoding utility to decode it. 3) If you are using TeamLinks for Windows, then with the message open, use the menu entry "Decode Message" on the file menu. Attachment tagging ------------------ A couple of problems have appeared recently that generally relate to bodypart tagging and decoding: 1) Starting with V2.0.2, MailWorks now supports full fileanames on attachments for local delivery, X.400 delivery, and SMTP/MIME. It does *not* yet carry filenames in the UUEncoded encoding used when sendMime is turned off (which is the default). The filenames used with UUEncoding are of the form Enclosure1, Enclosure2,... This limitation has been corrected in ECO4. 2) The MSMail driver includes a version of TLFormat.ini to assist in the mapping of file types from the server tagging to the tagging that MSMail requires. The version included in the driver kit has already gotten out of date (and will only get more so). The symptoms of this are that an MSMail recipient sees an attachment that is not recognized by MSMail, but if s/he saves the file to disk with an appropriate filename, it can be opened by the appropriate application. (Note that the symptoms are almost identical to the first problem, but the cause is very different.) The solution is to add the appropriate file types to the TLFormat.ini file used by the MSMail driver. Note that you cannot simply take the file from the latest version of TeamLinks, since newer versions of TeamLinks often add fields not recognized by the older MSMail driver code. Just the individual file type entries should be copied, and some of the newer fields should be dropped (e.g. in the following entry for Word 6, the line for Template, MIMEContentType, and PegasusType should be omitted when creating the entry for the MSMail driver: [WINWORD6] Desc=Microsoft Word for Windows V6.0/7.0 Document FileExt=DOC IosFormat=WINWORD6 IosDsab=FOREIGN IosFileExt=DOC Asn1=2B0C02877305014F Template=WINWORD6.DOC MIMEContentType=application/msword; name="TL.doc"; Type=%%peg%% PegasusType=MS-Word-6 ============================================================================ Release Notes MailWorks for UNIX, V2.0, ECO2 1/13/97 This document contains the following information: Problems fixed in ECO1 and ECO2. Additional Features implemented in ECO1 and ECO2: - Support for MTA password - Limit on the number of mcs connections accepted - POP3 administration - Support for filenames on message bodyparts - ISO Latin 2 - Controls on the elimination of duplicate messages - Improvements to the start and stop scripts Other notes on using MailWorks effectively - How to use a single msr with several servers - Valid SMTP addresses - Automatically applying quotes to SMTP addresses in TeamLinks - How to safely move or rename message stores - POP3 clients that are supported - Defining new data types - Memory usage - Interoperability with Microsoft Exchange Problems fixed in ECO2 ====================== * A number of significant memory leaks in the mcs process have been fixed in both ECO1 and ECO2. Sites that had been restarting MailWorks every night or every second night may find they need to restart only once per week. See the discussion later in the release notes for more information on memory usage. * Disable "From" field in command line interface: The command line interface allows users (or scripts) to specify a "from" value. While this can be useful for some scripts, it opens the door for impersonation when used interactively by end users. MailWorks now accepts a MAILworksrc parameter to control whether the from option is accepted. When allowFrom is TRUE, users and scripts will be able to specify a From field when they do a comp -headerlist. In this case, MailWorks will now add a Sender field to minimize the effects of any impersonation attempt. When allowFrom is FALSE, users and scripts will not be allowed to specify the From field. NOTE: the default value of this parameter is FALSE, which represents a change in behavior from prior versions. If you depend on being able to set the From field, e.g. for scripts, you should define this parameter to be TRUE in the MAILworksrc file. * If the directory service is unavailable at the time an incoming messge arrives, it will now be queued for later delivery (via lsfd) rather than being immediately rejected. * Several problems that caused inetgrecv to fail have been fixed. Inetgrecv can now properly decode MIME messages with attachments encoded in BinHex. * When sendMime is false (or not specified), forwarded messages are no longer corrupted. This had been particularly prevalent when the forwarded message had an attachment. * Message delivery dates are now properly preserved when the packf command is executed (and are properly imported by the inc command). If the MAILworksrc parameter sendMime is TRUE, the messages exported by the packf command will be MIME encoded. * A typographical error in the DMW-delete script (that prevented the complete deletion of an account) has been corrected. * stopMAILworks now waits 5 seconds before attempting to stop the mss process - this gives the mss a chance to properly close its connections to the other processes before beginning its own shutdown cycle. * When entering header date fields (e.g. deferred delivery date, expiration date) into the Motif client, the input box is now sized so that the time portion of the date is visible as it is being typed. * Clicking on the delete button of the Motif client's DDA dialog no longer brings up the Help window. * ECO2 fixes a couple of small windows in which messages could be lost if MailWorks or the system went down at the wrong time. We believe that other than power failures that would prevent memory writes to disk, all opportunities to lose a message have been fixed. * A number of problems have been fixed with the dates appearing on messages, particularly with TeamLinks clients. In particular: - When a message is being copied or moved to the server from a local TeamLinks drawer, the server will properly set the posted date. - When non-modifiable messages (i.e. received messages or sent copies) are being written to the server, the server will not reset the modified time, or in some cases will set the modified time to the delivered time. The field that the server identifies as the modification time appears in all TeamLinks clients in the Read Message window, and in older TeamLinks for Macintosh clients as the date/time that displays in the file cabinet display window. - When revisable (e.g. draft) messages or documents are copied to the server, the modification time is reset to the date/time of the copy. - When a message has BCCs and an expiration date or reply by date, the date is now properly stored with the message. * When transferring messages to an X.400 MTA, the X.400 field "Originally Specified Recipient No" is now properly set. This caused problems when the message was transferred to a non-Digital MTA. * The mss server now properly recovers from certain types of corruption in message stores. This error showed itself as ProtoBadLength in the mss logs. * The x488grecv process now properly recovers from many communication problems with the MTA - previously it was possible for x488grecv to get hung up waiting for an operation to complete that was never going to complete. Note: we had recommended against using the LOCAL option in the file /var/mta/mta_api_server_address - the situation that caused problems with this configuration option has since been corrected, so you may now use this configuration option. * The mcs server now properly handles messages containing both X.400 recipients and bcc recipients; this combination used to cause the server to crash. Additional features/capabilities =============================== MTA password ------------ MailWorks/UNIX now supports optional password authentication when MailWorks connects to the MAILbus400 MTA. To enable this password authentication, do the following: From the MTA side: 1) Using NCL, set a password for the MailWorks MTA agent as follows: ncl> SET MTA AGENT mailworks_mta_agent_name PASSWORD "secret" where "mailworks_mta_agent_name" is the name defined in the /usr/opt/DMW/MAILworksrc file as X400ClientName. 2) Add this command to the var/mta/scripts/start_mta.ncl at the point where the MailWorks MTA agent is defined, so upon restarting the MTA, the password is retained. From the MailWorks side: 1) Create a file of the name /var/opt/DMW/mtaAgentPwd. (This filename is case sensitive.) On the first line of this file, enter only the password set for the MailWorks MTA agent using NCL (e.g. secret). The password is case sensitive. This file should contain nothing else but this password on a single line. 2) Set the UNIX ownership and permissions on the file /var/opt/DMW/mtaAgentPwd so no unauthorized users can obtain the password. Notes: A password is not required to connect to the MTA. However, a matching password is required once either side (NCL or the mtaAgentPwd file) defines a password. It is not necessary to restart the MB400 MTA or MailWorks for password authentication to take effect. Once passwords are defined, they will be used automatically by MailWorks on the next MTA connection attempt. Limit number of connections --------------------------- If your users use TeamLinks, cc:Mail, or Microsoft Mail be aware that there is a limit on the number of connections that the mcs process can accept. (Microsoft Exchange clients communicating through the MAPI driver do not use the mcs process, so are not subject to this limit.) Prior to ECO1 of version 2.0, the mcs process would not properly recover when this limit was exceeded (among other effects, it would refuse to accept new connections, even when the number of active users dropped below the limit). Beginning with ECO1, it is now possible to put a limit on the number of connections that the mcs process will accept. If this limit is specified, then any attempted connection that would exceed this limit will be rejected (the user will get a message that the connection attempt failed), and an entry will be logged in the mcs log. This user can try again later, and if other users have disconnected from the MailWorks server (so that the number of active users is below the limit), the connection will be accepted. The limit is enforced if the parameter maxGENIConnections is defined in the file /usr/opt/DMW/MAILworksrc, and of course the maximum number of connections is the value of the parameter. If no parameter is defined, no limit is enforced. Note that the default MAILworksrc file specifies no limit, so if you have a large number of users, you should supply a limit. The parameter defines a limit on the number of connections that the mcs server will accept from a PC client. In general, a reasonable value for this parameter is 2600. Some background and details: When a TeamLinks or cc:Mail user logs into the MailWorks server, his client software is actually making two connections to the mcs server process (one to port 6161, and one to port 8484), the mcs server in turn makes one connection to the mss process on behalf of that user. Thus, in the simplest case, each user causes the mcs to consume 3 TCP connections. The mcs process has a limit of 4096 files and TCP connections that it can have open at one time (in general, the mcs process keeps very few files open, so the number of files does not contribute significantly to the limit). Thus if 1300 users connect, there will be 1300 connections to the mss process, and 1300*2 connections from the PC clients - the total of 3900 leaves a reasonable margin of error below the absolute limit of 4096. Microsoft Mail clients make two sets of connections to the server for each user, and some new mail notification applications make yet another set of connections. Thus, when Microsoft Mail is being used, the limit of 2600 PC connections will translate into fewer than 1300 users. When the limit is exceeded, a log entry similar to the following will be placed into the mcs log: ----- Mon Nov 11 22:36:24 1996, Program: ./mcs, Pid:14708, User: root, Type: Err, Sev: Error Version: 2.0-1, Version Date: Mon Nov 11 18:04:23 EST 1996 Module: 34, Error: 24 The limit of 1 PC-client/compatibility-server connections has been reached (Error MUAS_TooManyConns). As a result, a connection request by user testjmm has been rejected. The user should try connecting again later. ----- POP3 administration ------------------- By default, when a POP3 client deletes a message from the inbox, the message is placed into the user's wastebasket. If the user does not normally use any other clients that can empty the wastebasket (or if administrative scripts that empty the wastebasket are not used), this can lead to an accumulation of deleted messages in the wastebaskets. To overcome this, you can set the MAILworksrc parameter deletePop3Msgs to TRUE (the default value is FALSE). When this is set to TRUE, then when messages are deleted from a POP3 client, they are permanently deleted rather than being placed into the wastebasket. Note that this affects only deletions requested from POP3 clients - when a delete is requested from any other client, the message is placed into the wastebasket. Filenames --------- MailWorks will now preserve the filenames of message attachments when they have been supplied by the originating client. These filenames are carried on local delivery, in MIME messages, and in X.400 messages in FileTransferBodyParts. For local delivery, the filename supplied by the originating client is delivered with the message with no validation or re-processing of the name. Note that this includes optimized local delivery of messages to local X.400 or SMTP addressees (e.g. if the MAILworksrc parameters localSMTPAddresses and/or localX400Addresses are set). Note also that if a POP3 client is used to read locally delivered mail, the processing rules for MIME in the next paragraph apply. In MIME messages, the filename is carried in the name= clause of the content type entry. By default, if a filename is supplied, it will be fixed up if necessary to make it a legal filename, then used; if no name is supplied, the name= clause from the file .dmw_mime_send_map will be used instead. To describe the rules for handling filenames more precisely: * If no filename is supplied by the originating client, then the name= clause from the .dmw_mime_send_map file will be used in the MIME encoding. * If the MAILworksrc parameter overrideSendMap is set to FALSE, then the name= clause from .dmw_mime_send_map will be used in the MIME encoding. (The default for this parameter is TRUE, so that by default, the filename supplied by the originating client will be used.) * If the MAILworksrc parameter validateBPFileNames is set to TRUE, and the extension of the filename does not match the extension recorded in the Enclosure/DB file, then the filename supplied by the originating client will be replaced by the filename in the name= clause of .dmw_mime_send_map. The default for validateBPFileNames is FALSE, which means that the filename supplied by the originating client will be used. * If validateBPFileNames is FALSE (the default), and the MAILworksrc parameter fixupBPFileNames is TRUE (the default), then the filename supplied by the originating client will be "fixed up" if necessary, then used. The "fixup" rules are as follows: - If the name is valid according to the rule in the previous item, do nothing. - Otherwise, replace any non-printable or "quotation" character with an underscore ('_'). - Add the extension for the file type from the Enclosure/DB file. Thus, if a Word document is send with the filename D:\samp"foo.bar, the filename will become D__samp_foo_bar.doc Note that the fixup *may* result in a filename that is longer than some operating systems (e.g. MS-DOS or Macintosh) will accept, but it should be legal in other respects. Most importantly, most clients that depend on the extension to recognize file types will continue to work properly. In X.400 messages, the filename is carried as part of the newly defined File Transfer Body Part. As with MIME, the oversimplified description is that if a filename is supplied it is fixed up as necessary, and included in a File Transfer Body Part, otherwise the attachment is sent according to MailWorks' original rules. In this fallback case, attachments may be sent as General Text as a FAX bodypart, or a bilaterally defined bodypart, etc. Many binary files will be sent as an Externally Defined Body Part (also called BodyPart 15). To be more precise: * If the MAILworksrc parameter sendFTBP is FALSE, all bodyparts will be sent according to MailWorks' original rules, which generally means that cover memos will be sent as text, and binary attachments are sent as Externally Defined Body Part. The default for sendFTBP is TRUE, which means that MailWorks will attempt to send bodyparts using File Transfer Body Part, with the following qualifications. * If the cover memo is text, it will not be sent as File Transfer Body Part and hence, will have no title or filename. This is how most clients expect cover memos to be presented. * If the cover memo is Rich Text Format, it will be sent as File Transfer Body Part with a name of "cover.rtf", so that clients that rely on the filename extension will recognize it as rtf. * If an attachment does not have a filename, it will be sent according to MailWorks' original rules. * If the MAILworksrc parameter validateBPFileNames is set to TRUE, and the extension of the filename does not match the extension recorded in the Enclosure/DB file, then the file will be sent as an Externally Defined Body Part. The default for validateBPFileNames is FALSE, which means that the filename supplied by the originating client will be used. * If validateBPFileNames is FALSE (the default), and the MAILworksrc parameter fixupBPFileNames is TRUE (the default), then the filename supplied by the originating client will be "fixed up" if necessary, then used. The "fixup" rules are as follows: - If the name is valid according to the rule in the previous item, do nothing. - Otherwise, replace any non-printable or "quotation" character with an underscore ('_'). - Add the extension for the file type from the Enclosure/DB file. Thus, if a Word document is sent with the filename D:\samp"foo.bar, the filename will become D__samp_foo_bar.doc Note that the fixup *may* result in a filename that is longer than some operating systems (e.g. MSDOS or Macintosh) will accept, but it should be legal in other respects. Most importantly, most clients that depend on the extension to recognize file types will continue to work properly. Note that if you set sendFTBP to TRUE, you should confirm that you are using at least version 2.0 of MAILbus400. Earlier versions do not support the File Transfer Body Part, and you will find a number of error number 6 reported in the x488glogs, and any message with an attachment will fail to deliver. If you are using an older verion of MAILbus400, you should set sendFTBP=FALSE. In all cases when a message is received (either through SMTP or X.400) with a filename, the filename is stored with the message and made available to any client reading the message. When a message with filenames on the bodyparts is read from the Motif client, the list of filenames will be visible as a header field. If you feel that this will be distracting to users, you can set the MAILworksrc parameter hideBodyPartNames to TRUE to hide the display of this attribute in the Motif client only. The default value is FALSE, meaning that the names will be visible. ISO Latin 2 ----------- It is now possible to configure MailWorks to use ISO Latin 2 as its internal character set, rather than ISO Latin 1. This is accomplished by setting the MAILworksrc parameter useISOLatin2 to TRUE. When this is set to TRUE, then the ISO Latin 2 (ISO 8859-2) character set will be used when mapping characters from the Teletex (T.61) character set when receiving Teletex X.400 fields. This affects such fields as Subject, Free Form Name, and other address fields such as Common Name, Surname, Organizational Unit. When sending a message over X.400, characters in Subject and Free Form Name will be properly mapped from ISO Latin 2 to the Teletex character set; other fields will continue to be encoded as Printable String. If you will be using SMTP and MIME, you should also modify the MIME send and receive maps to reflect this change. In the file .dmw_mime_send_map, you should change the entry: PlainText:quoted-printable text/plain; \ charset=ISO-8859-1; \ Type=Text to PlainText:quoted-printable text/plain; \ charset=ISO-8859-2; \ Type=Text In the file .dmw_mime_receive_map, you should change the two entries: PlainText text/plain; charset=ISO-8859-1 TextIso8859-2 text/plain; charset=ISO-8859-2 to TextIso8859-1 text/plain; charset=ISO-8859-1 PlainText text/plain; charset=ISO-8859-2 Control elimination of duplicates --------------------------------- MailWorks contains a feature (informally called "de-duping") which eliminates duplicate incoming messages. This feature can be useful when communication with an MTA is unreliable - when the MTA transfers a message to MailWorks, if it cannot confirm that MailWorks has properly received the message, it may resubmit the message to guarantee that it was received. If MailWorks attempts to deliver a message to a user's inbox, and finds a message with the same message ID, the same number of bodyparts, and finds that the content of those bodyparts is identical (it actually compares all bytes of every bodypart), then the second message is simply discarded. If you are uncomfortable with this behavior and would prefer to have the duplicate messages delivered to users' inboxes, you can set the MAILworksrc parameter deliverDuplicates to TRUE. The default value for this parameter is FALSE, which causes the server to continue to eliminate duplicates on delivery. Note that MailWorks will continue to eliminate duplicate recipients in the TO list of an outbound message. This might occur, for instance if you use two overlapping distribution lists. This behavior is not controlled by the deliverDuplicates parameter. Start/Stop scripts ------------------ A number of changes have been made to the startMAILworks and stopMAILworks scripts for smoother and more reliable operation. startMAILworks The startup script startMAILworks now will: - Verify that the script is run from the root account. - Verify that no other MailWorks processes are running. - Wait a configurable amount of time between starting the msr and starting all other processes. The first action of most MailWorks processes is to connect to the msr process. If the msr takes a particularly long time to start, e.g. if it needs to load a very long list of aliases, then the other servers can fail in their connection to the msr. Each server will report this problem in its log file. To solve this problem, the environment variable, startupMSRSleepTime, has been added to the MAILworksrc file. By default, each process that needs to wait for the msr will wait 35 seconds. This variable may be modified to wait a longer or shorter amount of time based on a customer's configuration. The value for this environment variable is represented in seconds. (To be precise, the startMAILworks script will actually start these processes immediately, but the process itself will wait startupMSRSleepTime before attempting to connect to the msr.) stopMAILworks The shutdown script for MailWorks has been modified. The following modifications have been made: - deferd processes will now be terminated (note that starting with ECO2, these messages are still on a queue, so stopping the deferd processes will not result in a loss of messages.) - By default, the shutdown script will wait, an unlimited amount of time, for all MailWorks processes to terminate. A new environment variable, shutdownWaitTime, has been added to the MAILworksrc file to modify this new behavior. If a customer does not want to wait an indefinite length of time for MailWorks to shutdown, shutdownWaitTime should be set to the maximum number of minutes the shutdown script should wait for MailWorks to shutdown. Zero represents waiting an unlimited amount of time. Other Usage Notes ================= Single msr process ------------------ If you will be using a single msr supporting several machines, then when you run DMW-add on the machines that are not running the msr, you will be given an error message. After the DMW-add completes, you should go to the machine running the msr, and enter the following commands from the root account: #ali -global newaccountname node:fullpath #confpref newaccountname -mail_dir directorypath where: "newaccountname" is the MailWorks alias name for the new account, "node" is the node on which the user's account is stored, "fullpath" is the full path specification (including the file name) for the user's primary message store (usually, this is /usr/users/newaccountname/dmw/newaccountname.po), and directorypath is the path of the directory containing the user's message store (e.g. /usr/users/newaccountname/dmw): Valid SMTP addresses -------------------- If an SMTP address is entered with spaces around the @ (as in "President @ Whitehouse.gov"), this will be interpreted by sendmail as two different addresses ("President" and "Whitehouse.gov"). In most cases, this is not what you intend, and the message will be non-delivered, or will be delivered to the wrong local account. To avoid this, simply enter SMTP addresses without spaces. Quotes on SMTP addresses ------------------------ When TeamLinks clients are used with MailWorks for UNIX, SMTP addresses must be enclosed in quotes. (Without the quotes, the TeamLinks clients interpret the address as a Message Router address, and pre-parse the address in a way that causes the server problems.) Because it is easy for users to forget to include the quotes, you may want to customize the TeamLinks clients to automatically insert the quotes when they detect an SMTP-style address. In TeamLinks for Windows, go to Setup, pick Mail Profile, then addressing. Click on Customize Addressing, and type a double quote (") into the fields "Prefix to add" and "Suffix to add". You should also add the character > to the field "Disqualifying Characters". In TeamLinks for Macintosh, version 2.6 and later, use ResEdit to modify TeamLinks Mail (DMW). Edit resource STR# 130 and add a quote to string 1 (which is the suffix string) and string 5 (which is the prefix string). Note that prior to version 2.6, TeamLinks would attempt to double-quote your prefix and suffix strings, which meant that you would get three quotes, which did not work properly for this purpose. For both clients, you can make this customization *before* the client is installed, so that it can be done only once, rather than on every individual desktop. See the individual client documentation for details (e.g. for the Macintosh, this is described in the Troubleshooting Guide that is installed with the client). Moving Message Stores --------------------- When a message store is open, you cannot move, rename, delete or recreate that message store without causing corruption to the data in the message store. A message store may be open because a user has connected to that message store, or because a message has recently been delivered to that message store. A message store can also be open because a client machine has requested notification of delivery of new mail. Finally, a message store is held open for approximately 10 minutes after the last client closes it as a performance optimization (to avoid the cost of an open in case a new message arrives for that message store). If you need to move, rename, delete or recreate a message store, you should force it to be closed by using the confddb command with the -disable option to disable that message store. POP3 Clients ------------ Because of the sheer number of POP3 clients, we are unable to test all of them with MailWorks. We have tested with a number of the more popular clients, and expect that most POP3 clients will work properly with MailWorks. However, some clients depend on support for UIDL (an optional feature that has not yet been implemented in MailWorks) to support the "leave message on server" option - with these clients, you can retrieve messages from the server, but they will be deleted from the server as part of that retrieval. The following POP3 clients have been tested with MailWorks: Client Supports "Leave on Server" ------------------------------------------------- Netscape V2 No Netscape V3 Yes Eudora Pro Yes Eudora Light Yes QuickMail No Calypso Yes Registering new data types -------------------------- Digital has created a branch of the tree of Object Identifiers for use by customers to identify types that have not been registered by Digital. The stem of this branch is 2B0C028773050A. The first 127 customer- registered types can be created by appending 2 hex digits in the range 00 through 7F to the stem listed above. Be aware that the rules for constructing ASN.1 Object Identifiers are complex, and cannot be described simply here. Do not attempt to assign types beyond 127 unless you understand those rules. Memory usage ------------ Virtual size of server processes Be aware that the virtual size of the mss process can be affected by a number of different factors, including both the number and the size of the message stores on the server. (Note that even if a user is not logged in, his or her message store can be active if it is receiving mail.) If you find that the virtual size of the mss process is becoming large, you can encourage users to empty their wastebaskets and remove any old or unneeded messages in their sent items folder. On the other hand, there is no particular problem if the virtual size of the mss is large, as long as the machine has sufficient swap space (check this with the command swapon -s), and the process is not exceeding a process size limit (see the next paragraphs). Under heavy load conditions, it is possible that the mss or mcs process can exceed the default operating system limit of 1 gigabyte per process. Customers should monitor the size of the mcs and mss processes, and if they begin to approach this limit, the operating system should be reconfigured to permit them to grow beyond 1 gigabyte in virtual size. Note that you should also ensure that your system has sufficient swap space to accommodate such a large process. We have seen systems exceed this limit when the system has a large number of subscribers, and each of those subscribers has retained a large number of messages in their wastebasket. In one case, the system had 1000 subscribers, of which only 200-300 were connected at a time, and the mss grew to 1.3 gigabytes. After cleaning up the wastebaskets, the size of the mss remained at around 400 megabytes. I'll provide a brief overview of the parameters involved below. For complete details, you should consult the System Tuning and Performance Management Guide (Order number AA-Q0R3B-TE). When a process is created, its initial maximum size is determined by the parameter per-proc-address-space (with a default size of 1 gigabyte). After creation, the process can increase its maximum size up to the value of the parameter max-per-proc-address-space (again, the default is 1 gigabyte). Because the MailWorks processes do not explicitly increase their maximum, their limit will always be determined by per-proc-address-space. The parameter vm-maxvas is an absolute upper bound on the virtual address space that any user process can have. This parameter is essentially the same as max-per-proc-address-space, except that it is limited to *user* processes. So, if you find that your mcs or mss process is approaching the 1 gigabyte limit, you should reset the values of each of these parameters, e.g. to 2 gigabytes. In addition, if you observe that the size actually does begin to exceed 1 gigabyte, you should also increase the parameters per-proc-data-size and max-per-proc-data-size, normally to the same limits. These parameters are all set in the file /etc/sysconfigtab - after making a change or addition to this file, you need to restart the system. (Note that it is *not* necessary to rebuild the kernel.) It is recommended that you use the system command sysconfigdb to modify this file. When modifying this file, you will need to know that the subsystem ID for the parameter vm-maxvas is vm, and the subsystem ID for the remaining parameters is proc. In summary, your additions to the sysconfigtab should look like the following: vm: vm-maxvas=2147483248 proc: max-per-proc-address-space=2147483248 max-per-proc-data-size=2147483248 per-proc-address-space=2147483248 per-proc-data-size=2147483248 Memory usage and process size ------------------------------ The MailWorks server processes, especially the mcs and mss process, tend to consume more virtual memory than people expect. To help you understand how the servers work, and what is normal, the following discussion describes first the virtual size of the processes, and then talks about the resident memory size of the processes. First: because of the way the threads system works, the MailWorks processes will never become smaller in virtual size (although the resident size will vary, depending on a variety of factors). This is a side effect of the design of the threads memory management mechanism: when one of the MailWorks server processes allocates memory, and then frees memory, the freed memory is held for the process to re-use when the process allocates memory again. Thus, while the memory is not used by the server process, it still occupies virtual memory. This results in a "high-water effect": when everything else is working properly, the virtual size of a server process will remain at its highest level. Expressed differently, the size of the server will tend to grow the first day, then will tend to level off, growing again only if it has a particularly demanding task to do (e.g. if it has to deliver a large message to every user on the system). While the mcs process typically reaches its high-water mark in the first day of usage, for some customers the mss process will sometimes continue to grow over the next couple of days - this is normal. In general, we expect the size of the mss process to stabilize within 3-4 days The previous paragraphs describe the ideal situation. Prior to ECO2, the mcs process had some significant memory leaks, that caused the process size to continue to grow on the second and subsequent days of use. This forced most customers to restart MailWorks every day or every two days. Starting with ECO2, the most significant leaks have been fixed, which in turn means that you can restart MailWorks significantly less often than previously. How often is it necessary to restart MailWorks? This depends on how large the processes get, how much real memory you have, and how much swap space you have. After installing ECO2, we recommend that you start by letting the system run one day longer than with your previous release - monitor the size of the processes and your usage of swap space. If you continue to have sufficient swap space (at least 20% free), then allow the system to run for an additional day, and continue to monitor the use of swap space and process sizes. If yours is a new installation, start by letting MailWorks run for a week, then as your users' activity level rises, continue to monitor the system to confirm that a weekly restart is sufficient. Finally, what affects the size of the mss process? The primary factors that affect the size of the process are the number of message stores that are open at one time, and the size of the folders that are opened in those message stores. A message store is opened by the mss when the user opens it from a client, when a message is delivered to that message store, or when a system manager opens the message store from the command line (using setpms). The message store is closed by the mss approximately 10 minutes after the user disconnects, or the message delivery is completed. When a TeamLinks client requests notification of new mail delivery, that will also cause the message store to be held open. While a message store is open, the server will cache information in memory for any folders that are opened. So, what can make the mss process grow significantly? 1) If a message is addressed to all users (or a large number of users) on the system, the server will need to open a large number of message stores at about the same time. If the users have large inboxes, this will drive the memory requirements even higher. 2) If folders that are accessed frequently, such as the Inbox, the Outbox, or the Wastebasket get very large, then this can raise the memory requirements of the mss server. If you encourage your users to keep these folders reasonably empty, this can reduce the demands on memory. 3) If the system manager runs a script that uses the command line interface to open all message stores, then all message stores will be opened at the same time, at least temporarily. Special note to script writers: If your script simply uses the setpms command running as root user, then each execution of setpms will close previously opened message stores, which will allow the mss to actually close the message store after all other demands on the message store are complete. On the other hand, if the script switches users (using the su command) between executions of setpms, the Command Line Server cannot determine that the new setpms request has come from the same script. As a result, every message store will be held open until MailWorks is restarted. In addition to the extra demands on memory, this will increase the time it takes MailWorks to shutdown, and increases the chances of message store corruptions in case of an abnormal exit of MailWorks. In general we recommend against using su within such scripts; if you find it necessary, you should run such scripts when you will be able restart MailWorks after the completion of the script. Be sure to allow sufficient time for the mss process to finish - after opening *all* message stores, it can take a while to close them all. 4) If there is an unusually high level of incoming messages, then it is possible that many message stores will never reach the 10 minutes of inactivity, which in turn means that many of them will remain open. In this case, the number of message stores that is open can be considerably higher than the number of users who are connected to the server, and this in turn can drive the memory requirements up. Note: after all clients of a message store have disconnected from it, the mss will begin to close that message store after about 10 minutes, but in exceptional cases, it can take the mss 15 minutes to a half hour to completely close all of them even on an idle system. On a busy system, it can take much longer, since the closing is done as a lower-priority background activity. ------------------ So much for *virtual* size - what about the real memory demands of the server processes (also called the resident memory size). Clearly the real memory demands of the server are much less than the virtual demands - this is the very nature of a virtual memory system. Another thing to understand is that the actual resident memory size of the servers will go up and down with other demands on the system - the virtual memory system will tend to balance the needs of the MailWorks processes for memory with the needs of other processes on the system; it would not be surprising if the resident memory size of the MailWorks processes actually grew at times when they were relatively idle, if other demands on the system were low at the same time. In general, we recommend 1/3 to 1/2 of a megabyte of real memory for every connected user - this assumes that about 1/4 of the users with accounts are connected. If the fraction of connected users is smaller, which means that for every connected user there are more than 3 unconnected users, you may need more memory per connected user. (This is because the message stores for some of those "inactive" users may still be open in order to deliver incoming mail.) If you have a very active system, you may also need more physical memory than the general rule. During your system's peak time, you should monitor the system performance - you may need to add more physical memory if your system slows down noticeably during peak system times, and if vmstat shows that it is doing excessive paging at those times. There is no simple rule for what is "excessive" paging (since it depends a lot on the speed of your disks, how many devices you are using for swap space, and your tolerance for a slow system). However, we have seen systems that were performing quite well with paging on the order of 10-15 per second. Interworking with Microsoft Exchange ------------------------------------ If you will be exchanging mail between a Microsoft Exchange server and a MailWorks for UNIX server, you can either use SMTP and the Exchange Internet Mail Connector, or MAILbus400 and Exchange's X.400 Connector. 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. 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. When using X.400 to communicate between MailWorks and Exchange, you should configure MAILbus400 to convert text bodyparts to IA5Text in messages transferred to the Exchange domain. In addition, you should configure MailWorks to use File Transfer Bodyparts to encode files for which a filename is available: set the MAILworksrc parameters sendFTBP to TRUE. The extension on the filename is important to Exchange to recognize the file type. The following sample ncl scripts set up MAILbus400 to use TCP and RFC1006 to communicate with an Exchange domain called EXCHANGEDOMAIN: ------------ create mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"] set mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"] - application context mts transfer set mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"] - presentation address """MTA""/""MTA""/""MTA""/RFC1006+16.31.999.999,RFC1006" ! Note that the TCP address above is the address of the Exchange server set mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"] - local name = "MailWorks-mta" , - local password [type=ia5, ia5 string="MailWorksPassword"] ! The local name and password supplied here are also entered into Exchange ! as the Remote MTA Name and Remote MTA password. set mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"] - peer name = "EXCHANGEDOMAIN", - peer password [type=ia5, ia5 string="ExchangePassword"], - peer domain "EXCHANGEDOMAIN" set mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"] - trace on, - archive INBOUND AND OUTBOUND enable mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"] ----------- ! ! Commands to create the 'MailWorks' domain entry. ! CREATE MTS "/C=US/O=DEC/OU=ZKO/MTS=MailWorks-MTS" DOMAIN "EXCHANGEDOMAIN" - DIFFERENT CCITT DOMAIN = TRUE SET MTS "/C=US/O=DEC/OU=ZKO/MTS=MailWorks-MTS" DOMAIN "EXCHANGEDOMAIN" DESCRIPTION - "The MailWorks routing domain; direct connection" SET MTS "/C=US/O=DEC/OU=ZKO/MTS=MailWorks-MTS" DOMAIN "EXCHANGEDOMAIN" - ROUTING INSTRUCTION [ACTION=TRANSFER TO DOMAIN, - BOUNDARY MTA="MailWorks-mta"] ! ! Create the partial routing instruction to send mail to Exchange. ! CREATE MTS "/C=US/O=DEC/OU=ZKO/MTS=MailWorks-MTS" ORADDRESS - "C=US; A=TAN; P=EXCHANGEDOMAIN" SET MTS "/C=US/O=DEC/OU=ZKO/MTS=MailWorks-MTS" ORADDRESS - "C=US; A=TAN; P=EXCHANGEDOMAIN" ROUTING INSTRUCTION - [ACTION=TRANSFER TO DOMAIN, SERVER DOMAIN = "EXCHANGEDOMAIN"] ! ! This says that Exchange accepts any content type and the ! IA5Text EIT ({2 6 3 4 2}). The "any" EIT following the IA5Text one says ! send bodyparts as-is if can't convert them to IA5Text. ! SET MTS "/C=US/O=DEC/OU=ZKO/MTS=MailWorks-MTS" ORADDRESS - "C=US; A=TAN; P=EXCHANGEDOMAIN" - CONTENT INFORMATION [MAXIMUM CONTENT LENGTH = 0, CONTENT TYPES = - ("{1 3 12 2 1011 5 5 0 0}"), ENCODED INFORMATION TYPES = ( - "{2 6 3 4 2}", "{1 3 12 2 1011 5 5 1 0}")] ---------- When configuring the Microsoft Exchange server, in the Advanced Options for the X.400 connector, we suggest the following choices: * Enable "Allow BP-15" * For "MTA conformance", choose 1988 normal mode. * For "X.400 bodypart used for message text", choose IA5. Copyright (c) Digital Equipment Corporation 1998. All Rights reserved. This software is proprietary to and embodies the confidential technology of Digital Equipment Corporation. Possession, use, or copying of this software and media is authorized only pursuant to a valid written license from Digital or an authorized sublicensor. This ECO has not been through an exhaustive field test process. Due to the experimental stage of this ECO/workaround, Digital makes no representations regarding its use or performance. The customer shall have the sole responsibility for adequate protection and back-up data used in conjunction with this ECO/workaround.