MAILbus 400 SMTP Gateway for_DIGITAL_UNIX______________________________ Release Notes Revision/Update Information: Version 2.1A Digital Equipment Corporation Maynard, Massachusetts __________________________________________________________ Digital Equipment 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 DIGITAL or an authorized sublicensor. Digital Equipment 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. © Digital Equipment Corporation 1995, 1997. All Rights Reserved. The following are trademarks of Digital Equipment Corporation: DECnet, DIGITAL, MAILbus, VAX DOCUMENT, and the DIGITAL 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.1A and Changes Introduced in Version 2.1A 2 Installing Version 2.1A...................... 7 3 Differences Between Version 2.1A and V2.1.... 8 3.1 General Functions........................ 9 3.1.1 Delivery Status Notification (DSN) Correctly Formed....................... 9 3.1.2 Thread-Safe System Libraries Introduced............................. 9 3.1.3 Repaired Transfer of Repertoire 1 Characters When Character Set Parameter is ISO-8859-1.......................... 9 3.1.4 Changed Limit for Number of Connections to Server Process...................... 10 3.1.5 Gateway Configurable to Receive 8-Bit Data but Select Either 7-Bit or 8-Bit for Data Sent.......................... 10 3.1.6 IVP for NETMAN Now Running Properly.... 11 3.1.7 More Accommodating MIME Boundaries..... 11 3.2 Changes Relating to the MIME X.400 Enhanced Relay (MIXER)................... 11 3.2.1 MIXER Conformance Enhanced............. 12 3.2.2 RFC 1327/MIXER Field Name Changes...... 13 3.2.3 Ordering of RFC 822 Headers Now Unchanged.............................. 13 3.2.4 Correction to Header Separators........ 13 iii 3.3 Changes In Addressing Functions.......... 13 3.3.1 Removed Erroneous Parsing of Leading Hyphens................................ 13 3.3.2 Improved Handling of Invalid sendmail Originator Field....................... 14 3.3.3 No Segmentation Fault When an Incoming X.400 IPM Has No PRMD in Originator Field.................................. 14 3.3.4 No Segmentation Fault When PRMD Term Omitted from Gateway's O/R Address..... 15 3.3.5 Successful Transfer of MIME Mail with Many Recipients........................ 15 3.3.6 Successful Address Translation when O/R Address Uses Both Printable String and Teletex................................ 15 3.4 Changes Relating to Headers.............. 15 3.4.1 Corrected Parsing of Long Content-Type Field.................................. 15 3.4.2 "X-Disclose-Recipients: allowed" Setting Now Honoured................... 16 3.4.3 Corrected Mapping of Illegal Date Terms.................................. 16 Part III Restrictions and Documentation Errors 4 Restrictions in This Version of the SMTP Gateway...................................... 19 4.1 Quotation Marks Must Be Omitted in Address Test Tool Input.................. 19 4.2 Syntactical Errors in O/R Addresses...... 19 4.3 Bug in Example custom_decode Script...... 20 5 Restrictions in Other Products That Can Affect the SMTP Gateway ..................... 20 5.1 Microsoft Exchange Address Encapsulation Problem in Some Releases................. 20 5.2 Sendmail Truncates Addresses Longer Than 200 Characters........................... 20 5.3 Sendmail Removes Blind Carbon Copy Headers from Messages.................... 21 iv Part IV Background to Previous Kits 6 New Features for Version 2.1 ................ 25 6.1 Support for the Multipurpose Internet Mail Extensions Defined in RFC 1522...... 25 6.2 Support for Parts of MIXER............... 25 6.3 New Summary Event - Gateway Status ...... 26 6.4 Support for Remote MTA................... 26 7 Changes Since Version 2.0.................... 26 7.1 Interworking with Other MIME Products.... 26 7.2 New X-Author Header...................... 26 7.3 More Precise sendmail Rules.............. 27 7.4 Changes in O/R Address Translation....... 27 7.5 Running the Setup Procedure to Reinstate Rewrite Rules............................ 27 8 Changes Since Version 1.*.................... 27 8.1 Support for RFC 1327, RFC 1494 and RFC 1495..................................... 28 8.2 Untranslated Internet Message Headers Now Added to the End of X.400 Messages....... 28 8.3 Changes to the Way the SMTP Gateway Uses the MAILbus 400 MTA ..................... 28 8.4 Use Setup Procedure Instead of Editing the Startup NCL Script................... 29 8.5 Additional Characteristic Attributes for Modifying Message Exchange............... 29 8.6 Changes to the add_map and remove_map Tools.................................... 30 8.7 Changes to the Settings of the Address Lookup Attributes........................ 31 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.1A of the MAILbus 400 SMTP Gateway for DIGITAL[TM] UNIX[R]. They describe: o Information about installing this kit (see Section 2). o Differences between Version 2.1 and this kit (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.1A and Changes Introduced in Version 2.1A This part is divided into two main sections, as follows: o Section 2 describes how to install Version 2.1A of the SMTP Gateway. o Section 3 describes the differences between Version 2.1A and Version 2.1 of the SMTP Gateway. 2 Installing Version 2.1A 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: - DIGITAL UNIX V3.2G DECnet[TM]/OSI[R] for DIGITAL UNIX V3.2B MAILbus 400 MTA for DIGITAL UNIX (Base and Mgt Subsets) V2.0 DIGITAL X.500 Directory Service for DIGITAL UNIX (Base Subset) V3.0 - 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 MAILbus 400 MTA for DIGITAL UNIX (Base and Mgt Subsets) V2.0A, or later DIGITAL X.500 Directory Service for DIGITAL UNIX (Base Subset) V3.1, 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. _______________________________________________________ Subset Title Subset name Space Required in ____________________________________________/usr______/var MAILbus 400 SMTP SXANETMAN217 100kB 50kB Management 7 _______________________________________________________ Subset Title Subset name Space Required in ____________________________________________/usr______/var MAILbus 400 SMTP Gateway SXABASE217 1550kB 400kB MAILbus 400 SMTP SXADOC217 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/sxa217/kit o The command to run the verification procedure (VP) is: # setld -v SXABASE217 The version number of this kit when displayed using NCL management is V2.1.7. 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.1A ddd mmm nn hh:mm:ss GMT 1997 3 Differences Between Version 2.1A and V2.1 Note that these notes specify all substantive changes made since the release of Version 2.1 of the SMTP Gateway. A small number of users of Version 2.1 have received interim kits to deal with individual problems. The kits had filenames and processes numbered 211-216. This release is numbered Version 2.1A but its kit number is 217; for example, the subset name is SXABASE217. Version 2.1A supersedes any kit that you may have received since the Version 2.1 release in 1996. 8 3.1 General Functions 3.1.1 Delivery Status Notification (DSN) Correctly Formed The content-type of a DSN should be message/delivery- status, not the illegally formed message-delivery-status. This is now corrected. 3.1.2 Thread-Safe System Libraries Introduced The use of thread-unsafe system libraries could cause abnormal exits in the gateway's agent process in previous versions. The agent process for the SMTP Gateway is now linked against thread-safe libraries. 3.1.3 Repaired Transfer of Repertoire 1 Characters When Character Set Parameter is ISO-8859-1 Previous versions of the MAILbus 400 SMTP Gateway have failed to transfer some characters of Repertoire 1 when transferring mail from SMTP to X.400 when the Character Set parameter is ISO-8859-1. Repertoire 1 consists of the first 32 ASCII characters. Form Feed is the most notable of the characters that are not successfully transferred: of the other Repertoire 1 characters, Carriage Return and Line Feed are correctly transferred in all versions of the SMTP Gateway. The remaining characters, for example Back Space, BEL, and SUB, are not typically found in mail messages. This no longer happens. All Repertoire 1 characters are successfully transferred. Note: A gateway should typically not affect the text of messages it transfers: the MAILbus 400 SMTP Gateway makes a special case of transferring Repertoire 1 characters from SMTP to X.400 in order to ensure that text lines are terminated by Carriage Returns and Line Feeds. SMTP Gateway inserts Carriage Returns in lines terminated by Line Feeds. Such lines of text are common in the UNIX world, and some SMTP systems transfer files in this format even though the RFC 821 insists on the Carriage Return-Line Feed form. In order to be tolerant of what it receives from SMTP while being strict about what it transfers to X.400, the SMTP Gateway may correct the line terminators in text messages. 9 3.1.4 Changed Limit for Number of Connections to Server Process The SMTP Gateway no longer limits to 4 the number of connections to its server process (including the daemon's connection to the server). The server can now accept an absolute limit of 50 connections at once, but if the MAXIMUM AGENT CONNECTIONS parameter of the MTA module is less than 50, this limit will be respected. Increasing the MAXIMUM AGENT CONNECTIONS and the related OSI module parameter MAXIMUM TRANSPORT CONNECTIONS to take maximum advantage of this change is not recommended, as this may have a detrimental effect on overall system performance. Heavy load testing has never caused the maximum number of mailer connections to exceed 19, so a MAXIMUM AGENT CONNECTIONS setting of 20 (in addition to the requirements of any other MTA agents on the system) should be sufficient to ensure that messages are only queued within sendmail as the result of a bottleneck within sendmail itself. 3.1.5 Gateway Configurable to Receive 8-Bit Data but Select Either 7-Bit or 8-Bit for Data Sent The SMTP Gateway's interpretation of certain combinations of existing configuration parameters has changed to allow a new method of operation. In V2.1 the SMTP Gateway interpreted a Character Set parameter of ISO-8859-1 as meaning that eight-bit header data should be both accepted from and sent to sendmail. There was no method of configuring the gateway to accept data from a local eight-bit sendmail but to allow for a remote recipient to be not using eight-bit sendmail or an eight-bit enabled mail reader to read the header fields. The Text Encoder parameter could be set to quoted- printable to send messages to eight-bit sendmail in a seven-bit format, but - even with the Header Encoder parameter set to MIME - the headers would be sent to sendmail in eight-bit form and might be unreadable at their destination. 10 Now, the SMTP Gateway uses the Text Encoder parameter instead of the Character Set parameter in determining whether to bypass Header Encoding. This parameter is a better indication of whether sendmail recipients are capable of receiving eight-bit data. The combinations of parameters that have changed and their effects on the RFC 1522 encoding of Subjects and Freeform names on mail sent from X.400 to SMTP are: Header Encoding = MIME Character Set = ISO-8859-1 Text Encoder = quoted-printable (which ensures RFC 1522 encoding), and Header Encoding = MIME Text Encoder = 8bit-wrap or 8bit-nowrap (which calls for no RFC 1522 encoding) All combinations of parameters not listed above have not had their meanings changed since V2.1. 3.1.6 IVP for NETMAN Now Running Properly Previously, the Gateway's Installation Verification Procedure would fail when checking the NETMAN subset, for several internal reasons. This has been corrected for Version 2.1A. 3.1.7 More Accommodating MIME Boundaries In line with RFC 1521, earlier versions of the Gateway used space characters in MIME boundaries. This caused interworking problems with some other user agents that were not precisely MIME-conformant. In Version 2.1A, space characters have been removed from MIME boundaries and replaced with underscores. 3.2 Changes Relating to the MIME X.400 Enhanced Relay (MIXER) 11 3.2.1 MIXER Conformance Enhanced The Gateway now conforms to those mappings of RFC 822 header fields to and from X.400 Service Elements defined in the core MIXER document, with qualifications in these areas: o PD-OFFICE NUMBER The SMTP Gateway cannot handle OR-name terms containing spaces in mail sent from SMTP to X.400. MIXER suggests PD-OFFICE NUMBER as an additional synonym for the term the SMTP Gateway can already use under the names PD- OFFICE-NUM, PD-OFN, and the (non-standard) PD-OFFICE- NUMBER. Attempting to use PD-OFFICE NUMBER will not have the result of adding the MH_T_POSTAL_OFFICE_NUMBER to the X.400 IPM. Instead, the SMTP Gateway adds the X.400 element corresponding to PD-OFFICE (MH_T_POSTAL_ OFFICE_NAME). o Content-Languages: header The SMTP Gateway does not support the Content-Languages header defined in MIXER, but continues to use an enhanced version of the "Language:" field from RFC 1327. This language field supports the use of more than one language. o FTBP parameters defined in the MIXER-BODYMAP document The Gateway does not conform to the mappings of MIME headers to and from File Transfer Bodypart (FTBP) parameters defined in the MIXER-BODYMAP document. Version 2.1A, like V2.1, processes Externally Defined Bodyparts, and relies on the MTA to perform conversions between these two formats. The Gateway itself does not either generate or accept FTBPs. o Unmappable RFC 822 headers not preserved in an IPMS extension. Version 2.1A does not implement this MIXER function, just as Version 2.1 did not conform to RFC 1327 in this respect (see the SPD). The SMTP Gateway, on receiving an RFC 822 header that it cannot map directly to an X.400 header, encodes it as IA5 text (as MIXER recommends only for interworking with a 1984 MTA). 12 3.2.2 RFC 1327/MIXER Field Name Changes The following fields have had their names changed between RFC 1327 and MIXER and have been changed for Version 2.1A: o Content-Identifier: is now X400-Content-Identifier: o Expiry-Date: is now Expires: o Obsoletes: is now Supersedes: 3.2.3 Ordering of RFC 822 Headers Now Unchanged In UNIX versions prior to V4.0, sendmail re-ordered some RFC 822 Header fields that were passed to it by the Gateway when translating messages from X.400 to SMTP. This meant that, although the Gateway obeyed the rule in MIXER that says that "X400-Received:" and "Received:" should be the first headers on the message, this format was not preserved by the sendmail transport. In UNIX V4.0, sendmail no longer re-orders these fields, so the behaviour of the Gateway has been corrected. 3.2.4 Correction to Header Separators The standards defining the SMTP header fields constructed by the SMTP Gateway (that is, RFC 1327 and MIXER) state that the action codes in an X400-Received Header and the mailboxes in an X400-Recipient Header should be lists separated with commas. Previous versions of the SMTP Gateway separated the action codes with semi-colons and the mailboxes with spaces: this is now corrected. 3.3 Changes In Addressing Functions 3.3.1 Removed Erroneous Parsing of Leading Hyphens Previous versions of the SMTP Gateway performed in- sufficient parsing on recipient information provided by sendmail. In particular, recipient names beginning with hyphens were interpreted by the Gateway as being command line arguments to the mailer image, in addition to those provided by the sendmail configuration file. The most likely reason for a hyphen to be at the start of an Internet address is that a user or application accidentally added some UNIX-style command line options to their address in the belief that they would be interpreted by the sending application as though they were system command line options. 13 For example a recipient address beginning "-r" would be interpreted by the mailer as being a second originator for the mail, as the "-r" command line option is used by the sendmail configuration file to specify the Originator parameter. SMTP Gateway now prevents Recipients from being in- terpreted as command line options, by removing leading hyphens from the Recipients: field. 3.3.2 Improved Handling of Invalid sendmail Originator Field Previous versions of the SMTP Gateway crashed when attempting to send non-delivery messages to malformed Originator addresses provided by sendmail. On detecting an invalid Originator, the SMTP Gateway immediately attempted to construct a Delivery Service Notification (DSN) before it had read (from sendmail) the Recipient information it would need to include in the DSN itself. The resultant crash would cause a sendmail non-delivery message to be sent, but the original message would not be removed from the queue. This caused multiple non-deliveries for the same message. Rather than attempting to send its own DSN on receiving a malformed Originator, the SMTP Gateway now exits with an EX_NOUSER code. This causes sendmail to generate its own non-delivery message, which will probably not be successfully transferred (as the Originator is malformed); but sendmail's own loop detection mechanism will prevent the non-delivery message being returned to the MAILER- DAEMON. 3.3.3 No Segmentation Fault When an Incoming X.400 IPM Has No PRMD in Originator Field An SMTP Gateway running on UNIX V3.2D or higher no longer exits with a segmentation fault on receiving an IPM from X.400 that does not contain a PRMD term in its Originator field. 14 3.3.4 No Segmentation Fault When PRMD Term Omitted from Gateway's O/R Address If the SMTP Gateway is running on DIGITAL UNIX V3.2D or higher, and the SMTP Gateway is configured to have no PRMD term in its O/R address, then the SMTP Gateway no longer exits with a segmentation fault when mail is sent from SMTP to X.400 or when an X.400 Delivery Report is translated to an ESMTP-style Delivery Service Notification. 3.3.5 Successful Transfer of MIME Mail with Many Recipients The SMTP Gateway successfully transfers mail from X400 to SMTP when the message contains a large number of recipients and the Header Encoding attribute is set to MIME. 3.3.6 Successful Address Translation when O/R Address Uses Both Printable String and Teletex The SMTP Gateway successfully finds the SMTP version of an O/R address in the directory when the O/R address contains Printable String and Teletex values for the same term. 3.4 Changes Relating to Headers 3.4.1 Corrected Parsing of Long Content-Type Field If a MIME Content-Type field is too long to be readable on a single line, for example, if the field and its value are more than 80 characters in total, a mail agent will typically break the value into multiple lines, indenting the second and subsequent lines of the field's value with white space characters (as described in RFC 822). Previous versions of SMTP Gateway would only treat SPACE characters as white space in this context. The SMTP Gateway now correctly treats both TAB and SPACE characters as white space in all continuation lines in messages it receives from sendmail. Note that the indenting of continuation lines with white space is not a convention specific to the Content-Type field, but it was only in this header field that the problem occurred. 15 3.4.2 "X-Disclose-Recipients: allowed" Setting Now Honoured When translating an address from SMTP to X.400, the Gateway would previously accept only "X-Disclose- Recipients: true" as meaning that the Gateway should disclose recipients; anything apart from "true" was interpreted as "false" - even "allowed". Version 2.1A now interprets the setting "X-Disclose-Recipients: allowed" correctly, as is required for interworking with gateways that implement RFC 1327. 3.4.3 Corrected Mapping of Illegal Date Terms If a date component in one of three header fields is present on an SMTP message being transferred to X.400 by the SMTP Gateway, and the format of that date does not conform to the format defined in RFC 822, previous versions of the SMTP Gateway could map these dates into equally illegal X.400 date elements. These fields were Received, X400-Received, and DL-Expansion-History. If a date component in one of the above fields is malformed, the entire field is now included in the RFC 822-Headers text bodypart instead of being mapped to an X.400 element. Note that previous versions of the SMTP Gateway have correctly handled malformed dates in the "Date:" field. 16 Part III ________________________________________________________________ Restrictions and Documentation Errors This part lists the restrictions and documentation errors that apply to Version 2.1A and previous kits, as follows: o Section 4, Restrictions in This Version of the SMTP Gateway o 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.1A 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 19 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.1A 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 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. 5.2 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. 20 5.3 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. 21 Part IV ________________________________________________________________ Background to Previous Kits This part gives a brief description of Version 2.1 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, New Features for Version 2.1 o Section 7, Changes Since Version 2.0 o Section 8, Changes Since Version 1.* 6 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. 6.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. 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. 6.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 Section 3.2. 25 6.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. 6.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. 7 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. 7.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. 7.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. 26 7.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. 7.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. 7.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. 8 Changes Since Version 1.* Changes noted in this section are additional to the ones noted in Section 7, 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. 27 8.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: /var/smtpgw/doc/rfc1327.txt /var/smtpgw/doc/rfc1494.txt /var/smtpgw/doc/rfc1495.txt 8.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. 8.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. 28 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. 8.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. 8.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 29 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. 8.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 30 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 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. 8.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. 31