MAILbus 400 Message Transfer Agent and Application_Program_Interface_________________ Release Notes for Tru64 UNIX Revision/Update Information: Version 3.0 COMPAQ Computer Corporation Houston, Texas __________________________________________________________ Compaq Computer 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 COMPAQ or an authorized sublicensor. No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Compaq Computer Corporation or its affiliated companies. No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Compaq Computer Corporation or its affiliated companies. © 1992, 2002. All Rights Reserved. The following are trademarks of COMPAQ Information Technologies Group, L.P.: ALL-IN-1, DECdx, DECnet,LinkWorks, MAILbus, MailWorks, Message Router,OpenVMS, VAX, VAX DOCUMENT, WPS-PLUS and the COMPAQ logo. Microsoft and Microsoft Exchange are registered trademarks of Microsoft Corporation. Microsoft Exchange Server is a trademark of Microsoft Corporation. OSI is a registered trademark of CA Management, Inc. UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company Ltd. X/Open is a trademark of the X/Open Company Limited. All other trademarks and registered trademarks are the property of their respective owners. This document was prepared using VAX DOCUMENT, Version 2.1. ________________________________________________________________ Contents Part I Introduction 1 Introduction.................................... 3 2 Structure of the Release Notes.................. 3 Part II Installing Version 3.0 and Changes Introduced in Version 3.0 3 Installing Version 3.0.......................... 7 4 Differences Between Version 3.0 and Version 2.0C ................................................ 10 4.1 Secured Distribution List .................... 10 4.2 MTA Filter Mechanism ......................... 10 4.3 Maximum Content length check ................. 11 4.4 MTA generates unique names for upgraded FTBP attachments................................... 11 4.5 The Non-DEC OID bodypart translation failure....................................... 12 4.6 MTS replication problem is resolved .......... 12 4.7 MTA no longer crashes while decoding IPM extensions.................................... 12 4.8 Forced Exit in the Relayer Region ............ 12 4.9 Certified on Multi-CPU machines .............. 12 4.10 MTA now supports 256 parallel agent connections................................... 12 4.11 X.500 Directory service relocation ........... 13 4.12 NCL restrictions on large distribution lists......................................... 13 4.13 Domain name missing in accounting logs ....... 13 4.14 Outbound message stalls resolved ............. 13 iii Part III Restrictions and Documentation Errors 5 Restrictions in DECnet/OSI for Tru64 UNIX....... 17 5.1 X.500 Directory service Restrictions ......... 17 5.2 CML process crashes with "Process Error" and NCL dumps core for distribution list more than 320 enteries.................................. 17 5.3 Defining Transport Classes in the Transport Template Entity mta_any....................... 18 5.4 NCL Restrictions ............................. 19 5.4.1 Limited NCL Command Buffer Size............ 19 5.4.2 Filtering Multi-Valued Attributes Using NCL........................................ 20 6 Product Restrictions............................ 20 6.1 Restrictions in the MAILbus 400 MTA .......... 20 6.1.1 Teletex Characters in Routing Domain Names...................................... 20 6.1.2 Label for Extended Network Address......... 21 6.1.3 Maximum Attribute Length Not Checked for Directory Entries.......................... 21 6.1.4 Using the Recover Command.................. 21 6.2 Restrictions in Japanese Bodypart Converters.................................... 21 6.2.1 Control Codes and Escape Sequences......... 22 6.2.2 User Defined Characters.................... 22 6.3 Restrictions in the MAILbus 400 API .......... 22 6.3.1 Use of ma_wait and mt_wait................. 22 6.3.2 Remote Client Connections Using CONS....... 23 6.3.3 No Support for Multi-Threaded Environments............................... 23 6.3.4 Using om_encode and om_decode to Encode and Decode Objects............................. 23 6.3.5 Mandatory Fields on Delivery Envelope for Forwarded Message.......................... 23 6.3.6 OM_NETWORK_ERROR When Application Passes Invalid Data............................... 23 6.3.7 om_instance Only Works for Service-Generated Objects.................. 24 6.3.8 OSI Transport Not Available if You Link Against Archive Libraries.................. 24 6.3.9 Single-Process MAILbus 400 Application Cannot Use XDS if Linked Against Archive iv Libraries.................................. 24 6.3.10 1992 Changes Not Implemented in MAILbus 400 API........................................ 24 7 Errors in the Documentation..................... 25 7.1 MAILbus 400 API Documentation ................ 25 7.1.1 Error in Section 3.3.1 of Programming Guide...................................... 26 7.1.2 Addition to Internal Trace Entry Description in Chapter 8 of Programming Guide...................................... 26 7.1.3 Correction to Description of mtX_open ..... 26 7.1.4 Multi-Valued Attributes.................... 27 Part IV Background to Previous Kits 8 Documentation Provided ......................... 31 8.1 With the MAILbus 400 MTA ..................... 31 8.2 With the MAILbus 400 API ..................... 32 9 Differences between Version 2.0C and Version 2.0B............................................ 32 9.1 Multi-CPU Support ............................ 32 9.2 Broken Pipe .................................. 32 9.3 MTA now supports 256 parallel agent connections................................... 33 9.4 New MTS MSL provided ......................... 33 10 Difference between Version 2.0B and Version 2.0A............................................ 33 10.1 Year 2000 Ready .............................. 33 10.2 Readers Comments ............................. 33 11 Changes Introduced in Version 2.0A.............. 34 12 New Features in Version 2.0..................... 38 12.1 For the MAILbus 400 MTA Version 2.0 .......... 38 12.1.1 New Converters ............................ 38 12.1.2 File Transfer Bodyparts.................... 39 12.1.3 MTAmail.................................... 40 12.1.4 mta_api_server_address..................... 40 12.1.5 MTA Startup Script and Startup Time ....... 40 12.2 For the MAILbus 400 API Version 2.0 .......... 41 12.2.1 MTAmail.................................... 41 13 Upgrading....................................... 41 13.1 Upgrading the Compaq X.500 Directory Service....................................... 41 14 Interworking.................................... 42 v 14.1 Interworking with Microsoft Exchange Server .. 42 14.2 Interworking with the VAX Message Router X.400 Gateway....................................... 43 vi Part I ________________________________________________________________ Introduction This part provides a brief introduction to the products and describes the structure of these Release Notes. 1 Introduction These Release Notes provide information relating to both the MAILbus[TM] 400 Message Transfer Agent (MTA) and the MAILbus 400 Application Program Interface (API). The MAILbus 400 MTA provides X.400 message transfer services to client applications such as User Agents and Gateways. The MAILbus 400 MTA is an MTA conforming to the CCITT 1988 X.400 Recommendations and International Standard ISO/IEC 10021, plus the revisions and recommenda- tions that form the 1992 editions of the X.400 standards. The MAILbus 400 API is a callable interface that can be used to build applications that access the MAILbus 400 MTA and use its message transfer service. 2 Structure of the Release Notes These Release Notes are divided into four parts: o Part I provides a brief introduction to the products and describes the structure of these Release Notes. o Part II describes the changes introduced in V3.0 of the MAILbus 400 MTA. There is no change for MAILbus 400 API in this kit. o Part III lists the restrictions and documentation errors that apply to Version 3.0 and previous kits. o Part IV provides background information about previous kits. This information was available in the Release Notes for previous kits. It includes the following: - The documentation provided with the products - Differences between Version 2.0C and Version 2.0B - Differences between Version 2.0B and Version 2.0A - Changes for the Version 2.0A release of the products - New features for the Version 2.0 release of the products - Upgrading information - Interworking information 3 Part II ________________________________________________________________ Installing Version 3.0 and Changes Introduced in Version 3.0 This part is divided into two main sections, as follows: o Section 3 describes how to install Version 3.0 of the MAILbus 400 MTA and API. o Section 4 describes the differences between Version 3.0 and Version 2.0C of the MAILbus 400 MTA. 3 Installing Version 3.0 To install this kit follow the instructions in MAILbus 400 MTA Installing on a Tru64 UNIX System or MAILbus 400 API Installing on a Tru64 UNIX System, with the following exceptions: o Make sure you install one of the following configura- tions of prerequisite software: - Tru64 UNIX V4.0G DECnet-Plus for Tru64 UNIX V4.0C or later Compaq X.500 Directory Service for Tru64 UNIX (Base Subset)V4.0.25 or Compaq Tru64 UNIX Enterprise Directory V5.0, V5.1, V5.2 - Tru64 UNIX V5.0, V5.1, V5.1A DECnet-Plus for Tru64 UNIX 5.0-1 or later Compaq X.500 Directory Service for Tru64 UNIX (Base Subset)V4.0.25 or Tru64 UNIX Enterprise Directory V5.0, V5.1, V5.1A Note1: Due to limitation in the Schema supplied with X.500 Directory service V4.0-25 not all features within V3.0 of the MTA are available with this version of directory (Refer to section 13.1) Note2: If your system is running DECnet V4.0C, V5.0-1, V5.0A-1 or V5.1 you need to install the "libdnamgmt.so" DECnet patch. For more details please refer to section 5.2. o The command to deinstall any MAILbus 400 MTA or API subsets already installed on your systems is one of the following: # setld -d MTAABASE14? MTAASRVR14? MTAANETMAN14? MTABCLNT14? MTABMAN14? # setld -d MTAABASE2?? MTAASRVR2?? MTAANETMAN2?? MTABCLNT2?? MTAAMAN2?? The question mark (?) in subset names is a wildcard character. 7 o The approximate disk space required (in Kilobytes) for each of the MAILbus 400 MTA and API subsets in /usr /opt and /var/opt, and the corresponding softlinks for the files in /usr and /var are shown in the following table. ________________________________________________________________ Space Required Subset Title Subset Name (in kB) _______________________________________________/usr_______/var__ MAILbus 400 MTA Mgt (Tru64 MTAANETMAN300 1800 80 UNIX) MAILbus 400 MTA Server MTAASRVR300 29900 120 (Tru64 UNIX) MAILbus 400 MTA Base (Tru64 MTAABASE300 4400 70 UNIX) MAILbus 400 API (Tru64 UNIX) MTAACLNT300 11000 minimal MAILbus 400 API Reference MTAAMAN300 200 minimal Pages_(Tru64_UNIX)______________________________________________ o The installation instructions are: 1. Mount the disk as follows: # mount -r /dev/cdrom-device-name /mnt where cdrom-device-name is the name of your CDROM device special file, usually rz4c. 2. Load the subsets as follows: For the MTA: # setld -l /mnt/mtaa300/kit For the API: # setld -l /mnt/mtax300/kit When you deinstall the MTA, the MTA startup script ( /var/mta/scripts/start_mta.ncl) is renamed to /var/mta /scripts/start_mta.ncl.savn, where n is a number. The MTA installation procedure installs a new template /var/mta /scripts/start_mta.ncl file. After the subsets have been successfully installed, reapply your saved changes to the new copy of the start_mta.ncl file. 8 For the MAILbus 400 API, if you are using the archive libraries on Compaq UNIX, you will need to relink your application after you have installed Version 3.0. The version number of this kit when displayed using NCL management is V3.0.0. To identify this kit, type the following command: what /usr/sbin/mta/mta | grep MAILbus The following is the response from this command: MAILbus 400 MTA (V3.0-0) Aug DD hh:mm:ss IST 2002 Ex: MAILbus 400 MTA (V3.0-0) Wed Aug 03 11:23:45 IST 2002 Be aware that if you have installed Version 3.0 of the MTA on a version of Compaq UNIX prior to V4.0G and want to upgrade Compaq UNIX to V4.0G (or later), you must deinstall and then reinstall Version 3.0 of the MTA before you run Version 3.0 on the upgraded Compaq UNIX system. If you fail to do this and attempt to run the MTA without deinstalling and reinstalling it on Compaq UNIX V4.0G(or later), the MTA reports a Forced Exit event accompanied by a System Interface Error event when you try to start the MTA, as follows: Event: System Interface Error from: Node nodename MTA at : 1997-08-01-11:04:05.822+00:00I0.279 System Interface Error = Process Creation Parameter = "Reinstall MTA for this UNIX version" Error Text = "Version mismatch" Event: Forced Exit from: Node nodename MTA at : 1997-08-01-11:04:05.839+00:00I0.279 Exit Point = Management Agent If you see this error, deinstall Version 3.0 and then reinstall Version 3.0. You can do this after you have upgraded to V4.0G(or later) of Compaq UNIX.. 9 4 Differences Between Version 3.0 and Version 2.0C 4.1 Secured Distribution List Using distribution lists, senders can broadcast messages to a large number of users. This could lead to congestion of the message transfer system if used maliciously or without proper care. In order to address this problem, the distribution list entity has been modified to include two new attributes: "DL restriction" is set to either true or false. To restrict the usage of the list, this field is set to true. "Authorized Users" is a multi-valued attribute that allows the administrator to register the originators that can send mails to the distribution list. While processing the message, the MTA performs the directory lookup on distribution list object to read the "Authorized Users " attribute. If the originator's O/R address is a member of this attribute, the MTA processes the message.if the originator's address is not found in this attribute, an NDN will be returned to the originator. More details on these two attributes can be found in the NCL online help. 4.2 MTA Filter Mechanism The MTA now provides the option to mark a message transfer domain as "secure". A secure domain will accept messages only from "secure" originators. A target domain can be marked "secure" by setting to True, one of two new attributes, "Secured deliver" and "Secured transfer to domain". These attributes are part of the Routing Instruction in the domain's partial O/R address. An originator O/R address (or partial address) can be marked "secure" by setting the new attribute, "Authorization". This attribute is part of the origi- nator's O/R address entity. All these new attributes are Boolean, and are set to either True or False. If the attributes are not present, the value is assumed to be False. 10 While processing a message, if the MTA finds that the target domain has a routing instruction with either "secured deliver" or "secured transfer to domain" set to True, it performs a directory lookup on the originator O/R address (complete or partial) for the "Authorization" attribute. If this is True, the MTA processes the message. If False, the MTA sends an NDN to the originator. Further information is provided in the NCL online help. 4.3 Maximum Content length check Before the MTA delivers a message to a recipient, it checks the recipient's O/R address for the "content length limit" attribute. If the attribute is present, then the MTA delivers the message only if the message is within this limit. Otherwise the MTA sends an NDN to the originator. This feature has now been extended to message "transfer" between domains i.e., while the MTA relays a message on to a Peer MTA. If the message size exceeds the value specified in the recipient O/R address for the target Peer Domain, then the MTA sends an NDN to the originator of the message. 4.4 MTA generates unique names for upgraded FTBP attachments When the MTA upgraded 1988 Externally Defined Bodyparts (BP15) to 1992 File Transfer Bodyparts (FTBP), it would generate the filename "ATTACH.ext" for the FTBPs. "ext" is a 3-letter extension depending on the bodypart type. The MTA now generates unique names for such FTBPs. The first attachment is named "A0000000.ext". The second attachment is then named "A0000001.ext". "ext" is still a suitable 3-letter extension based on the bodypart type. If the MTA does not know the bodypart type, the 3-letter extension used is ".DAT". 11 4.5 The Non-DEC OID bodypart translation failure Earlier versions of the MTA would fail on bodypart translation from 1992 File Transfer Body Parts to BP14 Bilateral Bodyparts, if the FTBP OID were missing from the MTA's mapping table. The failure was also seen with translation from 1988 BP15s to BP14s. This problem has been solved with the MTA V3.0. 4.6 MTS replication problem is resolved After creating an X.500 object (eg. An "O/R address") on the replica node in master-replica X.500 DSA setup, the NCL SET MTS command on that object would fail on the replica node. This problem has been resolved with the MTA V3.0. 4.7 MTA no longer crashes while decoding IPM extensions The MTA would produce an access violation while decoding certain types of "IPMS Extensions". This problem has been resolved. 4.8 Forced Exit in the Relayer Region The MTA V3.0 fixes the problem of forced exit in the relayer region. This problem has been fixed by adding extra delay at strategic points. 4.9 Certified on Multi-CPU machines The MAILbus 400 MTA and API has been successfully tested on multiple CPU machines running Compaq UNIX Version 4.0G and Compaq Tru64 UNIX V5.0. 4.10 MTA now supports 256 parallel agent connections The MTA supports up to 256 parallel agent connections. This means up to 256 agents (including Gateways) can be concurrently served by the MTA. 12 4.11 X.500 Directory service relocation Earlier versions of the MTA could not continue working with an X.500 DSA, if the DSA were relocated while the MTA was running. A restart of the MTA was required. Now the MTA identifies a relocated DSA, and continues working without requiring a restart. 4.12 NCL restrictions on large distribution lists The MTA was earlier unable to display very large lists in response to an NCL query. This problem has been resolved now. 4.13 Domain name missing in accounting logs The MTA would, under certain conditions, not log the domain name for "Transfer In" entries in the accounting logs. This problem has been resolved now. 4.14 Outbound message stalls resolved Under certain high message traffic conditions, message flow out of the MTA would stall. Inbound messages were not affected. The outbound stalls would happen because the MTA on UNIX wouldn't immediately close OSAK ports after use, but would rely on idle time closures within the OSAK software. This would sometimes result in message stalls, because not enough OSAK ports were readily available. This problem has been resolved by closing OSAK ports immediately after use. Note that this problem does not occur with the MTA on Open VMS. 13 Part III ________________________________________________________________ Restrictions and Documentation Errors This part lists the restrictions and documentation errors that applies to Version 3.0 and previous kits, as follows: o Restrictions within DECnet/OSI that affect the MAILbus 400 MTA (see Section 5). o Product Restrictions (see Section 6). o Errors in the Documentation (see Section 7). 5 Restrictions in DECnet/OSI for Tru64 UNIX The MAILbus 400 MTA is an application layered on DECnet[TM]/OSI[R] for Compaq Tru64 UNIX. Some restrictions in DECnet/OSI for Compaq Tru64 UNIX can affect the behavior of the MAILbus 400 MTA. It is therefore helpful to be aware of DECnet/OSI restrictions, as listed in the DECnet/OSI for Tru64 UNIX Release Notes. The following sections list additional restrictions in DECnet/OSI for Tru64 UNIX that affect the MAILbus 400 MTA. 5.1 X.500 Directory service Restrictions Due to limitations in the schema supplied with Compaq Enterprise Directory V4.0-25, not all the new features of the MTA V3.0 are available with it. if you are using X.500 Compaq Enterprise Directory V4.0- 25 you can update the schema by manually recompiling it. Section 13.1 describes manual compilation of the schema. Alternatively you can upgrade to X.500 Compaq Enterprise Directory V5.0 or later, so that all the features of MTA V3.0 can be used. 5.2 CML process crashes with "Process Error" and NCL dumps core for distribution list more than 320 enteries. The CML process on DECnet versions V4.0C, V5.0-1, V5.0A-1, V5.1 crashes while creating/setting any oraddress entity with routing instruction as: ncl> set mts "/mts=mysore" oraddress "c=in;a=test" rout inst [action=secured deliver, server mta="test", agent="test"] PROCESS ERROR:Connection lost: remote side disconnected link. The NCL process gives memory fault core dump for show commands with more than 320 members in the distribution list. ncl> show mts "/mts=duet" OrAddress "C=in; A=vsnl; P=deil; O=idc; _ncl> CN=dl" all Node 0 MTS "/mts=duet" OrAddress "C=in; A=vsnl; P=deil; O=idc; CN=dl" Identifiers Name = "C=in; A=vsnl; P=deil; O=idc; CN=dl" 17 Characteristics Type = Distribution List Members = { "C=in; A=vsnl; P=deil; O=idc; CN=user1" , . . "C=in; A=vsnl; P=deil; O=idc; CN=user340" } Memory fault(coredump) These bugs have been resolved with a DECnet patch for shared library - libdnamgmt.so. This patch can be down- loaded via anonymous FTP to netrix.xpr.eds.vendors.cpqcorp.net from: /patches/osf1/V4.0C/libdnamgmt.so.v40C.5Aug2002.gz /patches/osf1/V5.0B/libdnamgmt.so.v50B.5Aug2002.gz /patches/osf1/V5.1/libdnamgmt.so.v51.5Aug2002.gz The patch can be identified by the patch string "patch #869 for MTA buffer overflow". This can be determined by #strings /usr/shlib/libdnamgmt.so.vxxx.5Aug2002.gz|grep patch This file must be copied to the "/usr/shlib" directory as libdnamgmt.so. No restart of the MTA or of DECnet is needed after the copy. 5.3 Defining Transport Classes in the Transport Template Entity mta_any The OSI Transport Service can use the following transport protocol classes: o OSI Transport Protocol Class 0 (TP0) o OSI Transport Protocol Class 2 (TP2) o OSI Transport Protocol Class 4 (TP4) However, due to a restriction in the Transport Service, only two of the three requested classes can be used by the Transport Service when accepting incoming transport connections. 18 The MTA uses the Transport Template entity "mta_any" for inbound communications. This Transport Template entity describes the Transport protocol classes that the MTA can accept, that is, TP0, TP2 and TP4. To ensure that the MTA uses the same two classes in a predictable manner, you should set up the Transport Template entity "mta_any" with two transport classes and not three. 5.4 NCL Restrictions The following subsections describe restrictions in NCL that have an impact on the MAILbus 400 MTA. 5.4.1 Limited NCL Command Buffer Size The NCL command input buffer size is 2048 bytes. This limits the number of characters that can be entered in one NCL command. When you interactively enter a command of more than 2048 bytes, the NCL command fails. This restriction is especially relevant when you use the MTS module to create directory entries that have long attribute values, for example, long distribution lists. You are advised to create a distribution list with some members and subsequently add additional members to it using the ADD command, for example: CREATE MTS "/MTS=ACME" ORADDRESS - "C=NZ;A=NZ-PTT;P=ACME;O=ACME;CN=DIST-LIST1" - TYPE=DISTRIBUTION LIST, MEMBERS { - "C=NZ;A=NZ-PTT;P=ACME;O=ACME;OU1=WELL;CN=Clare Roberts", - "C=NZ;A=NZ-PTT;P=ACME;O=ACME;OU1=AUCK;CN=William Laurence", - "C=NZ;A=NZ-PTT;P=ACME;O=ACME;OU1=WELL;CN=Jane Underwood", - "C=NZ;A=NZ-PTT;P=ACME;O=ACME;OU1=AUCK;CN=Fred Smith" } ADD MTS "/MTS=ACME" ORADDRESS - "C=NZ; A=NZ-PTT; P=ACME; O=ACME; CN=DIST-LIST1" - MEMBERS { - "C=NZ;A=NZ-PTT;P=ACME;O=ACME;OU1=WELL;CN=Henry Petra", - "C=NZ;A=NZ-PTT;P=ACME;O=ACME;OU1=WELL;CN=Simon Prior", - "C=NZ;A=NZ-PTT;P=ACME;O=ACME;OU1=WELL;CN=Freda Turner", - "C=NZ; A=NZ-PTT;P=ACME;O=ACME;OU1=WELL;CN=Cathy Barnes" } 19 In addition, the NCL command output buffer size is 1024 bytes. This limits the number of characters that can be displayed in one NCL display. 5.4.2 Filtering Multi-Valued Attributes Using NCL You cannot use NCL to filter multi-valued attributes with certain types of filter attributes, for example, particular members of distribution lists (in the MTS module), or MPDUs for a particular target (in the MTA module). If you enter an NCL command that contains the "with" qualifier to filter these attributes, NCL responds as follows: FAILED IN DIRECTIVE: Show DUE TO: No Such Entity Instance Exists 6 Product Restrictions The following sections describe restrictions in the MAILbus 400 MTA and MAILbus 400 API that you need to be aware of. 6.1 Restrictions in the MAILbus 400 MTA This section lists known restrictions in the MAILbus 400 MTA. 6.1.1 Teletex Characters in Routing Domain Names You cannot use teletex characters in any part of the distinguished name that identifies the routing domain entry in the directory. As an example, you cannot enter /C=AU/O=MY_ORG/MTS=ACME, because the underscore (_) is a teletex character. If you do enter teletex characters in the distinguished name for the routing domain entry, the MTS entity returns the following message: command failed due to: process failure 20 6.1.2 Label for Extended Network Address There is a restriction in the MTS entity that means you cannot enter PSAP as the label for an Extended Network Address. 6.1.3 Maximum Attribute Length Not Checked for Directory Entries No checks are made on the maximum length of attribute values supplied when directory entries are created using the entities of the MTS module. It is therefore possible to create entries in the directory whose attributes might not be acceptable according to CCITT requirements. The use of unacceptably long attributes might result in problems when the MAILbus 400 MTA is interworking with messaging systems that implement the maximum attribute lengths strictly according to the CCITT X.400 Series of Recommendations. When creating entries in the directory, follow the attribute length restrictions indicated in the MAILbus 400 MTA documentation. 6.1.4 Using the Recover Command No warning message is issued when you use the Recover command and the peer MTA's workspace is not locked (refer to the MAILbus 400 MTA Tuning and Problem Solving for details of this command). The Recover command should respond with the following message when attempting to recover a peer MTA's workspace that is not locked: Warning: Recovery initiated but the workspace is not locked 6.2 Restrictions in Japanese Bodypart Converters This section lists known restrictions for the Japanese Bodypart Converters that are provided with the MAILbus 400 MTA. 21 6.2.1 Control Codes and Escape Sequences Japanese Bodypart converters process the following characters as control codes in jpbody84 and jpbody88 bodyparts: CR, LF, HT, ESC, S, and CSI. The control codes, CR, LF and S are recognized and preserved. For other control codes or escape sequences, Japanese Bodypart converters replace them with appropriate characters or delete them as follows: o HT (Horizontal TAB) This is replaced with 8 space characters (20, hexadecimal) o Escape sequences If an escape sequence is recognized, it is removed. If the escape sequence is not recognized, the escape character and the character following the escape characters are removed. 6.2.2 User Defined Characters All characters in the expanded Kanji Area are replaced with A2A2 (hexadecimal) characters. 6.3 Restrictions in the MAILbus 400 API This section lists known restrictions in the MAILbus 400 API. 6.3.1 Use of ma_wait and mt_wait When awaiting a response from the ma_wait or mt_wait routine, the client is not notified if either of the following occurs: o A message changes state from that of reserved to unreserved. This restriction applies to the ma_wait and the mt_wait routines. o A message becomes available after being temporarily unavailable. This restriction applies only to the ma_wait routine. 22 6.3.2 Remote Client Connections Using CONS You cannot use a CONS NSAP for remote client connections over OSI Transport for this version of the MAILbus 400 API; you are restricted to using a CLNS NSAP or TCP/IP NSAP. 6.3.3 No Support for Multi-Threaded Environments The MAILbus 400 API is not supported in a multi-threaded environment. 6.3.4 Using om_encode and om_decode to Encode and Decode Objects You can only use om_encode or om_decode to encode and decode objects of the following classes: o The OR Address and OR Name classes within the MH Package. o The External class within the OM Package. You cannot use om_encode and om_decode with any class within the IM Package. 6.3.5 Mandatory Fields on Delivery Envelope for Forwarded Message In line with the X/Open[TM] specification for X.400 mail, the MAILbus 400 API allows an application to omit the attributes Actual Recipient Name, Content Type, Originator Name, and Submission Time from the Delivery Envelope of a forwarded message. According to X.420 and X.411 this is incorrect. An application should ensure that these fields are present on a forwarded message. 6.3.6 OM_NETWORK_ERROR When Application Passes Invalid Data Chapter 5 of MAILbus 400 API Programming explains what the API Server is. If your application uses the API Server to connect to the MAILbus 400 MTA, passing incorrect data to the MAILbus 400 API can lead to an OM_NETWORK_ERROR error. 23 6.3.7 om_instance Only Works for Service-Generated Objects The OM routine om_instance only determines the instance of a service-generated object, either public or private. It does not work for client-generated objects. 6.3.8 OSI Transport Not Available if You Link Against Archive Libraries If you link your application against archive libraries, the application cannot use OSI Transport to connect to the MAILbus 400 MTA. See Chapter 6 of MAILbus 400 API Programming for further information about linking. 6.3.9 Single-Process MAILbus 400 Application Cannot Use XDS if Linked Against Archive Libraries A single-process application cannot use both the MAILbus 400 API and the API to the Compaq X.500 Directory Service (XDS), if the application is linked against archive libraries. An application that wishes to use both the MAILbus 400 API and XDS must either use shared libraries or have multiple processes and keep calls to the two interfaces in separate processes. See Chapter 6 of MAILbus 400 API Programming for further information about linking. 6.3.10 1992 Changes Not Implemented in MAILbus 400 API The MAILbus 400 documentation set refers to the new ITU-TS (formerly "CCITT") recommendations as "the 1992 Standards". The MAILbus 400 API does not implement all the changes introduced since the 1988 publication. The following sections explain how MAILbus 400 API does not implement the 1992 Standards completely. o Other Notifications One of the additions to the standards since 1988 is the ability for IPM contents to carry a notification other than the two defined in the 1984 standards (Receipt Notification and Non-receipt Notification). The new notifications are user-definable and called "Other Notifications". Any user-defined notification that a MAILbus 400 MTA passes to an API application is presented in its encoded form in a General Content object. 24 o File Transfer bodypart One of the additions to the standards since 1988 is the IPM File Transfer bodypart. The MAILbus 400 API does not support a File Transfer bodypart object class. To avoid your application receiving File Transfer bodyparts, ensure that the Content Information for your users' O/R addresses is Content Type 1992 Externally Defined IPMS, that is, the object identifier, "{1 3 12 2 1011 5 5 0 1 22}". Using this content type will make sure that the MTA translates File Transfer Bodyparts to Externally Defined Bodyparts. o IPM Extensions There is no support in the MAILbus 400 API for the IPM extensions introduced in the 1992 MHS Standards. These are: the auto-submitted-indication field the mechanism for handling unknown extensions o P1 Per-Message Flags The 1992 MHS Standards defined two additions to the P1 Per-Message Flags. These are not accessible using the MAILbus 400 API. o New Diagnostic Codes The 1992 MHS Standards introduce some new reason and diagnostic codes for reports. It is possible that an application may receive these codes, but there is no symbol defined for them in the MAILbus 400 API's header files. 7 Errors in the Documentation The following section lists errors in the documentation provided with the MAILbus 400 API. 7.1 MAILbus 400 API Documentation The following sections describe errors in or additions to the MAILbus 400 API documentation. 25 7.1.1 Error in Section 3.3.1 of Programming Guide There is an error in the second paragraph of Section 3.3.1 of MAILbus 400 API Programming. Replace the last two sentences of the second paragraph in Section 3.3.1 with the following: If there is a Definitive O/R address in the routing instruction, the API uses this Definitive O/R address for the Distinguished Recipient Address attribute on objects of the Delivery Envelope. If there is no Definitive O/R address in the routing instruction, the Distinguished Recipient Address attribute is not present. In Delivery Reports, the Distinguished Recipient Address attribute is always present. 7.1.2 Addition to Internal Trace Entry Description in Chapter 8 of Programming Guide There is some information missing in the Internal Trace Entry description on page 8-67 of MAILbus 400 API Programming. Add the following text below the Attributes table on page 8-68: The Attempted Country Name, Attempted ADMD Name, and optionally the Attempted PRMD Identifier OM attributes make up the Attempted Global Domain Identifier. The Internal Trace Entry should contain either an Attempted MTA Name or an Attempted Global Domain Identifier, and not both. 7.1.3 Correction to Description of mtX_open The description of the Password argument of the mtX_open MT routine on page 14-12 of MAILbus 400 API Programming should read as follows: The password associated with the Client, as specified when the Client application was registered with the MTA. You should indicate the absence of a password by using OM_ STRING with a null pointer and zero length. 26 7.1.4 Multi-Valued Attributes There are certain attributes, in an object of the OR Address class, that can have more than one value; values of these attributes can have both a Printable String and a Teletex String syntax. There are rules about mixing syntaxes in values for these attributes. The next two sections explain what you must do if you want to include Domain-defined attributes (DDAs), Organisational Units. and Personal Name attributes in an object of the OR Address class. Compaq recommends that you should always supply a Printable String value for these attributes (in addition to a Teletex string value, if you need that), in case you need to interwork with a system that does not support the Teletex String syntax. Mixing Syntaxes in Organisational Units and DDAs An application should treat Organisational Units and DDAs as lists. Therefore if you use a particular syntax for one of these attributes within the list, you must also use that syntax for any previous member of the list. For example, the Organisational Unit attributes in this list have valid values: OU1: Teletex, Printable OU2: Teletex, Printable OU3: Printable However, for ease of maintenance and of interworking, it is advisable to use consistent values for all members of the list (in this case, OU3 would share the possible syntaxes of OU1 and OU2). For DDAs, there is a further consideration: DDAs have a type and a value. For each DDA in the list, the type and the value must have matching syntaxes. So rules governing the matching of syntaxes affect both the list itself and each individual DDA in the list: o A member of the list must have a syntax that matches that of the previous member of the list - for example, if Domain Type 2 has a Teletex String syntax, Domain Type 1 must also have a Teletex String syntax. 27 o For any DDA, the syntax for both type and value must match - for example, if Domain Type 1 has a Teletex String syntax, Domain Value 1 must also have a Teletex String syntax. Personal Name Attributes The Personal Name attributes are Surname, Given Name, Initials, and Generation. When dealing with Personal Name attributes, an application should take account of the following: the Surname within the Personal Name attributes is mandatory, and the Personal Name attributes are considered as a group. Therefore, if you provide a value with one syntax for a Surname attribute, you must supply values with the same syntax for any other Personal Name attributes. For example, if you supply a Teletex String value for Surname, you must also supply Teletex String values for any other Personal Name attributes you use. Similarly, if you supply a Printable String value for Surname, you must also supply Printable String values for any other Personal Name attributes you use. Value Positions for Multi-Valued Attributes In the MAILbus 400 API, attributes of an object of the OR Address class that have both a Printable String and a Teletex String syntax are multi-valued attributes: the Printable String goes in value position 0, and the Teletex String goes in value position 1. The MAILbus 400 API will accept a Teletex String value with no Printable String equivalent for these objects, and may present your application with one. Note, however, that the Teletex String value will still be in value position 1; value position 0 will not have a value. 28 Part IV ________________________________________________________________ Background to Previous Kits This part gives a brief description of Version 2.0C, Version2.0B, Version 2.0A and Version 2.0 of the MAILbus 400 MTA and MAILbus 400 API. This information was available in the Release Notes for the previous kits and so might be familiar to you. It includes: o Documentation Provided (see Section 8). o Differences between Version 2.0C and Version 2.0B (see Section 9) o Difference between Version 2.0B and Version 2.0A (see Section 10) o Changes Introduced in Version 2.0A (see Section 11). o New features for the Version 2.0 release of the MAILbus 400 MTA and MAILbus 400 API (see Section 12). o Upgrading to Version 2.0 (see Section 13). o Interworking information (see Section 14). 8 Documentation Provided The following sections list the documentation provided with the MAILbus 400 MTA and MAILbus 400 API. 8.1 With the MAILbus 400 MTA The documentation provided with the MAILbus 400 MTA is written for the MAILbus 400 MTA running on the OpenVMS[TM] or Tru64 UNIX operating systems. Information provided in the documents listed below applies to both operating systems, unless specifically indicated: o MAILbus 400 Getting Started, Version 2.0 This guide is new to the MAILbus 400 MTA documentation set and describes how to get your messaging system, based on the MAILbus 400 MTA and its products, started quickly. o MAILbus 400 MTA Planning and Setup, Version 2.0 This guide contains information about how to plan and set up a Message Transfer System (MTS) based on the MAILbus 400 MTA. This guide also contains some introductory information and the MAILbus 400 MTA Glossary. o MAILbus 400 MTA Installing on a Compaq Tru64 UNIX System, Version 2.0 This installation card describes how to install the MAILbus 400 MTA on a DECnet/OSI node. Use this card in conjunction with Part III of MAILbus 400 MTA Planning and Setup and these Release Notes. o MAILbus 400 MTA Tuning and Problem Solving, Version 2.0 This guide explains how the MAILbus 400 MTA works, how to modify MAILbus 400 MTA attributes according to your management requirements, and how to solve problems that might occur in an MTS based on the MAILbus 400 MTA. In addition to these guides, reference information is available in the MTA Module Online Help and MTS Module Online Help. 31 8.2 With the MAILbus 400 API The documentation provided with the MAILbus 400 API is written for the MAILbus 400 API running on the OpenVMS and the Tru64 UNIX operating systems. Information provided in the documents listed below applies to both operating systems, unless specifically indicated: o MAILbus 400 API Installing on a Tru64 UNIX System, Version 2.0 This installation card describes how to install the MAILbus 400 API on a DECnet/OSI node. o MAILbus 400 API Programming, Version 1.4 This guide describes all the packages, functions and data types provided by the MAILbus 400 API. This guide has not been updated for MAILbus 400 API Version 2.0. Any documentation amendments are described in Section 7. 9 Differences between Version 2.0C and Version 2.0B 9.1 Multi-CPU Support Version 2.0C of the MAILbus 400 MTA and API has been successfully tested on multiple CPU machines running Tru64 UNIX Version 4.0B and 4.0D. 9.2 Broken Pipe When there is a heavy backlog of messages (eg. 4000) and the swap space is low (approximately 25%), the MAILbus 400 MTA used to crash and log a message 'srv_dispatch failed: 3' in the trace file. This problem has been fixed in Version 2.0C. 32 9.3 MTA now supports 256 parallel agent connections MTA was not able to support 256 parallel agent connec- tions. This problem has been fixed and MTA now supports 256 simultaneous agent connections. MTA internal data structures have been modified and process quota's have been enhanced to allow 256 agents to connect simultaneously to MTA. 9.4 New MTS MSL provided The setting of some OR address attributes is now resolved in Version 2.0C by creating a new definition for MTS MSL. 10 Difference between Version 2.0B and Version 2.0A 10.1 Year 2000 Ready Version 2.0B of the MAILbus 400 MTA and MAILbus 400 API also becomes Year 2000 Ready. Any two digit dates received by the MAILbus 400 MTA and MAILbus 400 API are interpreted as follows: - Years "70" to "99" (inclusive) as "1970" to "1999" and - Years "00" to "69" (inclusive) as "2000" to "2069". Version 2.0B of the MAILbus 400 MTA and MAILbus 400 API are specified as Year 2000 Ready and will correctly process, calculate, compare and sequence date data from, into and between the twentieth and the twenty- first centuries and the years 1999 and 2000, including leap year calculations, when used in accordance with the associated Compaq Product documentation and provided that all hardware, firmware and software used in combination with such Compaq Products properly exchange date data with the Compaq Products. 10.2 Readers Comments The address for Reader's comments as documented in the Release Notes and the books is no longer relevant. - Internet : migbooks@reo.mts.dec.com - X.400 : S=migbooks; O=digital; OU1=reo; P=digital; A=gold 400; C=gb 33 Any comments on documentation should be directed to the local customer support centres. If the readers have some comments to send they should use the prepaid readers' comments forms, if they are supplied at the back of the book. 11 Changes Introduced in Version 2.0A The following list describes all the problems with MAILbus 400 MTA that are solved in Version 2.0A. o The MTA has changed the way it handles the conversion of Externally Defined bodyparts to Bilaterally Defined bodyparts, most commonly used when it downgrades the IPMS message content to messaging systems based on the 1984 MHS Standards. Bilaterally Defined bodyparts are also known as Unidentified, binary bodyparts or Bodypart 14. In many cases, it is no longer necessary to create a Bodypart entity for each Externally Defined bodypart that is to be converted as described in Section 12.2.3 of MAILbus 400 MTA Tuning and Problem Solving. The Bodypart entities that are no longer required are those whose object identifiers for the Encoded Information Types (EITs) match the object identifiers for the data component of the bodypart. This change in behaviour of the MTA is of most value when new Externally Defined bodypart types are introduced into the messaging system for which there is no corresponding Bodypart entity created in the MTA startup script. Note that it is still necessary to perform the other steps to ensure conversion of new bodypart types, for example, entering Content Information in the directory and ensuring the appropriate converters are available. Refer to MAILbus 400 MTA Tuning and Problem Solving for more information about conversions and downgrading. o When the MTA downgrades, to a messaging system based on 1984 MHS Standards, a forwarded message that does not contain an original-encoded-information-type element on the delivery envelope, it no longer fails to deliver 34 the message. Instead, the MTA delivers the message without the delivery envelope. o When the MTA downgrades, to a messaging system based on 1984 MHS Standards, a message or probe that has a private-domain-identifier element present in any per- domain-bilateral-information element on the envelope, it now deletes the whole of the per-domain-bilateral- information element from the envelope, which makes the message or probe compliant with the 1984 MHS Standards. Previously, the MTA only deleted the private-domain- identifier element in such cases. o When a message addressed to more than one actionable recipient is due to be downgraded but its content cannot be downgraded by this MTA, it is now transferred to a peer MTA, if appropriate, for all recipients of the message. Previously, the MTA only transferred the message for the first recipient and generated a non- delivery notification for all other intended recipients of the message. o When the MTA receives a File Transfer bodypart message with a FileAttributes parameter that does not include the optional Pathname attribute, the MTA now transfers the message. Previously, the MTA did not transfer the message and returned a non-delivery notification with a diagnostic of Invalid Arguments. o Accounting has been improved as follows: - Accounting now distinguishes between delivery and non-delivery reports. - As well as recording the rounded-up size of messages and reports in Kilobytes, Accounting now also records the actual size of messages and reports in bytes (that is, octets). To enable the recording of this information, add the following Accounting filter settings, as appropriate, to the filter sets and enable Accounting: Message Octets Report Octets 35 The ASN.1 data stored in the Accounting files (encoded using Basic Encoding Rules (BER)) has been modified to reflect the changes to Accounting. Report Types The ASN.1 definition of the PerRecipientReportTransferFields element is now: PerRecipientReportTransferFields ::= SET { actual-recipient-name [0] ActualRecipientName, last-trace-information [3] LastTraceInfromation, originally-intended-recipient-name [4] OriginallyIntendedRecipientName OPTIONAL } LastTraceInformation ::= SET {report-type [1] ReportType} The Accounting Decoder tool displays report information in the Reported Actual and Intended Information field of reports, as follows: o For a delivery report: Reported Actual and Intended Information actual-recipient-name originally-intended-recipient-name delivery delivery time type of mts user o For a non-delivery report: Reported Actual and Intended Information actual-recipient-name originally-intended-recipient-name non-delivery reason diagnostic Octets The ASN.1 definition of the AccountingSequence element is now: AccountingSequence ::= SEQUENCE { accounting-time INTEGER, accounting-point AccountingPoint, content-size [0] IMPLICIT INTEGER OPTIONAL, message-source [1] IMPLICIT MsgSource OPTIONAL, 36 CHOICE { domain-name [2] IMPLICIT PrintableString, registered-agent-name [3] IMPLICIT PrintableString, mta-or-set-name [4] IMPLICIT PrintableString, unregistered-agent-name [5] IMPLICIT ORName, } OPTIONAL content-size-in-bytes [6] IMPLICIT INTEGER OPTIONAL } The Accounting Decoder tool displays message and report octets as follows: Message Octets n bytes Report Octets n bytes Where n is the number of bytes in the message or report. Refer to MAILbus 400 MTA Tuning and Problem Solving for more information about Accounting. o When the MTA converts, to ISO 6937, a bodypart whose last line is not terminated with a CR/LF sequence, the last line is no longer lost. o The Compaq X.500 Directory Service DSA no longer reports authentication failure events when the MTA rebinds after losing the DSA connection. o The MTA no longer logs recoverable DSA communication problems to the event file. o When using a replicated DSA, the MTA on the shadow DSA node no longer gives directory service errors when the master DSA is unavailable. As the MTA no longer forces the use of the master DSA, you should ensure that the shadow DSA is updated after any changes. Compaq recommends that you use OnChange replication. Refer to Compaq X.500 Directory Service Management for details of configuring replication. 37 o The MTA now uses the TCP/IP Transport Service to make connections to peer MTAs in the same routing domain when it is directed to do so by the "set mta transport service options" command. o The MTA now successfully connects to the second and subsequent MTAs in an MTA set when the connection to the first MTA in the set fails. o The MTA now assigns a unique local identifier to each MPDU it processes. o The MTA now ensures that the GDI in the external and internal trace information matches the GDI in the message identifier when the GDI is one of the GDIs specified for the local MTA. This is most significant when the GDI is placed in the message identifier by an Agent and when the MTA is multi-homed. 12 New Features in Version 2.0 The following sections describe the new features introduced for Version 2.0 of the MAILbus 400 MTA and MAILbus 400 API. 12.1 For the MAILbus 400 MTA Version 2.0 The following subsections describe changes introduced in Version 2.0 of the MAILbus 400 MTA. 12.1.1 New Converters The MAILbus 400 MTA Version 2.0 provides a way of converting from WPS-PLUS[TM] and DECdx[TM] to text. The MTA startup script now contains the definitions for the following Converter entities: o decdxtolatin1 o wpsplustolatin1 These Converter entities define DECdx to ISO Latin 1 and WPS-PLUS to ISO Latin 1 conversions. You might want to specify that you want the DECdx and WPS-PLUS bodypart to be converted to IA5 Text. Entities defining sequences of conversions for WPS-PLUS and DECdx to IA5 Text are provided in the MTA startup script. 38 12.1.2 File Transfer Bodyparts The MAILbus 400 MTA Version 2.0 now provides a mechanism for translating between Externally Defined bodyparts and File Transfer bodyparts. As a result, the Content Type Interpersonal Messaging 1992 has been expanded to include File Transfer bodyparts. You can now specify the following as Content Types: o 1992 Externally Defined IPMS o 1992 File Transfer IPMS o 1992 IPMS Passthrough If you have not set a Content Type in your users' Content Information, or have set the Content Type to Any, your users will now also receive File Transfer bodyparts. If the user's Agent cannot receive File Transfer bodyparts, for example, MailWorks[TM] for UNIX, ALL-IN-1[TM] or LinkWorks[TM], you must edit the Content Information and add the Content Type 1992 Externally Defined IPMS, that is, the object identifier: "{1 3 12 2 1011 5 5 0 1 22}". Using this Content Type will make sure that the MTA translates File Transfer bodyparts to Externally Defined bodyparts. The definition for Content Type Interpersonal Messaging 1992, as it was in previous versions of the MAILbus 400 MTA, has been amended to 1992 Externally Defined IPMS. As a result of this change, File Transfer bodyparts will be translated to Externally Defined bodyparts. If you want to transfer both Externally Defined and File Transfer bodyparts, you will have to modify the Content Type in the Content Information for your users and specify the object identifier for 1992 IPMS Passthrough, "{1 3 12 2 1011 5 5 1 22 0}". You might want to do this for connections to other MTAs that support the 1992 MHS Standards. The MTA uses a bodypart mapping table to translate between Externally Defined bodyparts and File Transfer bodyparts. If your messaging system comprises mail applications that generate File Transfer bodyparts, for example, the Microsoft Exchange[R], you might need to modify the way that the MTA translates between the individual bodyparts. 39 Refer to Chapter 11 of MAILbus 400 MTA Tuning and Problem Solving for details of the new MTA Content Types and details of the bodypart mapping table. 12.1.3 MTAmail MTAmail, the example Agent provided with the MAILbus 400 MTA, has an improved interface. Refer to MAILbus 400 MTA Planning and Setup for details of the new interface. When submitting a message using MTAmail, you must now specify the O/R addresses of the originator and the recipient(s) as strings, separating the individual O/R address attributes with semicolons, for example: c=nz;a=nz-ptt;p=acme;o=acme;ou1=auck;cn=Kim Yip In the previous versions of the MAILbus 400 MTA, MTAmail prompted you for each individual O/R address attribute. 12.1.4 mta_api_server_address You are no longer restricted to specifying connection information only on the first line of mta_api_server_ address. The connection information can be preceded by lines that start with a comment character, a hash (#). 12.1.5 MTA Startup Script and Startup Time The Create Externally Defined Bodypart script located at /var/mta/scripts/create_mta_extdef_bodyparts.ncl is no longer commented out of the MTA Startup script by default. As a result the Create Externally Defined Bodypart script will always be executed as part of the MTA startup. The means the MTA will take longer to start than in previous versions of the product. If you do not need to create bodypart definitions for Externally Defined Bodyparts, you can improve the MTA startup time by placing a comment character (!) at the following command in the MTA Startup script as follows: ! do /var/mta/scripts/create_mta_extdef_bodyparts.ncl 40 12.2 For the MAILbus 400 API Version 2.0 The following subsections describe changes introduced in Version 2.0 of the MAILbus 400 API. 12.2.1 MTAmail The MTAmail example Agent that is provided with the MAILbus 400 API has an improved interface; see Section 12.1.3. In the previous versions of the MAILbus 400 API, MTAmail prompted you for each individual O/R address attribute. 13 Upgrading The following section describes a task that you must consider if you intend to upgrade the Compaq X.500 Directory Service used with the MAILbus 400 MTA. 13.1 Upgrading the Compaq X.500 Directory Service If the DSA version that is running on your system is or later than V4.0.25 and earlier than V5.0, it is required to recompile the schema files (that is provided along with the kit), because of the changes that have been made for the O/R address entities. If the DSA Version is 5.0 and later there is no need to recompile the schema files beacuse V5.0 is shipped along with the new attributes. To compile the schema files follows these steps: 1. # cd /var/dxd 2. # /usr/sbin/dxd_sc The compiled schema is created in /var/dxd 3. Stop and restart the DSA as follows. 4. # NCL 5. NCL> DISABLE DSA 6. NCL> DELETE DSA TO SNAPSHOT 7. NCL> CREATE DSA FROM SNAPSHOT 8. NCL> ENABLE DSA 41 9. When the DSA has been recreated and enabled success- fully with the new schema, you can delete the snapshot file from the DSA system, as follows: 10.# rm DSA-information-tree.snapshot* 14 Interworking The following subsection provides information about versions of related products that you need to be aware of if you are using these products with the MAILbus 400 MTA. 14.1 Interworking with Microsoft Exchange Server The Microsoft Exchange Server[TM] is a mail application that generates File Transfer Bodyparts. If your mail system includes the Microsoft Exchange Server, you will need to set the Content Type on the O/R address entry, or entries, for the Microsoft Exchange users as 1992 File Transfer IPMS. MAILbus 400 MTA Tuning and Problem Solving describes the object identifiers for the Content Types, and Section 12.1.2 of these Release Notes describes the new Content Types, in particular the File Transfer Bodypart, in more detail. Be aware that if your mail system also includes ALL-IN-1 Version 3.2 or LinkWorks, an interoperability problem has been identified. This interoperability problem prevents the Microsoft Exchange Server receiving any message from either ALL-IN-1 Version 3.2 or LinkWorks over a 1992 connection from the MAILbus 400 MTA. Microsoft will be providing a fix for this interoperabil- ity problem, which will be available by the end of April 1996, and on request. To obtain this fix, contact the support center for your Microsoft Exchange Server. 42 14.2 Interworking with the VAX Message Router X.400 Gateway If you intend to use the MAILbus 400 MTA with the VAX[TM] Message Router[TM] X.400 Gateway (MRX), make sure that you have installed MRX Version 2.3 or later. To obtain MRX Version 2.3 contact your Compaq support center. When using the MAILbus 400 MTA with MRX you must ensure that the MRX MTA control flag GOSIP_CONFORM is set for each peer MTA record relating to a MAILbus 400 MTA. Note that MRX is an MTA conforming to the 1984 messaging standards. 43