hp MAILbus 400 Message Transfer Agent and Application_Program_Interface_________________ Release Notes for Tru64 UNIX Revision/Update Information: Version 3.1 Hewlett-Packard Development Company, L.P. Houston, Texas __________________________________________________________ Hewlett-Packard Development Company, L.P 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 Hewlett-Packard Development Company, L.P or an authorized sublicensor. No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Hewlett- Packard Development Company, L.P or its affiliated companies. © Copyright 1992, 1992-2003 Hewlett-Packard Development Company, L.P. The following are trademarks of Hewlett-Packard Development Company, L.P. in the U.S and/or other countries: 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. 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.1 of the MAILbus 400 MTA. The MAILbus 400 API subsets MTAACLNT310 and MTAABASE310 supplied with this kit are TruCluster-enabled. Please note that these API subsets cannot be used to work with MAILbus 400 MTA versions less than V3.1. Also, the previous MAILbus 400 API subsets will continue to work with MAILbus 400 MTA V3.1. Refer to section 6.3.1 for further details. o Part III lists the restrictions and documentation errors that apply to Version 3.1 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 3.0 and 2.0C - Differences between Differences between Version 2.0C and Version 2.0B - Differences between Version 2.0B and Version 2.0A 3 - Changes to Version 2.0A release of the products - New features for the Version 2.0 release of the products - Upgrading information - Interworking information 4 Part II ________________________________________________________________ Installing Version 3.1 and Changes Introduced in Version 3.1 This part is divided into two main sections, as follows: o Section 3 describes how to install Version 3.1 of the MAILbus 400 MTA and API. o Section 4 describes the differences between Version 3.1 and Version 3.0 of the MAILbus 400 MTA. 3 Installing Version 3.1 To install this kit follow the instructions in the Guides 'MAILbus 400 MTA Installing on a Tru64 UNIX System' or 'MAILbus 400 API Installing on a Tru64 UNIX System', with the following exceptions: Refer to Section 6.3.1 of this Release Notes for the restrictions that apply when installing MAILbus 400 API. o Make sure you install the following configurations of prerequisite software: To install the TruCluster enabled MAILbus 400 MTA V3.1 on a non-cluster system, make sure you install one of the following configurations of prerequisite software: - Tru64 UNIX V4.0G DECnet-Plus for Tru64 UNIX V4.0C or later Tru64 UNIX Enterprise Directory V5.0 or later. - Tru64 UNIX V5.0, V5.1, V5.1A or later DECnet-Plus for Tru64 UNIX 5.0-1 or later Tru64 UNIX Enterprise Directory V5.0 or later To install the TruCluster enabled MAILbus 400 MTA V3.1 on a TruCluster system, make sure you install the following configurations of prerequisite software: - Tru64 UNIX V5.1 (Rev. 732) or later; TruCluster Server T5.1-10 (Rev. 387) or later; DECnet-Plus for Tru64 UNIX V5.0A-1 (Rev. 4.4) or later; Tru64 UNIX Enterprise Directory V5.0 or later (not required for the API); Refer to the Guide 'MAILbus 400 MTA Installing on a Tru64 UNIX System' for further details on Installing and Configuring MAILbus 400 MTA on TruCluster. Note1: Due to limitation in the Schema supplied with X.500 Directory service V4.0-25 not all features within V3.1 of the MTA are available with this version of directory (Refer to section 14.1 of this Release Notes) 7 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. Note3: The Port 200 will be registered for 'mta_api_ server' service in the file /etc/clua_services as 'in_ multi, static' during the MTA installation process on a Trucluster environment. Example entry created in the file /etc/clua_services 'mta_api_server 200/tcp in_multi,static' Note4: When installing MTA on a TruCluster environment, Port 102 has to be registered for 'rfc1006' in the file /etc/clua_services as 'in_multi,static,out_alias'. To do this, do the following: Put the entry in file /etc /clua_services as below: "rfc1006 102/tcp in_multi,static,out_alias" Run the command - 'cluamgr -f ' This has to be done only if the DECnet version on the system is less than V5.1A. The registration will be done automatically during the DECnet Installation Procedure for V5.1A onwards. 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. 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. 8 ________________________________________________________________ Space Required Subset Title Subset Name (in kB) _______________________________________________/usr_______/var__ MAILbus 400 MTA Mgt (Compaq MTAANETMAN310 1800 80 Tru64 UNIX) MAILbus 400 MTA Server MTAASRVR310 29900 120 (Compaq Tru64 UNIX) MAILbus 400 MTA Base (Compaq MTAABASE310 4400 70 Tru64 UNIX) MAILbus 400 API (Compaq MTAACLNT310 11000 minimal Tru64 UNIX) MAILbus 400 API Reference MTAAMAN310 200 minimal Pages_(Compaq_Tru64_UNIX)_______________________________________ o The installation instructions are: a. Installation from CD 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/mtaa310/kit For the API: # setld -l /mnt/mtax20C/kit b. Installation from tar file 1. Copy the tar file to a directory, for example, /tmp1, on the target node. 2. Create a temporary directory, for example, /tmp2, to contain the MTA and API subsets. 3. Change current directory to /tmp2. 9 4. Unpack the tar file into this directory, for example: # tar -xvf /tmp1/mtaa310.tar 5. You can now install V3.1 from the temporary directory: # setld -l . Refer to the Guide 'MAILbus 400 MTA Installing on a Tru64 UNIX System' for further details on Installing and Configuring MAILbus 400 MTA on TruCluster. 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. 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.1. Refer to Section 6.3.1 of this Release Notes for the restrictions that apply when installing MAILbus 400 API. The version number of this kit when displayed using NCL management is V3.1.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.1-0) DD hh:mm:ss IST 2002 Ex: MAILbus 400 MTA (V3.1-0) Wed Apr 9 10:53:52 IST 2003 Be aware that if you have installed Version 3.1 of the MTA on a version of Tru64 UNIX prior to V4.0G and want to upgrade Tru64 UNIX to V4.0G (or later), you must deinstall and then reinstall Version 3.1 of the MTA before you run Version 3.1 on the upgraded Tru64 UNIX system. If you fail to do this and attempt to run the MTA without deinstalling 10 and reinstalling it on Tru64 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.1 and then reinstall Version 3.1. You can do this after you have upgraded to V4.0G(or later) of Tru64 UNIX. 4 Differences Between Version 3.1 and Version 3.0 4.1 TruCluster Enabled MTA This release of MTA is TruCluster enabled. The MTA can be configured for Failover and Load Balancing exploiting the Cluster Alias and the Cluster Application availability features of the TruCluster. In a TruCluster configured MTA, the MPDUs for delivery to User Agents get distributed over the various MTA nodes in the cluster. To provide a common view for these distributed MPDUs from a single User Agent session, an XAPI Bridge has been implemented in the MTA. This bridge transparently provides access to all the MPDUs destined for an XAPI User Agent over a single User Agent session. Refer to the Guide 'MAILbus 400 MTA Installing on a Tru64 UNIX System' for further details on Installing and Configuring MAILbus 400 MTA on TruCluster. 11 4.1.1 Local Submission on Cluster MTA V3.1 supports MTA clients to have a UNIX Domain Socket connection to the local node to submit messages. The submission of messages always happens on the local node. 4.1.2 XAPI Configuration Files To facilitate the User Agents to connect to all MTAs in the cluster, the following two files have to be updated: /var/mta/mta_api_server_address /var/mta/mta_server_names ( This is a new file and can be present in the $HOME location or default location "/var/mta/mta_server_names" ) i /var/mta/mta_api_server_address On the cluster this file is member-specific i.e. each member has an individual copy of this file. In addition each remote User Agent has a copy of this file on the system where it runs. The entries in this file are in the following format LOCAL #TCP xxxxxxxxxxxxxx #OSITP 49xxxxxxxxxxxxx The entries in the file have to be modified as follows #LOCAL TCP (eg. 16.121.137.111). #OSITP 49xxxxxxxxxxxx Note: 1. Any of the member node addresses could also be optionally used in this file. But in such a case the user agents will not have the automatic load balancing and failover features provided by the cluster alias. 2. The Multiple Delivery feature for UAs works only with the TCP option above. (And also with the LOCAL option only if the User Agent has been relinked with the new XAPI library provided with MTA V3.1.) Only IP addresses are allowed in this file. Node names are not allowed. 12 ii /var/mta/mta_server_names This file is also a member specific file. It is a new file specific to MTA on cluster. It stores the information of all the currently configured and online MTA nodes in the cluster. Using an available editor the /var/mta/mta_server_names file has to be edited to include all the node names (except the local node name on each node) in the cluster on which MTA instances are running. The format of entries in this file is as below; it is also included in the file available after a successful installation of MTA. TCP hostname-1 TCP hostname-2 . . TCP hostname-n Where each entry corresponds to a node in the cluster where the MTA is configured and online. Each hostname in this file should be the fully qualified hostname of the node, including the domain name. Or it could be the alias name of the node as defined in the '/etc/hosts' file on the cluster. The maximum limit for the number of node names to be put in this file is 8. Lines starting with a '#' character are treated as comment lines. White space characters can be used as separators between the words on a line. Note: 1. The administrator of this file should ensure that this file does not contain duplicate entries for any cluster node. 2. The administrator of this file should ensure that on each node this file does not contain the entry for the Local Node. 3. The administrator of this file should ensure that the number of entries in this file (for member node names) should not exceed 8. 13 If this number exceeds 8 then user agents will not be able to connect to MTA and the following message will be logged in the 'user.log' file: "MTA_SERVER_ NAMES file contains more than eight entries" and an 'OM_NETWORK_ERROR' will be returned to the User agents trying to connect. 4.1.3 Submission Performance Enhancement The buffer size for om_write call is increased 10 times from 1024, for more throughput during submission of messages from an XAPI user agent. 4.1.4 maX_open call Cluster-Enabled The maX_open call has the support for distributed connection over the cluster. (changes as per CFS-93621) 4.1.5 XAPI Automatic Reconnect Logic In the Trucluster MTA an XAPI User Agent opens a connection with all the configured MTA instances in the cluster. Now during the lifetime of the UA session if some of the MTA instances go down, the UA session looses connection with these MTA instances. If such MTA instances come back up, then earlier it was not possible for the UA to re-connect to these MTA instances without being brought down and re-connecting. The new implementation overcomes the above limitation. Now when one or more MTA instances go down during the User Agent session, the XAPI tries to reconnect to such failed MTA instances on behalf of the User Agent Session, provided the User Agent makes any of the following XAPI Calls: o ma_size o ma_wait o ma_start_delivery For each MTA instance for a User Agent Session the following additional information is maintained: o Reconnect Count (RC): This counts the number of unsuccessful reconnect attempts made by the UA session to a particular MTA instance. 14 o Previous Time stamp (PTS): The time stamp corresponding to the previous failed/successful reconnect attempt. (Initial value corresponds to the time stamp taken on successful/unsuccessful connection during ma_open) When the User agent issues an ma_size, ma_wait or an ma_ start_delivery call, it checks for the MTA instances that have been marked invalid for the User Agent Session. (MTA connections are marked invalid by the XAPI functions if on performing an operation over that connection, an NETWORK_ ERROR is received internally by the XAPI). If an invalid MTA connection is found, the new function- ality in these routines check for a 'Reconnect Count' (stored in internal XAPI structures) for the particular MTA connection in that User Agent Session. If this count is zero (0), a reconnection attempt is tried straight away. If the reconnection attempt succeeds then the new connection descriptor is updated in the User Agent session information. If the reconnection attempt fails then the Reconnect Count counter is incremented as well as the current time stamp is stored in the Previous Time in the UA session information for the particular MTA instance. If the Reconnect count for a particular MTA connection in a User Agent Session is found to be greater than zero (0) it implies that an earlier reconnection attempt (from this UA session to the particular MTA instance) had failed. In such a situation, the next reconnection attempt is made only if a calculated interval has elapsed since the last unsuccessful reconnection attempt ("Previous Time Stamp"). The interval in which a reconnection attempt is not made is calculated as per the following formula RC * XAPI_RECONNECT_TIME. This implies that the interval is increased as the number of the unsuccessful attempts increase. This increase in interval is allowed up to a maximum value of 2 hours, after which this value remains constant at 2 hrs for further reconnect attempts that fail. 15 If the reconnection attempt is successful then the Reconnect Count (RC) counter is reinitialized to zero and the Previous Time stamp (PTS) is updated with the current time stamp in the UA session information for the MTA instance. If the new environment variable XAPI_RECONNECT_TIME is not defined, then the MTA internally takes a value of 300 seconds. 4.1.6 IR Listener Restart made faster MTA now supports socket reuse address for the IR listener on port 201. This enables the IR Listener to come up successfully even in the presence of temporary TCP states for port 201. Also, the IR Listener Restart Interval in MTA has been reduced from 300 seconds to 10 seconds to allow this process to come back up faster in case of a failure. 4.1.7 Connect Timeout made configurable The XAPI connect timeout is one more feature which has evolved with this new MTA kit. This feature allows the User to place a maximum timeout limit for a connection /reconnection attempt that is made from the XAPI (on behalf of a UA) to the MTA (port 201). This is helpful in situations where the XAPI needs to connect to N MTA instances in a cluster and one (or more) of the connection attempts hangs. In such a situation the connection attempt to the next MTA instance will be tried by the XAPI after the default TCP timeout of 75 seconds on the hanged connection is reached. To allow the user to decrease (increase) the TCP 75 seconds default timeout, an environment variable XAPI_ CONNECT_TIMEOUT has been provided. The value set for this environment variable at the time of MTA startup, acts as the actual time limit after which the connect socket call in the XAPI timeouts, instead of waiting for the default TCP 75 seconds for the same purpose. If the new environment variable XAPI_CONNECT_TIMEOUT is not defined, then the MTA internally takes a value of 75 seconds. 16 4.2 Rolling Upgrade support for MTA As of the Version 3.1 MTA release, MAILbus 400 MTA may be upgraded as part of a TruCluster rolling upgrade. Steps To upgrade MAILbus 400 MTA as part of a cluster roll: 1. Create tagged files for MAILbus 400 MTA as part of the setup stage by adding MTA to the "clu_upgrade setup" command, example: # clu_upgrade -v setup MTA 2. Reboot all of the cluster members except the lead member, as per the rolling upgrade instructions. When the cluster members have been rebooted, they will continue to run the older version of MAILbus 400 MTA until they are rolled. 3. Do the Pre-Install check by executing the below command. This command verifies if cluster is ready for installation or not. This command should be run on lead member. example: # clu_upgrade -v preinstall 4. Deinstall the MAILbus 400 MTA by executing the following command. example: # /usr/sbin/setld -d 5. Install the new version of MAILbus 400 MTA by running the following command. The command should be run on the lead member. example: # clu_upgrade -v install 17 6. Do the Post-install check by running "postinstall" command on the lead member. This verifies the update installation command completed successfully. example: # clu_upgrade -v postinstall 7. Do the rolling upgrade by running the "roll" command. This command must be run on the member to be rolled. The member should be in a single user mode. example: # clu_upgrade -v roll 8. Reboot all of the cluster members except the lead member, as per the rolling upgrade instructions. 9. Run the "switch " command. This can be run on any cluster member. The switch command verifies that all members are running the same versions of the base operating system and cluster software, and that no members are using the tagged files. example: # clu_upgrade -v switch 10.Clean (remove) the tagged files. The clean command can be run on any cluster member. The clean command verifies that the switch stage has completed. If so, clean deletes all tagged .Old.. files example: # clu_upgrade -v clean Steps to upgrade MAILbus 400 MTA independently without a Full Cluster roll. 1. Creating tagged files. The "clu_upgrade tagged" command will create the tag files for the MAILbus 400 MTA. example: # clu_upgrade -v tagged add MTA 18 2. Enable all the cluster members excluding the lead members to run on tagged files by running the following command. example: # clu_upgrade -v tagged enable 3. Reboot all of the cluster members except the lead member, as per the rolling upgrade instructions. When the cluster members have been rebooted, they will continue to run the older version of MAILbus 400 MTA until they are rolled. 4. Deinstall the MTA on lead member using setld. example: # /usr/sbin/setld -d 5. Install the new version of MAILbus 400 MTA using setld. example: # /usr/sbin/setld -l 6. Disable the members which are running on tagged files to run on new installed files. example: # clu_upgrade -v tagged disable 7. Reboot all the cluster members excluding lead member. 8. Remove the tagged files. example: # clu_upgrade -v tagged remove MTA 4.2.1 Limitations of a rolling upgrade The following limitations apply when performing a rolling upgrade of MTA: o The minimum installed version of MAILbus 400 MTA is V3.1. i.e. it will be possible to roll from this version of MTA to future MTA releases. 19 o When rolling the MTA with the complete cluster roll the following restriction applies for DECnet. The operating system must be upgraded to at least Tru64 V5.1B. Prior versions of Tru64 include DECnet on the list of blocking layered products, so the install update application will not work if DECnet is installed. As of Tru64 V5.1B, this restriction is removed. o When rolling the MTA with the complete cluster roll the following restriction applies for DECnet. The minimum installed version of DECnet should be V5.1. o All installed MAILbus 400 MTA subsets must be of the same version. o When performing a Cluster Roll to new Major version of the OS, please check that the MAILbus 400 MTA version running on the cluster has been certified on the new OS version. o When performing a cluster rolling upgrade the 'clu_ upgrade -v clean' operation does not remove all the ".Old" created by the clu_upgrade procedure earlier. This is a known problem with the 'clu_upgrade' procedure. Please contact the Trucluster engineering for the latest information on this. 4.3 Retry interval for agent made configurable The retry interval for agent has been made a configurable parameter. The retry interval for Temporary Failure to deliver an MPDU to an XAPI User Agent can be specified by defining an environment variable named MTA_AGT_RETRY. The value of this environment variable is in minutes and needs to be set before the MTA startup. The default value of this retry interval is 10 minutes. 4.4 Comparison of routing instruction attributes, agents and domains has been made case-insensitive During the routing of messages, a case-sensitive comparison was made for agent names and domain names. This has been modified to a case-insensitive comparison. 20 Part III ________________________________________________________________ Restrictions and Documentation Errors This part lists the restrictions and documentation errors that applies to Version 3.1 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 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.1 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 14.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.1 can be used. 5.2 CML process crashes with "Process Error" and NCL dumps core for distribution list more than 320 entries. 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" 23 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. 24 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" } 25 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 5.5 Restrictions for DECnet versions less than V5.1A For installing/configuring DECnet versions less than V5.1A on TruCluster System V5.1 or above, the following issues need to be taken note of. The information below is being provided for reference purposes only, please contact the DECnet support group for further information on the same. How to install DECnet/OSI and WAN (X.25) in TruCluster System V5.1. The DECnet/OSI and related WAN (X.25) products for DECnet versions less than V5.1 are not TCS V5.x aware. You can however install them in the TCS V5.x cluster such that they will function in parallel on all nodes in the cluster. Thus these products will become a multi-instance application outside of the control of CAA. The following note describes the conflicts that need to be resolved and gives an overview of the procedure. If you just install the above products in the cluster there will be the following conflicts: 1. Conflicts to be resolved o MAC address modification clash 26 The above products modify the MAC address of the network cards on which they run. So does the clustering software for the default cluster alias. The easiest and certainly the best way to avoid the conflict is to configure the product on its own networking interface and the cluster alias on another interface. When this is not possible you will have to resort to trying to afford the conflict by carefully starting DECnet/OSI before the clustering sets up the cluster alias on the interface in the boot sequence. Though this approach works in theory, it is not recommended. o Log files name clash. There are a few log files that should be made node specific in /var/dna: DECnet_saved_files.log dna_install.log session.log decnetstartup.log ..... etc. 2. Overview of the multi-instance installation of DECnet /OSI The general idea is to make /var/dna directory a CDSL. You need to do this in certain order. The only trap is that certain symbolic links need to be changed so they we can continue to point into the right places. 3. Overview of the installation procedure DECnet/OSI The following assumes that DECnet/OSI is installed on a networking interface allocated exclusively for its use. 1. Install licenses on all nodes. 2. Select a node eg. member1. Install and configure the products normally on this node and test their operation. Shutdown DECnet/OSI and X.25. 27 3. Fix all relative symbolic links in /var/dna and /var /dna/scripts The links are of the form: example_file -> ../../some/other/path/example_file They all need to be changed to: example_file -> /some/other/path/example_file The following is the (possibly incomplete) list of the offending links: in /var/dna: dna_version mop_v3_clients_template x25ip.db x25rc.defaults x25rc.required in /var/dna/scripts: block_events.template create_session_control_applications.ncl start_event_dispatcher.template x25_extra_create.ncl x25_extra_create.ncl.preXXA312 x25_extra_enable.ncl x25_extra_security.ncl x25_extra_security.ncl.preXXA312 x25_extra_set.ncl x25_extra_set.ncl.preXXA312 x25addressconversion.ncl 4. Move the directory /var/dna and its contents into directory /var/cluster/members/member1: cd /var mv dna /var/cluster/members/member1 This is the same fileset so mv(1) will work. 5. Truncate all logs in /var/dna. This is done not to carry the old logs from member1 to the other members. 6. Create the CDSL: cd /var ln -s /var/cluster/members/{memb}/dna 7. Create copies of the dna directory for all other members. 28 cd /var/cluster/members/member1 tar cf - ./dna | (cd /var/cluster/members/member2; tar xpf -) tar cf - ./dna | (cd /var/cluster/members/member3; tar xpf -) and so on for all other members on which you wish to run the application. 8. Run DECnet/OSI and X.25 configuration on all target members except member1 9. Start the DECnet/OSI and X.25 application on all members. 4. Upgrade notes If you ever need to upgrade DECnet/OSI or X.25 or upgrade the operating system (which requires de- installation of DECnet/OSI and X.25) then you would need to reinstall DECnet/OSI and X.25 completely using the procedure outlined here. The above steps are required for DECnet versions less that V5.1A. DECnet V5.1A onwards is Trucluster aware; refer to DECnet release notes for further information. 5. Another approach cd /var mkdir dna mkcdsl -a /var/dna This will create a soft link that points to /cluster /members/{memb}/var/dna and create a directory dna on all the cluster members cd dna; mkdir scripts mkcdsl -a /var/dna/scripts Installation on member1 setld -l . Configuration on member1 decnetsetup advanced 29 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 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. 30 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 When performing recovery of the workspace of an MTA present in the cluster environment, the recover command should be run with the Absolute pathname of the workspace of that MTA in the cluster. Example: The Command to Recover workspace of Member2 from the Member1 as shown below. ncl> recover mta workspace "/cluster/members/member2/var /mta/workspace/stable" 6.1.5 Using the TruCluster MKCDSL Command A QAR (QAR 89069) has been raised with the Tru64 UNIX Engineering for the restriction in 'mkcdsl' command with the '-a' option. Although it is not a restriction of MAILbus 400 MTA, it would be useful for the administrators when changing the default CDSLs created during MAILbus 400 MTA installation. 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. 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. 31 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 MTA-API Interworking Restrictions The MAILbus 400 API subsets MTAACLNT310 and MTAABASE310 supplied with this kit are TruCluster-enabled. These subsets can be used to install only the MAILbus 400 API on a system. But such an API installation will inter- work with only MAILbus 400 MTA V3.1 onwards. It will not inter-work with version of MAILbus 400 MTA prior to V3.1. The existing versions of the MAILbus 400 API V2.0C or earlier will continue to inter-work with MTA V3.1. When using the old API versions with MTA V3.1, if the 'LOCAL' mode is used in the mta_api_server_address file, then no XAPI Bridge functionality will be available to the User Agent connecting using the 'LOCAL' mode of connection. 32 6.3.2 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. 6.3.3 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.4 No Support for Multi-Threaded Environments The MAILbus 400 API is not supported in a multi-threaded environment. 6.3.5 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.6 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. 33 An application should ensure that these fields are present on a forwarded message. 6.3.7 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. 6.3.8 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.9 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.10 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.11 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 34 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. 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. 35 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. 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. 36 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. 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. hp 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). 37 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. 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. 38 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 3.0 and Version 2.0C (see Section 9) o Differences between Version 2.0C and Version 2.0B (see Section 10) o Difference between Version 2.0B and Version 2.0A (see Section 11) o Changes Introduced in Version 2.0A (see Section 12). o New features for the Version 2.0 release of the MAILbus 400 MTA and MAILbus 400 API (see Section 13). o Upgrading to Version 2.0 (see Section 14). o Interworking information (see Section 15). 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 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. 41 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 3.0 and Version 2.0C 9.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. 42 More details on these two attributes can be found in the NCL online help. 9.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. 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. 9.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. 43 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. 9.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". 9.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. 9.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. 9.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. 44 9.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. 9.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 Tru64 UNIX V5.0. 9.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. 9.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. 9.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. 9.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. 45 9.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. 10 Differences between Version 2.0C and Version 2.0B 10.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. 10.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. 10.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 quotas have been enhanced to allow 256 agents to connect simultaneously to MTA. 46 10.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. 11 Difference between Version 2.0B and Version 2.0A 11.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 hp Product documentation and provided that all hardware, firmware and software used in combination with such hp Products properly exchange date data with the hp Products. 11.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 Any comments on documentation should be directed to the local customer support centers. 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. 47 12 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 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, 48 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 The ASN.1 data stored in the Accounting files (encoded using Basic Encoding Rules (BER)) has been modified to reflect the changes to Accounting. 49 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, 50 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. 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. 51 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. 13 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. 13.1 For the MAILbus 400 MTA Version 2.0 The following subsections describe changes introduced in Version 2.0 of the MAILbus 400 MTA. 13.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. 52 13.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. 53 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. 13.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. 13.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 (#). 13.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 54 13.2 For the MAILbus 400 API Version 2.0 The following subsections describe changes introduced in Version 2.0 of the MAILbus 400 API. 13.2.1 MTAmail The MTAmail example Agent that is provided with the MAILbus 400 API has an improved interface; see Section 13.1.3. In the previous versions of the MAILbus 400 API, MTAmail prompted you for each individual O/R address attribute. 14 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. 14.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 because 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 55 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* 15 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. 15.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 13.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. 56 15.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. 57 A ________________________________________________________________ APPENDIX A: MAILbus 400 MTA V3.1 Document List Following are the set of documents provided with MAILbus 400 MTA V3.1 for Tru64 UNIX . 1. MAILbus 400 Getting started (Hard copy) 2. MAILbus 400 Message Transfer Agent Planning and Setup, Version 2.0 3. MAILbus 400 Message Transfer Agent Installing on Tru64 UNIX System, Version 3.1 4. MAILbus 400 MAILbus 400 Message Transfer Agent Tuning and Problem Solving, Version 2.0 5. hp MAILbus 400 MAILbus 400 Message Transfer Agent and Application Program Interface Release Notes for Tru64 UNIX, Version 3.1 6. MAILbus 400 MAILbus 400 Message Transfer Agent and Application Program Interface Cover Letter for Tru64 UNIX, Version 3.1 APPENDIX A: MAILbus 400 MTA V3.1 Document List A-1