MAILbus 400 Message Transfer Agent and Application_Program_Interface_________________ Release Notes for DIGITAL UNIX Revision/Update Information: Version 2.0C 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. © 1994, 1999. All Rights Reserved. The following are trademarks of COMPAQ Computer Corporation: ALL-IN-1, DECdx, DECnet, DIGITAL, 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 2.0C and Changes Introduced in Version 2.0C 3 Installing Version 2.0C......................... 7 4 Differences Between Version 2.0C and Version 2.0B ........................................... 9 4.1 Multi-CPU Support ............................ 9 4.2 Broken Pipe .................................. 10 4.3 MTA now supports 256 parallel agent connections................................... 10 Part III Restrictions and Documentation Errors 5 Restrictions in DECnet/OSI for DIGITAL UNIX..... 13 5.1 Defining Transport Classes in the Transport Template Entity mta_any....................... 13 5.2 NCL Restrictions ............................. 13 5.2.1 Limited NCL Command Buffer Size............ 14 5.2.2 Filtering Multi-Valued Attributes Using NCL........................................ 14 6 Product Restrictions............................ 15 6.1 Restrictions in the MAILbus 400 MTA .......... 15 6.1.1 Teletex Characters in Routing Domain Names...................................... 15 6.1.2 Label for Extended Network Address......... 15 6.1.3 Maximum Attribute Length Not Checked for Directory Entries.......................... 15 iii 6.1.4 Using the Recover Command.................. 16 6.2 Restrictions in Japanese Bodypart Converters.................................... 16 6.2.1 Control Codes and Escape Sequences......... 16 6.2.2 User Defined Characters.................... 17 6.3 Restrictions in the MAILbus 400 API .......... 17 6.3.1 Use of ma_wait and mt_wait................. 17 6.3.2 Remote Client Connections Using CONS....... 17 6.3.3 No Support for Multi-Threaded Environments............................... 17 6.3.4 Using om_encode and om_decode to Encode and Decode Objects............................. 17 6.3.5 Mandatory Fields on Delivery Envelope for Forwarded Message.......................... 18 6.3.6 OM_NETWORK_ERROR When Application Passes Invalid Data............................... 18 6.3.7 om_instance Only Works for Service-Generated Objects.................. 18 6.3.8 OSI Transport Not Available if You Link Against Archive Libraries.................. 18 6.3.9 Single-Process MAILbus 400 Application Cannot Use XDS if Linked Against Archive Libraries.................................. 18 6.3.10 1992 Changes Not Implemented in MAILbus 400 API........................................ 19 7 Errors in the Documentation..................... 20 7.1 MAILbus 400 API Documentation ................ 20 7.1.1 Error in Section 3.3.1 of Programming Guide...................................... 20 7.1.2 Addition to Internal Trace Entry Description in Chapter 8 of Programming Guide...................................... 20 7.1.3 Correction to Description of mtX_open ..... 21 7.1.4 Multi-Valued Attributes.................... 21 iv Part IV Background to Previous Kits 8 Documentation Provided ......................... 27 8.1 With the MAILbus 400 MTA ..................... 27 8.2 With the MAILbus 400 API ..................... 28 9 Difference between Version 2.0B and Version 2.0A............................................ 28 9.1 Year 2000 Ready .............................. 28 9.2 Readers Comments ............................. 29 10 Changes Introduced in Version 2.0A.............. 29 11 New Features in Version 2.0..................... 33 11.1 For the MAILbus 400 MTA Version 2.0 .......... 33 11.1.1 New Converters ............................ 34 11.1.2 File Transfer Bodyparts.................... 34 11.1.3 MTAmail.................................... 35 11.1.4 mta_api_server_address..................... 35 11.1.5 MTA Startup Script and Startup Time ....... 36 11.2 For the MAILbus 400 API Version 2.0 .......... 36 11.2.1 MTAmail.................................... 36 12 Upgrading....................................... 36 12.1 Upgrading the DIGITAL X.500 Directory Service....................................... 36 13 Interworking.................................... 37 13.1 Interworking with Microsoft Exchange Server .. 37 13.2 Interworking with the VAX Message Router X.400 Gateway....................................... 37 v 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 Version 2.0C of the MAILbus 400 MTA and MAILbus 400 API in this kit. This part also describes how to install Version 2.0C. o Part III lists the restrictions and documentation errors that apply to Version 2.0C 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.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 2.0C and Changes Introduced in Version 2.0C This part is divided into two main sections, as follows: o Section 3 describes how to install Version 2.0C of the MAILbus 400 MTA and API. o Section 4 describes the differences between Version 2.0C and Version 2.0B of the MAILbus 400 MTA. 3 Installing Version 2.0C To install this kit follow the instructions in MAILbus 400 MTA Installing on a DIGITAL UNIX System or MAILbus 400 API Installing on a DIGITAL UNIX System, with the following exceptions: o Make sure you install one of the following configura- tions of prerequisite software: - DIGITAL UNIX V4.0B with patches: OSF410-400151 (44.00), OSF410-400196 (85.00), and OSF410-400239-1 (136.01) DECnet/OSI for DIGITAL UNIX, V4.0A or later with dnaevld patched to 12-MAR-97, or later DIGITAL X.500 Directory Service for DIGITAL UNIX (Base Subset) V3.1, or later (not required for the API) - DIGITAL UNIX V4.0D with patch reference DUV40DAS00003 or RCS 4.3.134.2. DECnet/OSI for DIGITAL UNIX, V4.0B DIGITAL X.500 Directory Service for DIGITAL UNIX (Base Subset) V3.1, or later (not required for the API) 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 MTAABASE20? MTAASRVR20? MTAANETMAN20? MTABCLNT20? MTAAMAN20? 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. 7 ________________________________________________________________ Space Required Subset Title Subset Name (in kB) _______________________________________________/usr_______/var__ MAILbus 400 MTA Mgt (DIGITAL MTAANETMAN202 1800 80 UNIX) MAILbus 400 MTA Server MTAASRVR202 29900 120 (DIGITAL UNIX) MAILbus 400 MTA Base MTAABASE202 4400 70 (DIGITAL UNIX) MAILbus 400 API (DIGITAL MTAACLNT202 11000 minimal UNIX) MAILbus 400 API Reference MTAAMAN202 200 minimal Pages_(DIGITAL_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/mtaa202/kit For the API: # setld -l /mnt/mtax202/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. For the MAILbus 400 API, if you are using the archive libraries on DIGITAL UNIX, you will need to relink your application after you have installed Version 2.0C. The version number of this kit when displayed using NCL management is V2.0.150. 8 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 (V2.0C-150) Thu May 14 19:46:35 IST 1999 Be aware that if you have installed Version 2.0C of the MTA on a version of DIGITAL UNIX prior to V4 and want to upgrade DIGITAL UNIX to V4 (or later), you must deinstall and then reinstall Version 2.0C of the MTA before you run Version 2.0C on the upgraded DIGITAL UNIX system. If you fail to do this and attempt to run the MTA without deinstalling and reinstalling it on DIGITAL UNIX V4, 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 2.0C and then reinstall Version 2.0C. You can do this after you have upgraded to V4 of DIGITAL UNIX. 4 Differences Between Version 2.0C and Version 2.0B 4.1 Multi-CPU Support Version 2.0C of the MAILbus 400 MTA and API has been successfully tested on multiple CPU machines running DIGITAL UNIX Version 4.0B and 4.0D. 9 4.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. 4.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. 10 Part III ________________________________________________________________ Restrictions and Documentation Errors This part lists the restrictions and documentation errors that apply to Version 2.0C 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 DIGITAL UNIX The MAILbus 400 MTA is an application layered on DECnet[TM]/OSI[R] for DIGITAL UNIX. Some restrictions in DECnet/OSI for DIGITAL 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 DIGITAL UNIX Release Notes. The following sections list additional restrictions in DECnet/OSI for DIGITAL UNIX that affect the MAILbus 400 MTA. 5.1 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. 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.2 NCL Restrictions The following subsections describe restrictions in NCL that have an impact on the MAILbus 400 MTA. 13 5.2.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" } 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.2.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: 14 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 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. 15 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. 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 character are removed. 16 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. 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. 17 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. 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 DIGITAL 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. 18 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. 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. 19 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. 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 20 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. 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. DIGITAL 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 21 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. 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. 22 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. 23 Part IV ________________________________________________________________ Background to Previous Kits This part gives a brief description of Version 2.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 Difference between Version 2.0B and Version 2.0A (see Section 9) o Changes Introduced in Version 2.0A (see Section 10). o New features for the Version 2.0 release of the MAILbus 400 MTA and MAILbus 400 API (see Section 11). o Upgrading to Version 2.0 (see Section 12). o Interworking information (see Section 13). 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 DIGITAL 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 DIGITAL 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. 27 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 DIGITAL 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 DIGITAL 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 Difference between Version 2.0B and Version 2.0A 9.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 DIGITAL Product documentation and provided that all hardware, firmware and software used in combination with such DIGITAL Products properly exchange date data with the DIGITAL Products. 28 9.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 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. 10 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. 29 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, 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. 30 - 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. 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 31 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, 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 DIGITAL 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. 32 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. DIGITAL recommends that you use OnChange replication. Refer to DIGITAL 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. 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. 11 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. 11.1 For the MAILbus 400 MTA Version 2.0 The following subsections describe changes introduced in Version 2.0 of the MAILbus 400 MTA. 33 11.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. 11.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. 34 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. 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. 11.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. 11.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 (#). 35 11.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 11.2 For the MAILbus 400 API Version 2.0 The following subsections describe changes introduced in Version 2.0 of the MAILbus 400 API. 11.2.1 MTAmail The MTAmail example Agent that is provided with the MAILbus 400 API has an improved interface; see Section 11.1.3. In the previous versions of the MAILbus 400 API, MTAmail prompted you for each individual O/R address attribute. 12 Upgrading The following section describes a task that you must consider if you intend to upgrade the DIGITAL X.500 Directory Service used with the MAILbus 400 MTA. 12.1 Upgrading the DIGITAL X.500 Directory Service This information is significant if you are using more than one DSA within your routing domain. Before starting to upgrade your MAILbus 400 MTAs, make sure that you read the DIGITAL X.500 Directory Service Release Notes and DIGITAL X.500 Directory Service Read Before Installing. These documents explain why it is necessary to upgrade all your DSAs to Version 2.0A, or later. 36 13 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. 13.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 11.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. 13.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 DIGITAL 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. 37