MAILbus 400 SMTP Gateway for_Compaq_Tru64_UNIX_________________________ Release Notes Revision/Update Information: Version 2.3 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. © 2000. All Rights Reserved. The following are trademarks of COMPAQ Computer Corporation: DECnet, DIGITAL, MAILbus, VAX DOCUMENT, and the COMPAQ logo. Internet is a registered trademark of Internet, Inc. Microsoft Exchange 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 by X/Open Company, Ltd. This document was prepared using VAX DOCUMENT, Version 2.1. ________________________________________________________________ Contents Part I Introduction 1 Introduction.................................... 3 Part II Installing Version 2.3 and Changes Introduced in Version 2.3 2 Installing Version 2.3.......................... 7 3 Differences Between Version 2.3 and Version 2.2............................................. 8 3.1 Support for multiple SMTP Gateway instances on the same server............................... 9 3.2 Support for 8-bit charactersets in attachment-filenames.......................... 9 3.3 Message filtering based on partial address translations.................................. 10 3.4 Improved handling of MIME messages ........... 11 3.5 Improved handling of O/R address attributes that start with a digit....................... 12 3.6 Handling of RFC822 headers ................... 12 Part III Restrictions and Documentation Errors 4 Restrictions in this Version of the SMTP Gateway......................................... 15 4.1 Quotation Marks Must Be Omitted in Address Test Tool Input............................... 15 4.2 Syntactical Errors in O/R Addresses .......... 15 4.3 Bug in Example custom_decode Script .......... 16 5 Restrictions in Other Products that Can Affect the SMTP Gateway................................ 16 iii 5.1 Exhange Server 5.5 and its handling of X.400 FTBP filenames................................ 16 5.2 Microsoft Exchange Address Encapsulation Problem in Some Releases...................... 17 5.3 Sendmail Truncates Addresses Longer Than 200 Characters.................................... 18 5.4 Sendmail Removes Blind Carbon Copy Headers from Messages................................. 18 5.5 Two Digit Years used by External Software .... 19 Part IV Background to Previous Kits 6 Changes Introduced in Version 2.2............... 23 6.1 File Transfer Body Part Support .............. 23 6.1.1 Transformation of FTBPs in the X.400-to-MIME direction.................... 24 6.1.2 Generation of FTBPs in the MIME-to-X.400 direction.................................. 24 6.1.3 Interoperability Notes..................... 25 6.1.4 "mta_mpchild" patch for the MAILbus 400 Message Transfer Agent..................... 26 6.1.5 Important: Note on Gateway setup........... 27 6.2 Use of the Bodypart Mapping Table ............ 28 6.3 O/R address mapping modification ............. 28 7 Changes Introduced in Version 2.1C.............. 29 7.1 Certified on Multi CPU Machines .............. 29 7.2 Handling improperly formed X.400 O/R addresses..................................... 29 7.3 Faster Encoders and Decoders ................. 29 7.4 New Template for the Bodypart Mapping Table .. 30 7.5 Handling encoded text/HTML attachments ....... 30 8 Changes Introduced in Version 2.1B.............. 30 8.1 Year 2000 Compliance ......................... 30 8.2 Improved Handling of X.400 Trace Headers ..... 30 8.3 Tested also on Digital UNIX V4.0D ............ 31 8.4 Readers Comments ............................. 31 9 Changes Introduced in Version 2.1A.............. 31 9.1 General Functions ............................ 31 9.2 Changes Relating to the MIME X.400 Enhanced Relay (MIXER)................................. 32 9.3 Changes in Addressing Functions .............. 32 9.4 Changes Relating to Headers .................. 32 10 New Features for Version 2.1 ................... 32 iv 10.1 Support for the Multipurpose Internet Mail Extensions Defined in RFC 1522................ 32 10.2 Support for Parts of MIXER ................... 33 10.3 New Summary Event - Gateway Status ........... 33 10.4 Support for Remote MTA ....................... 33 11 Changes Since Version 2.0....................... 34 11.1 Interworking with Other MIME Products ........ 34 11.2 New X-Author Header .......................... 34 11.3 More Precise sendmail Rules .................. 34 11.4 Changes in O/R Address Translation ........... 35 11.5 Running the Setup Procedure to Reinstate Rewrite Rules................................. 35 12 Changes Since Version 1.*....................... 35 12.1 Support for RFC 1327, RFC 1494 and RFC 1495 .. 35 12.2 Untranslated Internet Message Headers Now Added to the End of X.400 Messages............ 36 12.3 Changes to the Way the SMTP Gateway Uses the MAILbus 400 MTA .............................. 36 12.4 Use Setup Procedure Instead of Editing the Startup NCL Script............................ 37 12.5 Additional Characteristic Attributes for Modifying Message Exchange.................... 37 12.6 Changes to the add_map and remove_map Tools .. 38 12.7 Changes to the Settings of the Address Lookup Attributes.................................... 39 v Part I ________________________________________________________________ Introduction This part provides a brief introduction to the product and describes the structure of these notes. 1 Introduction The MAILbus[TM] 400 SMTP Gateway enables users of X.400- based and SMTP-based messaging systems (such as the Internet[R]) to exchange messages. The MAILbus 400 SMTP Gateway translates X.400 messages into the format used within the Internet (as defined in RFC 822), and translates Internet messages into X.400 format. These release notes are provided with Version 2.3 of the MAILbus 400 SMTP Gateway for Compaq Tru64[TM] UNIX[R]. They describe: o Information about installing this kit (see Section 2). o Differences between Version 2.2 and Version 2.3 (see Section 3). o The restrictions in this version of the MAILbus 400 SMTP Gateway (see Section 4). o The restrictions in other products that can affect the MAILbus 400 SMTP Gateway (see Section 5). o Changes introduced in all previous kits (see Part IV). 3 Part II ________________________________________________________________ Installing Version 2.3 and Changes Introduced in Version 2.3 This part is divided into two main sections, as follows: o Section 2 describes how to install Version 2.3 of the SMTP Gateway. o Section 3 describes the differences between Version 2.3 and Version 2.2 of the SMTP Gateway. 2 Installing Version 2.3 To install this kit follow the instructions in MAILbus 400 MTA Installing on a DIGITAL UNIX System, with the following exceptions: o Make sure you install one of the following configura- tions of prerequisite software: - Compaq Tru64 UNIX V4.0D DECnet/OSI for Compaq Tru64 UNIX, V4.0B or later MAILbus 400 MTA for Compaq Tru64 UNIX (Base and Mgt Subsets) V2.0C, or later Compaq X.500 Directory Service for Compaq Tru64 UNIX (Base Subset)V3.1, or later - Compaq Tru64 UNIX V4.0E with patch: DUV40EAS0002- 19990617.tar June 17,1999 DECnet/OSI for Compaq Tru64 UNIX, V4.0B or later MAILbus 400 MTA for Compaq Tru64 UNIX (Base and Mgt Subsets) V2.0C, or later Compaq X.500 Directory Service for Compaq Tru64 UNIX (Base Subset) V3.1 ECO3, or later - Compaq Tru64 UNIX V5.0 DECnet-Plus for Compaq Tru64 UNIX V5.0 MAILbus 400 MTA for Compaq Tru64 UNIX (Base and Mgt Subsets) V2.0C or later Compaq X.500 Directory Service for Compaq Tru64 UNIX (Base Subset) V3.1 ECO3 or later o The command to deinstall any SMTP Gateway subsets already installed on your system is: # setld -d SXABASEnnn SXANETMANnnn SXADOCnnn Replace nnn with the version number of the subsets installed on your system. o The approximate disk space required (in Kilobytes) for each of the MAILbus 400 SMTP Gateway subsets in /usr /opt and /var/opt, and the corresponding softlinks for the MAILbus 400 SMTP Gateway's files in /usr and /var are shown in the following table. 7 ______________________________________________________________ Subset Title Subset name Space Required in ____________________________________________/usr______/var MAILbus 400 SMTP SXANETMAN230 100kB 50kB Management MAILbus 400 SMTP Gateway SXABASE230 1550kB 400kB MAILbus 400 SMTP SXADOC230 50kB 800kB Supplementary_Documents _____________________________________________________________ o The installation instructions are: - 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. - Load the subsets as follows: # setld -l /mnt/sxa230/kit o The command to run the verification procedure (VP) is: # setld -v SXABASE230 The version number of this kit when displayed using NCL management is V2.3.0. To identify this kit, type the following command: what /usr/sbin/smtpgw/smtpgw | grep MAILbus The following is the response from this command: MAILbus 400 SMTP Gateway (mailer/daemon) V2.3-0 ddd mmm nn hh:mm:ss GMT 2000 3 Differences Between Version 2.3 and Version 2.2 8 3.1 Support for multiple SMTP Gateway instances on the same server Until this release of the SMTP Gateway, one could only run one instance of the Gateway on each machine. One could not, for example, run three Gateways on the same machine.With this release of the Gateway, this restriction is removed. A script has been provided, which arranges for additional Gateway instances to execute on the same server. The advantage of running multiple instances on the same server is that there will be multiple Gateways handling the message traffic between the X.400 user community and the internet user community, thus speeding up message flow between the two. When all the Gateway instances are made to use the same configuration, then load balancing is automatically achieved. Please note that this feature is NOT to be confused with cluster awareness. This feature does not imply support for clustering.The existing, default cluster compatibility of the Gateway remains unchanged. For detailed instructions on using this feature, please read the 'Multiple Gateway User Guide' that has been provided with the Gateway. 3.2 Support for 8-bit charactersets in attachment-filenames The earlier release of the Gateway would only map 7-bit (US ASCII) attachment-filenames in a standards-compliant manner.It would simply byte-copy filenames with 8-bit characters.This release of the Gateway improves its handling of 8-bit characters in attachment-filenames.Now, filenames containing characters from the complete Latin character-set (ISO 8859-1) are mapped and made available on both sides of the Gateway. - In the MIME messages it generates, the Gateway now encodes such filenames in accordance with RFC 2047. - In the X.400 messages it generates, it now encodes such filenames in accordance with X.420, with one exception.It does not add designation and invocation sequences as required by X.420. This is because of limitations in Exchange Server 5.5. These have been explained in Section 5.1.By the same token, while 9 accepting X.400 messages, the Gateway assumes that X.400 filenames do not contain such escape sequences. 3.3 Message filtering based on partial address translations When the SMTP Gateway receives a message, it uses several methods to try to translate the addresses on the message.To obtain a translation for an address, the SMTP Gateway goes through different steps in an order that depends on whether the message comes from Internet and passes through the SMTP Gateway to reach the X.400 network, or the message comes from the X.400 network and passes through the SMTP Gateway to reach the Internet. The translation of an address also depends on the value of the characteristic attribute of the SMTP Gateway, namely, the "Lookup X.400 Users" and "Lookup Internet Users". Currently,the values that can be assigned to the lookup attributes are OPTIONAL and MANDATORY. For message filtering based on partial address translations, a new value, "Partial", has been defined". These attributes can thus take on one of three values-"Mandatory", "Optional" and "Partial". With the value set to "Partial", the message filtering proceeds on lines similar to that for "Mandatory", but the difference is that a translation for the COMPLETE (originator or recipient) address need not exist. A translation for even a part (higher hierarchical level) of the address is sufficient condition for the Gateway to transfer the message to the other side. If no translation exists, a non-delivery is returned to the originator. This is also similar to the behaviour for "Optional", but with the difference that a translation for the (originator or recipient) address MUST exist. If no translation exists, a non-delivery is returned to the originator. Address encapsulation(as in the case of "Optional") is NOT performed. Thus, a translation, for either the complete address or for a part(higher hierarchical level) of the address is required. The above restriction is only applied to action- able(envelope) originator and recipient addresses. 10 For all X.400 addresses, the lookup attribute, "Lookup X.400 Users" is or relevance. For all Internet addresses, the lookup attribute "Lookup Internet Users" is of relevance. For any X.400 address, if the characteristic attribute "Lookup X.400 users" is set to PARTIAL, a translation for this O/R address is searched under the "Translations" field of the "O/R address" entity in the MTS. The translation may be defined for either the complete X.400 address or for a part of the address. For any Internet address, if the characteristic attribute "Lookup Internet user" is set to PARTIAL, a translation for this Internet address is searched under the "Foriegn address" field of the "DOMAIN" entity in the MTS.The translation may be defined for either the complete Internet address or for a part of the address. Please refer to the NCL online help of the SMTP-Gateway module for more details on this new value. You can refer to the Gateway Managing Guide for more on how the existing two values ("Mandatory" and "Optional") influence message filtering. Translations can be added and removed with the help of the tools provided with the Gateway - "add_map" and "remove_ map". Please refer to the Gateway Managing Guide for details on the use of these tools. 3.4 Improved handling of MIME messages The Gateway has been made more robust in its processing of MIME messages. It now does not fail on receipt of messages with long attachment-filenames and with empty values for certain headers. 11 3.5 Improved handling of O/R address attributes that start with a digit While mapping an O/R address to its Internet equivalent, if the O/R address contained attributes starting with a digit, the Gateway would retain such attributes in the LHS part of the Internet address and would not move them as Internet subdomains to the RHS. Now, the more desirable alternative of moving such attributes to the RHS has been implemented. 3.6 Handling of RFC822 headers On messages coming from Internet to the X.400 MTA,if the Gateway finds Internet headers that it cannot convert to X.400 equivalents, it copies such headers and values into an IA5 text bodypart. It then appends this text bodypart to the X.400 message being generated. This bodypart, however, may cause problems for some EDI agents. The administrator can control whether or not the Gateway adds this bodypart to X.400 messages. A new characteristic attribute, "RFC822 Headers", has been defined for this purpose. This can be modified using NCL or by the advanced set up procedure. When set to "On", the Gateway appends the bodypart to X.400 messages. This is the default.When set to "Off", the Gateway does not add the headers bodypart to X.400 messages. 12 Part III ________________________________________________________________ Restrictions and Documentation Errors This part lists the restrictions and documentation errors that apply to Version 2.3 and previous kits, as follows: - Section 4, Restrictions in this Version of the SMTP Gateway - Section 5, Restrictions in Other Products that Can Affect the SMTP Gateway 4 Restrictions in this Version of the SMTP Gateway This section describes restrictions in Version 2.3 of the SMTP Gateway. 4.1 Quotation Marks Must Be Omitted in Address Test Tool Input When entering an Internet address in the address test tool, you must not enclose encoded X.400 attributes in quotation marks. For example, when sending a message to the gateway you might use an address of the form To: "/OU=Finance/OU=Napier/PRMD=VEG/ADMD=NZ-PTT/C=NZ"@node8.x400 When entering the same address to the address test tool, however, you must omit the quotation marks: > /OU=Finance/OU=Napier/PRMD=VEG/ADMD=NZ-PTT/C=NZ@node8.x400 4.2 Syntactical Errors in O/R Addresses The SMTP Gateway always raises a Directory Configuration Error when a syntactically incorrect O/R address is constructed from a Foreign Address directory entry and data provided by the originator of an Internet message. The Problem Attribute in the Directory Configuration Error event is the full address received from Internet that would result in a syntactically incorrect O/R address. The gateway manager must examine this value and the corresponding Foreign Address entries in the directory to determine the origin of the error. A syntactical error might be either in one of these directory entries, or in the address supplied by the originator. The Constraint Error field indicates what sort of syntax error has occurred. This field has these possible values: o Too Many Characters Supplied An O/R term was too long, or contains non-printable characters. o Not Enough Characters Supplied An O/R name contains some Teletex attributes that would make up a Personal Name, but no Teletex Surname. o No Error 15 There is no error in the Foreign Address entry, but a constructed address would contain an incomplete set of Organisation Units, for example, /OU1 and /OU3 but no /OU2. 4.3 Bug in Example custom_decode Script The default custom_decode script shipped with Version 2.3 can fail on certain uuencoded bodyparts. Lines not labelled as compressed are inappropriately read and processed by an insufficiently precise grep command. 5 Restrictions in Other Products that Can Affect the SMTP Gateway This section lists restrictions in other products that can affect SMTP Gateway operation. 5.1 Exhange Server 5.5 and its handling of X.400 FTBP filenames Exchange Server 5.5 deviates from the ITU X.420 recom- mendation for FTBP filenames in that it does not handle designation and invocation sequences in FTBP filenames. It generates (and expects) a simple byte-sequence representing the filename itself. To co-exist with this non-compliance, the MAILbus 400 SMTP Gateway also generates (and expects) a simple byte- sequence in the X.400 FTBP pathname. It neither generates (nor expects) escape sequences in the pathname. Due to this absence of escape sequences, the Gateway has no way of knowing the character set used to represent the input X.400 filename.The Gateway thus assumes that the filename has been encoded in the widely-accepted default ISO 8859-1 character set (ISO repertoires 6 and 100).It conversely, also uses ISO 8859-1 to encode filenames in the X.400 messages it generates. Exchange Server, however, uses the Windows Codepage 850 are equivalent in the byte-codes they as sign to low-order characters(7- bit characters), they are incompatible in the byte-codes for high-order characters (with MSB containing a binary 1).To overcome this, a simple edit to the Windows NT registry is required on the Exchange Server machine. This 16 edit is required so that Exchange Server uses Codepage 1252 instead of the default Codepage 850 for X.400 filenames.Codepage (1252) is the nearest equivalent of ISO 8859-1 and use of this Codepage aids interoperability. This edit will not affect Exchange Server's interaction with other Exchange Servers, with Exchange/Outlook clients or with internet mail. For this edit, please follow these simple steps: 1. Login to the Windows NT machine (running Exchange Server) as 'administrator' and run 'regedit'. 2. In the registry window, in the left-hand pane, navigate to the Codepage page as follows: HKEY_LOCAL_MACHINE- >SYSTEM->CurrentControlSet->Control->Nls->CodePage. Now, in the right-hand pane, there appears a list of CodePages available on the machine. 3. Select the '(Default)' entry - this is usually the topmost entry and then select 'Edit->Modify' from the menu bar. 4. A window pops up that lets you modify the 'Value Data' for the entry (the '(Default)' entry). Change this 'Value Data' so that it reads c_1252.nls. 5. Then exit the registry and restart Exchange Server. Exchange Server will use Codepage 1252 now to encode X.400 filenames,and you are all set to use Exchange Server 5.5 MTA with MAILbus 400 MTA and MAILbus 400 SMTP Gateway. 5.2 Microsoft Exchange Address Encapsulation Problem in Some Releases In some releases of Microsoft Exchange, the Internet Mail Connector does not correctly encapsulate RFC 822 addresses for inclusion in X.400 Domain-Defined Attributes. 17 5.3 Sendmail Truncates Addresses Longer Than 200 Characters It is possible for Internet addresses longer than approximately 200 characters to be truncated by some sendmail implementations. If a recipient's address is truncated by sendmail, the message cannot be delivered to the recipient, and a non-delivery report is returned to the originator. Internet addresses themselves do not tend to exceed the 200 character limit. However, if your Internet users need to include long O/R addresses in Internet addresses in order to address X.400 users, this problem could occur. Therefore, if your O/R addresses tend to be very long, you should consider setting up partial address translations for these O/R addresses. Then, Internet users no longer need to include the long O/R addresses in Internet addresses. Part II of MAILbus 400 SMTP Gateway Managing describes in detail how to set up address translations. 5.4 Sendmail Removes Blind Carbon Copy Headers from Messages When translating between Internet and X.400 messages, one of the message headers that the SMTP Gateway translates is the Blind Carbon Copy (BCC) header. However, some sendmail implementations remove BCC headers from all Internet messages they process. When the SMTP Gateway exchanges messages with such a sendmail implementation, no BCC headers will be present on the messages exchanged between Internet and X.400 users. This is because sendmail removes the BCC headers on Internet messages before they reach the SMTP Gateway and also removes the BCC headers on the Internet messages that the SMTP Gateway generates from X.400 messages. 18 5.5 Two Digit Years used by External Software The Gateway internally deals with years in 4 digits. However, when presented with 2-digit years, the Gateway interprets the years as follows : If YY is between 81 and 99 (inclusive), then CC is 19. (i.e., YYYY is 1981 - 1999). If YY is between 00 and 80 (inclusive), then CC is 20. (i.e.,YYYY is 2000 - 2080). 19 Part IV ________________________________________________________________ Background to Previous Kits This part gives a brief description of previous Versions of the SMTP Gateway. This information was available in the Release Notes for the previous kits and so might be familiar to you. It includes: o Section 6, Changes Introduced in Version 2.2 o Section 7, Changes Introduced in Version 2.1C o Section 8, Changes Introduced in Version 2.1B o Section 9, Changes Introduced in Version 2.1A o Section 10, New Features for Version 2.1 o Section 11, Changes Since Version 2.0 o Section 12, Changes Since Version 1.* 6 Changes Introduced in Version 2.2 There are a few interoperability considerations that have been explained in the supporting document with this version. An MTA patch is being supplied with this release (mta_ pchild). This patch is not a bug fix patch, neither it is essential for full File Transfer Body Part (FTBP)functionality. It will be helpful (though not mandatory) in installations where X.400 user agents do not support FTBPs. Details can be found in the supporting document. 6.1 File Transfer Body Part Support With this release, the MAILbus 400 SMTP Gateway adds support for X.400 File Transfer Body Parts. File Transfer Body Parts (FTBPs) are the preferred means of transporting arbitrary binary bodyparts in X.400 messages with the X.400 (1992) series of recommendations. The earlier recommendations (1998 and before that, 1984) defined BP15 (Externally Defined) and BP14 (Bilaterally Defined) bodyparts respectively for carrying such information. FTBPs overcome several technical limitations of BP14s and BP15s. FTBPs store the attachment data (eg. Word document) along with certain parameters that let X.400 user agents process the attachment appropriately - parameters like the structure of the file, type of data being carried in the file, the name of the file, size of the file, creation date of the file, an identifier that identifies the application that can process the file, and so on. The X.400 series' definition of File Transfer Body Parts is very extensive, and is inconvenient for representation in MIME. Therefore, the Message Attachment Working Group (MAWG) of the Electronic Messaging Association (EMA) specified a restricted profile of the X.400 FTBP definition and this MAWG FTBP profile is followed by several X.400 software vendors. The MAILbus 400 Message Transfer Agent (MTA) and the MAILbus 400 SMTP Gateway (Gateway) follow the MAWG's FTBP profile. 23 6.1.1 Transformation of FTBPs in the X.400-to-MIME direction The Gateway accepts FTBPs in X.400 messages from the MTA and restructures them into MIME bodyparts according to the specifications in RFC 2157 (MIXER). The resulting Internet MIME bodyparts are labelled with: o a 'type/subtype' that correspond to the input X.400 FTBP data o a 'content-disposition' header, the parameters of which correspond to the input X.400 FTBP file-parameters like filename, creation date, modification date, read date, size (of the file), and so on. If the input FTBP has no filename, then the Gateway generates one. If the input FTBP is a result of the MTA's upgradation of a BP15 bodypart, then the MTA generates a filename before handing the message to the Gateway. There are some concerns in this area with FTBPs generated by Microsoft Exchange Server, which concerns have been explained below, in the section on interoperability. 6.1.2 Generation of FTBPs in the MIME-to-X.400 direction The Gateway generates X.400 FTBPs whenever the input MIME message bodypart satisfies certain conditions. These are, in that order: 1. the bodypart has a 'content-disposition' header, with value of 'attachment', optionally followed by file parameters, or 2. the bodypart has a 'type/subtype' of 'application /octet- stream', or 3. the bodypart has a 'name' parameter with its 'content- type' header. The first case usually implies that a file is being transferred in the bodypart. All the information in that header needs to be conveyed to the X.400 side. The X.400 bodypart that can convey this information is an FTBP, and the Gateway generates an FTBP. The second case is to ensure that when the type of data is unknown (indicated by 'application/octet-stream'), then the preferred means of carrying such data on the X.400 side is by means of FTBPs. 24 The third case is to preserve attachment names. Although use of the 'name' parameter has been deprecated by successive RFCs, certain vendors continue to use it to this day, and so the Gateway supports this to maximise interoperability. 6.1.3 Interoperability Notes 1. Some X.400 user agents do not yet support FTBPs. For message delivery to such user agents, the MTA downgrades FTBPs to BP15s or BP14s, whichever is supported by these user agents. In such cases, although the actual data being transferred is retained, there could be loss of the additional information that identifies data type. Also, when such user agents generate messages with attachments (either as BP14 or BP15 bodyparts), then the MTA upgrades such bodyparts to FTBP, adding as much information as it can ascertain or otherwise generate; information like the type of data, certain date fields, filenames, etc. In this regard, an optional MTA patch is being supplied with this release. Details about this patch can be found towards the end of this memo. The Gateway also generates certain desirable FTBP parameters when they are missing. 2. Certain aspects of FTBPs generated by Microsoft's Exchange Server deviate from the MAWG's FTBP profile. While this is not incorrect, it creates interworking problems. One such example is the semantics of the 'DOCUMENT_TYPE_NAME' parameter of an FTBP. This parameter indicates the structure of the file (whether byte sequence, record structure, etc.). The gatewaying RFCs rely on the semantics recommended by the MAWG's FTBP profile and the Gateway follows this. With Exchange deviating from this profile, there could be incompatibilities in this area. However, the Gateway relaxes some restrictions set in the RFCs so that interoperability can be maximised. 25 3. Another Exchange interworking difficulty is the use of the 'ENV_APPLICATION_REFERENCE' parameter of an FTBP. This parameter is meant to identify the application that can load or process the attachment. However, Exchange's FTBPs use one single value (the 'Generic MAPI Attachment' value) in this field for many different types of attachments. This makes it extremely difficult for the Gateway to identify the correct data type, and hence, the correct MIME 'content type /subtype' header values to use in its MIME output. If an FTBP coming from Exchange has a filename parameter, then this problem is avoided if the receiving MIME user agent can use the filename extension to determine the correct application to invoke to display the file to the user. 4. Yet another Exchange interworking issue is the apparent inability of Exchange to accept messages that contain the "last-read-date" parameter with an FTBP. There are three date parameters (all optional) that go with an FTBP; the "creation-date", "last-modification-date" and "last-read- date". These dates apply to the file being sent in the FTBP. Exchange accepts messages that contain the first two of these date parameters but rejects messages that contain the third parameter - the "last-read-date". However, this will probably not happen many times, because the Gateway only generates this parameter if the input MIME message had one; and of the messages that come from the Internet, those that come from an Exchange client do not have any dates at all. 6.1.4 "mta_mpchild" patch for the MAILbus 400 Message Transfer Agent This is an optional MTA patch, being supplied with this release. It is intended for MTAs running on Tru64 UNIX, and will be rolled into the next MTA release. This patch is NOT a bug-fix, NOR is it necessary for full and proper FTBP functionality. It is only a cosmetic modification of the already existing filename generator in the BP15-to- FTBP upgrade feature of the MTA, and will be useful (but not essential) in installations where some or all X.400 26 user agents do not support FTBP. To install this patch, follow the six steps below: 1. Shutdown the MTA 2. Change to the directory /usr/opt/MTAASRVRnnn/usr/sbin /mta/ 3. Make a backup of the "mta_pchild" image that's already there 4. Copy the new "mta_pchild" image there 5. Ensure that the new image has 'execute' permissions 6. Start the MTA Note that this patch image is based on MTA V2.0B and runs on Tru64 UNIX V4.0B and higher up to V5.0. If the MTA on your system is of a different version than V2.0B, then a suitable patch will be built for your system on request until the patch is rolled into the MTA as a standard feature. 6.1.5 Important: Note on Gateway setup When you install this version of the MAILbus 400 SMTP Gateway, please ensure that BEFORE you run "smtpgw_setup", you update your copy of the file "/var/smtpgw/content_ information.txt" so that it includes: 1. the Content Type {1 3 12 2 1011 5 5 0 1 22 1} and 2. the Encoded Information Type {2 6 1 12 0} for File Transfer Body Parts. This is required so that the MAILbus 400 MTA knows that it can transfer File Transfer Body Parts to and from the Gateway. A template file "/var/smtpgw/content_information.template" has been provided to help you do this. You should overwrite the ".txt" file with the new ".template" file before you run "smtpgw_setup". However, if you have customised the ".txt" file, then you will need to merge the two points above into the ".txt" file before running "smtpgw_setup". 27 6.2 Use of the Bodypart Mapping Table The Gateway has been using this table to correlate between MIME types and X.400 BP15 attachments. With FTBP support, the Gateway continues to use this table for mapping between X.400 FTBP data types and MIME bodypart types, and for generating filenames when they are absent. However, the Gateway now also uses the optional last column (column 8) from this table - this column contains the Object Identifiers (OIDs) registered at the EMA to uniquely identify various types of data. The OID for a particular data type is registered by the vendor that generates/owns that data type. These OIDs are used to identify FTBP data when any two X.400 services interact to exchange messages. In the mapping table, if this field is absent for a particular data type, it means that the vendor of that data type had not registered an OID with the EMA at the time the table was released with the Gateway. In such cases, the X.400 standards say that a special OID {2 16 840 1 113694 2 2 1 1} that represents an 'unnknown attachment' be used. In the absence of any other data-type identification information (like filename extension), MIME types of "application/octet-stream" correspond to this OID and vice versa. This release of the Gateway supplies a new copy of the mapping table. This is unrelated to FTBP support. The new copy only updates the table with records for some new data types like Office 2000 attachments. 6.3 O/R address mapping modification There was an issue with O/R address mappings in the inbound direction (i.e., SMTP -> to -> X.400). If an Internet mail address had no mapping and needed to be encapsulated within a Domain-Defined Attribute (DDA: RFC- 822), then the resultant O/R address would contain the partial address of the Gateway and the DDA: RFC-822. If the partial address of the Gateway contained only the COUNTRY and ADMD attributes, then the resulting O /R address would be invalid according to X.402. This would cause one X.400 user agent to fail while replying to such messages. The Gateway's address mapping was therefore modified to work around this issue. 28 For all outbound messages (MTA ->to-> SMTPGW ->to-> Internet), the Gateway's mapping remains unchanged. For all inbound messages, the following happens: 1. If the originator's address (Internet mail address) HAS a mapping in the MTS, then the behaviour is unchanged. The mapping is used to generate the X.400 O/R address. Such an address will be valid and in accordance with X.402. 2. If the originator's address does NOT have a mapping in the MTS, then: o If the resultant O/R address contains only the COUNTRY and ADMD fields besides the DDA (eg. "c=de; a=viat; *rfc- 822=a(a)b"), the Gateway derives a PersonalName from the Internet address of the originator and appends it to the O/R address already formed (eg. "c=de; a=viat; *rfc-822=a(a)b; g=firstname; s=lastname"). o If the resultant O/R address contains COUNTRY, ADMD and ANOTHER FIELD besides the DDA, then the Gateway's mapping is unchanged. 7 Changes Introduced in Version 2.1C 7.1 Certified on Multi CPU Machines The SMTP Gateway has been tested and certified for full functionality on Multi-CPU Alpha servers. The testing and certification was conducted with DIGITAL UNIX V4.0B and V4.0D running MTA V2.0C. 7.2 Handling improperly formed X.400 O/R addresses The Gateway has been made more robust in its handling of improperly formed O/R address structures in the headings of X.400 Messages. 7.3 Faster Encoders and Decoders The performance of the Gateways Base 64 encoder and decoder and Quoted Printable encoder has been improved. 29 7.4 New Template for the Bodypart Mapping Table The Gateway now comes with a new template for the MIME- Bodypart Mapping Table mbmt.cf. The template is named mbmt_221.template, and can be found in /var/smtpgw/, along with the earlier templates. The table has been updated with a few records, that enable the Gateway to recognize changes in the naming styles of certain types of document. 7.5 Handling encoded text/HTML attachments The Gateway now handles the decoding of Encoded Bodyparts that contain either text or HTML. 8 Changes Introduced in Version 2.1B 8.1 Year 2000 Compliance The MAILbus 400 SMTP Gateway also becomes Year 2000 Ready with its Version 2.1B release. Any two digit dates received by the Gateway are interpreted as follows: - Years "81" to "99" (inclusive) as "1981" to "1999" and - Years "00" to "80" (inclusive) as "2000" to "2080" MAILbus 400 SMTP Gateway is specified as Year 2000 Ready and will correctly process, calculate, compare and sequence date data from, into and between the twentieth and the twenty-first centuries and the years 1999 and 2000, including leap year calculations, when used in accordance with the associated Compaq Product documentation and provided that all hardware, firmware and software used in combination with such Compaq Products properly exchange date data with the Compaq Products. 8.2 Improved Handling of X.400 Trace Headers When passing through an X.400 Message Transfer System (MTS) consisting of several Message Transfer Agents (MTA's), several internal (internal to the MTS) trace headers are added to the message by each successive MTA. In one particular case, the Gateway would post an "Invalid X.400 Trace Header" error for a particular message arriving at the boundary. This problem has now been solved. 30 8.3 Tested also on Digital UNIX V4.0D The SMTP Gateway has been tested, successfully, for full functional capability on this new platform. No problems were encountered during the tests. 8.4 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. 9 Changes Introduced in Version 2.1A 9.1 General Functions o Delivery Status Notification(DSN)Correctly Formed o Thread-Safe System Libraries introduced o Repaired Transfer of Repertoire 1 Characters when Character Set Parameter is ISO-8859-1 o Changed Limit for Number of Connections to Server Process o Gateway Configurable to Receive 8-Bit Data bus Select Either 7-Bit or 8-Bit for Data Sent o IVP for NETMAN now running properly o More Accomodating MIME Boundaries 31 9.2 Changes Relating to the MIME X.400 Enhanced Relay (MIXER) o MIXER Conformance Enhanced o RFC 1327/MIXER Field Name Changes o Ordering of RFC 822 Headers now unchanged o Correction to Header Seperators 9.3 Changes in Addressing Functions o Removed Erroneous Parsing of Leading Hyphens o Improved Handling of Invalid sendmail Originator Field o No Segmentation Fault when PRMD term omitted from the Gateway's O/R Address o Successful Transfer of MIME Mail with many recipients o Successful Address Translation when O/R Address uses both Printable String and Teletex 9.4 Changes Relating to Headers o Corrected Parsing of Long Content-Type Field o "X-Disclose-Recipients:allowed" Setting now honoured o Corrected Mapping of Illegal Date Terms 10 New Features for Version 2.1 The following sections describe the new features that have been introduced in Version 2.1 of the SMTP Gateway. If upgrading, you must read the relevant chapter of MAILbus 400 SMTP Gateway Managing. 10.1 Support for the Multipurpose Internet Mail Extensions Defined in RFC 1522 The SMTP Gateway conforms to the Multipurpose Internet Mail Extensions (MIME) defined in RFC 1522. MIME is a standardized way of encoding headers and bodyparts that have always been difficult to transfer in RFC 822-based Internet systems, such as headers that use non-ASCII characters. 32 To manage the new RFC 1522 encodings, there is a new attribute of the SMTP-Gateway entity, Header Encoding. By default, however, the setting of the Header Encoding attribute makes the SMTP Gateway generate non-MIME headers. Further details of the Header Encoding attribute are in both MAILbus 400 SMTP Gateway Managing and the SMTP Gateway Module Online Help. More information about the SMTP Gateway's conformance to relevant RFCs is provided in Appendix E of MAILbus 400 SMTP Gateway Managing. RFC 1522 is provided with the SMTP Gateway and is located at /var/smtpgw/doc/rfc1522.txt. 10.2 Support for Parts of MIXER MIXER is an Internet draft that defines the MIME X.400 Enhanced Relay. MIXER was, when Version 2.1 of the SMTP Gateway was released, still evolving. Version 2.1 of the SMTP Gateway implements the parts of MIXER that were comparatively stable. MAILbus 400 SMTP Gateway Managing gives details of which parts of MIXER are implemented. For further changes related to MIXER, see section 3.2 of MAILbus 400 SMTP Gateway Release Notes Version 2.1A. 10.3 New Summary Event - Gateway Status There is now a summary event, Gateway Status, that gives the overall status of the SMTP Gateway and points to any error event that stops the SMTP Gateway from running normally. For further details of this event see MAILbus 400 SMTP Gateway Managing or the SMTP Gateway Module Online Help. 10.4 Support for Remote MTA This release can support an MTA running on a different node from the SMTP Gateway. See MAILbus 400 SMTP Gateway Managing for details. 33 11 Changes Since Version 2.0 This section lists some significant changes since Version 2.0 of the SMTP Gateway. For further details of all these changes, see MAILbus 400 SMTP Gateway Managing. 11.1 Interworking with Other MIME Products In Version 2.0 of the SMTP Gateway, the transfer of binary bodyparts between Microsoft Exchange[TM] and the SMTP Gateway caused problems. This was as a result of the different ways of identifying bodyparts used by Microsoft Exchange and the SMTP Gateway. 11.2 New X-Author Header When sending a message from X.400 to the Internet, if the originator address consisted only of a free form name, previous versions of the SMTP Gateway constructed an invalid From: field. When a free form name is the only indication of where a message came from, Version 2.1 of the SMTP Gateway no longer produces a From: field, but instead produces a new header, X-Author. 11.3 More Precise sendmail Rules In previous versions, the SMTP Gateway used imprecise sendmail rules. Version 2.1 has changed the rules in several major ways: o The rules now use only the SMTP Gateway's RFC 822 domain name. o The rules are easier to edit than in previous versions. See Appendix F of MAILbus 400 SMTP Gateway Managing for details of the new rewrite rules. 34 11.4 Changes in O/R Address Translation The method the SMTP Gateway uses for translating from X.400 O/R addresses to SMTP addresses, is different now from the method used in previous versions. Previous versions of the SMTP Gateway used an Internet address supplied in the RFC 822 DDA only if the remainder of the O/R address matched the SMTP Gateway's own address or was in the directory. Now, if an RFC 822 DDA supplies an Internet address, the SMTP Gateway uses that address irrespective of any other O/R address terms. This is in accordance with MIXER. 11.5 Running the Setup Procedure to Reinstate Rewrite Rules This version of the SMTP Gateway adds rewrite rules to sendmail.cf when the setup procedure runs. Previous versions added rewrite rules when the SMTP Gateway was installed, and used a script to reinstate them. This script is no longer a part of the SMTP Gateway kit; to reinstate rewrite rules you simply run the setup script. 12 Changes Since Version 1.* Changes noted in this section are additional to the ones noted in Section 11, and apply only if you are upgrading from a Version 1.* SMTP Gateway. If you are upgrading from a Version 2.0 SMTP Gateway you can omit this section. 12.1 Support for RFC 1327, RFC 1494 and RFC 1495 Since Version 2.0, the SMTP Gateway has conformed to RFC 1327, which defines how gateways should translate the headers on Internet messages and messages based on the 1988 X.400 recommendations. RFC 1327 also defines how to translate between the bodies of Internet and X.400 messages, though these definitions have been superseded by RFC 1494 and RFC 1495. Version 2.1 of the SMTP Gateway continues to conform to both RFC 1494 and 1495 as described in Appendix E of MAILbus 400 SMTP Gateway Managing. RFC 1327, 1494 and 1495 are provided with the SMTP Gateway and are located at: 35 /var/smtpgw/doc/rfc1327.txt /var/smtpgw/doc/rfc1494.txt /var/smtpgw/doc/rfc1495.txt 12.2 Untranslated Internet Message Headers Now Added to the End of X.400 Messages When the SMTP Gateway generates an X.400 message from an Internet message, it writes those Internet message headers that it could not translate into a text bodypart and places the bodypart at the end of the X.400 message. In Version 1.*, the SMTP Gateway added the untranslated Internet message headers in a bodypart at the beginning of the X.400 message. Note that the SMTP Gateway translates more Internet headers into X.400 headers than Version 1.*. This reduces the likelihood of a bodypart with untranslated Internet message headers being added to the end of the X.400 message. 12.3 Changes to the Way the SMTP Gateway Uses the MAILbus 400 MTA Since Version 2.0, the SMTP Gateway has not used the Shared File 1984 interface when connecting to the MAILbus 400 MTA; it uses the XAPI interface instead. Also, the SMTP Gateway no longer accesses the DIGITAL X.500 Directory Service directly; instead, it uses services provided by the MAILbus 400 MTA. As a result of these changes, two password attributes were added to the SMTP-Gateway entity: PW-Agent and PW-Domain. The PW-Agent attribute contains the password that provides the required authorization when the SMTP Gateway connects to the MTA. The PW-Domain attribute contains the password that provides the required authorization for the SMTP Gateway when it passes a request for directory information to the MTA. How to upgrade from a previous version of the SMTP Gateway is described in detail in MAILbus 400 SMTP Gateway Managing. 36 12.4 Use Setup Procedure Instead of Editing the Startup NCL Script The SMTP Gateway accesses and modifies information in the SMTP Gateway's startup NCL script each time you run the setup procedure. If you modify the SMTP Gateway's startup NCL script manually it is possible that the setup procedure subsequently fails to access or modify the information in the startup NCL script. Therefore we recommend that you always make changes to the SMTP Gateway's startup NCL script by running the setup procedure. 12.5 Additional Characteristic Attributes for Modifying Message Exchange A number of new characteristic attributes have been provided since Version 2.0 of the SMTP Gateway. With the exception of the Trace Logging attribute, these new attributes allow you to specify how the SMTP Gateway translates between X.400 and Internet messages. The new attributes are: Text Encoder Binary Encoder Character Set Character Translation Address Comments Trace Logging The SMTP Gateway is installed with values for these at- tributes that should be appropriate for most requirements. If you need to modify the settings of these attributes, run the SMTP setup procedure in the advanced mode. The new attributes and the setup procedure in the advanced mode are described in detail in Chapter 10 of MAILbus 400 SMTP Gateway Managing. 37 12.6 Changes to the add_map and remove_map Tools Changes have been made to the usage of the add_map and remove_map tools. You no longer need to use the -bothways parameter with the add_map tool in order to set up two address entries (that is, an O/R address entry and a foreign address entry) for the same user or group of users. In Version 2.0 of the SMTP Gateway, the following new parameters were introduced: o The -oneway parameter. Use this parameter to add different address entries to the directory, depending on whether an address translation is to be used in an originator or a recipient address. o The -x400user parameter. Use this parameter to add address entries to the directory for X.400 users. With this parameter only the Internet translation is added to a user's O/R address entry; no content information and routing instruction is added. o The -i parameter. This parameter replaces the -r parameter. Use the -i parameter to indicate an Internet address in an add_map or remove_map command. For example, the following command sets up two address entries for the same user, that is, an O/R address entry and a foreign address entry: % /var/smtpgw/scripts/add_map -o "c=nz;a=nz-ptt;p=veg;ou1=gisborne;ou2=domestic;s=nimble" -i nimble@domestic.veggies.com Always enter add_map and remove_map commands on one line; the commands in this section are printed on several lines for clarity. In the following example one address entry is set up, indicated by the -oneway parameter: % /var/smtpgw/scripts/add_map -o "c=nz;a=nz-ptt;p=veg;ou1=gisborne;ou2=export;s=jameson" -i jameson@export.veggies.com -oneway 38 Note also that the manpages for the add_map and remove_map tools are no longer available. Instead, you can obtain online help on the add_map and remove_map tools by typing: % /var/smtpgw/scripts/add_map (for help on the add_map tool) % /var/smtpgw/scripts/remove_map (for help on the remove_map tool) More information on the add_map and remove_map tools is provided in Chapter 7 of MAILbus 400 SMTP Gateway Managing. 12.7 Changes to the Settings of the Address Lookup Attributes The SMTP Gateway has the following attributes, which specify how the SMTP Gateway is to translate addresses on messages: Lookup Internet Users Lookup X400 Users In Version 1.* of the SMTP Gateway these attributes had three settings: Off, Optional and Mandatory. Since Version 2.0, the SMTP Gateway has had only two settings for these attributes: Optional and Mandatory. The functionality of the Off setting has been included in the Optional setting. Therefore, if you have used the Off setting before, accept the value Optional when setting up the SMTP Gateway during the upgrade to Version 2.1. 39