Solstice™ X.400 Messaging Server 9.0 Administrator’s Guide
A Sun Microsystems, Inc. Business 2550 Garcia Avenue Mountain View, CA 94043 U.S.A.
Part No: 802-5045-10 Revision A, February 1996 1996 Sun Microsystems, Inc. 2550 Garcia Avenue, Mountain View, California 94043-1100 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Portions of this product may be derived from the UNIX® system, licensed from UNIX System Laboratories, Inc., a wholly owned subsidiary of Novell, Inc., and from the Berkeley 4.3 BSD system, licensed from the University of California. Third-party software, including font technology in this product, is protected by copyright and licensed from Sun’s suppliers. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19. The product described in this manual may be protected by one or more U.S. patents, foreign patents, or pending applications.
TRADEMARKS Sun, Sun Microsystems, the Sun logo, SunSoft, the SunSoft logo, SunLink, Solstice, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd. OPEN LOOK is a registered trademark of Novell, Inc. PostScript and Display PostScript are trademarks of Adobe Systems, Inc. All SPARC trademarks are trademarks or registered trademarks of SPARC International, Inc. in the United States and other countries. SPARCcenter, SPARCcluster, SPARCompiler, SPARCdesign, SPARC811, SPARCengine, SPARCprinter, SPARCserver, SPARCstation, SPARCstorage, SPARCworks, microSPARC, microSPARC-II, and UltraSPARC are licensed exclusively to Sun Microsystems, Inc. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK® and Sun™ Graphical User Interfaces were developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements. X Window System is a trademark of X Consortium, Inc. THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN. THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THE PUBLICATION. SUN MICROSYSTEMS, INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAMS(S) DESCRIBED IN THIS PUBLICATION AT ANY TIME.
Please Recycle Contents
Part 1 —Introducing Solstice X.400 and its Configuration Tool 1. Introducing the Solstice X.400 Messaging System ...... 1 Overview of an X.400 Message Handling System ...... 1 The X.400 MHS Protocols ...... 4 X.400 Management Domains ...... 6 X.400 Addressing ...... 7 Routing Messages in the X.400 Domain ...... 14 The Solstice X.400 Message Store...... 14 The Solstice X.400 Internet Adaptor ...... 15 Routing Messages in the Internet Mail Domain ...... 15 Routing Messages from Internet Mail to X.400 ...... 16 Routing Messages from X.400 to Internet Mail ...... 18 Supported Mail Header Fields...... 19 X.400 Use of X.500 Directory Services ...... 20 Introducing the RFC1006 Driver...... 21
iii 2. Starting and Using x400tool...... 23 Before You Start ...... 24 Starting x400tool on Your Local Machine ...... 25 Starting x400tool on a Remote Machine ...... 25 Using x400tool ...... 26 Starting and Stopping X.400 Processes ...... 28 Backing Up Your Configuration...... 29 Restoring an Existing Configuration ...... 29 Printing Your Configuration...... 30 Locating x400tool Files ...... 31 3. Overview of Configuring Your Messaging System...... 33 Adding Information about Messaging Servers ...... 33 Local Message Store Using a Local MTA ...... 34 Local Message Store Using a Remote MTA ...... 35 Local MTA Using a Remote Message Store ...... 36 Adding Information about the Internet Mail Adaptor ...... 37 Adding Information about User Agents and DSAs...... 37 Part 2 —Configuring Your Messaging Server 4. Configuring Your Local Messaging Server ...... 41 Specifying Your Local Server Name ...... 42 Setting an Access Control Password ...... 42 Specifying Your Global Domain Identifier ...... 44 5. Tuning Your Local Messaging Server ...... 45
iv Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Tuning Associations...... 46 Tuning Basic Associations...... 46 Tuning Other Association Options ...... 48 Tuning the Reliable Transfer Service ...... 52 Tuning the Security Options...... 54 Tuning the Remote Operations Service...... 56 Tuning the Session Layer ...... 58 Setting the Type of Report Requested by Outgoing Messages. 61 Tuning the MTA Timer Tolerance ...... 62 Tuning Congestion Thresholds ...... 62 Enabling Message Tracking ...... 64 6. Adding Remote Server Information to Your Messaging System65 Adding or Changing Information About a Remote Messaging Server...... 66 Specifying a Name and Type for the Remote Server...... 67 Enabling and Disabling Access Control for a Remote MTA 68 Specifying the Global Domain Identifier of a Remote MTA 69 Selecting the Version of X.400 Supported by the Remote MTA70 Selecting the Version of RTS Supported by the Remote MTA 70 Specifying the OSI Address of the Remote Server...... 71 Adding Information About an X.500 DSA ...... 73 7. Testing and Tuning Connections to a Remote MTA ...... 75 Tuning the Remote MTA Association Options...... 76 Testing an MTA Association ...... 77
Contents v Configuring Routes to a Remote MTA ...... 80 Setting a Default MTA...... 80 8. Adding Message Store User Information to Your Messaging System...... 83 Creating a Message Store User Group...... 83 Configuring Message Store User Information ...... 86 Adding Message Store User Information ...... 86 Updating and Deleting Message Store User Information. . 88 9. Adding Third-Party Agents to Your Messaging System . . . . 89 Adding and Configuring Third-Party User Agents...... 89 Adding a Third-Party User Agent ...... 90 Specifying the User Agent Name and Type ...... 91 Enabling and Disabling User Agent Access Control...... 92 Specifying the Body Types Supported ...... 93 Specifying the Standard Content Types Supported...... 94 Specifying the Non-Standard Content Types Supported . . 95 Configuring Routes to a User Agent ...... 95 Adding and Configuring X.400 MT (P1) Agents ...... 96 Adding a Third-Party P1 Agent...... 96 Specifying the P1 Agent Name ...... 96 Enabling and Disabling P1 User Access Control ...... 97 Specifying the Type of P1 Access...... 97 Specifying the Global Domain Identifier ...... 98 Configuring Routes to a P1 Agent ...... 99
vi Solstice X.400 Messaging Server Administrator’s Guide—February 1996 10. Routing Between Messaging Components...... 101 Routing in the X.400 Domain ...... 101 Default Routing Entries...... 103 Modifying the Default Routing Table ...... 103 Deleting an Existing Routing Entry...... 104 Specifying Alternate Recipients ...... 104 Testing the Routing Algorithm...... 106 Part 3 —Configuring and Using Your Internet Mail Adaptor 11. Configuring the Solstice X.400 Internet Adaptor...... 111 Before You Start ...... 112 Software Requirements for the Solstice X.400 Internet Adaptor 112 Determining Your Internet Domain Address...... 113 Adding Solstice X.400 Internet Adaptor Information ...... 115 Adding the Pseudo Host Name to the NIS Database ...... 118 Modifying sendmail.cf to Add a Pseudo Host Name Manually 119 12. Testing and Tuning the Solstice X.400 Internet Adaptor . . . . 121 Testing the Solstice X.400 Internet Adaptor ...... 122 Checking the Address Conversion ...... 122 Sending a Test Message...... 123 Modifying the Mapping Tables ...... 126 Using the Mapping Table Editor ...... 126 Replacing a Deleted Solstice X.400 Internet Adaptor ...... 129 Configuring Routes to the Solstice X.400 Internet Adaptor . . . 129
Contents vii Modifying the sendmail Configuration File for the Internet Adaptor...... 130 Using the gen_sendmail.cf Script ...... 130 Modifying sendmail.cf Manually ...... 131 13. Sending and Receiving Internet Mail Through the Internet Adaptor ...... 133 Sending Messages Using Internet Mail Applications ...... 133 Addressing Messages Through the Solstice X.400 Internet Adaptor...... 134 Using X.400 Mail Header Fields in mailtool...... 135 Sending Messages Containing International Character Sets 136 Mapping X.400 and Internet Addresses ...... 138 Part 4 —Managing Your Messaging System 14. Managing Your Messaging System with x400tool ...... 141 Displaying OSI Addressing Information ...... 142 Displaying Status Information ...... 143 Changing the Tool Properties...... 143 Activating a Status Window...... 144 Refreshing a Status Window Manually...... 144 Printing the Current Status...... 144 Displaying the Status of the Local MTA ...... 145 Displaying the Status of a Remote MTA...... 146 Displaying the Status of a Message Store User Group . . . . 149 Displaying the Status of the Solstice X.400 Internet Adaptor 151 Displaying the Status of a User Agent ...... 153
viii Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Stopping and Starting Statistics Collection...... 154 Opening and Closing Agents ...... 154 Opening a Closed Agent...... 155 Closing an Open Agent...... 155 Purging the Message Queues ...... 156 Purging the First Message in the Queue ...... 156 Purging Messages for a Specific Agent ...... 157 Purging All Incoming Messages ...... 158 Purging All Outgoing Messages ...... 158 Purging a Message Store ...... 159 Backing Up and Restoring Message Stores...... 160 15. Managing Your Messaging System with Command-Line Tools 163 Journal Files ...... 163 Regenerating the Configuration from Text ...... 164 Using the MTA Database Tools ...... 166 Using x400trace ...... 167 Trace Examples...... 168 Using x400decode ...... 170 Part 5 —Appendices A. Error Messages ...... 173 Errors Returned by x400tool...... 173 Errors Returned by the RFC1006 Driver Utilities ...... 182 rk6d Daemon Errors...... 182
Contents ix rkstat Errors ...... 183 rk6trace Errors ...... 183 Alarms Returned by the Messaging System...... 184 Messages Returned by the OSI Alarmer ...... 189 Abnormal Events Returned by the Messaging System ...... 190 Errors Indicating Rejected RFC1006 Connections ...... 192 B. Technical Specification and Conformance Information. . . . . 193 ITU (CCITT) MHS Recommendations Overview ...... 194 Solstice X.400 Messaging Server Feature List...... 195 MT Service Elements (P1) ...... 195 IPM Service Elements ...... 197 Message Store Service Elements ...... 200
x Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Figures
Figure 1-1 The X.400 Message Handling System Model ...... 2 Figure 1-2 Exchanging Messages Between Users ...... 5 Figure 1-3 The Global Domain Identifier for an MTA ...... 6 Figure 1-4 O/R Address Conventions ...... 9 Figure 1-5 Routing Messages in the Internet Mail Domain ...... 15 Figure 1-6 Routing Mail from Internet Mail to X.400 Mail...... 17 Figure 1-7 Routing Messages from X.400 Mail to Internet Mail ...... 18 Figure 1-8 MTA Use of an X.500 Directory Service...... 20 Figure 1-9 RFC1006 Driver and Higher Layer Entities...... 21 Figure 2-1 x400tool: Main Window ...... 27 Figure 2-2 x400tool: Starting and Stopping Processes ...... 28 Figure 3-1 Local Message Store User Group using Local MTA...... 34 Figure 3-2 Local Message Store User Group using Remote MTA...... 35 Figure 3-3 Local MTA Serving Remote Message Store User Group. . . . . 36 Figure 4-1 Setting an Access Control Password for the Local MTA. . . . . 43 Figure 4-2 Specifying the Global Domain Identifier for the Local MTA . 44
xi Figure 5-1 Resource Sharing During a Shortage Condition...... 46 Figure 5-2 Tuning the Association Thresholds ...... 47 Figure 5-3 Association Thresholds Based On Number of Messages . . . . 49
Figure 5-4 Association Thresholds Based On Time Spent in Queue . . . . 50 Figure 5-5 Remote MTA Association Priority ...... 51 Figure 5-6 Tuning the Reliable Transfer Service ...... 52 Figure 5-7 Setting the MTA Connection Validation ...... 54 Figure 5-8 Specifying the Restrictions Placed on the O/R Name ...... 55 Figure 5-9 Tuning the Remote Operations Service ...... 57 Figure 5-10 Tuning the Session Layer ...... 58 Figure 5-11 Defining the Report Request ...... 61 Figure 5-12 Defining the Timer Tolerance ...... 62 Figure 5-13 Tuning the Congestion Thresholds...... 63 Figure 6-1 Remote Server Configuration Window ...... 67 Figure 6-2 Specifying the Global Domain Identifier for a Remote MTA . 69 Figure 6-3 Remote Directory (X.500) Window...... 73 Figure 7-1 Tuning the Remote MTA Association Management Options. 76 Figure 7-2 Using the Trigger...... 78 Figure 7-3 Unsuccessful Trigger Attempt...... 79 Figure 8-1 Message Store User Group Configuration Window ...... 84 Figure 8-2 Message Store User Configuration Window...... 86 Figure 9-1 Adding a Third-Party User Agent ...... 90 Figure 9-2 Enabling and Disabling Access Control for a User Agent. . . . 92 Figure 9-3 Specifying Non-Standard Content Types ...... 95 Figure 9-4 Specifying the Type of P1 Access ...... 98
xii Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Figure 9-5 Specifying the Global Domain Identifier ...... 99 Figure 10-1 Example Routing Entries ...... 102 Figure 10-2 Creating an Alternate Recipients ...... 105
Figure 10-3 Testing the Routing Algorithm ...... 107 Figure 11-1 The Solstice X.400 Internet Adaptor Configuration Window. 115 Figure 12-1 Test Address Conversion for the X.400 Internet Adaptor. . . . 122 Figure 12-2 Internet Mail Message Sent Through the X.400 Internet Adaptor ...... 124 Figure 12-3 Internet Mail Message Received Through the X.400 Internet Adaptor ...... 125 Figure 12-4 Mapping Table Editor...... 127 Figure 12-5 Mapping Editor Filter ...... 128 Figure 13-1 Defining a Custom Mail Header ...... 135 Figure 13-2 Adding a Custom Header ...... 136 Figure 13-3 International Characters in the Internet Mail Domain...... 137 Figure 13-4 International Characters Through the X.400 Internet Adaptor 137 Figure 14-1 x400tool: Changing the Tool Properties...... 143 Figure 14-2 MS Group Status Window ...... 150 Figure 14-3 Closed Message Transfer Agent Icon ...... 155 Figure 14-4 Open Message Transfer Agent Icon ...... 155 Figure 14-5 Purging Messages in a Queue ...... 157 Figure 14-6 Purging Incoming Messages ...... 158 Figure 14-7 MS Users Mailbox Backup Window...... 161
Figures xiii xiv Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Tables
Table 1-1 Attribute Categories ...... 7 Table 1-2 Standard Attribute Keys...... 8 Table 1-3 Supported Mail Header Fields ...... 19 Table 4-1 Access Control Algorithm ...... 43 Table 6-1 Access Control Algorithm ...... 68 Table 8-1 Mandatory and Conditional Message Store User Parameters 87 Table 9-1 Standard Body Types Defined by the X.400 Recommendations ...... 93 Table 9-2 Standard Content Types Defined by the X.400 Recommendations ...... 94 Table 11-1 Internet Adaptor Configuration Options...... 117 Table 13-1 X.400 Abbreviations ...... 138 Table 15-1 x400trace Protocols...... 167 Table 15-2 x400trace OSI Processes ...... 167 Table 15-3 x400trace Filters ...... 168 Table 15-4 x400decode Protocols...... 170 Table B-1 Basic Message Transfer Service Support ...... 195
xv Table B-2 Optional Message Transfer Service support ...... 195 Table B-3 Basic Inter-Personal Message Service Support ...... 197 Table B-4 Optional Inter-Personal Message Service Support...... 197
Table B-5 Basic Message Store Service Support ...... 200 Table B-6 Optional Message Store Service Support...... 200
xvi Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Preface
This manual explains how to configure and maintain the SolsticeTM X.400 Messaging Server and the Solstice X.400 Internet Adaptor.
The Solstice X.400 Messaging Server provides the following: • A message transfer agent (MTA), used to transfer electronic messages. • A message store that can serve up to 250 users, all using a single message store process. • An RFC1006 driver, enabling you to run Solstice X.400 products without the SunLink OSI Communications Platform (Stack). • An SNMP (simple network management protocol) agent, enabling you to monitor and analyze messaging components in your network. • Tools to configure, manage, test, and troubleshoot a messaging system. • Application programming interfaces (APIs) and examples, enabling you to develop local access messaging applications. See the Solstice X.400 Programming Reference Manual for more information.
The Solstice X.400 Internet Adaptor is an X.400-to-Internet mail gateway. You can use this to handle the exchange of electronic messages between Internet mail applications (for example, mailtool) and the X.400 domain.
This manual is intended for system administrators who are familiar with the SolarisTM operating environment. It assumes that you have installed the product software and license, as described in Installing and Licensing Solstice X.400 Products.
xvii How This Manual is Organized
This manual is in five parts:
Part 1 - Introducing Solstice X.400 and its Configuration Tool
This part introduces X.400, the Solstice X.400 Messaging Server, the Solstice X.400 Internet Adaptor, and the configuration tool x400tool.
Chapter 1, “Introducing the Solstice X.400 Messaging System,” provides an overview of X.400 Message Handling Systems. It also introduces the Solstice X.400 Messaging Server and the Solstice X.400 Internet Adaptor, and describes their components.
Chapter 2, “Starting and Using x400tool,” describes how to start the OPEN LOOKTM administration tool for the Solstice X.400 Messaging Server and the Solstice X.400 Internet Adaptor (x400tool), and provides an overview of how to use it.
Chapter 3, “Overview of Configuring Your Messaging System,” gives a summary of the steps you must follow to configure your messaging system.
Part 2 - Configuring Your Messaging Server
This part describes how to set up, tune, and test the components of your messaging system.
Chapter 4, “Configuring Your Local Messaging Server,” describes how to use x400tool to set up your local MTA and your local message store.
Chapter 5, “Tuning Your Local Messaging Server,” describes how to use x400tool to tune your local MTA and message store.
Chapter 6, “Adding Remote Server Information to Your Messaging System,” describes how to use x400tool to add information about remote MTAs, message stores, and directory system agents (DSAs) to your messaging system.
Chapter 7, “Testing and Tuning Connections to a Remote MTA,” describes how to tune and test remote server associations. It also describes how to configure routes to remote MTAs manually.
Chapter 8, “Adding Message Store User Information to Your Messaging System,” describes how to use x400tool to add information about users of your message store.
xviii Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Chapter 9, “Adding Third-Party Agents to Your Messaging System,” describes how to use x400tool to add third-party user agents (UAs) and P1 agents (for example, message gateways) to your messaging system.
Chapter 10, “Routing Between Messaging Components,” describes how to use x400tool to modify the default routing tables to handle complex routing between components in the X.400 domain.
Part 3 - Configuring and Using Your Internet Mail Adaptor
This part describes how to set up, tune, and test the Solstice X.400 Internet Adaptor.
Note – You do not need to read this part if you do not have a license for the Solstice X.400 Internet Adaptor.
Chapter 11, “Configuring the Solstice X.400 Internet Adaptor,” describes how to use x400tool to set up a Solstice X.400 Internet Adaptor to exchange electronic messages between the Internet and X.400 mail domains.
Chapter 12, “Testing and Tuning the Solstice X.400 Internet Adaptor,” describes how to test the configuration of your Solstice X.400 Internet Adaptor. It also describes how to modify mapping tables, how to configure routes manually, and how to modify the sendmail configuration file.
Chapter 13, “Sending and Receiving Internet Mail Through the Internet Adaptor,” describes how to use UNIX mail tools to send and receive messages through the Solstice X.400 Internet Adaptor.
Part 4 - Managing Your Messaging System
This part describes how to manage and monitor the components in your messaging system.
Chapter 14, “Managing Your Messaging System with x400tool,” describes how to use x400tool to maintain your messaging system and to gather information about the current state of its component parts.
Chapter 15, “Managing Your Messaging System with Command-Line Tools,” describes how to use the command-line recovery, tracing, and statistics tools.
xix Part 5 - Appendices
This part includes the following supplementary information:
Appendix A, “Error Messages,” contains information to help you diagnose and resolve problems with your messaging system.
Appendix B, “Technical Specification and Conformance Information,” contains a technical specification for the Solstice X.400 Messaging Server, and a brief description of the ITU X.400 recommendations to which it conforms.
New Features of the Solstice X.400 Messaging Server
The main features that have been added for this release of Solstice X.400 are: • An X.400 message store. See “The Solstice X.400 Message Store” on page 14. • Optional use of an X.500 Directory Service. The MTA component of the Solstice X.400 Messaging Server contains a directory user agent (DUA), that enables your messaging applications to use X.500 directory names as well as X.400 addresses. For more information, see “X.400 Use of X.500 Directory Services” on page 20. • A set of MTA database tools to list, backup, and restore the temporary MTA database. These tools are described in “Using the MTA Database Tools” on page 166. • An RFC1006 driver, giving you the option of running the Solstice X.400 Messaging Server over TCP/IP without the SunLink OSI Communications Platform (stack). For more information see “Introducing the RFC1006 Driver” on page 21”. • An SNMP agent to monitor and analyze your messaging components from a single location, using a management application such as Solstice Messaging Manager. The agent is described in the Solstice Messaging Management Administrator’s Guide. • A message tracking facility, enabling you to store a permanent record of messages processed by your local server. You can then, for example, use this information to calculate a charge (or bill) for your users. See “Enabling Message Tracking” on page 64.
xx Solstice X.400 Messaging Server Administrator’s Guide—February 1996 The Solstice X.400 Product Range
The Solstice X.400 product range, as shown in Figure P-1, includes: • The Solstice X.400 Messaging Server. This is at the heart of your messaging system. It includes a Directory-Service-enabled MTA, a message store (with a license for twenty users), and an SNMP Agent. • Solstice X.400 User Mailboxes provide additional MS User licenses, enabling up to 250 users to connect to your message store. • The Solstice X.400 Internet Adaptor is an optional component of the Solstice X.400 Messaging Server. It is an X.400/Internet mail gateway. • The Solstice Messaging Manager communicates with SNMP Agents. From a single location, you can monitor and analyze the components of your messaging system. • The Solstice X.400 Client Toolkit is a messaging toolkit, which you can use to develop X.400 applications that have remote access to a messaging server.
Solstice X.400 Messaging System
User Agent Directory Service
Solstice X.400 User Mailbox MTA DUA Solstice X.400 Message Store Internet Adaptor MS User
Solstice SNMP Messaging Agent Manager
Solstice X.400 UNIX Mail Client Toolkit
Figure P-1 The Solstice X.400 Product Range
xxi Product Documentation
The Solstice X.400 Messaging Server document set also includes: • Installing and Licensing Solstice X.400 Products (CD Insert) • Solstice X.400 Programming Reference Manual (Part No. 802-5047) • Solstice XOM Programming Reference Manual (Part No. 802-1311)
The Solstice X.400 document set also includes: • Solstice Messaging Management Administrator’s Guide (Part No. 802-5048) • Solstice X.400 Client Toolkit Administrator’s Guide (Part No. 802-5046)
These books are available on-line if you have installed the Answerbooks supplied with the CD-ROM. Installing and Licensing Solstice X.400 Products describes how to install the Answerbooks.
If you are using the SunLink OSI Communications Platform (Stack) instead of the RFC1006 driver, you will also need the following documents: • Installing and Licensing SunLink OSI (Part No. 804-4666) • SunLink OSI Communication Platform Administrator’s Guide (Part No. 801-4975)
ITU (CCITT) X.400 MHS Recommendations
The Solstice X.400 Messaging Server implements the ITU (formerly known as CCITT) X.400 MHS recommendations. The Solstice message store implements the 1988 revision of the recommendations; the Solstice message transfer agent (MTA) implements the 1992 revision. The recommendations specify a method of exchanging electronic messages between diverse systems, based upon the principles of the OSI reference model. For an overview of these recommendations, see Appendix B, “Technical Specification and Conformance Information”. The complete CCITT 1988 X.400 recommendations are contained in the CCITT Blue Book: Data Communications Networks Message Handling Systems Recommendations X.400—X.420 (Volume VIII, Fascicle VIII.7) November 1988.
xxii Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Restrictions on Messaging System Component Names
The following characters must not be used for any of the names describing messaging system components:
Invalid Characters Description @ “at” symbol / forward slash \ backslash # hash or pound sign space -> tab
MTA and message store group names cannot be more than 32 characters long; user agent, P1 user agent, and message store user names cannot be more than 16 characters long.
What Typographic Changes Mean
The following table describes the typographic changes used in this book.
Table P-1 Typographic Conventions
Typeface or Symbol Meaning Example AaBbCc123 The names of commands, Edit your .login file. files, and directories; Use ls -a to list all files. on-screen computer output machine_name% You have mail.
AaBbCc123 What you type, contrasted machine_name% su with on-screen computer Password: output AaBbCc123 Command-line placeholder: To delete a file, type rm filename. replace with a real name or value AaBbCc123 Book titles, new words or Read Chapter 6 in User’s Guide. terms, or words to be These are called class options. emphasized You must be root to do this.
xxiii Shell Prompts in Command Examples
The following table shows the default system prompt and superuser prompt for the C shell, Bourne shell, and Korn shell.
Table P-2 Shell Prompts
Shell Prompt C shell prompt machine_name% C shell superuser prompt machine_name# Bourne shell and Korn shell prompt $ Bourne shell and Korn shell superuser prompt #
xxiv Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Part 1 — Introducing Solstice X.400 and its Configuration Tool
This part has three chapters: • Chapter 1, “Introducing the Solstice X.400 Messaging System,” provides an overview of X.400 Message Handling Systems. It also introduces the Solstice X.400 Messaging Server and the Solstice X.400 Internet Adaptor, and describes their components. • Chapter 2, “Starting and Using x400tool,” describes how to start the administration tool (x400tool) for the Solstice X.400 Messaging Server and the Solstice X.400 Internet Adaptor , and provides an overview of how to use the tool. • Chapter 3, “Overview of Configuring Your Messaging System,” gives a summary of the steps to follow to configure your messaging system.
Introducing the Solstice X.400 Messaging System 1
Overview of an X.400 Message Handling System page 1 The X.400 MHS Protocols page 4 X.400 Management Domains page 6 X.400 Addressing page 7 Routing Messages in the X.400 Domain page 14 The Solstice X.400 Message Store page 14 The Solstice X.400 Internet Adaptor page 15 X.400 Use of X.500 Directory Services page 20 Introducing the RFC1006 Driver page 21
This chapter provides an overview of X.400, the Solstice X.400 Messaging Server and the Solstice X.400 Internet Adaptor, and introduces the terminology used to describe their components.
Overview of an X.400 Message Handling System
Figure 1-1 on page 2 shows the components of a typical X.400 Message Handling System. This system is used to transfer electronic messages from one end user to another.
1 1
User Agent
User Agent Message Transfer System (MTS)
Message Message Transfer Agent Transfer Agent User Agent
Message Store
Local Message Message Internet Transfer Agent Transfer Agent Adaptor Internet Mail
Internet Mail
3rd Party Postal Service, Access Unit Fax, etc.
Figure 1-1 The X.400 Message Handling System Model
2 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 1
The principal components of an X.400 Message Handling System are: • User Agents (UA) User agents handle the submission and delivery of electronic messages. They provide the direct interface between end users (application processes) and messaging servers. • Messaging Servers A messaging server consists of the following components:
• Message Transfer Agent (MTA) Message transfer agents are the X.400 routers. They handle the routing of electronic messages. A collection of MTAs is called a message transfer system (MTS). Your local MTA is the MTA running on your local machine. It handles the routing of electronic messages between user agents (application programs) and remote MTAs. It is the focal point through which all messages pass through your local messaging system. Remote MTAs are the message transfer agents with which your local MTA can communicate directly. They handle the routing and relaying of electronic messages throughout the X.400 domain. • Message Store (MS) A message store acts as an intermediary between MTS users and an MTA. It stores X.400 messages, and lets users manipulate and send messages in a variety of ways. Without a message store, UAs must connect to an MTA and explicitly request to receive messages. A message store accepts delivery of messages on behalf of a UA and stores the messages for subsequent viewing, retrieval, and forwarding. The MS provides a UA with additional functionality compared to direct delivery to the MTS. For example, an MS can send alerts to a UA when it receives a certain message. • Message Adaptor A message adaptor (or message gateway) handles the translation of electronic message formats between dissimilar mail systems—for example, between Internet mail and X.400 mail. • Access Units (AU) An access unit provides the direct interface between other communication systems (such as fax or postal services) and the messaging system.
Introducing the Solstice X.400 Messaging System 3 1
The X.400 MHS Protocols
A messaging system uses protocols to reliably transport messages from one end user to another. The X.400 message handling system uses the following protocols: • Message Transfer Protocol (P1) The message transfer protocol defines the structure used to transport an electronic message (the “envelope”) between end users. It includes the addresses of both the originator and the recipient of the message. • Interpersonal Messaging Protocol (P2 & P22) The interpersonal messaging protocols define the content of the message (the “letter”). An interpersonal message consists of a header that contains information about the message (for example, originator and recipient addresses, date, subject) and body parts that contain the content of the letter. • The MTS Access Protocol (P3) The MTS access protocol enables message delivery and submission between the MTS and a message store and between the MTS and a user agent. • The Message Store Protocol (P7) The message store protocol enables a UA to communicate with an MS. It allows a UA to submit messages, to retrieve messages or parts of messages, and to perform administrative operations such as changing passwords.
Figure 1-2 on page 5 shows the way in which X.400 messages are exchanged between end users.
4 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 1
User Agent User Agent
Interpersonal Messaging Protocol (P2, P22)
Message Store Protocol (P7)
MTS Access Protocol (P3) Message Store
P3 (internal)
Message Transfer Protocol (P1)
Message Remote Message Transfer Agent Transfer Agent Local Messaging Server
Figure 1-2 Exchanging Messages Between Users
The Solstice X.400 Messaging Server also supports the exchange of EDI messages as defined by X.435. This protocol defines a wide range of electronic commercial communications. For example, a bill (or invoice) that is exchanged between end users. This might be a message consisting of a header that contains information about the message (for example, originator and recipient addresses, date, subject) and a body that contains the content of the bill (for example, an EDIFACT, X.121, or ASCII message).
Refer to the CCITT X.435 Recommendation and the Solstice X.400 Programming Reference Manual for more information on EDI messaging.
Introducing the Solstice X.400 Messaging System 5 1
X.400 Management Domains
The purpose of the X.400 MHS recommendations is to create a global X.400 domain within which communicating systems throughout the world can exchange electronic messages. This global X.400 domain is divided into countries and each country is further divided into management domains—that is, one or more MTAs (and any associated UAs) governed by a controlling organization.
Management domains are divided into administrative management domains (ADMD) and private management domains (PRMD): • An ADMD is controlled by an administration; for example, a national Postal Telegraph and Telephone (PTT) Agency or a non-national organization. • A PRMD is controlled by any other type of organization; for example, a privately-owned company.
An ADMD (such as ATLAS or MCIMAIL) is typically divided into PRMDs. In general, the ADMD handles all messages that are either exchanged between PRMDs or exchanged across international boundaries. However, since the ADMD charges for its services and since not all PRMDs are controlled by an ADMD, there are exceptions to this rule.
Each MTA is assigned a global domain identifier that specifies the country, the ADMD, and (optionally) the PRMD in which the MTA is located as shown in Figure 1-3. This is the minimum information required to identify a given MTA.
Country=US
ADMD=MCI
PRMD=USHQ
Figure 1-3 The Global Domain Identifier for an MTA
6 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 1
X.400 Addressing
An originator/recipient ( O/R) address specifies the information needed to deliver a message to an end user. It is analogous to the address used to direct a letter within the postal service.
An O/R address consists of a list of attributes that describe the end user and locate that end user within the global X.400 domain. If there are multiple end users, the O/R address describes a distribution list.
Attributes contained in an O/R address are defined by recommendation X.402 and are generally divided into the four categories shown in Table 1-1.
Table 1-1 Attribute Categories
Attribute Type Description Personal Attributes Attributes that describe the end user, for example, surname, given name Organizational Attributes Attributes that describe the organization to which the end user belongs; for example, organization name, organizational unit Architectural Attributes Attributes that describe the environment to which the organization belongs; for example, PRMD, X.121 address Geographical Attributes Attributes that describe the physical location of the end user; for example, country, postal code
Domain-defined attributes are attributes that fall outside the scope of the CCITT recommendations. These attributes are interpreted only within the confines of the domain in which they are defined, but are transmitted as part of the address in the same way as standard attributes. The Solstice X.400 Messaging Server supports both standard and domain-defined attributes.
In a text representation (for example, for addressing within Internet mail) each attribute is represented by a code (or key) to which an appropriate value is assigned. Table 1-2 on page 8 lists the standard attribute keys and a description of each attribute as defined by the 1988 revision of X.402. Keys may be represented in uppercase or lowercase. Attribute values may be represented in printable text format (TXT), teletext format (TLTX), or numeric format (NUM) as indicated. Note that the Solstice X.400 Internet Adaptor does not support teletext format O/R addresses.
Introducing the Solstice X.400 Messaging System 7 1
Table 1-2 Standard Attribute Keys
Attribute Key Attribute Description TXT TLXT NUM ADMD administration domain name X X CN common name X X C country name X X X121 network address X UA-ID numeric user identifier X O organization name X X OU or OU
8 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 1
Representing O/R Addresses
There are two notations used for representing O/R addresses. Of these, the more widely accepted notation separates the component attributes by a slash (/) character.
By convention, O/R addresses are often represented in an order similar to that used for postal addresses as shown in the example in Figure 1-4.
From: Originator’s Name Street Address Town Country
Recipient’s Name Company Name Street Address Town Country
/C=FR/ADMD=ATLAS/PRMD=EUROHQ/O=MKTG/S=DUPONT/
Figure 1-4 O/R Address Conventions
A less common notation separates the component attributes by a semicolon (;). Using this notation, the address shown in Figure 1-4 becomes:
S=DUPONT;O=MKTG;PRMD=EUROHQ;ADMD=ATLAS;C=FR
Introducing the Solstice X.400 Messaging System 9 1
O/R addresses are divided into four types: • Mnemonic O/R Address • Numeric O/R Address • Terminal O/R Address • Postal O/R Address
Refer to Chapter 13, “Sending and Receiving Internet Mail Through the Internet Adaptor” for a description of how to use X.400 O/R addresses when sending messages using Internet mail applications such as mail or mailtool.
Mnemonic O/R Address This is the most common type of O/R address. It identifies the user and the administrative domain within which the user is located. By definition, all attributes are assigned text (or teletext) format values. A mnemonic O/R address consists of the following component attributes:
• One country-name (C) and one administration-domain-name (ADMD), which may be assigned a blank space as a value. This identifies the ADMD within which the user is located. • A combination of attributes selected from the following list: private-domain-name (PRMD) organization-name (O) organizational-unit-names (OU) common-name (CN) personal-name (PN) surname (S) — mandatory given-name (G) initials (I) generation-qualifier (GQ) • Optionally, one or more domain-defined attributes (DD).
Note that you can have up to four organizational unit (OU) names in a mnemonic O/R address. If you use organizational unit names, the order of the attributes can be important. You can use either numbered organizational unit names (OU1, OU2, etc.) or unnumbered organizational unit names. Numbered organizational unit names are used in an O/R address as follows:
/S=DUPONT/OU2=FCAST/OU1=PROD/O=MKTG/PRMD=EUROHQ/ADMD=ATLAS/C=FR/
10 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 1
Unnumbered organizational unit names are interpreted in the order in which they appear, numbered from the side nearest the country code:
/S=DUPONT/OU=FCAST/OU=PROD/O=MKTG/PRMD=EUROHQ/ADMD=ATLAS/C=FR/ or /C=FR/ADMD=ATLAS/PRMD=EUROHQ/O=MKTG/OU=PROD/OU=FCAST/S=DUPONT/
Numeric O/R Address A numeric O/R address identifies the user and the ADMD within which the user is located using numeric attributes only. It consists of the following component attributes:
• One country-name (C) and one administration-domain-name (ADMD), both of which must be assigned numeric values. This identifies the ADMD within which the user is located. • One numeric-user-identifier (UA-ID) and (optionally) a private-domain-name (PRMD). • Optionally, one or more numeric domain-defined attributes (DD).
Terminal O/R Address A terminal O/R address identifies a user by means of a network address and some other optional information. It consists of the following component attributes:
• One network address (X.121). • Optionally, a terminal-identifier (T-ID). • Optionally, one country-name (C) and one administration-domain-name (ADMD). They identify the ADMD through which the terminal is accessed. If one of these attributes is specified, the other must also be specified. • Optionally, one private-domain-name (PRMD). It is required only when the country-name and administration-domain- name are present. • Optionally, one or more domain-defined attributes (DD). They are required only when the country-name and administration-domain- name are present.
Introducing the Solstice X.400 Messaging System 11 1
Postal O/R Address A postal O/R address identifies the user by means of the user’s postal address (street address, postal code, etc.) and is used to physically deliver a message to a user.
Postal O/R addresses are not directly applicable to the Solstice X.400 Messaging Server and physical-delivery attributes are not supported by x400tool. Although the Solstice X.400 Messaging Server supports messages that present a postal O/R address, it does not base any of its routing decisions on the physical-delivery attributes.
The X.400 recommendations specify a formatted postal O/R address that is composed of several attributes: • One country-name (C) and one administration-domain-name (ADMD). This identifies the ADMD within which the user is located. • One physical-delivery-country-name (PD-C) and one physical-delivery-postal-code (PD-CODE) that identify the physical (geographical) location at which the user takes delivery of the message. • Optionally, a combination of attributes from the following list: private-domain-name (PRMD) physical-delivery-service-name (PD-SERVICE) physical-delivery-personal-name (PD-PN) physical-delivery-office-name (PD-OFFICE) physical-delivery-office-number (PD-OFFICE-NUM) physical-delivery-organization-name (PD-O) physical-delivery-unformatted-postal-address (PD-ADDRESS) physical-delivery-postal street-address (PD-STREET) physical-delivery-postal-box-address (PD-BOX) physical-delivery-unique-postal-name (PD-UNIQUE) physical-delivery-local-postal-attributes (PD-LOCAL) physical-delivery-poste-restante-address (PD-RESTANTE)
12 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 1
X.400 Addressing Using X.500 Directory Services
If your network has access to an X.500 Directory Service, your user agents can specify an O/R name for the address of the message recipient. An O/R name can consist of an O/R address (as described in “Representing O/R Addresses” on page 9), a directory name, or both an O/R address and a directory name. A directory name is a unique way to identify an entry in an X.500 Directory.
There are two types of directory name: • Distinguished Name Each entry in an X.500 Directory is named by an ordered sequence of attributes know as relative distinguished names (RDNs). A distinguished name is a sequence of RDNs that uniquely represent the entry. An example distinguished name is: /C=FR/O=Sun/OU=Sunsoft/CN=J.Sinclair/
This distinguished name is made up of the following RDNs: CountryName=Fr Organization=Sun Organizational Unit=Sunsoft CommonName=J.Sinclair
When a UA submits a message with the recipient address in distinguished name format, the MTA queries the Directory Service to determine the recipient’s O/R address. • Alias An alias is a “user-friendly” abbreviation of a distinguished name. It provides a shorthand way of referring to an entry in an X.500 Directory. An example alias is: jsinclair
When a UA submits a message with an alias for the recipient address, the MTA queries the Directory Service to determine the recipient’s O/R address.
An O/R address is always required by an MTA to route a message. A Solstice X.400 MTA uses an X.500 Directory Service to translate a directory name (be it a distinguished name or an alias) into an X.400 O/R address.
Introducing the Solstice X.400 Messaging System 13 1
Routing Messages in the X.400 Domain
An MTA functions like a traditional postal service sorting-office—sorting the messages for delivery, based on the recipient address.
When it receives a message, the MTA compares the list of attributes in the O/R address against the entries in its local routing table. If the O/R address (or part of the O/R address) matches one of the entries, the message is forwarded to the agent associated with the matching entry. This can be any one of the recognized components in the messaging system.
Refer to Chapter 10, “Routing Between Messaging Components” for detailed instructions on defining entries in the routing table used by your local MTA.
The Solstice X.400 Message Store
The Solstice X.400 message store (MS), as supplied with the Solstice X.400 Messaging Server, can be configured to handle up to 250 individual users, each with its own information base of messages. These users can be located on the same machine as the message store (local users) or on other machines (remote users).
To manage information about message store users, and to avoid entering similar configuration information again and again, you define message store user groups. A message store user group is a collection of message store users. You can think of a message store user group as being an individual message store. For example, you could have a message store user group called Sales (your first message store), and another called Engineers (your second message store).
For each message store user group that you define, you also specify which MTA is serving that group. For example, the message store user group Sales could be served by the local MTA, while the message store user group Engineers could be served by a remote MTA.
In practice, however, message store user groups should be served by the local MTA. This prevents unnecessary network traffic. For example, suppose a message store user sends a message to a user in the same message store user group. The message is routed by the serving MTA. If this MTA is remote, the message is routed from the local system to the remote system and then back again to the local system.
14 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 1
The Solstice X.400 Internet Adaptor
One of the optional features of the Solstice X.400 Messaging Server is the Solstice X.400 Internet Adaptor. This handles the exchange of mail messages between Internet mail systems that conform to RFC 822 (such as mailtool) and X.400 mail systems.
The Solstice X.400 Internet Adaptor maps RFC 822 addresses and service elements to equivalent X.400 addresses and service elements, and adds any additional information required to route messages across the global X.400 domain. It provides support for the transfer of MIME (Multipurpose Internet Mail Extensions) attachments as defined by RFC 1341, and incorporates additional mail features such as international character set and Sun multimedia attachment support.
Routing Messages in the Internet Mail Domain
This section provides an overview of UNIX mail handling services and routing in the Internet mail domain. Refer to the Solaris documentation for a detailed description of the Internet mail system.
The routing of messages within the Internet mail domain is handled by the sendmail daemon as shown in Figure 1-5.
UNIX Mail
/var/mail
sendmail sendmail
/bin/mail
UNIX Mail Figure 1-5 Routing Messages in the Internet Mail Domain
Introducing the Solstice X.400 Messaging System 15 1
When sendmail receives a message (from either a local UNIX mail application or from a remote sendmail daemon) it expands and parses the recipient address using the information in its local configuration file (sendmail.cf). • If the message cannot be delivered locally, the message is relayed between sendmail daemons based on the recipient address and the information in the NIS database (or the local /etc/hosts if NIS is not running). • If the message can be delivered locally, sendmail calls the program /bin/mail which writes the message into the recipient’s mailbox (/var/mail/username). From the mailbox, the message can be retrieved with an Internet mail application such as mailtool.
Routing Messages from Internet Mail to X.400
Your Solstice X.400 Internet Adaptor provides an interface between the sendmail daemon (which routes electronic mail in the Internet mail domain) and your local MTA (which routes electronic mail in the X.400 domain).
Each Solstice X.400 Internet Adaptor is identified by a pseudo host name which is an alias for the machine on which the adaptor is running. This alias must be entered in the NIS database (or in /etc/hosts if NIS is not running). It must also be registered in the local configuration file (sendmail.cf) for the sendmail daemon running on the same machine as the adaptor. (Note that the local sendmail.cf is modified automatically with a default pseudo host name—x400-gate—when the Solstice X.400 Messaging Server is installed.) Refer to Chapter 11, “Configuring the Solstice X.400 Internet Adaptor” for more information.
Routing messages between the Internet mail domain and the X.400 mail domain occurs in two distinct steps:
1. Routing the message to the machine on which the adaptor is running. When sendmail receives a message (from either a local Internet mail application or from a remote sendmail daemon) it expands and parses the recipient address, using the information in its local configuration file (sendmail.cf). If the message cannot be delivered locally, it is relayed between sendmail daemons based on the recipient address and the pseudo host name located in the NIS database (or the local /etc/hosts if NIS is not running) until it reaches the machine on which the adaptor is located.
16 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 1
2. Routing the message to the adaptor running on the machine. The sendmail daemon running on the same machine as the adaptor recognizes the message based on the pseudo host name entered in its local configuration file (sendmail.cf). As a result, it calls the X.400 mailer program osix400mail in place of the UNIX mailer program /bin/mail.
Instead of writing the message directly into the recipient’s mailbox, the X.400 mailer osix400mail writes the message into a product-specific spool directory (/var/SUNWconn/OSIROOT/spool) where it can be accessed and parsed by the Solstice X.400 Internet Adaptor. The Solstice X.400 Internet Adaptor translates Internet address and message elements into X.400 equivalents and passes the outgoing message to the local MTA for delivery across the X.400 domain. Figure 1-6 shows how outgoing messages are routed from the Internet mail domain to the X.400 mail domain through the Solstice X.400 Internet Adaptor.
Internet Mail
/var/SUNWconn/OSIROOT/spool
sendmail sendmail
osix400mail Internet Adaptor
Message Transfer Agent
Figure 1-6 Routing Mail from Internet Mail to X.400 Mail
Introducing the Solstice X.400 Messaging System 17 1
Routing Messages from X.400 to Internet Mail
When the Solstice X.400 Internet Adaptor receives an incoming message from the local MTA, it converts the X.400 address and message elements into Internet mail equivalents. It passes the message directly to the local sendmail daemon, which handles the routing in the Internet mail domain based on the information in its local configuration file and the NIS database.
When the message reaches the machine on which the mailbox for the recipient is located, the sendmail daemon calls the UNIX mailer program /bin/mail. This writes the message into the recipient’s mailbox from where it can be retrieved using an Internet mail application (such as mailtool).
Figure 1-7 shows how incoming messages are routed from the X.400 mail domain to the Internet mail domain through the Solstice X.400 Internet Adaptor.
Message Transfer Agent
Internet Adaptor
/var/mail
sendmail sendmail /bin/mail
Internet Mail
Figure 1-7 Routing Messages from X.400 Mail to Internet Mail
18 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 1
Supported Mail Header Fields
The Solstice X.400 Internet Adaptor translates the mail headers that are used to carry additional information and to modify the behavior of the mail delivery system for each message—for example, to mark the message for urgent delivery or to request a delivery report. It supports all the mail headers specified within RFC 822, and additional headers specified in RFC 987 and RFC 1327. Header fields are mapped according to the rules defined in RFC 1327.
Table 1-3 lists the most commonly used mail header fields that can be used to set X.400 flags in messages sent through the Solstice X.400 Internet Adaptor. Refer to “Using X.400 Mail Header Fields in mailtool” on page 135 for detailed instructions on how to set mail header fields from within Internet mail applications.
Table 1-3 Supported Mail Header Fields
Header Fields Usage Bcc (blind carbon copy) recipient address Cc (carbon copy) recipient address Conversion true/false Conversion-with-loss true/false Delivery-Report always/never/audited/non-delivery Disclose-Recipient true/ false Expiry-Date RFC 822 format date Importance low/high/routine Priority low/urgent/normal Receipt-Notification always/non-receipt/never Reply-to originator address Sender originator address Sensitivity personal/private/confidential/non-sensitive Subject string To recipient address
Introducing the Solstice X.400 Messaging System 19 1
X.400 Use of X.500 Directory Services
The MTA supplied with the Solstice X.400 Messaging Server contains an X.500 directory user agent (DUA). This uses the directory access protocol (DAP) to communicate with directory system agents (DSAs), such as the DSA supplied with the Solstice X.500 Directory Server. A collection of DSAs make up an X.500 Directory Service, which is accessed by an MTA as shown in Figure 1-8.
DSA
DAP DUA
DSA Message Transfer Agent DSA
Directory Service
Figure 1-8 MTA Use of an X.500 Directory Service
A Directory Service contains information about, for example, messaging system users. It can provide a translation of user-friendly names to OSI network addresses.
With its DUA functionality, a Solstice X.400 MTA can: • Look up a recipient’s O/R address. See “X.400 Addressing Using X.500 Directory Services” on page 13. • Expand Distribution List (DL) information. DL expansion is more efficient when relying on a distributed directory.
To enable your MTA to use a directory service, you must first add information about a DSA to your messaging system. You can do this using x400tool. Refer to “Adding Information About an X.500 DSA” on page 73 for more information.
20 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 1
Introducing the RFC1006 Driver
The Solstice X.400 Messaging Server and the Solstice X.400 Client Toolkit include an RFC1006 driver. The driver implements the RFC1006 protocol, which enables these OSI applications to run over TCP/IP. The RFC1006 driver can be used instead of the OSI Communication Platform (Stack) below the transport layer interface (TLI), as shown in Figure 1-9.
Application X.400 Application
Presentation X.400 Product Daemon Session User Space Kernel Space Transport Layer Interface (TLI)
RFC1006 RFC1006 Driver
TCP/IP Figure 1-9 RFC1006 Driver and Higher Layer Entities
If you want to run the Solstice X.400 Messaging Server or the Solstice X.400 Client Toolkit over TCP/IP only, replace the OSI Stack with the RFC1006 driver. This will free up memory and disk resources.
The RFC1006 package, SUNWrk6, includes three software components: • The rk6d(1M) daemon controls the RFC1006 driver. It is started automatically whenever you reboot your machine. You can fine-tune the configuration of the rk6d daemon by editing its configuration file (rk6d.conf(4)), or by stopping the daemon then restarting it manually with some command-line options. • The rk6stat(1M) utility displays statistical information. • The rk6trace(1M) utility traces incoming and outgoing Protocol Data Units (PDUs).
For more information on the RFC1006 driver utilities, see their manpages.
Introducing the Solstice X.400 Messaging System 21 1
22 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Starting and Usingx400tool 2
Before You Start page 24 Starting x400tool on Your Local Machine page 25 Starting x400tool on a Remote Machine page 25 Using x400tool page 26
This chapter describes how to start the OPEN LOOK graphical user interface for the Solstice X.400 Messaging Server (x400tool), and introduces its primary components. x400tool is used to configure and maintain your messaging system. Before starting to use x400tool, read Chapter 1, “Introducing the Solstice X.400 Messaging System”, which introduces the terms and concepts presented throughout this manual.
Note – Throughout this manual, it is assumed that you accepted the default base directory (/opt) for the Solstice X.400 Messaging Server executable files when you installed the software. If this is not the case, you will need to replace /opt in the example commands with the actual base directory for your system.
23 2
Before You Start
Before you start to use x400tool:
1. Ensure that you have installed the software and licenses for the Solstice X.400 products you have purchased.
2. Make sure that the transport provider is running: a. If your messaging applications use an OSI transport provider, make sure that the SunLink OSI stack is configured and running.
hostname# ps -ef | grep osinetd root
If the stack is not running, start it manually by typing:
hostname# /etc/rc2.d/S90osinet start
Refer to the Installing and Licensing SunLink OSI and the SunLink OSI Communication Platform Administrator’s Guide for detailed instructions. b. If your messaging applications use the RFC1006 driver, make sure that the rk6d daemon is running.
hostname# ps -ef | grep rk6d root
If the daemon is not running, start it manually by typing:
hostname# /etc/rc2.d/S90rk6 start
3. Modify the local environment variables to add the following definitions: $PATH /opt/SUNWconn/sbin
$MANPATH /opt/SUNWconn/man
$HELPPATH /opt/SUNWconn/mhs/lib/locale/C
24 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 2
Starting x400tool on Your Local Machine
To start and use x400tool:
1. Log in as root or become superuser, if you have not done so already. To help protect your messaging system from unauthorized modification, x400tool cannot be run without superuser privileges.
2. Ensure that the Solstice X.400 processes have started. If you rebooted your machine after you installed the Solstice X.400 Messaging Server, these processes should already be started. You can verify this by typing:
# ps -ef |grep osi root
If the Solstice X.400 processes are not running, start them manually by using x400start:
hostname# /opt/SUNWconn/sbin/x400start osimta osix400mqa osix400ms osismtpx400
Note – If you do not have a license for the Solstice X.400 Internet Adaptor, you do not need to start the osismtpx400 process.
3. Start x400tool by typing:
hostname# /opt/SUNWconn/sbin/x400tool &
Starting x400tool on a Remote Machine
If you want to use x400tool to configure a remote machine as a messaging server, you can start x400tool remotely so that it is displayed on the monitor of your local machine.
Starting and Using x400tool 25 2
To start x400tool remotely:
1. On your local machine, disable access restrictions for the remote machine so you are able to display x400tool on your local monitor.
localhost% $OPENWINHOME/bin/xhost + remotehost
2. Log in to the remote machine as root or superuser.
3. Ensure that the Solstice X.400 processes are running on the remote machine. Start the processes manually if required.
remotehost# /opt/SUNWconn/sbin/x400start osimta osix400mqa osix400ms osismtpx400
Note – If you do not have a license for the Solstice X.400 Internet Adaptor, you do not need to start the osismtpx400 process.
4. On the remote machine, start x400tool so that it is displayed on your local monitor.
remotehost# /opt/SUNWconn/sbin/x400tool -display localhost:0 &
Using x400tool
When you start x400tool you will see a map of the current messaging system. An icon will appear representing each component of your system. If this is the first time you started x400tool on your machine, you will see the following icons: • An icon labeled local server that represents your (unconfigured) local MTA and message store • An icon labeled Directory that represents an X.500 DSA • If licensed, an icon labeled SMTP_X400 that represents an (unconfigured) Solstice X.400 Internet Adaptor
Figure 2-1 on page 27 shows an example main window as it appears when you start x400tool for the first time.
26 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 2
To modify the configuration of any of the components in your messaging system, double-click SELECT on its icon to activate the associated configuration window.
Figure 2-1 x400tool: Main Window x400tool has three pull-down menus that can be used to modify, test, and manage the system: • The Configure menu is used to modify the configuration of your messaging system. It also contains options used to backup and restore the configuration. • The Test menu is used to check the associations between components and the routing of electronic messages throughout your messaging system. There is also an option to check the conversion of addresses made by the Solstice X.400 Internet Adaptor. • The Manage menu is used to maintain the elements of your messaging system and to recover status information. It is also used to backup and restore individual message store user mailboxes.
Starting and Using x400tool 27 2
Starting and Stopping X.400 Processes
The Processes item is used to start and stop X.400 processes, such as the MTA and message store. The Process manager window is shown in Figure 2-2. 1. Click SELECT on the Processes... button to activate the X.400 Process Manager window.
2. Start or stop the process. • To stop an active process, choose the process to stop from the processes scrolling-list, then click SELECT on Stop. • To start an idle process (a process that is installed but not running) choose the process to start from the processes scrolling-list, then click SELECT on Start.
Click SELECT to display detailed information when starting a process
Figure 2-2 x400tool: Starting and Stopping Processes
28 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 2
Backing Up Your Configuration
The Backup Config item is used to save your current MTA and message store configuration to a set of files. By default, configuration files are saved in the directory /var/opt/SUNWconn/OSIROOT/mhs/conf, but you can specify an alternative location. The configuration is saved under a number of files identified by the same file prefix. The file prefix.mhscf defines the name and location of all other configuration files. You specify a prefix to identify the configuration when you backup the files. The configuration that is displayed when you start x400tool for the first time is saved in the file /var/opt/SUNWconn/OSIROOT/mhs/conf/master.mhscf.text. A backup of this initial configuration is contained in master.mhscf.text.ref.
1. Stop the message store process osix400ms if it is running. See “Starting and Stopping X.400 Processes” on page 28.
2. Press MENU on the Configure menu button and choose the Backup Config item. Release MENU to activate the file selection window.
3. Choose a directory and enter the prefix for your backup configuration. The suffix .mhscf.text will be added automatically when you save your configuration.
4. Click SELECT on Backup to save your configuration to file.
Note – To backup a message store user mailbox, see “Backing Up and Restoring Message Stores” on page 160.
Restoring an Existing Configuration
The Restore Config item is used to load an existing MTA and message store configuration from file. You can use this facility to restore the master configuration /var/opt/SUNWconn/OSIROOT/mhs/conf/master.mhscf.text.
Caution – Restoring a configuration will overwrite the messages stored in a message store user mailbox. Before you restore a ! configuration, backup your message store as described in “Backing Up and Restoring Message Stores” on page 160.
Starting and Using x400tool 29 2
1. Press MENU on the Configure menu button and choose the Restore Config item. Release MENU to activate the file selection window.
2. Choose a directory and select an existing configuration. Only files that are appended with .text are displayed. When you select a file called prefix.text, all of the configuration files that start with this prefix will be loaded.
3. Click SELECT on Restore to load the contents of the configuration files. x400tool stops the active X.400 processes, restores the configuration, then restarts the processes.
Note – To restore a message store user mailbox, see “Backing Up and Restoring Message Stores” on page 160.
Printing Your Configuration
The Print option is used to format and print the current configuration. You can print to any local printer or to a file.
1. Press MENU on the Configure menu button and drag the pointer to the Print item. Release MENU to activate the print selection window.
2. Choose the name of a printer from the pull-down menu, or specify the name of a file. If there are no printers configured for your system, then you can only print to a file.
3. Click SELECT on Print to print the configuration.
30 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 2
Locating x400tool Files
Several files are associated with the Solstice X.400 Messaging Server. These files can be divided into the following categories: • Spool or log files that contain a record of all transactions that occur in your messaging system. These files are located under the directory /var/opt/SUNWconn/OSIROOT/spool. • MTA database files. These files are also located under the directory /var/opt/SUNWconn/OSIROOT/spool. For more information, see “Using the MTA Database Tools” on page 166. • MS database files that contain the components of a message store users information base. These files are also located under the directory /var/opt/SUNWconn/OSIROOT/spool.
If these files become too large, for example, if the queue of messages becomes very long, use symbolic links to another directory where there is more room. Ensure that any directories that are symbolically linked have the correct access rights.
Caution – Do not delete the files in your spool directory. Use the “purge” option (see “Purging the Message Queues” on page 156) to remove unwanted ! messages completely.
To display the location of the files associated with your current configuration:
♦ Press MENU on the Configure menu button and drag the pointer to the File Info item. Release MENU to activate the Current Configuration window. This displays the base directories in which the spool and database files are located.
Starting and Using x400tool 31 2
32 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Overview of Configuring Your Messaging System 3
Adding Information about Messaging Servers page 33 Adding Information about the Internet Mail Adaptor page 37 Adding Information about User Agents and DSAs page 37
This chapter provides an overview of the steps required to configure a message transfer agent (MTA), an X.400 message store, and a Solstice X.400 Internet Adaptor. It also summarizes the steps you should follow to add information about remote X.500 directory system agents (DSAs) and third-party or P1 user agents to your messaging system.
Adding Information about Messaging Servers
Depending on which MTAs will serve a particular message store user group, there are different steps you must follow to configure your messaging system. The following sections summarize the various configuration steps.
33 3
Local Message Store Using a Local MTA
The simplest and most common way to install and configure the Solstice X.400 Messaging Server is to have your message store user groups served by the MTA on the same system. This configuration is shown in Figure 3-1.
Messaging Server
Local Message Store User Group Message Transfer Agent
P1 Local Message Transfer Agent
Figure 3-1 Local Message Store User Group using Local MTA
To set up your local messaging system with this configuration:
1. Configure your local MTA, as described in Chapter 4, “Configuring Your Local Messaging Server”. You do not need to add any information in this step that is specific to the message store.
2. Add remote MTA information to your configuration, as described in Chapter 6, “Adding Remote Server Information to Your Messaging System”. In this step, you enter P1 MTA address information so that the local and remote MTAs can communicate.
3. Add message store user information to your configuration, as described in Chapter 8, “Adding Message Store User Information to Your Messaging System”. In this step, you create a message store user group, add information about the users in the group, and define the local MTA as the MTA serving the group.
34 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 3
Local Message Store Using a Remote MTA
Figure 3-2 shows a message store user group using an MTA running on another system.
Remote Users of Local MS
Local Message Store User Group
P3 Message Transfer Agent
Figure 3-2 Local Message Store User Group using Remote MTA
To set up your local messaging system with this configuration:
1. Configure your local message store, as described in Chapter 4, “Configuring Your Local Messaging Server”.
2. Add remote MTA information to your configuration, as described in Chapter 6, “Adding Remote Server Information to Your Messaging System”. In this step, you enter P3 MTA address information so that the message store can communicate with the remote server (the remote MTA). You do not need to add any P1 MTA address information.
3. Add message store user information to your configuration, as described in Chapter 8, “Adding Message Store User Information to Your Messaging System”. In this step, you define the users of the message store, and define a remote MTA as the MTA serving the group.
4. On the remote system, follow the steps summarized in “Local MTA Using a Remote Message Store” on page 36.
Overview of Configuring Your Messaging System 35 3
Local MTA Using a Remote Message Store
Figure 3-3 shows a local MTA serving a remote message store user group. Although the message store is remote, because its serving MTA is local you must define the message store user group on both the remote system and the local system.
Local Users of Remote MS
P3 Local Message Remote Transfer Agent Message Store User Group
Figure 3-3 Local MTA Serving Remote Message Store User Group
To set up your messaging system with this configuration:
1. Configure your local MTA, as described in Chapter 4, “Configuring Your Local Messaging Server”. You do not need to add any information in this step that is specific to the message store.
2. Add remote message store information to your configuration, as described in Chapter 6, “Adding Remote Server Information to Your Messaging System”. In this step, you enter P3 MS address information so that messages received by the local MTA for a message store user can be forwarded to the remote system where the message store is located.
3. Add message store user information to your configuration, as described in Chapter 8, “Adding Message Store User Information to Your Messaging System”. In this step, you define the local users of the remote message store and define the remote message store as the message store serving the group.
4. On the remote system, follow the steps summarized in “Local Message Store Using a Remote MTA” on page 35.
36 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 3
Adding Information about the Internet Mail Adaptor
Once you have configured your local messaging server, you can configure your Solstice X.400 Internet Adaptor.
1. Configure your local MTA, as described in Chapter 4, “Configuring Your Local Messaging Server”.
2. Configure the Internet Adaptor as described in Chapter 11, “Configuring the Solstice X.400 Internet Adaptor”.
Adding Information about User Agents and DSAs
Below is a summary of the steps you should follow to configure the Solstice X.400 Messaging Server for X.500 directory system agents (DSAs), and third-party or P1 user agents.
1. Use x400tool to add information about a DSA, if required. Refer to “Adding Information About an X.500 DSA” on page 73.
2. Use x400tool to add any third-party user agents or P1 user agents to your messaging system. You can develop your own user agents and P1 user agents (using the SunLink X.400 Client Toolkit), and add these to your messaging system. Refer to Chapter 9, “Adding Third-Party Agents to Your Messaging System” for detailed instructions.
3. Use x400tool to modify the routing table for your local MTA, if required. When you add agents to the messaging system, default entries are made in the local routing table; however, you may need to modify these entries to improve the granularity of the routing algorithm. Refer to Chapter 10, “Routing Between Messaging Components” for detailed instructions.
Overview of Configuring Your Messaging System 37 3
38 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Part 2 — Configuring Your Messaging Server
This part has seven chapters: • Chapter 4, “Configuring Your Local Messaging Server,” describes how to use x400tool to set up your local MTA and message store. • Chapter 5, “Tuning Your Local Messaging Server,” describes how to use x400tool to tune your local MTA and message store. • Chapter 6, “Adding Remote Server Information to Your Messaging System,” describes how to use x400tool to add remote MTAs, message stores, and DSAs to your messaging system. • Chapter 7, “Testing and Tuning Connections to a Remote MTA,” describes how to test and tune remote server associations. It also describes how to configure routes to remote MTAs manually. • Chapter 8, “Adding Message Store User Information to Your Messaging System,” describes how to use x400tool to add information about users of your message store. • Chapter 9, “Adding Third-Party Agents to Your Messaging System,” describes how to use x400tool to add third-party user agents (UAs) and P1 agents to your messaging system. • Chapter 10, “Routing Between Messaging Components,” describes how to use x400tool to modify the default routing tables to handle complex routing between components in your messaging system.
Configuring Your Local Messaging Server 4
Specifying Your Local Server Name page 42 Setting an Access Control Password page 42 Specifying Your Global Domain Identifier page 44
This chapter describes how to use x400tool to name your local messaging server (the local MTA and local message store) and to specify the global domain identifier for your local MTA. It assumes that you have already started x400tool. Refer to Chapter 2, “Starting and Using x400tool” for detailed instructions.
When you start x400tool for the first time, your messaging system map shows an icon representing an unconfigured local messaging server. You must add information for your own local MTA and message store.
41 4
Specifying Your Local Server Name
The local server name is used to identify the local MTA and message store. In the case of an MTA, it is the name on which remote MTAs base the acceptance of an association request if access control is enabled. It is not part of the X.400 address and is not used for routing messages.
You must give this name to other system administrators who want to add your local server to their messaging systems.
To specify your local server name:
1. Double-click SELECT on the local server icon to activate the Local Server Configuration window.
2. Type the name assigned to your local server on the Name input line. You must enter a name of 16 characters or less.
Setting an Access Control Password
The access control mechanism is used to verify the source of a message. It depends on the configuration of both the local MTA and the remote MTA. Access control must be enabled or disabled for each remote MTA. • The remote MTA configuration determines whether access control is enabled. See “Enabling and Disabling Access Control for a Remote MTA” on page 68 for detailed instructions. • The local MTA configuration determines what is transmitted when access control is enabled. Access control can be based on the name of the initiating MTA only, or on the name and password of the initiating MTA. • The access control algorithm is summarized in Table 4-1. Note that this algorithm can be further modified by setting the advanced security parameters discussed in “Tuning the Security Options” on page 54.
42 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 4
Table 4-1 Access Control Algorithm
Local MTA Remote MTA Access Control Access control OFF Access control OFF Access control DISABLED Access control OFF Access control ON Local MTA name and null password Access control ON Access control OFF Access control DISABLED Access control ON Access control ON Local MTA name and true password
By default, the local MTA access control is set OFF. Passwords must not contain more than 62 characters. If you do not set a password, a null password is transmitted.
You must give this password to other system administrators who want to add your local MTA to their messaging systems.
To set your access control password:
♦ From the Local Server Configuration window, click SELECT to disable or enable access restrictions, and enter a password (if required). If you set a password, it will be sent to all remote MTAs that have access control enabled.
Click SELECT Type password
Figure 4-1 Setting an Access Control Password for the Local MTA
Configuring Your Local Messaging Server 43 4
Specifying Your Global Domain Identifier
The global domain identifier locates your local MTA within the global X.400 domain. It consists of a country code, an ADMD, and an optional PRMD. Refer to “X.400 Management Domains” on page 6 for a more detailed description of the global domain identifier.
You must give this global domain identifier to other system administrators who want to add your local MTA to their messaging systems.
To specify the global domain identifier for the local MTA:
1. From the Local Server Configuration window, enter the global domain identifier for your local MTA as shown in Figure 4-2. • Type a country code and ADMD. If necessary use the domain help to locate this information. If your local MTA does not require an ADMD in its X.400 address, enter a space on the ADMD input line. • Type your PRMD on the input line. If your local MTA is not part of a PRMD, you can leave a null PRMD entry. Do not insert a space.
Use the Domain Help to identify the country code and ADMD Figure 4-2 Specifying the Global Domain Identifier for the Local MTA
44 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Tuning Your Local Messaging Server 5
Tuning Associations page 46 Tuning the Reliable Transfer Service page 52 Tuning the Security Options page 54 Tuning the Remote Operations Service page 56 Tuning the Session Layer page 58 Setting the Type of Report Requested by Outgoing Messages page 61 Tuning the MTA Timer Tolerance page 62 Tuning Congestion Thresholds page 62 Enabling Message Tracking page 64
This chapter describes how to use x400tool to set advanced local server configuration features. It assumes that you have already set up your local server, as described in Chapter 4, “Configuring Your Local Messaging Server”.
Note – Tuning your local messaging server is optional; your local server should operate correctly using the default values.
The advanced configuration options for your local server are used to define the relationship between the local server and the remote MTAs in the local messaging system. In particular, they are used to set the thresholds at which certain events occur.
45 5
Tuning Associations
An association is like a link between two MTAs. Once an association is established, it is maintained until either there are no more messages waiting to be exchanged between the two MTAs, or one of the predefined thresholds is reached.
Tuning Basic Associations
The local MTA is able to open associations as required until a set (non-configurable) maximum number is reached. As the total number of current associations approaches this limit, the local MTA enters a shortage condition.
Your local MTA reacts to a shortage condition by trying to share its resources equally between the other components in the messaging system as shown in Figure 5-1. During a shortage condition, the local MTA closes associations automatically when the sent data or sent messages thresholds are reached.
The association is released automatically in order to service other agents
Figure 5-1 Resource Sharing During a Shortage Condition
46 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 5
To modify the behavior of associations between your local MTA and the remote MTAs in your messaging system, follow these steps:
1. Double-click SELECT on the local Server icon to activate the Local Server Configuration window.
2. Click SELECT on the MTA Tuning... button.
3. Press and drag MENU on the Tuning pull-down menu, and release MENU over the Association item.
4. Press and drag SELECT on the sliders to change the thresholds and time-outs as shown in Figure 5-2. You can also type the values directly on the input line for each option.
Drag SELECT on the slider
Type the value on the input line and press Return
Figure 5-2 Tuning the Association Thresholds
Tuning Your Local Messaging Server 47 5
Sent Data Threshold: Defines the maximum quantity (in multiples of 10 Kbytes) of data sent over a single association before the association is closed automatically. This threshold is applied only when there is a high demand for associations (shortage condition).
Sent Message Threshold: Defines the maximum number of messages sent over a single association before the association is closed automatically. This threshold is applied only when there is a high demand for associations (shortage condition).
Retry Connection Timeout: Defines the delay between a failed association attempt and the next retry.
Idle Association Timeout: Defines the maximum amount of time that an association is allowed to remain idle (no messages transmitted) before the association is closed automatically.
Recovery Attempts Delay: Defines the delay between a failed message delivery attempt and the start of the recovery process initiated by the local MTA (outgoing messages).
Association Retention Timeout: Defines the maximum delay permitted between a failed message delivery attempt and the start of the recovery process initiated by the remote MTA (incoming messages).
Once you have finished tuning the basic association options described in this section, apply your configuration by clicking SELECT on the Apply button.
Tuning Other Association Options
There are three queues associated with each remote MTA defined in the messaging system. Messages that are waiting to be sent to a remote MTA are placed in one of its queues according to the priority (non-urgent, normal, or urgent) assigned in the message header. (See “Defining a Custom Mail Header” on page 135 for instructions on assigning the priority to a message using mailtool.)
The Other Options are used to define the conditions under which the local MTA will open another association with a remote MTA. For outgoing messages, the local MTA bases its decision on the number of messages in each queue and the time that messages have spent in the queue.
48 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 5
You can also define the algorithm used to determine the priority assigned to a remote MTA when it requests an association for an incoming message. When the local MTA receives a number of simultaneous association requests it accepts the request from the remote MTA with the highest priority first.
1. From the Association Tuning window, click SELECT on the Other Options... button.
2. Press and drag SELECT on the sliders to change the thresholds and the MTA priority as required. You can also type the values directly on the input line for each option. In this case, you must press Return to enter each typed value into the database.
Figure 5-3 shows the default values assigned to thresholds based on the number of messages in the queue:
Figure 5-3 Association Thresholds Based On Number of Messages
Urgent Messages: Defines the total number of messages that must be waiting in the urgent (high-priority) queue before an association is opened with the remote MTA.
Normal Messages: Defines the total number of messages that must be waiting in the normal (unspecified-priority) queue before an association is opened with the remote MTA.
Non-Urgent Messages: Defines the total number of messages that must be waiting in the non-urgent (low-priority) queue before an association is opened with the remote MTA.
Total Number of Messages: Defines the total number of messages that must be waiting in all three queues (urgent, normal, and non-urgent) before an association is opened with the remote MTA.
Tuning Your Local Messaging Server 49 5
Figure 5-4 shows the default values assigned to thresholds based on the time spent in the queue:
Figure 5-4 Association Thresholds Based On Time Spent in Queue
Timer Unit: Defines the number of minutes by which the other thresholds in this category are multiplied.
Urgent Queue Stay-Time: Defines the maximum time (stay-time X timer unit) that messages are allowed to spend in the urgent (high-priority) queue before an association is opened.
Normal Queue Stay-Time: Defines the maximum time (stay-time X timer unit) that messages are allowed to spend in the normal (unspecified-priority) queue before an association is opened.
Non-Urgent Queue Stay-Time: Defines the maximum time (stay-time X timer unit) that messages are allowed to spend in the non-urgent (low-priority) queue before an association is opened.
50 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 5
Figure 5-5 shows the default values assigned to options which determine the priority of remote MTA associations:
Figure 5-5 Remote MTA Association Priority
These options define the relative importance of the factors used to determine the priority assigned to a remote MTA when it requests an association. Three factors are considered:
Number of Messages: Defines the multiplier applied to the number of messages waiting in the queue.
Size of Messages: Defines the multiplier applied to the size of the messages waiting in the queue.
Time Spent in Queue: Defines the multiplier applied to the time messages have spent in the queue.
Once you have finished tuning the Other association options described in this section, apply your configuration by clicking SELECT on the Apply button.
Tuning Your Local Messaging Server 51 5
Tuning the Reliable Transfer Service
The reliable transfer service (RTS) is used to ensure the safe delivery of messages. To tune the reliable transfer service:
1. Double-click SELECT on the local server icon to activate the Local Server Configuration window.
2. Click SELECT on the MTA Tuning... button.
3. Press and drag MENU on the Tuning pull-down menu, and release MENU over the Reliable Transfer Service item.
4. Modify the Reliable Transfer Service options shown in Figure 5-6.
Figure 5-6 Tuning the Reliable Transfer Service
52 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 5
RTS Inactivity Timeout: Defines the maximum delay allowed between the opening of an association and the start of activity. If no activity occurs within this specified delay, the association is closed automatically.
Initiator Checkpoint Size: Defines the checkpoint size proposed by your local MTA for outgoing messages. Regular synchronization marks (or checkpoints) are normally sent during message transmission. This allows the RTS to recover broken messages from the last checkpoint received. The checkpoint size (the amount of data sent between checkpoints) is a negotiated parameter proposed by the association initiator.
Acceptor Checkpoint Size (if proposed=0): Defines the checkpoint size for incoming messages if there is no checkpoint size proposed by the remote MTA. • If you set this value to 0, your local MTA will accept associations that do not use synchronization. • If you set this value to >0, your local MTA will propose this checkpoint size to the remote MTA. The remote MTA may choose to reject the proposal.
Acceptor Checkpoint Size (if proposed>0): Defines the maximum checkpoint size for incoming messages accepted by your local MTA. The checkpoint size proposed by the remote MTA will be used unless it exceeds this value.
Minor Synchronization: When minor synchronization is enabled, minor (intermediate) checkpoints are generated between the standard checkpoints.
Minor Sync. Window Size: Defines the amount of data sent between minor checkpoints.
Required Session Version: Defines the session layer protocol version required by the local MTA for all incoming messages. This may be version 1 only, or both version 1 and 2. For sessions with a remote 1988 system, you should set this option to both version 1 and 2.
Once you have finished tuning the Reliable Transfer Service options described in this section, apply your configuration by clicking SELECT on the Apply button.
Tuning Your Local Messaging Server 53 5
Tuning the Security Options
The security options are used to modify the basic access control mechanism. Refer to “Setting an Access Control Password” on page 42 and “Enabling and Disabling Access Control for a Remote MTA” on page 68 for detailed instructions on enabling and disabling access control for each remote MTA.
To tune the security options:
1. Double-click SELECT on the local server icon to activate the Local Server Configuration window.
2. Click SELECT on the MTA Tuning... button.
3. Press and drag MENU on the Tuning pull-down menu, and release MENU on the Security item.
4. Press and drag MENU on the MTA connection validation pull-down menu and release MENU over the desired validation system as shown in Figure 5-7. This option determines which elements the local MTA uses to check the source of incoming messages during the association negotiation phase. The local MTA refuses associations that fail to provide the expected parameters.
Check address: The local MTA checks the OSI address elements only.
Check name: The local MTA checks the name only.
Check address and name: The local MTA checks both the name and the OSI address elements.
Drag and release MENU
Figure 5-7 Setting the MTA Connection Validation
54 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 5
5. Click SELECT on the check boxes to define the restrictions placed upon the originator/recipient (O/R name) that identifies the user agent that sent the incoming message. When a message is submitted by a user agent, the local MTA verifies the originator O/R address and applies the routing algorithm defined by the entries in its routing table.
• If you check “must be local” the originator O/R address must match an entry in the routing table used by the local MTA, and this entry must point to a local user agent. • If you check “must belong to requesting agent” the originator O/R address must match an entry in the routing table used by the local MTA. The matching entry must be associated with the user agent that submitted the message.
Click SELECT
Figure 5-8 Specifying the Restrictions Placed on the O/R Name
Once you have finished tuning the Security options described in this section, apply your configuration by clicking SELECT on the Apply button.
Tuning Your Local Messaging Server 55 5
Tuning the Remote Operations Service
The Remote Operation Service Element (ROSE) is a request-reply protocol used by application entities. It defines procedures that can be processed remotely, much like a remote procedure call.
ROSE transfers information as operation protocol data units (OPDUs). For each exchange of information, ROSE creates a queue to store these OPDUs. This acts as a buffer for the application entity. When the application entity finishes processing an OPDU, it reads the next OPDU from the queue.
ROSE has several configurable parameters. The default value for each parameter is usually sufficient for ROSE to work efficiently. However, you may decide to fine-tune the ROSE parameters, depending on your particular environment.
To tune ROSE:
1. Double-click SELECT on the local server icon to activate the Local Server Configuration window.
2. Click SELECT on the MTA Tuning... or the Msg Store Tuning... button.
3. Press and drag MENU on the Tuning pull-down menu, and release MENU on the Remote Operations Service item.
4. Press and drag SELECT on the sliders to change the ROSE parameters as shown in Figure 5-9 on page 57. You can also type the values directly on the input line for each option. In this case, you must press Return to enter each typed value into the database.
ROSE Flow Control Options Window Size: Defines the initial number of OPDUs that can be exchanged between application entities.
Receive Queue Size: Defines the maximum number of OPDUs that ROSE can store in each incoming queue.
Ready Timer: Sets the time that ROSE waits for a reply after it sends a request to an application entity.
56 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 5
ROSE Recovery Options These parameters are included for possible future use.
ROSE Resource Management Options Default Block Size: Defines the maximum size of data that ROSE transmits in a block. This is only used if the block size is not defined elsewhere.
Memory Data Size: Defines the maximum amount of message data ROSE stores in memory. If the amount of data is greater than this size, ROSE saves the data in a file. Specify a value of 0 to force ROSE to save in files all the data it receives.
Figure 5-9 Tuning the Remote Operations Service
Once you have finished tuning the ROSE options described in this section, apply your configuration by clicking SELECT on the Apply button.
Tuning Your Local Messaging Server 57 5
Tuning the Session Layer
The session layer manages and synchronizes communication between end-users. If there is a problem with either the originator or the recipient, the session layer uses its synchronization points to determine from where it should resume the data exchange. You can tune session layer parameters to change how the session entity deals with data received or sent.
To tune the session layer:
1. Double-click SELECT on the local server icon to activate the Local Server Configuration window.
2. Click SELECT on the MTA Tuning... or the Msg Store Tuning... button.
3. Press and drag MENU on the Tuning pull-down menu, and release MENU on the Session item.
4. Modify the session layer options as shown in Figure 5-10.
Figure 5-10 Tuning the Session Layer
58 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 5
Session Connection Timer Options Timeout: Defines the time (in seconds) during which a session connection can wait for an accept, after which the connection aborts.
Initiator Reuse Timeout: If the transport connection can be reused (according to the outcome of the Propose Reuse of TC protocol negotiation), when the timeout between the termination of a session connection and the initiation of another session connection expires, the associated transport connection is terminated. This timeout specifies how long to maintain the transport connection open after the associated session connection is closed, if the connection was initiated locally.
Acceptor Reuse Timeout: If the transport connection can be reused (according to the outcome of the Propose Reuse of TC protocol negotiation), when the timeout between the termination of a session connection and the initiation of another session connection expires, the associated transport connection is terminated. This timeout specifies how long to maintain the transport connection open after the associated session connection is closed, if the connection was initiated remotely.
Protocol Options Click SELECT on the checkboxes to switch the following protocol options on or off:
Version 1: Specifies length restrictions on PDUs.
Version 2: Specifies no length restriction for PDUs.
Extended Concatenation: Allows the extended concatenation of PDUs and TPDUs.
Accept Reuse of TC: Accepts the reuse of a transport connection (TC) when proposed by the remote system.
Attempt Reuse of TC: Proposes to the peer session entity that the transport connection should be used again after the specified timeout. If the peer session entity accepts, the transport connection can be reused. If you choose this option, make sure that the Accept Reuse of TC is also set on.
Tuning Your Local Messaging Server 59 5
Try to Reuse TC: Specifies that new connection requests can attempt to reuse a transport connection to the peer session entity. If you choose this option, make sure that the Propose Reuse of TC is also set on. The peer session entity must also allow reuse of transport connections. Ensure that the Accept Reuse of TC and Propose Reuse of TC are both selected if you choose this option.
Include SSAP-ID: Adds the session service access point identifier to the AC SPDU (Session layer Protocol Data Unit Accept PDU).
Use TRS Expedited: Specifies that the Transport Expedited Data service should be used if it is available.
Functional Unit Options The functional unit options are for debugging purposes. The default is that all functional units are supported by the local session entity. These can be overridden by negotiated values. These options do not normally need to be updated.
Once you have finished tuning the session options described in this section, apply your configuration by clicking SELECT on the Apply button.
60 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 5
Setting the Type of Report Requested by Outgoing Messages
You can set the types of reports that may be requested by a user agent when sending messages to the local MTA.
There are three types of reports that may be requested by a user agent when sending messages to the local MTA: • Basic: Non-delivery report requested—unconfirmed delivery. • Confirmed: Delivery and non-delivery reports requested. • Audit and Confirmed: Delivery and non-delivery reports requested. Trace information for the delivered message is also requested.
1. Double-click SELECT on the local server icon to activate the Local Server Configuration window.
2. Click SELECT on the MTA Tuning... button.
3. Press and drag MENU on the Tuning pull-down menu, and release MENU over the Other item.
4. Press and drag MENU on the Report Request pull-down menu and release MENU to define the type of report requested by outgoing messages as shown in Figure 5-11.
Drag and release MENU
Figure 5-11 Defining the Report Request
Tuning Your Local Messaging Server 61 5
Tuning the MTA Timer Tolerance
The MTA timer tolerance (error margin) is applied to all timer values checked by the local MTA—for example, trace information. Altering this parameter can help accommodate problems that occur when MTAs have their clock or time zone set incorrectly. Messages that claim to have been sent before they arrived are normally rejected as errors; however, you can increase the tolerance within which your local MTA will ignore this discrepancy.
Setting a value of 255 minutes disables the MTA timer tolerance.
To tune the MTA timer tolerance:
1. Open the Other Tuning Options window as described in “Setting the Type of Report Requested by Outgoing Messages” on page 61.
2. Drag SELECT on the slider (or type in the value on the input line) to define the Time Tolerance as shown in Figure 5-12.
Drag SELECT
Figure 5-12 Defining the Timer Tolerance
Tuning Congestion Thresholds
Congestion thresholds determine the disk space thresholds at which your local MTA passes from normal to critical to congested state. Depending on the amount of space remaining in your spool file system, your local MTA may refuse to accept further incoming messages.
To tune the congestion thresholds:
1. Open the Other Tuning Options window as described in “Setting the Type of Report Requested by Outgoing Messages” on page 61.
2. Click SELECT on the increment/decrement buttons (or type the value on the input line) to define the congestion thresholds as shown in Figure 5-13 on page 63.
62 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 5
Click SELECT
Figure 5-13 Tuning the Congestion Thresholds
Normal to Critical: Defines the disk space threshold (in Kbytes) at which your local MTA passes from a normal to a critical state. If you have less than this amount of disk space left in your spool file system, the situation is considered critical and the local MTA will limit the amount of incoming data.
Critical to Congested: Defines the disk space threshold (in Kbytes) at which your local MTA passes from a critical to a congested state. If you have less than this amount of disk space left in your spool file system, the situation is considered congested and the local MTA will refuse all incoming data.
Back to Normal: Defines the disk space threshold (in Kbytes) at which your local MTA passes from a critical or congested state, and returns to a normal state. You must have at least this amount of disk space left in your spool file system before your local MTA will lift the restrictions placed on incoming data.
When specifying values for these parameters, the relationship between the three thresholds should be: Back to Normal > Normal to Critical > Critical to Congested
Current Congestion State: Displays the current state of your spool file system. • Normal: All new incoming messages accepted. • Critical: No new incoming messages will be accepted. Incoming message transfers currently in progress will be accepted if possible. • Congested: No incoming messages will be accepted. Incoming message transfers currently in progress will be aborted.
Tuning Your Local Messaging Server 63 5
Enabling Message Tracking
Your local MTA generates billing information each time a message is processed. This information is stored temporarily, before being overwritten by later billing information. Message tracking lets you keep a permanent record of each message processed by your MTA.
If you enable message tracking, billing information is not overwritten. Instead, it is copied to the /var/opt/SUNWconn/OSIROOT/spool/x400bills directory and translated into a text file. You can then, for example, read this information into a spreadsheet application and use it to calculate a charge (or bill) for your users.
For more information on billing information and message tracking, see the README file in the /opt/SUNWconn/mhs/examples/billing directory.
To enable or disable message tracking:
1. Open the Other Tuning Options window as described in “Setting the Type of Report Requested by Outgoing Messages” on page 61.
2. Click SELECT on the Message Tracking On or Off button. By default, message tracking is off.
64 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Adding Remote Server Information to Your Messaging System 6
Adding or Changing Information About a Remote Messaging Server page 66 Adding Information About an X.500 DSA page 73
This chapter describes how to use x400tool to add information about remote messaging servers to your local messaging system. A remote server can be a remote message transfer agent (MTA), a remote message store, or both a remote MTA and message store. This chapter also describes how to add information about a remote X.500 directory system agent (DSA).
This chapter assumes that you have already configured your local messaging server as described in Chapter 4, “Configuring Your Local Messaging Server”. Your local server can only communicate directly with remote servers that are added to your local messaging system.
You must obtain information about the remote MTA or message store from the system administrator who set it up.
65 6
Adding or Changing Information About a Remote Messaging Server
To add or change information about a remote MTA or message store to your messaging system:
1. If you are adding information about this server for the first time: a. Press and drag MENU down and right to display the New Agent submenu. b. Release MENU on the Remote Server item to add a new (unconfigured) remote server to your messaging system. The Remote Server Configuration window is displayed as shown in Figure 6-1 on page 67.
2. If you have already added some information about this server, double- click SELECT on the Remote Server icon. The Remote Server Configuration window is displayed as shown in Figure 6-1 on page 67.
3. Enter or change information about the remote server as described in the following subsections:
Specifying a Name and Type for the Remote Server page 67 Enabling and Disabling Access Control for a Remote MTA page 68 Specifying the Global Domain Identifier of a Remote MTA page 69 Selecting the Version of RTS Supported by the Remote MTA page 70 Selecting the Version of X.400 Supported by the Remote MTA page 70 Specifying the OSI Address of the Remote Server page 71
Note – Some of this information is not required, depending on whether the remote server includes an MTA.
Once you have completed the steps described in this section, apply your remote server configuration by clicking SELECT on the Apply button. This adds the remote server to your messaging system and adds a default route to the routing table used by the local server (provided an identical route does not exist). The default route is based on the global domain identifier for the remote server. See “Configuring Routes to a Remote MTA” on page 80 for more information.
66 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 6
Specifying a Name and Type for the Remote Server
The remote server name identifies it within your messaging system. It is not part of the X.400 address and is not used for routing messages.
1. From the Remote Server Configuration window, type a name for this remote server on the Name input line. The name you use must be unique within your configuration. You cannot modify this name once your configuration is applied.
2. Click SELECT on the Server Type buttons to specify whether the server is an MTA, a message store, or both an MTA and a message store.
Figure 6-1 Remote Server Configuration Window
Adding Remote Server Information to Your Messaging System 67 6
Enabling and Disabling Access Control for a Remote MTA
The access control mechanism depends on the configuration of both the local and remote MTA: • The remote MTA configuration determines whether access control is enabled for that MTA. The system administrator responsible for the remote MTA must also enable access control and provide you with its password, if access control is required. • The local MTA configuration determines what is transmitted when remote access control is enabled. Access control can be based on the name of the initiating MTA only, or on the name and password of the initiating MTA. (Refer to “Setting an Access Control Password” on page 42 for detailed instructions on setting the password for your local MTA.)
The access control algorithm is summarized in Table 6-1. Note that the algorithm can be modified by setting the advanced security parameters discussed in “Tuning the Security Options” on page 54.
Table 6-1 Access Control Algorithm
Remote MTA Access Control Access control OFF Access control DISABLED Access control ON Access control ENABLED
Note – If you enable access control for a remote MTA, you must obtain its password from the system administrator who set it up.
♦ From the Remote Server Configuration window, click SELECT on the Access Control buttons to disable or enable access restriction, and enter a password (if required). This is the password that the local MTA must receive from the remote MTA before it will accept an association for an incoming message.
68 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 6
Specifying the Global Domain Identifier of a Remote MTA
The global domain identifier identifies the remote MTA within the global X.400 domain. It consists of a country code, an ADMD, and an optional PRMD. Refer to “X.400 Management Domains” on page 6 for a more detailed description of the global domain identifier. You do not need to specify a global domain identifier when the remote server is a message store.
You must obtain the global domain identifier for the remote MTA from the system administrator who set it up.
♦ From the Remote Server Configuration window, enter the global domain identifier for the remote server as shown in Figure 6-2. • Type a country code and ADMD. If necessary use the domain help to locate this information. If the address of the remote server does not require an ADMD, then insert a space. • Type your PRMD on the input line. If the remote server is not part of a PRMD, you can leave a null PRMD entry. Do not insert a blank space.
Use the Domain Help to identify the country code and ADMD
Figure 6-2 Specifying the Global Domain Identifier for a Remote MTA
Adding Remote Server Information to Your Messaging System 69 6
Selecting the Version of X.400 Supported by the Remote MTA
The Solstice X.400 Messaging Server is an implementation of the 1988 and 1992 version of the X.400 recommendations; however, it can exchange messages with systems that comply to previous versions. • Choose 1984 X.400 Version Support if the remote MTA complies to the 1984 version. This disables the input line for the OSI presentation selector. This is the default option. • Choose 1988 X.400 Version Support if the remote MTA complies to the 1988 or 1992 version. This is the case if the remote MTA is running a Solstice X.400. This enables the input line for the OSI presentation selector and the ability to select the Reliable Transfer Service version.
To choose the X.400 Version Support:
♦ From the Remote Server Configuration window, click SELECT on 1984 or 1988 to select the X.400 Version Support. This selection should agree with the configuration of the remote server.
Note – When you change the 1988 X.400 Version Support, the related number of associations will also change accordingly, if you have not previously altered them. You should verify that the number of associations is correct for your chosen supported X.400 version. (See “Tuning the Remote MTA Association Options” on page 76.)
Selecting the Version of RTS Supported by the Remote MTA
The Reliable Transfer Service is used to ensure the safe delivery of messages to a remote MTA. The RTS 1984 version interfaces directly with the session layer, whilst RTS 1988 interfaces with the presentation layer. You will not normally need to change the default option. Check with your remote system administrator for the version of RTS. To select the RTS version:
♦ From the Remote Server Configuration window, click SELECT on 1984 or 1988 to select the Reliable Transfer Service Version. If you have selected 1984 X.400 version support, you cannot change this option.
70 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 6
Specifying the OSI Address of the Remote Server
Your local messaging server uses an OSI address to reach the remote server across the OSI network. If you have a message store that is served by a remote MTA, then the message store also uses the OSI address to reach the MTA. The OSI address of an MTA or message store depends on how the remote server is physically attached to the OSI network.
You must obtain the OSI address for a remote server from the system administrator who set it up.
A remote server can be attached to the OSI network through the following network interfaces: • X.25 (WAN). Note that the network address is an X.121 network address. • TCP/IP (RFC 1006). • LLC1 (LAN). For example, FDDI • CONS (X.25 1984) Note that the network address is an NSAP address.
You need to specify the subnetwork connection configured for the remote server indicating the transport layer connection.
If the remote server uses different OSI addresses for incoming and outgoing messages you must create two remote servers in your messaging system. Your local MTA and message store will send messages to one remote server and receive messages from the other.
Depending on how you want to configure your messaging system to use message stores, you may need to enter more than one OSI address. Use the table below to determine which types of OSI address are valid. Refer to “Adding Information about Messaging Servers” on page 33 for more information on when to use the different types of OSI address.
Remote Server Valid Address MTA only P1 MTA Address P3 MTA Address, if the remote MTA is serving a local message store user group Message Store only P3 MS Address MTA and MS Any combination
Adding Remote Server Information to Your Messaging System 71 6
To enter the components of the OSI address for a remote server:
1. From the Remote Server Configuration window, enter the required OSI addresses. • Enter a P1 MTA Address if you are configuring a remote MTA to communicate with your local MTA. • Click SELECT on P3 MTA Address... if you are configuring a remote MTA to communicate directly with your local message store. • Click SELECT on P3 Msg. Store Address... if you are configuring a remote message store to communicate with your local MTA.
2. Drag MENU on the network type pull-down menu to choose the type of network interface used to attach the remote server to the OSI network.
3. Drag MENU to select the address format for each selector. The elements of an OSI address can be entered in character format (char) or in hexadecimal format (hex).
4. Enter each layer of the OSI address. You must obtain the OSI address for the remote server from the system administrator who set it up.
• For an OSI address for an X.25 interface, type the entire X.25 address including the subaddress (without any internal prefixes) on the network address input line. The X.25 address is composed of decimal digits only. • For an OSI address for a LAN interface, you can either enter the NSAP in character or hexadecimal. • For an OSI address for a TCP/IP (RFC 1006) interface, you can enter either the network address in Internet format (dot notation) on the network address input line, or the host name that corresponds to this address on the host name input line. The network address is recovered from the NIS map using gethostbyname(3N).
5. Optionally, if the remote server is an MTA and the machine on which it resides has a second network interface: a. Click SELECT on Backup Address. b. Enter each layer of the second P1 MTA address as described in Step 4. Your local server will use the second OSI address if the remote MTA is unreachable via the first address.
72 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 6
Adding Information About an X.500 DSA
Using x400tool, you can add information about an X.500 directory system agent (DSA) to your messaging system. Refer to “X.400 Use of X.500 Directory Services” on page 20 for more information on DSAs.
If there is a configured Solstice DSA or Solstice DUA installed on the same system as your messaging server, you can use x400tool to import information about the Directory Service into your messaging system.
1. Double-click SELECT on the Directory icon to activate the Remote Directory (X.500) Access window as shown in Figure 6-3.
Figure 6-3 Remote Directory (X.500) Window
Adding Remote Server Information to Your Messaging System 73 6
2. Click SELECT on Import Configuration. x400tool reads configuration information from the Solstice DUA or DSA and updates the Remote Directory Access window.
3. Click SELECT on Apply.
If there is not a Solstice DUA or DSA installed on the same system as your messaging server, you can enter remote DSA information manually:
1. Double-click SELECT on the Directory icon to activate the Remote Directory (X.500) Access window as shown in Figure 6-3
2. Type the directory name (distinguished name or alias) of the local MTA.
3. Enter the local MTA’s access control password (if required) on the Password input line.
4. Type the directory name (distinguished name or alias) of the remote DSA. You must obtain this from the system administrator who set up the DSA.
5. Type the Application Process Title and Application Entity Qualifier, if required. These are relative distinguished names. Include both the attribute type and value. You must obtain them from the system administrator who set up the remote DSA.
6. Drag MENU on the network type pull-down menu to choose the type of network interface used to attach the remote DSA to the OSI network.
7. Drag MENU to select the address format for each selector. The elements of an OSI address can be entered in character format (char) or in hexadecimal format (hex).
8. Enter each layer of the OSI address. See “Specifying the OSI Address of the Remote Server” on page 71. You must obtain the OSI address for the remote DSA from the system administrator who set it up.
9. Click SELECT on Apply.
74 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Testing and Tuning Connections to a Remote MTA 7
Tuning the Remote MTA Association Options page 76 Testing an MTA Association page 77 Configuring Routes to a Remote MTA page 80
This chapter describes how to use x400tool to tune and test remote MTA associations. It also describes how to manually configure routes to remote MTAs.
This chapter assumes that you have already set up a remote server as described in Chapter 6, “Adding Remote Server Information to Your Messaging System”.
75 7
Tuning the Remote MTA Association Options
The remote MTA Association Management parameters are used to restrict the number of simultaneous associations that are created between your local MTA and the remote MTA.
1. Double-click SELECT on the remote server icon to activate the Remote Server Configuration window.
2. Click SELECT on the Associations button to activate the Remote MTA Associations window.
3. Press and drag SELECT on the sliders to change the thresholds and time- outs as shown in Figure 7-1. You can also type the values directly on the input line for each option.
Figure 7-1 Tuning the Remote MTA Association Management Options
The table below shows the default settings for the associations:
Local Remote Two-way Monologue Two-way Monologue 1984 0101 1988 1010
76 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 7
Remote MTA Association Management Options Max. Local Associations: Defines the maximum number of simultaneous associations that your local MTA can open with the remote MTA (association initiated by the local MTA). Note that Two Way associations have priority over Monologue associations. • Two way: Defines the maximum number of simultaneous associations that your local MTA can open with the remote MTA to send and receive messages. • Monologue: Defines the maximum number of simultaneous associations that your local MTA can open with the remote MTA to send messages only.
Max. Remote Associations: Defines the maximum number of simultaneous associations that the remote MTA can open with your local MTA (association initiated by the remote MTA). Note that Two Way associations have priority over Monologue associations. • Two way: Defines the maximum number of simultaneous associations that the remote MTA can open with your local MTA to send and receive messages. • Monologue: Defines the maximum number of simultaneous associations that the remote MTA can open with your local MTA to send messages only.
Once you have completed the configuration steps described in this section, save the remote MTA configuration by clicking SELECT on the Apply button. Note that this will only take effect after you have also Applied the selections on the Remote MTA window to confirm the overall configuration.
Testing an MTA Association
Once you add a remote MTA to your messaging system, you can test the configuration with the trigger option. This tests whether your local MTA can reach the remote MTA across the OSI network. It does not test whether electronic messages are correctly routed to this MTA or whether they can be delivered to their ultimate recipient.
To use the trigger successfully, the following conditions must be met: • The remote MTA defined in your local messaging system must be defined as a local MTA (local server) in the remote messaging system to which it belongs.
Testing and Tuning Connections to a Remote MTA 77 7
• The local MTA defined in your local messaging system must be defined as a remote MTA (remote server) in the remote messaging system. It does not have to be open to respond to the trigger. • The access control parameters must be set coherently between the local and remote MTAs in both messaging systems. • The remote MTA must be open. Highlight the remote MTA, press MENU on the Manage menu button and drag the pointer to the Open Agent item. Release MENU to open the remote MTA.
To use the Trigger option:
1. Click SELECT on the icon that corresponds to the remote MTA you want to test.
2. Press MENU on the Test menu button and drag the pointer to the Trigger item. Release MENU to activate the Trigger Remote MTA window.
3. Click SELECT on the Trigger button to test the association between your local MTA and the remote MTA as shown in Figure 7-2.
Remote MTA name
Local MTA name
Figure 7-2 Using the Trigger
If the trigger is successful, the local MTA will open an association with the remote MTA and the current connection state will change to connected. This shows that the remote MTA is configured correctly and will be able to receive electronic messages from your local MTA.
The association remains open for the time specified by the Idle Association Timeout for your local MTA. By default, this is one minute. (Refer to “Tuning Associations” on page 46 for detailed instructions on how to alter this delay.)
78 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 7
If the trigger is unsuccessful, the current connection state is marked as either disconnected or unreachable. If it is marked unreachable, as shown in Figure 7-3, then the icon for the remote MTA is also marked unreachable and the remote MTA is closed. It must be reopened before you can try another trigger attempt. Refer to “Displaying Status Information” on page 143 for detailed instructions on how to reopen a closed MTA.
Connection state after an unsuccessful trigger
Figure 7-3 Unsuccessful Trigger Attempt
The probable cause of the unsuccessful trigger attempt is shown in the status bar at the bottom of the window. The most common causes of a failed trigger are:
Remote MTA refuses connection: This occurs if there is a problem with the access control mechanism (for example, passwords not set correctly) or if your local MTA is not included in the remote messaging system configuration.
Remote OSI address invalid: The local MTA was unable to reach the specified remote MTA with the OSI address elements provided. Check that you entered the correct OSI address. Use osi_trace to examine the connection attempt.
Testing and Tuning Connections to a Remote MTA 79 7
Configuring Routes to a Remote MTA
When you add a remote MTA to your messaging system, x400tool attempts to create a default entry in the local routing table. This table is used by your local MTA to determine the forwarding address for each message that it receives. The default route for the remote MTA is based upon its global domain identifier.
If x400tool cannot create a default route (because, for example, an identical route already exists in the routing table) you will have to modify the routing table to add an entry that improves the granularity of the routing mechanism.
For example, if two remote MTAs are defined with the same global domain identifier, the local MTA will not create a default route for the second one. You must create a new entry in the routing table and add a discriminating attribute (for example, organization name, organizational unit name) to the route so that your local MTA can forward messages correctly to both systems.
Refer to Chapter 10, “Routing Between Messaging Components” for detailed instructions on how to modify default routing entries.
Setting a Default MTA
If you define a default MTA (also called a “catch-all” MTA), then the local MTA uses it as the destination for all messages that it fails to route based on the entries in its routing table. This mechanism works efficiently for X.121 addresses and for a default MTA that has its domain name (Country, ADMD, and PRMD) as its route; however, you must take care when there are other MTAs in the messaging system that route messages based on the organization name or other lower level attributes.
For example, to route a message with the address /C=FR/A=ATLAS/P=CORP/O=GRP/ to the default MTA in a messaging system that includes a remote MTA with the route /C=FR/A=ATLAS/P=CORP/O=MKTG/, you must ensure that the default MTA has the domain name /C=FR/A=ATLAS/P=CORP/ entered in its routing table.
Note – You must define a default MTA if you want to route messages based on an X.121 address only. The remote MTA that you choose for the default MTA must support routing decisions based on the X.121 address.
80 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 7
You can choose any of the remote MTAs in your messaging system as the default MTA. Ideally, the default MTA should point to a public X.400 provider since they maintain comprehensive and up-to-date routing tables that increase the chance of the message reaching its ultimate destination.
To set a default MTA:
1. Click SELECT on the icon that corresponds to the remote MTA that you want as your default MTA.
2. Press MENU on the Configure menu button and drag the pointer to the Default MTA item.
3. Activate the submenu and choose Set to configure the remote MTA as the default MTA.
Note – If you change the configuration of a default MTA, such that it is no longer the default MTA, it will route messages as normal. That is, messages that match its default route will continue to be routed through it.
Testing and Tuning Connections to a Remote MTA 81 7
82 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Adding Message Store User Information to Your Messaging System 8
Creating a Message Store User Group page 83 Configuring Message Store User Information page 86
This chapter describes how to use x400tool to add information about message store users. It assumes that you have already set up a local or remote message transfer agent (MTA).
See “The Solstice X.400 Message Store” on page 14 for a description of how the message store works.
Creating a Message Store User Group
For a minimum message store configuration you must create at least one message store user group, specify a name and a global domain identifier for it, and add at least one message store user.
Each message store user that you add to a message store user group has parameters that are common to all users of that group. For example, they share the same organizational attributes, geographical attributes, serving MTA, and serving message store.
83 8
To create a message store user group:
1. Press MENU on the Configure menu button and drag the pointer to display the New Agent submenu. Release MENU over MS Users Group. The MS Users Group Configuration window is displayed, as shown in Figure 8-1.
Figure 8-1 Message Store User Group Configuration Window
2. Type a name for the MS user group on the Group Name input line. The message store user group name is not part of an X.400 address and is not used for routing messages.
84 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 8
3. Press and drag MENU on the X.400 O/R Address Type pull-down menu and release it to define the type of X.400 address. See “Representing O/R Addresses” on page 9 for information on the types of X.400 address.
4. Enter the global domain identifier for the message store as shown in Figure 4-2 on page 44. • Type a country code and ADMD. If necessary, use the domain help to locate this information. If your message store does not require an ADMD in its X.400 address, enter a space on the ADMD input line. • Type your PRMD on the input line. If your message store is not part of a PRMD, you can leave a null PRMD entry. Do not insert a space.
5. If you selected a Mnemonic X.400 O/R address type in Step 3, enter any organizational attributes.
6. If necessary, click SELECT on Body and Contents to change the supported body and content types. In most cases, you will not need to change the default settings. By default, a message store user group supports any body type, and the X.400 1984 (P2) and X.400 1988 (P22) standard content types. For a full description, see “Specifying the Body Types Supported” on page 93 and “Specifying the Standard Content Types Supported” on page 94.
7. If necessary, click SELECT on Alternate Recipient to define an alternate recipient address. See “Specifying Alternate Recipients” on page 104 for information on how to specify an alternate recipient for a message store user group.
8. If you are adding users of a remote message store, click SELECT on the message store that this group is served by in the Message Stores scrolling-list. You must have already entered a P3 message store address. See Chapter 6, “Adding Remote Server Information to Your Messaging System”.
9. Click SELECT on the MTA that the message store is served by in the MTAs scrolling-list. If the message store is served by a remote MTA, you must have already entered a P3 MTA address. See Chapter 6, “Adding Remote Server Information to Your Messaging System”.
Before you can apply the message store user group, you must add at least one message store user.
Adding Message Store User Information to Your Messaging System 85 8
Configuring Message Store User Information
For a minimal message store user configuration you must specify a user name, password, and surname.
Adding Message Store User Information
To add a message store user to a message store user group:
1. From the MS Users Group Configuration window, click SELECT on Add User. The MS User Configuration window is displayed, as shown in Figure 8-2.
The X.400 O/R Address components you entered in the group configuration window are displayed here
Figure 8-2 Message Store User Configuration Window
86 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 8
2. Type a name and password for the message store user on the User Name input line and Password input line. Note that these parameters are case sensitive.
3. Type the remainder of the user’s X.400 O/R Address parameters. Depending on the type of O/R address, some parameters are mandatory while others are conditional. See Table 8-1 for a summary of mandatory (M) and conditional (C) parameters.
Table 8-1 Mandatory and Conditional Message Store User Parameters
Parameter Mnem1 Num2 Term3 Name M M M Password M M M Personal name attributes: Surname, M n/a n/a Given Name, Initials, Generation UA ID n/a M n/a X.121 Address n/a n/a M Terminal ID n/a n/a C Domain defined attributes and values n/a n/a C
1 Mnemonic. X.400 (1984) calls this Form 1 Variant 1.
2 Numeric. X.400 (1984) calls this Form 1 Variant 2.
3 Terminal. X.400 (1984) calls this Form 1 Variant 3 and Form 2.
4. Click SELECT on Apply to add the user to the message store user group. The MS User Configuration window is closed.
Note – Once you have added a user to the mesage store user group, you cannot change the message store or the MTA serving the group.
5. Click SELECT on Apply to add the message store user group to your configuration.
Adding Message Store User Information to Your Messaging System 87 8
Updating and Deleting Message Store User Information
To update a message store user:
1. Double-click SELECT on a message store user group icon to activate the MS Users Group Configuration window.
2. Double-click SELECT on the user you want to modify. The MS User Configuration window is displayed, as shown in Figure 8-2 on page 86. Change any parameters, then click SELECT on Apply.
To delete a message store user:
1. Double-click SELECT on a message store user group icon to activate the MS Users Group Configuration window.
2. Choose the user you want to delete from the Group Users scrolling-list.
3. Click SELECT on Delete User.
To delete an entire message store user group:
1. Click SELECT on a message store user group icon.
2. Press MENU on the Configure menu button and drag the pointer to the Delete Agent item. Release MENU to activate a confirmation window. Deleting a message store user group will also delete all message store users contained in that group.
88 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Adding Third-Party Agents to Your Messaging System 9
Adding and Configuring Third-Party User Agents page 89 Adding and Configuring X.400 MT (P1) Agents page 96
This chapter describes how to add local or remote user agents (UAs) and X.400 MT (P1) users (for example, message gateways) to your messaging system. It assumes that you have already defined your local message transfer agent (MTA) as described in Chapter 4, “Configuring Your Local Messaging Server”.
Adding and Configuring Third-Party User Agents
User agents (UAs) handle the submission and delivery of electronic messages. They provide the direct interface between end-users (application processes) and the messaging system. Native UAs are not supplied with the Solstice X.400 Messaging Server; however, you can add a third-party UA to your messaging system by giving it an identifying name and specifying the body types and contents that it uses.
Refer to the Solstice X.400 Programming Reference Manual for detailed information regarding the development of X.400-compatible user agents and X.400 MT (P1) users using the Message Access (MA) and Message Transfer (MT) interfaces.
89 9
Adding a Third-Party User Agent
To add a third-party user agent to your messaging system:
1. Press and drag MENU down and right to display the New Agent submenu.
2. Release MENU over the User Agent item to add a new (unconfigured) user agent to your messaging system. The User Agent Configuration window is displayed, as shown in Figure 9-1.
Figure 9-1 Adding a Third-Party User Agent
90 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 9
Specifying the User Agent Name and Type
The user agent name identifies the user agent within your messaging system. It is not part of the X.400 address and is not used for routing messages.
The type of user agent can be local or remote. A local UA is one connected through the XAPIA MA interface directly to the local MTA. A remote UA is connected through a subnetwork and uses the P3 protocol.
Note – Solstice X.400 does not currently provide a remote P3 user agent. However, you can develop one using the Solstice X.400 Client Toolkit, or obtain one from other suppliers.
1. Double click SELECT on the user agent icon to activate the User Agent Configuration window, if it is not already displayed.
2. Type the name assigned to this user agent on the Name input line. An unassigned (blank) user name will generate an error when you apply your configuration. You cannot modify this name once it is applied.
3. Click SELECT on the User Agent Type buttons to specify whether the UA is local or remote. If you specify a remote user agent, a User Agent Address window is displayed:
a. Enter the OSI address for the remote user agent. The presentation, session and transport selectors should be the same as those defined in the remote stack configuration. b. Select the Network Type used by the remote user agent. The type of subnetwork can be X.25, LAN, TCP/IP, or CONS (X.25 84). This will be defined in the remote UA’s configuration. Depending on which subnetwork type you select, additional address information is required. For example, if you select X.25, you must enter the X.121 address, or if you select CONS X.25 1984, you need to enter the NSAP address. For a LAN, you can enter the NSAP in character or hexadecimal format.
Adding Third-Party Agents to Your Messaging System 91 9
Enabling and Disabling User Agent Access Control
The access control mechanism is dependent upon the configuration of the both the user agent and its local server: • The user agent configuration determines whether access control is enabled for that UA. If access control is enabled, the local messaging server checks the identity of the UA sending the message before it will accept the connection. • The local server configuration determines what is transmitted when access control is enabled. Access control can be based on the name of the initiating agent only, or on the name and password of the initiating agent.
Note that this algorithm can be modified by setting the advanced security parameters for the local server as described in “Tuning the Security Options” on page 54.
To enable or disable access control:
1. Double-click SELECT on the user agent icon to activate the User Agent Configuration window, if it is not already displayed.
2. Click SELECT to disable or enable access restriction, and enter a password (if required) as shown in Figure 9-2. This is the password that the local server expects to receive from the user agent before it will accept an association for an outgoing message.
Click SELECT Type password
Figure 9-2 Enabling and Disabling Access Control for a User Agent
92 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 9
Specifying the Body Types Supported
Body types define the format in which the bodyparts of messages are transmitted. Bodyparts may be either binary data or text. An undefined bodypart is treated as binary data. You can prevent the local server from forwarding bodyparts that the user agent is unable to process by specifying the body types that the user agent supports.
Note that the body type definition is only relevant if either X.400 1984 (P2) or X.400 1988 (P22) is selected as one of the supported standard content types. See “Specifying the Standard Content Types Supported” on page 94.
To specify the body types supported by the user agent:
1. Double-click SELECT on the user agent icon to activate the User Agent Configuration window, if it is not already displayed.
2. Click SELECT on one or more of the check boxes associated with the body types supported by the user agent. The possible body types are described in Table 9-1.
Table 9-1 Standard Body Types Defined by the X.400 Recommendations
Body Type Description any UA will accept all possible body types (both binary data and text) and will accept messages with body parts of various formats. undefined UA will accept a message including binary data (bilaterally defined data) bodyparts. Only supported by the 1984 version of the X.400 specifications. telex UA will accept messages including telex format bodyparts. IA5 UA will accept messages including IA5 (ASCII) text format bodyparts. G3 Fax UA will accept messages including Group 3 (G3) fax format bodyparts. G4 Fax UA will accept messages including Group 4 (G4) fax format bodyparts. teletext UA will accept messages including teletext format bodyparts as defined by T.61. videotex UA will accept messages including videotex format (as defined by T.100 and T.101) bodyparts. voice UA will accept messages including voice bodyparts. sfd UA will accept messages including a Simple Format Document (SFD) as defined by the 1984 revision of the X.400 recommendations.
Adding Third-Party Agents to Your Messaging System 93 9
Table 9-1 Standard Body Types Defined by the X.400 Recommendations
Body Type Description mixed UA will accept messages of a sort that can be processed by mixed-mode terminals (teletext and G4 fax). ODA UA will accept messages conforming to Office Documentation Architecture standards. For example, this allows recognition of word-processor files. ISO 6937 UA will accept messages including full ASCII text plus additional features, such as accents. It is the equivalent of the teletext format.
Specifying the Standard Content Types Supported
You can prevent the local server from forwarding messages that the user agent is unable to process by specifying the content types that the UA supports.
To specify the standard content types supported by the user agent:
1. Double-click SELECT on the user agent icon to activate the User Agent Configuration window.
2. Click SELECT on the check boxes associated with the supported standard content types that the user agent supports. The possible content types are described in Table 9-2.
Table 9-2 Standard Content Types Defined by the X.400 Recommendations
Content Type Description X.400 1984 Standard content type 2. Indicates that the user agent will accept Interpersonal (P2) Messages (used to exchange electronic mail between end-users) conforming to the 1984 revision of the X.400 recommendations. X.400 1988 Standard content type 22. Indicates that the user agent will accept Interpersonal (P22) Messages (used to exchange electronic mail between end-users) conforming to the 1988 revision of the X.400 recommendations. Unidentified Standard content type 0. Indicates that the user agent will accept messages of an unidentified (or unknown) content type. The user agent may or may not be able to process the message. External Standard content type 1. Indicates that the user agent will accept messages whose content type is not defined by the X.400 recommendations. EDI Standard content type 35. Indicates that the user agent will accept EDI messages (used to exchange billing information between end-users).
94 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 9
Specifying the Non-Standard Content Types Supported
You can also specify the non-standard content types (content types not defined by the X.400 recommendations) supported by your third-party user agent. These are used for end-to-end communication between user agents and rely upon proprietary encoding.
To specify the non-standard content types supported by the user agent:
1. Double-click SELECT on the user agent icon to activate the User Agent Configuration window.
2. Type a numeric content type identifier on the Value input line as shown in Figure 9-3. The code must be recognized as a content type by the user agent. Its value must not correspond to any of the standard content types, or any other non-standard types. The standard content types are: 0 (unidentified), 1 (external), 2 (X.400 1984; P2), 22 (X.400 1988; P22), and 35 (EDI).
3. Click SELECT on Add to place the non-standard content type in the scrolling-list.
Enter the non-standard content type code
Click SELECT on Add
Figure 9-3 Specifying Non-Standard Content Types
Configuring Routes to a User Agent
After you have added a new user agent to your messaging system, you need to modify the routing table used by the local server to add at least one route for the user agent. Refer to Chapter 10, “Routing Between Messaging Components” for detailed instructions.
Adding Third-Party Agents to Your Messaging System 95 9
Adding and Configuring X.400 MT (P1) Agents
An X.400 MT (P1) agent relies upon the X.400 message transfer (MT) service for the exchange of electronic messages between X.400-compatible systems. Message transfer agents (MTAs) and message adaptors are typical examples of X.400 P1 users.
The Solstice X.400 Internet Adaptor is a native P1 user agent; however, you can also add third-party P1 user agents to your local server configuration. These should be developed using the XAPIA message transfer (MT) interface defined by X/Open. Refer to the Solstice X.400 Programming Reference Manual for further details.
Adding a Third-Party P1 Agent
You define a third-party P1 agent by giving it a name and specifying its global domain identifier. By default, a new P1 agent is assigned the same global domain identifier as the local MTA.
To add a third-party P1 agent to your messaging system:
1. Press and drag MENU down and right to display the New Agent submenu.
2. Release MENU over the X.400 P1 User item to add a new (unconfigured) P1 user to your messaging system.
Specifying the P1 Agent Name
The P1 user agent name identifies the third-party P1 user within your messaging system. It is not part of the X.400 address and is not used for routing messages; it is used as the client name in the mt_open function of the XAPIA message transfer (MT) interface.
To specify the P1 User name:
1. Double-click SELECT on the P1 user icon to activate the P1 User Configuration window, if it is not already displayed.
2. Type the name assigned to this P1 user on the Name input line. An unassigned (blank) user name will generate an error when you try to apply your configuration. You cannot modify this name once it is applied.
96 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 9
Enabling and Disabling P1 User Access Control
The P1 user access control mechanism has the same dependencies as the user agent access control mechanism, as described in “Enabling and Disabling User Agent Access Control” on page 92.
To enable or disable P1 user access restrictions:
1. Double-click SELECT on the P1 user icon to activate the MT User Configuration window.
2. Click SELECT to disable or enable access restriction, and enter a password (if required. This is the password that the local MTA must receive from the P1 user before it will accept an association for an incoming message.
Specifying the Type of P1 Access
You need to specify the type of access required for the P1 user. • Specify XAPIA Message Transfer Interface for XAPIA applications that use the P1 protocol to access the MTA. • For other applications which do not use XAPIA, you should use the message queue interface. This architecture reflects that of third party MTAs (non-XAPIA), which use message queues to interface between P1 applications and their MTAs. You can specify a maximum of 16 P1 users that use the message queue interface.
Note – By default the incoming messages are queued in: /var/SUNWconn/OSIROOT/spool/p1_username/in_queue and the outgoing messages are queued in: /var/SUNWconn/OSIROOT/spool/p1_username/out_queue Sometimes these message queues can become large and may cause problems by being in this location. To avoid these problems, create a symbolic link between these directories and another location where file size is not so limited.
To specify the type of access:
1. Press MENU on Access and drag the pointer down to choose the XAPIA Message Transfer Interface or Message Queues item, as shown in Figure 9-4.
Adding Third-Party Agents to Your Messaging System 97 9
2. Release the MENU button on the appropriate access type. For XAPIA P1 applications, choose the XAPIA Message Transfer Interface item, for access from other types of P1 applications, choose the Message Queues item.
Figure 9-4 Specifying the Type of P1 Access
3. Press Apply to save the changes and return to the P1 user configuration screen.
Specifying the Global Domain Identifier
The global domain identifier locates a P1 user within the global X.400 domain. It consists of a country code, an ADMD, and an optional PRMD. By default, a new P1 user is assigned the same global domain identifier as the local MTA.
To specify the global domain identifier:
1. Double-click SELECT on the P1 User icon to activate the MT User Configuration window.
2. Enter the global domain identifier for the remote MTA as shown in Figure 9-5. By default, the P1 user is assigned the same global domain identifier as your local MTA. If you need to modify the default global domain identifier:
98 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 9
• Type a country code and ADMD. If necessary use the domain help to locate this information. If your local MTA does not require an ADMD in its X.400 address, enter a space on the ADMD input line. • Type your PRMD on the input line. If your local MTA is not part of a PRMD, you can leave a null PRMD entry. Do not insert a blank space.
Type the PRMD on the input line
Use the Domain Help to identify the country code and ADMD
Figure 9-5 Specifying the Global Domain Identifier
Once you have completed the basic configuration steps described in this section, apply your P1 user configuration by clicking SELECT on the Apply button. This adds the P1 user to your messaging system and adds a default route to the routing table used by the local server (provided an identical route does not exist).
Configuring Routes to a P1 Agent
When you add a new P1 user to your messaging system, x400tool attempts to create a default entry in the local routing table. If x400tool cannot create a default route, you will have to modify the routing table manually.
For example, if you already have a remote MTA defined with the same global domain identifier, the local MTA will not create a default route for the P1 user. You must create a new entry in the routing table and add some discriminating attribute (organization name, organizational unit name, etc.) to the route so that your local MTA can forward messages correctly to both systems.
Refer to Chapter 10, “Routing Between Messaging Components” for detailed instructions on how to modify default routing entries.
Adding Third-Party Agents to Your Messaging System 99 9
100 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Routing Between Messaging Components 10
Routing in the X.400 Domain page 101 Default Routing Entries page 103 Specifying Alternate Recipients page 104 Testing the Routing Algorithm page 106
This chapter describes how to use x400tool to modify and test the routing table used by the local messaging server. It also explains how to add alternate recipicients for message store user groups, user agents, and P1 agents.
Routing in the X.400 Domain
An MTA functions like a traditional postal service sorting office—sorting messages for delivery based on their addresses. The MTA compares the component attributes of each O/R address against the entries in its local routing table. Each entry associates a given list of attributes with one of the recognized components in the messaging system. All messages with an O/R address (or part of an O/R address) that matches one of these lists of attributes will be forwarded to the same destination.
101 10
The default routing entries for components added to a messaging system are always based on the global domain identifier. For example, suppose your local messaging server has a global domain identifier of /P=SUN/A=ATLAS/C=FR/. You add a remote MTA with a global domain identifier of /P=HQ/A=ATLAS/C=FR/ to your messaging system. All messages received by your local server with /P=HQ/A=ATLAS/C=FR/ as part of their O/R address will be forwarded to that remote MTA.
Each entry in the local routing table is associated with a single remote MTA; however, each remote MTA can be associated with multiple routing entries.
When you add components to your messaging system that are located within the same management domain, they will have the same global domain identifier. To differentiate between the routing to these components, you must modify the routing tables used by your local server.
For example, the MTAs servicing the European headquarters for a company are all located within the same management domain and have the same global domain identifier /P=EUROHQ/A=ATLAS/C=FR/. To differentiate between MTAs within the same global domain, the routing algorithm is expanded to include the organizational attribute:
/C=FR/A=ATLAS/P=EUROHQ/O=SALES/ Routing entries for the remote MTA handling messages for the sales and marketing groups /C=FR/A=ATLAS/P=EUROHQ/O=MKTG/
/C=FR/A=ATLAS/P=EUROHQ/O=PRDEV/ Routing entries for the remote MTA handling messages for the product development and test groups /C=FR/A=ATLAS/P=EUROHQ/O=TEST/
Figure 10-1 Example Routing Entries
Messages for members of the sales and marketing groups are relayed through one MTA; messages for members of the product development or test groups are relayed through another.
102 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 10
Default Routing Entries
When you add a remote MTA or P1 user agent to your messaging system, x400tool attempts to create a default entry in the local routing table. The default route is based upon the global domain identifier for the new component and in many cases this information will be sufficient to allow your local MTA to route or relay messages to it.
A default routing entry is of the form /C=country_code/A=admd/P=prmd/.
Before creating the default entry, x400tool checks the local routing table for an identical entry. If one already exists, the default entry is not created and x400tool issues a warning that tells you to modify the default routing table.
You can also modify the default routing entry if you want to fine-tune the routing algorithm.
Modifying the Default Routing Table
The routing table for the local MTA is composed of groups of entries. Each group of entries is associated with one of the components in the local messaging system.
The Routing window has a scrolling-list that contains the current routing entries for the selected component. You can add new routing entries to this list, or modify existing entries.
Note – You do not need to modify the routing entry for a message store user, since each message store user has only one possible route.
To add a new routing entry or modify an existing routing entry for one of the components in your messaging system:
1. Click SELECT on its icon to highlight it.
2. Press MENU on the Configure menu button and drag the pointer to the Modify Routing item. Release MENU to activate the Routing window.
3. If you are modifying an existing routing entry, click SELECT on one of the entries in the scrolling-list to highlight it and display its component attributes.
Routing Between Messaging Components 103 10
4. Specify a global domain identifier of the component (country, ADMD, and optionally, a PRMD) as the foundation for your routing entry. You must specify a country code and an ADMD. Use the Domain Help to find this information, if required. If the component is not part of an established ADMD you must enter a blank space.
5. Specify any other attributes that will be used to sort the messages sent to the selected component. Refer to the description of O/R addresses in “X.400 Addressing” on page 7 for description of the valid O/R address types.
6. Click SELECT on Add or Update to update the scrolling-list.
Deleting an Existing Routing Entry
To delete an existing routing entry:
1. Activate the Routing window for one of the components in the local messaging system.
2. Click SELECT on one of the entries in the scrolling-list to highlight it and display its component attributes.
3. Click SELECT on Delete to remove the selected entry from the scrolling- list.
Specifying Alternate Recipients
You can define an alternate O/R address for each user agent and message store user group in your messaging system. These O/R addresses are used by the local server if it cannot route a message to the component defined by the O/R address contained in the message.
For example, if the message contains a body part of a type that is not supported by the user agent specified by the O/R address in the message, the local MTA will forward the message to the alternate recipient address if one is defined.
The alternate recipient is usually a system administrator, or someone charged with ensuring that the redirected message reaches its ultimate destination.
104 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 10
To specify an alternate recipient for a component:
1. Activate the Alternate Recipient window. • If you are specifying an alternate recipient for a user agent: a. Click SELECT on the agent’s icon. b. Press MENU on the Configure menu and release it over Modify Routing to activate the Routing window. c. Click SELECT on Alternate Recipient. • If you are specifying an alternate recipient for a message store user group, click SELECT on Alternate Recipient from the MS Users Group Configuration window.
2. Type in the full O/R address for the alternate recipient.
3. Click SELECT on Apply to add the alternate recipient address to your configuration.
Figure 10-2 Creating an Alternate Recipients
Routing Between Messaging Components 105 10
Testing the Routing Algorithm
You can use x400tool to test the routing algorithm defined by the entries in the local routing table. This feature does not send any messages; it tells you if the local MTA would be able to route a message based on a given O/R address.
To test the routing algorithm:
1. Press MENU on the Test menu button and drag the pointer to the Test Routing item. Release MENU to activate the Test Routing window.
2. Type in the component attributes for the O/R address you want to test. Refer to the description of O/R addresses in “X.400 Addressing” on page 7 for description of the valid O/R address types.
3. Click SELECT to check the box for Use Default MTA, if you want to allow the local MTA to use the default (“catch-all”) MTA to route messages that it cannot forward in any other way. See “Setting a Default MTA” on page 80 for more information.
4. Click SELECT to check the box for Use Alternate Recipients, if you want the local MTA to make use of any alternate recipients you may have defined.
5. Click SELECT on Test to see if the local MTA is able to route messages containing the specified O/R address.
There are three possible results:
Routing Possible: If the local MTA is able to route the message it displays a status message in the bottom-left corner of the Test Routing window. This message includes the name of the component that would have received the message, based on the current routing algorithm.
Routing Ambiguous: If the routing algorithm generates an ambiguous result—for example, if the local MTA is unable to distinguish between two possible destinations— or if the format of the O/R address is not compliant with the X.400 specification, x400tool generates an error message. This may occur if you have not specified enough details for the test route, for example, missing surname.
Routing Impossible: If the local MTA cannot route the message at all x400tool generates an error message.
106 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 10
Click SELECT to test the routing Status message indicates that routing would have been successful
Figure 10-3 Testing the Routing Algorithm
Routing Between Messaging Components 107 10
108 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Part 3 — Configuring and Using Your Internet Mail Adaptor
This part has three chapters. You do not need to read this part if you do not have a license for the Solstice X.400 Internet Adaptor. • Chapter 11, “Configuring the Solstice X.400 Internet Adaptor,” describes how to use x400tool to set up a Solstice X.400 Internet Adaptor to exchange electronic messages between the Internet mail domain and the X.400 domain. • Chapter 12, “Testing and Tuning the Solstice X.400 Internet Adaptor,” describes how to test the configuration of your Solstice X.400 Internet Adaptor. It also describes how to modify mapping tables, how to configure routes manually, and how to modify the default sendmail configuration file (sendmail.cf) • Chapter 13, “Sending and Receiving Internet Mail Through the Internet Adaptor,” describes how to use Internet mail applications to send and receive Internet mail messages through the Solstice X.400 Internet Adaptor.
Configuring the Solstice X.400 Internet Adaptor 11
Before You Start page 112 Adding Solstice X.400 Internet Adaptor Information page 115 Adding the Pseudo Host Name to the NIS Database page 118 Modifying sendmail.cf to Add a Pseudo Host Name Manually page 119
This chapter describes how to use x400tool to set up a Solstice X.400 Internet Adaptor to handle the exchange of messages between Internet mail applications and the X.400 domain. It assumes that you have already set up your local server as described in Chapter 4, “Configuring Your Local Messaging Server”.
The Solstice X.400 Internet Adaptor is an optional component of the Solstice X.400 Messaging Server.
The Solstice X.400 Internet Adaptor is an implementation of RFC1327. It maps Internet mail (RFC 822) addresses and service elements to equivalent X.400 addresses and service elements, and adds any additional information required to route messages across the global X.400 domain. Refer to “The Solstice X.400 Internet Adaptor” on page 15 for a detailed description of the adaptor and how it works.
Note – In previous versions of Solstice X.400, the Solstice X.400 Internet Adaptor was called the X.400/SMTP Gateway.
111 11
Before You Start
Before you start to configure your Solstice X.400 Internet Adaptor, ensure that you have the required software, and determine your local Internet domain address.
Software Requirements for the Solstice X.400 Internet Adaptor
Ensure that you have the following software installed on your machine: • The Solstice X.400 Messaging Server. • A license for the Solstice X.400 Internet Adaptor. Note that the adaptor has a separate license from the Solstice X.400 Messaging Server. • OpenWindows 3.1 or later, and in particular the file cetables which is used by the Solstice X.400 Internet Adaptor. To check that the file cetables is available on your machine, type:
hostname% ls $OPENWINHOME/lib/cetables/cetables /usr/openwin/lib/cetables/cetables
• The sendmail daemon. This is used by Internet mail applications such as mail and mailtool. To check that the sendmail daemon is running on your machine, type:
hostname% ps -ef | grep sendmail pid timestamp /usr/lib/sendmail -bd -q1h
The sendmail daemon uses the configuration file sendmail.cf. When you install the Solstice X.400 Messaging Server software, this file is modified automatically (using the script gen_sendmail.cf) to add a default pseudo host name and X.400-specific rules. However, if sendmail.cf does not exist, or if you have a customized version of the file, the modification will fail. Refer to “Modifying the sendmail Configuration File for the Internet Adaptor” on page 130 for instructions of how to use the gen_sendmail.cf script and how to add the necessary modifications manually.
112 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 11
Determining Your Internet Domain Address
Your Internet mail domain address is equivalent to an X.400 global domain identifier. It locates the machine on which your adaptor is running within the global Internet mail address space. A typical Internet mail domain name looks like this:
Division.Company.COM
Your local Internet mail domain address is defined within the sendmail configuration file (/etc/mail/sendmail.cf) located on your mail host (or on your mail server if you are remotely mounting your /var/mail directory).
A mail host is a machine that is designated as the primary mail machine on your network. This is the machine that receives mail from outside your local domain; it is also the machine that receives mail that the local domain cannot deliver.
A mail server is a machine that stores mailboxes for client machines (in /var/mail). When mailboxes are located on a mail server, messages are first delivered to the mail server, and not directly to the client machine.
Refer to your Solaris documentation for a detailed description of the components of an Internet mail system and the addresses used to route messages between them.
To determine the Internet domain address for your local machine: • If /var/mail is mounted remotely, determine the name of your mail server:
hostname% mount | grep spool /tmp_mnt/var/spool/mail on mail_server:/var/spool/mail datestamp
If /var/mail is mounted remotely, the mount point displayed with the name of the mail server (mail_server). This is where you will find your local Internet domain address.
Configuring the Solstice X.400 Internet Adaptor 113 11
• If your /var/mail is located on your own machine, determine the name of your mail host.
hostname% ypmatch mailhost hosts 129.123.123.12 mail_host mailhost
The name of the mail host (mail_host) follows the IP address. This is where you will find your local Internet domain address. • Look for your Internet domain name in the sendmail.cf configuration file on either your mail server (if your mailbox is mounted remotely) or on your mail host (if your mailbox is mounted locally).
On machines running Solaris 2.x, this file is /etc/mail/sendmail.cf.
hostname% more /etc/mail/sendmail.cf | grep Dm # appear in you mail headers, add a “Dm” line to define your domain name # The Dm value is what is used in outgoing mail. The Cm values are # accepted in incoming mail. By default Cm is set from Dm but you might # DmCS.Podunk.COM Dm
Make a note of the local Internet domain address (local_domain_address) in the last line of text. You will need to know this when configuring your adaptor.
You can use x400tool to show you how this address is converted to an X.400 address in the adaptor (see “Testing the Solstice X.400 Internet Adaptor” on page 122).
114 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 11
Adding Solstice X.400 Internet Adaptor Information
The Solstice X.400 Internet Adaptor Configuration window (shown in Figure 11-1) is used to define the way in which messages and addresses are mapped between Internet mail and X.400 mail applications. It is also used to define the Internet domain address and pseudo host name that sendmail uses for routing electronic messages to the adaptor.
To configure the Solstice X.400 Internet Adaptor:
1. Double-click SELECT on the SMTP_X400 icon to activate the Solstice X.400 Internet Adaptor Configuration window shown in Figure 11-1.
Figure 11-1 The Solstice X.400 Internet Adaptor Configuration Window
Configuring the Solstice X.400 Internet Adaptor 115 11
2. Drag and release MENU to define the default character set that is used to map between Internet mail and X.400 mail bodyparts (the content of the message). The default value is ISO8859-1. Note that the ASCII character set does not support international (8-bit) characters. International characters are represented by the nearest ASCII (7-bit) character.
3. Drag and release MENU to define the default body type created when a message that contains international characters is received from Internet mail. Under most circumstances, you should choose the default value of ISO6937 as the default body type. ISO6937 provides full IA5 (ASCII) and Teletext (T61, a subset of ASCII) character support, and also supports international (8-bit) characters. If ISO6937 is enabled, but the message does not contain 8-bit characters, an IA5 (7-bit) body part is created automatically.
4. Enter the local Internet domain address for the adaptor on the Local UNIX Mail Domain input line. This is the domain name that you recovered from the sendmail.cf file on your mail host or mail server. See “Determining Your Internet Domain Address” on page 113 for detailed instructions.
5. Enter the pseudo host name that will be used to route messages from Internet mail applications to the adaptor. Use the default pseudo name x400-gate, or enter a new name. The local UNIX mail daemon (sendmail) will route all messages identified by the pseudo host name to the Solstice X.400 Internet Adaptor.
The pseudo host name must be entered in the /etc/hosts file on your NIS server (or on your local machine if you are not running NIS) as an alias of the machine running the adaptor. See “Adding the Pseudo Host Name to the NIS Database” on page 118 for information on how to do this.
If you modify the default pseudo host name, the change must also be registered in the sendmail.cf file on your mail host (if /var/mail is located locally) or on your mail server (if /var/mail is located remotely).
116 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 11
6. Click SELECT on the checkboxes to enable or disable the optional configuration parameters. These are described in Table 11-1.
Table 11-1 Internet Adaptor Configuration Options
Checkbox Description Uppercase Country Converts country codes contained in X.400 addresses to uppercase characters. Some ADMDs (such as ATLAS in France) require that country codes always be in uppercase. If this option is enabled, the Solstice X.400 Internet Adaptor automatically converts any lowercase country codes to uppercase characters. Manage Content Preserves the content of failed deliveries. By default, your adaptor requests Return Locally negative-delivery reports and content return for the messages it sends to the messaging system. The negative-delivery report normally contains the content of the original message; however, the only way to guarantee this is to set Manage Content Return Locally. This preserves a local copy of an outgoing message until a positive-delivery report is received. Note: This facility can be costly, in terms of both disk space and network charges imposed by ADMDs. The file system used by the local server to spool messages can fill with local copies of outgoing messages that are only deleted when a positive-delivery report is received. In addition, you may be charged for the return of positive-delivery reports by some ADMDs. Disable Prevents the adaptor from providing supplementary information when it Supplementary generates a non-delivery report. Info The adaptor provides the reason for the failed delivery (generated by sendmail) in a supplementary information field in the non-delivery report. Some ADMDs (such as ATLAS in France) do not support this field. Enable MIME If this feature is enabled, incoming messages from the X.400 domain are Compliance converted to be MIME-compliant when they are output to Internet mail.
Once you have completed the basic configuration steps described in this section, apply your Solstice X.400 Internet Adaptor configuration by clicking SELECT on the Apply button.
If you modified the default pseudo host name you will see a message warning you that you must modify the sendmail.cf file on your local machine. If you do not authorize x400tool to modify this file, you must edit it manually to change the pseudo host name for your adaptor. See “Modifying sendmail.cf to Add a Pseudo Host Name Manually” on page 119 for more information. If you have a standard sendmail.cf file, then you can usually allow the sendmail.cf file to be changed automatically.
Configuring the Solstice X.400 Internet Adaptor 117 11
Adding the Pseudo Host Name to the NIS Database
The pseudo host name is an alias for the machine on which the adaptor is running. To enter the pseudo host name into the name service (NIS, NIS+, DNS, etc.) database:
1. Edit the /etc/hosts file on your NIS server (or on your local machine if you are not running NIS) and add the pseudo host name for the adaptor. This creates an alias for the machine on which the adaptor is running. Add the pseudo host name to the line where the primary IP address and host name for your local machine is defined:
IP address localhost pseudo hostname
For example, if the host name for your local machine (the machine on which the adaptor is running) is papyrus, and you accepted the default pseudo host name proposed by x400tool (x400-gate), the entry in /etc/hosts would be:
IP address papyrus x400-gate
2. If you are running NIS, you need to build a new NIS database that includes the pseudo host name for the adaptor.
hostname# cd /var/yp hostname# make
3. Verify that the pseudo host name for the adaptor is registered correctly in the Name Service database by using ypmatch(1):
hostname# ypmatch pseudo hostname hosts IP address localhost pseudo hostname
118 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 11
Modifying sendmail.cf to Add a Pseudo Host Name Manually
If you changed the default pseudo host name while configuring the Solstice X.400 Internet Adaptor, you need to register this change in /etc/mail/sendmail.cf on your local machine. If you did not authorize x400tool to make this change, you must edit the file manually.
To modify sendmail.cf:
1. Log in as root, or become superuser, and use a text editor such as vi, to edit the file /etc/mail/sendmail.
2. Search for the text string CXx400-gate and replace the default pseudo host name (the text after CX) with the pseudo host name you assigned for your adaptor.
# local MHS pseudo-hosts: must include the MHS encoded_orname_pseudo_host # (typically x400-gate) and may include the 822 host addresses of local # X.400 systems CXpseudo host name CXx400-gate
3. Save your modifications (overriding the read-only protection) and exit the text editor.
4. Find out the process id (pid) for the sendmail daemon.
hostname# ps -ef | grep sendmail owner pid timestamp /usr/lib/sendmail -bd -q1h
5. Kill the sendmail daemon and then restart it so that it uses the modified configuration file.
hostname# kill -15 pid hostname# /usr/lib/sendmail -bd -q1h
Configuring the Solstice X.400 Internet Adaptor 119 11
120 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Testing and Tuning the Solstice X.400 Internet Adaptor 12
Testing the Solstice X.400 Internet Adaptor page 122 Modifying the Mapping Tables page 126 Replacing a Deleted Solstice X.400 Internet Adaptor page 129 Configuring Routes to the Solstice X.400 Internet Adaptor page 129 Modifying the sendmail Configuration File for the Internet Adaptor page 130
This chapter describes how to use x400tool to test and tune your Solstice X.400 Internet Adaptor. It also describes how to customize the sendmail configuration file (/etc/mail/sendmail.cf) manually so that the sendmail daemon recognizes the Solstice X.400 Internet Adaptor. For more general and detailed information on how to customize sendmail.cf, see your Solaris documentation.
This chapter assumes that you have already set up your adaptor as described in Chapter 11, “Configuring the Solstice X.400 Internet Adaptor”.
121 12
Testing the Solstice X.400 Internet Adaptor
You can test that your adaptor has been correctly configured in two stages: • Check that the address is converted by the adaptor in the way you expected it. Use the Address Conversion function on the Test pull-down menu. • Send an electronic mail message to yourself, via the adaptor.
Checking the Address Conversion
To ensure that the adaptor translates your Internet mail address to an X.400 address in the expected way, or that X.400 addresses are converted to correct Internet addresses, you should check them with the Address Conversion option.
1. Press and drag MENU down the Test menu and release it over the Test Addr Conv item. The Test Address Conversion screen is displayed, as shown in Figure 12-1.
Figure 12-1 Test Address Conversion for the Solstice X.400 Internet Adaptor
122 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 12
2. Press SELECT on X.400 (for an address conversion from X.400 to Internet), or SMTP (for an address conversion from Internet to X.400).
3. Enter the address for which you want to see the result of the adaptor conversion. If you enter an X.400 address, the available components are displayed in the scroll list. Press SELECT to choose each component and then enter its value in the address field.
4. When you have entered the complete address, press SELECT on Test to display the conversion that would be made in the adaptor. Check that the address displayed is correct. Note that the correct address conversion is only possible if you have configured the adaptor. That is, if the address that you try to test is not a real or configured system, then the conversion result will include unknown characters. These characters are defined in RFC987 and RFC1327.
Sending a Test Message
When you are sure that the address is correct and that you have configured the adaptor, you should test that it works by sending a message to yourself, via the adaptor.
Send a message using your own Internet mail address, specifying the adaptor using the pseudo host name that you assigned to it. For example, if you assigned the default pseudo host name proposed by x400tool (x400-gate) then the address would be:
recipient_name@x400-gate
Figure 12-2 on page 124 shows the mailtool compose window that is used to send a mail message to test the Solstice X.400 Internet Adaptor. The local Internet mail address is the login name of the recipient (jsmith) and the Internet mail domain address is the pseudo host name assigned to the adaptor (x400-gate).
Testing and Tuning the Solstice X.400 Internet Adaptor 123 12
Figure 12-2 Internet Mail Message Sent Through the Solstice X.400 Internet Adaptor
Figure 12-3 on page 125 shows the Internet mail message that was received through the Solstice X.400 Internet Adaptor. The full message header shows how the message is routed between systems and how the local Internet mail address is converted into an equivalent X.400 O/R address.
124 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 12
Figure 12-3 Internet Mail Message Received Through the Solstice X.400 Internet Adaptor
Testing and Tuning the Solstice X.400 Internet Adaptor 125 12
Modifying the Mapping Tables
Caution – You should not modify the mapping tables supplied with Solstice X.400 Messaging Server other than under exceptional circumstances. Altering these mapping tables will affect the operation of your Solstice X.400 Internet ! Adaptor.
The Solstice X.400 Internet Adaptor translates SMTP (RFC 822) addresses and message elements to X.400 equivalents. This is done based on the mappings defined in RFC 1327 (superseding RFC 987 and RFC 1148) which provide for transparent conversion between Internet mail and X.400 domains. In particular, the Solstice X.400 Internet Adaptor translates addresses using the standard mapping tables developed by the COSINE MHS project. These tables comply to RFC 1327 and are distributed globally under the auspices of the MHS Coordination Service.
There are three mapping tables: • rfc1148-mapping1: contains standard mappings between X.400 addresses and SMTP (RFC 822) addresses. • rfc1148-mapping2: contains standard mappings between SMTP (RFC 822) addresses and X.400 addresses. • rfc1148-gate: contains mappings for the default Internet Adaptor that must be used if the domain is not defined in rfc1148_mapping2.
Using the Mapping Table Editor
To modify the standard mapping tables supplied with Solstice X.400:
1. Double-click SELECT on the SMTP_X400 icon to activate the X.400/SMTP Configuration window.
2. Click SELECT on the Mapping Tables button to activate the Mapping Table Editor.
3. The Load Translation Table File window is displayed when you open this window. If this window is already open, then drag and release MENU on the File manu button to activate it. Choose one of the mapping tables from the list and click SELECT on Load. Figure 12-4 shows the mapping table editor with a mapping table loaded.
126 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 12
Internet mail domain address
X.400 domain address Figure 12-4 Mapping Table Editor
4. Click SELECT on the Filter button to activate the Filter window. Use these options to limit the search so that the editor displays only a subset of all possible mappings. The filter can be a regular expression.
For example, set the Country filter ON and enter the appropriate country code for the X.400 domain in which you are interested—in the example shown in Figure 12-5 on page 128, FR for France was entered.
Click SELECT on Apply to display the mappings associated with this country.
Testing and Tuning the Solstice X.400 Internet Adaptor 127 12
Filter criterion
Click SELECT to apply the filter
Figure 12-5 Mapping Editor Filter
You can use the mapping table editor to insert new mappings, change existing mappings, or delete entries from the mapping table.
The following options are associated with the Mapping Editor:
Insert: The Insert menu button is used to insert a new mapping into the table at the specified position: • Before: inserts a new mapping immediately before the selected entry. • After: inserts a new mapping immediately after the selected entry. • Top: inserts a new mapping at the top of the table. • Bottom: inserts a new mapping at the bottom of the table.
Delete: Removes the selected entry from the table.
Change: Modifies the selected entry with the new domain information.
Clear: Clears the domain information.
Undo: Reverses the last action taken.
128 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 12
Replacing a Deleted Solstice X.400 Internet Adaptor
There is an unconfigured Solstice X.400 Internet Adaptor in your messaging system by default when you first start x400tool.
You can only have one Solstice X.400 Internet Adaptor in your messaging system at any one time; however, if you delete the default adaptor, you can replace it by adding a new Solstice X.400 Internet Adaptor:
1. Press and drag MENU down and right to display the New Agent submenu.
2. Release MENU over the Internet Adaptor item to add a new (unconfigured) Solstice X.400 Internet Adaptor to your messaging system.
3. Start the process osismtpx400 as described in “Starting and Stopping X.400 Processes” on page 28.
4. Configure the new adaptor as described in Chapter 11, “Configuring the Solstice X.400 Internet Adaptor”.
Configuring Routes to the Solstice X.400 Internet Adaptor
When you add a new Solstice X.400 Internet Adaptor to your messaging system, x400tool attempts to create a default entry in the local routing table. This table is used by the local server to determine the forwarding address for each message it receives. The default route for the Solstice X.400 Internet Adaptor is based on the global domain identifier assigned to the local MTA.
If x400tool cannot create a default route (because, for example, an identical route already exists in the routing table) you will have to modify the routing table to add an entry that improves the granularity of the routing mechanism.
For example, if you already have a remote MTA defined with the same global domain identifier, the local MTA will not create a default route for the Solstice X.400 Internet Adaptor. You must create a new entry in the routing table and add some discriminating attribute (organization name, organizational unit name, etc.) to the route so that your local MTA can forward messages correctly to both systems.
Refer to Chapter 10, “Routing Between Messaging Components” for detailed instructions on how to modify default routing entries.
Testing and Tuning the Solstice X.400 Internet Adaptor 129 12
Modifying the sendmail Configuration File for the Internet Adaptor
Under most circumstances, sendmail.cf must be modified in order to send mail to X.400 recipients using Internet-style addresses of the form:
recipient_name@domain_name
When you install the Solstice X.400 Messaging Server software, the sendmail.cf file is modified automatically using the script gen_sendmail.cf. You can also run this script manually; for example, when you change your sendmail.cf file and want to reapply the X.400-specific rules, or to apply the X.400-specific rules to a subsidiary sendmail configuration file.
Using the gen_sendmail.cf Script
To run the gen_sendmail.cf script, type:
hostname# /opt/SUNWconn/bin/gen_sendmail.cf
The script uses the following parameters as default: • PSEUDOHOST (default pseudo host name): x400-gate • S2XMAIL (full path to mailer): /opt/SUNWconn/bin/osix400mail
The script first adds the default pseudo host name for the Solstice X.400 Internet Adaptor. It then adds X.400-specific definitions to the start rules. The script ends by ensuring that all the other lines of sendmail.cf are left untouched by the modifications.
130 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 12
Modifying sendmail.cf Manually
If you have a customized version of the sendmail.cf file, the automatic modification at installation may fail. You can still make the required changes to sendmail.cf manually:
On the machine on which the Solstice X.400 Internet Adaptor is running:
1. Create the file /var/SUNWconn/OSIROOT/mhs/conf/x400domains with the following entries:
pseudo_hostname domain_name
2. In sendmail.cf, replace the entry CXpseudo_hostname with the name of this file:
# local MHS pseudo-hosts: must include the MHS encoded_orname_pseudo_host # (typically x400-gate) and may include the 822 host addresses of local # X.400 systems CX
On your mail host (provided this is not the machine on which the adaptor is running):
1. Create the file /etc/mail/x400domains with the following entries:
pseudo_hostname domain_name
2. Edit sendmail.cf to add the following entries:
FX/etc/mail/x400domains DYpseudo_hostname
Testing and Tuning the Solstice X.400 Internet Adaptor 131 12
3. Edit sendmail.cf to add the following lines after the start rule S0:
R$*<@$*$=X.LOCAL>$* $#$M $@$Y $:$1<@$2.$3>[email protected] R$*<@$+.$=X.$+>$* $#$M $@$Y $:$1<@$2.$3.$4>$5user@mhs-host R$*<@$=X.$+>$* $#$M $@$Y $:$1<@$2.$3>$4user@mhs-host R$*<@$+.$=X>$* $#$M $@$Y $:$1<@$2.$3>$4user@mhs-host R$*<@$=X>$* $#$M $@$Y $:$1<@$2>$3user@mhs-host
4. Edit the mapping tables used by the Solstice X.400 Internet Adaptor to map X.400 and Internet mail addresses. See “Modifying the Mapping Tables” on page 126 for detailed instructions. • In the mapping table rfc11848-mapping1, add an entry to map from the UNIX domain to the X.400 domain.
domain_name x400_address
• In the mapping table rfc11848-mapping2, add an entry to map from the X.400 domain to the UNIX domain.
x400_address domain_name
132 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Sending and Receiving Internet Mail Through the Internet Adaptor 13
Sending Messages Using Internet Mail Applications page 133 Mapping X.400 and Internet Addresses page 138
This chapter describes how to use Internet mail applications (such as mail(1) and mailtool) running in Solaris environments to send and receive messages through the Solstice X.400 Internet Adaptor. It assumes that you have already set up your messaging system, including your local MTA and Solstice X.400 Internet Adaptor.
For detailed information on setting up a mail service entirely within the Internet domain, see your Solaris documentation.
Sending Messages Using Internet Mail Applications
Internet mail applications rely on the sendmail(8) daemon to route messages between users. After the sendmail daemon has been reconfigured (by modifying sendmail.cf), you can use, for example, mail, mailx, or mailtool to exchange mail messages directly with the X.400 domain through the Solstice X.400 Internet Adaptor.
Note – You cannot use an X.500 directory name for the address of the recipient when sending messages through the Internet Adaptor.
133 13
Addressing Messages Through the Solstice X.400 Internet Adaptor
To address mail to a recipient through the Solstice X.400 Internet Adaptor, you need to specify the local address of the recipient and the domain address of the adaptor. The complete domain address for the Solstice X.400 Internet Adaptor comprises the pseudo host name (alias) assigned to the adaptor, and the domain address of the Internet mail domain in which the adaptor is located. You can express the recipient’s local address as an Internet mail alias or as a full X.400-style address.
For example, to use mail(1) or mailx(1) to send a message to a recipient Roger Blake whose local mail alias is rblake through a Solstice X.400 Internet Adaptor with a pseudo host name x400-gate, located in the domain Division.Company.COM:
host% mail [email protected] Subject:test This is a test message.
To use mail or mailx to send a message to the same recipient by specifying the full X.400 O/R address:
host% mail /S=rblake/O=XYZ/A=BT/C=UK/@x400-gate.Division.Company.COM Subject:test This is a test message.
When addressing messages through an adaptor located within the same Internet mail domain, you do not need to specify the full domain name for the Solstice X.400 Internet Adaptor. For example:
host% mail /S=rblake/O=XYZ/A=BT/C=UK/@x400-gate Subject:test This is a test message.
Note that you can check the way that the adaptor converts the Internet address into an X.400 address using the Address Conversion feature. See “Testing the Solstice X.400 Internet Adaptor” on page 122.
134 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 13
Using X.400 Mail Header Fields in mailtool
X.400 mail header fields are used to carry additional information and to modify the behavior of the mail delivery system on a per-message basis—for example, to mark the message for urgent delivery. See “Supported Mail Header Fields” on page 19 for more information.
You set the X.400 header fields that you can use from within mailtool by defining custom header fields. To define a custom header field:
1. Press and drag MENU on the Edit pull-down menu.
2. Release MENU on the Properties... item to activate the Properties window.
3. Press and drag MENU on the Category pull-down menu. Release MENU on the Compose Window item.
4. Type in the name of the header field on the Header Field input line. Type in your preferred default value, if applicable. Refer to Table 1-3 on page 19 for details.
5. Click SELECT on the Add button to place the customized header in the scrolling-list.
6. Click SELECT on the Apply button to apply your changes and add the custom headers to the compose window.
Figure 13-1 Defining a Custom Mail Header
Sending and Receiving Internet Mail Through the Internet Adaptor 135 13
To add a customized header to a message from within mailtool:
1. Press and drag MENU on the Header pull-down menu.
2. Release MENU on the custom header that you want to add.
Figure 13-2 Adding a Custom Header
Sending Messages Containing International Character Sets
The Solstice X.400 Internet Adaptor supports the translation of the international character sets supported by the Sun Internet mail applications.
When a message that includes international characters is set entirely within the Internet mail domain, the service element X-Sun-Charset is set automatically to ISO-8859-1. Figure 13-3 on page 137 shows the full header of a message containing international characters and sent to a recipient in the UNIX mail domain.
When the message is received by the Solstice X.400 Internet Adaptor, the X- Sun-Charset service element is translated into the X.400 service element Original-Encoded-Information-Types and set to ISO-6937-Text. ISO- 6937 provides full IA5 (ASCII), Teletext (T.61 a subset of ASCII), plus international (8 bit) characters. Figure 13-4 on page 137 shows the same message sent through the adaptor.
136 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 13
Figure 13-3 International Characters in the Internet Mail Domain
Figure 13-4 International Characters Through the Solstice X.400 Internet Adaptor
Sending and Receiving Internet Mail Through the Internet Adaptor 137 13
Mapping X.400 and Internet Addresses
Some Internet mail addresses contain ASCII characters that are not directly mapped to X.400 address elements. Abbreviations are used to represent characters such as “@”, “%”, and “!”, which appear commonly in Internet mail addresses. Table 13-1 lists these special abbreviations:
Table 13-1 X.400 Abbreviations
X.400 Abbreviation ASCII Character (a) @ at character (p) % percentage (b) ! exclamation (bang) (q) “ double-quotes (u) _ underscore (l) ( left parenthesis (bracket) (r) ) right parenthesis (bracket)
For example, to map an Internet mail address of the form [email protected], the country, ADMD, and PRMD point to the Solstice X.400 Internet Adaptor that accesses the X.400 mail domain. The Internet mail address can be specified by using the domain-defined identifier DD.RFC-822, as shown below:
/C=US/A=MCI/P=XYZ/DD.RFC-822=avon(b)kerr(a)Division.Company.COM/
138 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Part 4 — Managing Your Messaging System
This part contains the following chapters: • Chapter 14, “Managing Your Messaging System with x400tool,” describes how to use x400tool to maintain your messaging system and to gather information about the current status of its component parts. • Chapter 15, “Managing Your Messaging System with Command-Line Tools,” describes how to use the command-line recovery, tracing, and statistics tools.
Managing Your Messaging System withx400tool 14
Displaying OSI Addressing Information page 142 Displaying Status Information page 143 Stopping and Starting Statistics Collection page 154 Opening and Closing Agents page 154 Purging the Message Queues page 156 Purging a Message Store page 159 Backing Up and Restoring Message Stores page 160
This chapter describes how to use x400tool to maintain your messaging system and to gather information about the current state of its components.
The chapter assumes that you have already set up your messaging system, including your local MTA, message store and Solstice X.400 Internet Adaptor.
141 14
Displaying OSI Addressing Information
System adminstrators who want to add your MTA or message store to their messaging systems need information about the OSI addresses of your local components. The Local Server Configuration window displays the OSI addresses and protocols by which your server can be reached. This information is based on the running OSI stack configuration, unless the RFC1006 driver is installed.
To display address and protocol information of your local MTA and message store, follow these steps:
1. Double-click SELECT on the local server icon to activate the Local Server Configuration window.
2. Press and drag MENU on the Protocol pull-down menu, and release MENU to select a protocol. There are three protocols that can be used to reach your local server:
• P1 displays the P1 address of your MTA. This information is needed by remote system administrators who are configuring an MTA and want to add your MTA to their messaging system. • P3 server displays the P3 address of your MTA. This information is needed by remote system administrators who are configuring a message store and want to add your MTA to their messaging system. • P3 client/P7 displays the P3 address of your message store. This information is needed by remote system administrators who are configuring an MTA or a message store and want to add your message store to their messaging system.
3. Press and drag MENU on the Access pull-down menu, and release MENU to select a network interface. The address for your local server depends on how your machine is physically connected to the network. It can be attached to the X.400 domain through one of four network interfaces:
• X.25, for X.25 1980. Note that the address is an X.121 network address • TCP/IP (RFC 1006). If you are using the RFC1006 driver, this is the only available network interface • LLC1 (LAN)—for example, Ethernet • CONS, for X.25 1984. Note that the address is an NSAP address.
142 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 14
Displaying Status Information
There is a status window associated with each component of your messaging system. These windows display the status of the component, current at the time that the window was last refreshed. Status windows can be refreshed automatically at specific intervals or refreshed manually. The behavior of the status windows is determined by setting the x400tool properties.
Changing the Tool Properties
The tool Properties affect the way in which x400tool status windows are refreshed. The Properties window in shown in Figure 14-1.
1. Click SELECT on the Properties... button to activate the Tool Properties window.
2. Click SELECT on either Automatic or Manual to set the refresh mechanism for the x400tool status windows. • If you choose Automatic, the status windows are refreshed automatically at intervals specified by the value Interval. Click SELECT on the slider to set a value for the interval, or type a value and press Return. • If you choose Manual, you must use the “Refresh” button on each status window to update the display every time you want to see the most recent information.
3. Click SELECT on Apply, Reset, or Default. The default value is 20 seconds.
Click SELECT
Drag SELECT on the slider
Figure 14-1 x400tool: Changing the Tool Properties
Managing Your Messaging System with x400tool 143 14
Activating a Status Window
To display the status window for a component in your messaging system:
1. Click SELECT on its icon.
2. Press MENU on the Manage menu button and drag the pointer to the Status item. Release MENU to activate the associated status window.
Note – You can only view status information if statistics collection is switched on. (Statistics collection is on by default). See “Stopping and Starting Statistics Collection” on page 154.
Refreshing a Status Window Manually
If you have selected manual refresh for the x400tool status windows (see “Changing the Tool Properties” on page 143) or if you want to see the most recent status for one of the messaging components, you can use the refresh button on the status window to update the information displayed.
1. Activate the Status window for one of the agents.
2. Click SELECT on the refresh button to update the information.
Printing the Current Status
To print a summary of all the status information associated with a given component in the messaging system:
1. Activate the Status window for one of the agents.
2. Click SELECT on Print to activate the Print Selection subwindow.
3. Either choose the name of a printer from the pull-down menu, or specify the name of a file.
4. Click SELECT on Print to print the status information.
144 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 14
Displaying the Status of the Local MTA
The local MTA status window displays the information about the flow of messages throughout the messaging system, as seen from the local MTA.
Use the local MTA status window to examine: • The current state of the queues for incoming messages (messages received by the local MTA) and outgoing messages (messages sent by the local MTA) at the time the window was last refreshed. The information is displayed as the total number of messages of each type (urgent, normal, non-urgent, and notifications) and the volume of data (in bytes) held in each queue. • A summary of the total traffic flow (messages sent and received) through the local MTA since it was last restarted, and the total number of associations open at the time the window was last refreshed.
Number of current The total number of associations open between the associations local MTA and other components in the messaging system at the time the window was last refreshed. Total number of messages The total number of messages sent by the local sent by local MTA MTA to other components in the messaging system. Total number of messages The total number of messages received by the local received by local MTA MTA from other agents (MTAs, adaptors, or user agents) in the messaging system.
• A summary of the total failed transfers and errors occurring since the local MTA was last restarted.
Authentication failures The number of times that the local MTA has rejected sent an association indication from a remote MTA because the OSI address or password presented was incorrect. Authentication failures The number of times that a remote MTA has received rejected an association request from the local MTA because the OSI address or password presented was incorrect. RTS busy indications sent The number of RTS (reliable transfer system) busy indications sent by the local MTA to remote MTAs.
Managing Your Messaging System with x400tool 145 14
RTS busy indications The number of RTS (reliable transfer system) busy received indications received by the local MTA from remote MTAs. Abnormal transfers when The number of abnormal transfers that occurred sending when the local MTA was sending outgoing messages. Abnormal transfers when The number of abnormal transfers that occurred receiving when the local MTA was receiving incoming messages. Unacceptable dialog mode The number of times that a connection was refused received with the reason “unacceptable dialog mode”. For example, a two-way connection was attempted with a remote MTA that is configured for monologue only.
Displaying the Status of a Remote MTA
The remote MTA status window displays information about the performance of the association between the local MTA and a given remote MTA, as seen from the local MTA.
Use the remote MTA status window to examine: • The current state of the queues for outgoing messages—that is, messages sent from the local MTA to the remote MTA—at the time the window was last refreshed. The information is displayed as the total number of messages of each type (urgent, normal, non-urgent, and notifications) and the volume of data (in bytes) in each queue. • A summary of the traffic flow (messages sent and received) between the local MTA and the remote MTA since the local MTA was last restarted, and the total number of associations open at the time the window was last refreshed.
Number of current The total number of associations open between associations the local MTA and the remote MTA at the time the window was last refreshed. Total number of messages The total number of messages sent by the local sent by local MTA MTA to the remote MTA.
146 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 14
Total number of messages The total number of messages received by the received by local MTA local MTA from the remote MTA. Total number of bytes sent The total number of bytes sent by the local MTA by local MTA to the remote MTA. Total number of bytes The total number of bytes received by the local received by the local MTA MTA from the remote MTA.
• The current state of the remote MTA at the time the window was last refreshed, and a summary of the of the connection negotiation between the local MTA and the remote MTA since the time that the local MTA was last restarted.
Current state The current state of the remote MTA (open or closed) and the current state of the association (if the remote MTA is open). Connection requests sent The number of times that the local MTA has issued a connection request to the remote MTA. Connection responses The number of times the remote MTA has received responded to a connection request from the local MTA. Connection indications The number of times that the local MTA has received received a connection indication from a remote MTA requesting an association. Connection confirmation The number of times that the local MTA has sent a sent connection confirmation in response to a connection request from the remote MTA.
• A summary of the failed transfers and errors associated with the selected remote MTA since the local MTA was last restarted.
Authentication failures sent The number of times that the local MTA has rejected an association indication from the selected remote MTA because the OSI address or password presented was incorrect. Authentication failures The number of times that the selected remote received MTA has rejected an association request from the local MTA because the OSI address or password presented was incorrect.
Managing Your Messaging System with x400tool 147 14
RTS busy indications sent The number of RTS (reliable transfer system) busy indications sent by the local MTA to the selected remote MTA. RTS busy indications The number of RTS (reliable transfer system) busy received indications received by the local MTA from the selected remote MTA. Abnormal transfers when The number of abnormal transfers that occurred sending when the local MTA was sending outgoing messages to the selected remote MTA. Abnormal transfers when The number of abnormal transfers that occurred receiving when the local MTA was receiving incoming messages from the selected remote MTA. Connection abort sent The number of times that the local MTA has generated a connection abort to request the breaking of a connection. Connection abort indication The number of times that the local MTA has received received a connection abort request from the selected remote MTA. Unacceptable dialog mode The number of times that a connection was received refused with the reason “unacceptable dialog mode”. For example, a two-way connection was attempted with a remote MTA that is configured for monologue only.
148 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 14
Displaying the Status of a Message Store User Group
The Message Store status window, as shown in Figure 14-2 on page 150, displays information about the users in a message store user group, and about the messages stored in a user’s information base.
The Users scrolling-list displays the following information for each user: • User name • The connection state (connected or not connected) • The total number of messages and reports stored • The total size of the user’s information base
The title bar displays the total number of idle, local, and remote users.
To display information about the messages stored in a user’s information base:
1. Click SELECT on a user name in the Users scrolling list.
2. Click SELECT on Show User Messages. The User Information Base scrolling-list is updated to display information about the first fifty messages in that user’s information base.
For each message, the following is displayed: • Message type (Message or Report) • Message status (New, Listed, or Fetched) • The creation date and time of the message • Message subject • The O/R address of the message originator
3. Click SELECT on Next Range to display the next fifty messages. The status bar displays the range of messages currently displayed.
For information on how to purge messages in a user’s information base, see “Purging a Message Store” on page 159.
Managing Your Messaging System with x400tool 149 14
Figure 14-2 MS Group Status Window
150 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 14
Displaying the Status of the Solstice X.400 Internet Adaptor
The Solstice X.400 Internet Adaptor status window displays information about the performance of the association between the local MTA and the Solstice X.400 Internet Adaptor (or other P1 agent).
Use the Solstice X.400 Internet Adaptor status window to examine: • The current state of the queues for outgoing messages; that is, messages sent from the local MTA to the adaptor (or P1 agent). The information is displayed as the total number of messages of each type (urgent, normal, non-urgent, and notifications) and the volume of data (in bytes) in each queue. • A summary of the traffic flow (messages sent and received) between the local MTA and the adaptor since the local MTA was last restarted, and the total number of associations open.
Number of current The total number of associations open between associations the local MTA and the adaptor (or P1 agent). Total number of messages The total number of messages sent by the local sent by local MTA MTA to the adaptor (or P1 agent). Total number of messages The total number of messages received by the received by local MTA local MTA from the adaptor (or P1 agent). Total number of bytes sent The total number of bytes sent by the local MTA by the local MTA to the adaptor. Total number of bytes Total number of bytes received by the local MTA received by the local MTA from the adaptor.
• The current state of the adaptor (or P1 agent), and a summary of the of the connection negotiation exchanged between the local MTA and the adaptor since the time that the local MTA was last restarted or the statistics collection was started.
Current state The current state of the adaptor (open or closed) and the current state of the association (if the adaptor is open). Connection requests sent The number of times that the local MTA has issued a connection request to the adaptor.
Managing Your Messaging System with x400tool 151 14
Connection responses The number of times the adaptor has responded received to a connection request from the local MTA. Connection indications The number of times that the local MTA has received received a connection indication from a adaptor requesting an association. Connection confirmations The number of times that the local MTA has sent a sent connection confirmation in response to a connection indication from the adaptor.
• A summary of the failed transfers and errors associated with the selected remote MTA since the local MTA was last restarted.
Authentication failures sent The number of times that the local MTA has rejected an association indication from the adaptor because the OSI address or password presented was incorrect. Authentication failures The number of times that the adaptor has rejected received an association request from the local MTA due to an incorrect address or password. RTS busy indications sent The number of RTS (reliable transfer system) busy indications sent by the local MTA to the adaptor. RTS busy indications The number of RTS busy indications received by received the local MTA from the adaptor. Abnormal transfers when The number of abnormal transfers that occurred sending when the local MTA was sending outgoing messages to the adaptor. Abnormal transfers when The number of abnormal transfers that occurred receiving when the local MTA was receiving incoming messages from the adaptor. Connection abort sent The number of times that the local MTA has generated a connection abort to request the breaking of a connection with the adaptor. Connection abort indication The number of times that the local MTA has received received a connection abort request from the adaptor. Unacceptable dialog mode The number of times an error occurred when the received local MTA was negotiating the handshaking applied to the exchange of messages.
152 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 14
Displaying the Status of a User Agent
The user agent status window displays information about the performance of the connection between the local MTA and a User Agent.
Use the User Agent status window to examine: • The current state of the queues for outgoing messages; that is, messages sent from the local MTA to the user agent. The information is displayed as the total number of messages of each type (urgent, normal, non-urgent, and notifications) and the volume of data (in bytes) in each queue. • A summary of the traffic flow (messages sent and delivered) between the local MTA and the selected user agent since the local MTA was last restarted expressed in terms of the number of messages and the total number of bytes of data.
Messages Submitted The number of messages sent from the UA to the local MTA. Messages Delivered The number of messages sent from the local MTA to the UA. Bytes Submitted The number of bytes sent from the UA to the local MTA. Bytes Delivered The number of bytes sent from the local MTA to the user agent.
• The current state of the user agent, and a summary of the connection negotiation exchanged between the local MTA and the user agent since the time that the local MTA was last restarted.
Current state The current state of the UA (open or closed) and the current state of the association (if the UA is open). Connection requests sent The number of times that the local MTA has issued a connection request to the UA. Connection responses The number of times the UA has responded to a received connection request from the local MTA. Connection indication The number of times that the local MTA has received received a connection indication from the UA requesting a connection.
Managing Your Messaging System with x400tool 153 14
Connection confirmations The number of times that the local MTA has sent a sent connection confirmation in response to a connection indication from the UA. Notification indications The number of times that the local MTA has received received a notification indication from the UA.
Stopping and Starting Statistics Collection
The information displayed in the x400tool status windows is based on data recovered from the messaging system. You can improve the performance of your local server by switching this feature off.
To stop collecting statistics from your messaging system:
♦ Press MENU on the Manage menu button and drag the pointer to the Stop Collecting item. Release MENU to stop collecting statistics.
You can only view status information if you have started statistics collection. To restart collecting statistics from your messaging system:
♦ Press MENU on the Manage menu button and drag the pointer to the Start Collecting item. Release MENU to start collecting statistics.
Opening and Closing Agents
Closing an agent breaks its association with the local MTA, but does not remove the agent from the messaging system. It will not be recognized by the local MTA or by any other agent. You cannot close your local server.
While an agent is closed, it will neither accept nor forward messages. Incoming message transfers in progress when an agent is closed are aborted and a non-delivery message is generated.
154 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 14
Opening a Closed Agent
An agent can be closed either automatically or manually. To reopen an agent after it has been closed:
1. Click SELECT on an agent that is showing “Closed” in its icon.
2. Press MENU on the Manage menu button and drag the pointer to the Open Agent item. Release MENU to reopen the closed agent.
Symbol indicating that the agent is closed temporarily
Figure 14-3 Closed Message Transfer Agent Icon
Closing an Open Agent
An agent can be closed either automatically or manually. It might be closed automatically if it does not respond to the local MTA after a specified time, and there are no pending messages. To close an agent manually:
1. Click SELECT on an open agent.
2. Press MENU on the Manage menu button and drag the pointer to the Close Agent item. Release MENU to close the open agent.
A blank space indicates that the agent is open
Figure 14-4 Open Message Transfer Agent Icon
Managing Your Messaging System with x400tool 155 14
Purging the Message Queues
Purging message queues removes either one or all the messages that are currently waiting to be delivered. This is a risky undertaking because there is no way to determine the content of the messages in the queue and there is the chance that you will destroy valuable correspondence. However, under exceptional circumstances, this feature can be used to unblock your messaging system if there is a severe problem with one or more messages in the queue.
For example, if your local server tries to send an unusually large message to a remote MTA that is unable to cope with it, the message may block the queue and trap a number of smaller messages behind it. In this case, you should purge the first message in the queue to resolve the problem. You will lose the contents of the first message, but the other messages will be delivered correctly.
Caution – Do not delete the files associated with the mail queues (or any other files associated with the Solstice X.400 Messaging Server). Always use the ! purge option if you need to clear the message queues.
Purging the First Message in the Queue
The local MTA holds the outgoing messages waiting to be sent to a given agent (remote MTA, Solstice X.400 Internet Adaptor, P1 agent, or user agent) in a separate queue. You can purge the first message in the queue without affecting the other messages in it.
To purge the first message in the queue:
1. Click SELECT on the icon for a remote MTA, Solstice X.400 Internet Adaptor, P1 agent, or user agent.
2. Press MENU on the Manage menu button and drag the pointer to the Purge Queues item. Release MENU to activate the Purge Messages window for the local MTA.
3. Click SELECT on the First Message button to specify the first message only.
4. Click SELECT on the Purge button to remove all the messages waiting in outgoing queue for the selected agent.
156 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 14
Click SELECT to specify the first message only
Click SELECT to purge the specified queues
Figure 14-5 Purging Messages in a Queue
Purging Messages for a Specific Agent
If purging the first message in the queue does not unblock your messaging system, you can purge all the messages queued for one agent without affecting the queues for the other agents in the messaging system.
To purge the queue containing outgoing messages for a specific agent:
1. Open the Purge Messages window, as described in “Purging the First Message in the Queue” on page 156.
2. Click SELECT on the All Messages button to specify the queues affected by the purge.
3. Click SELECT on the Purge button to remove all the messages waiting in outgoing queue for the selected agent.
Managing Your Messaging System with x400tool 157 14
Purging All Incoming Messages
Incoming messages are messages sent by the other agents in your messaging system to the local MTA. To purge all the queues containing incoming messages:
1. Click SELECT on the icon for the local MTA.
2. Press MENU on the Manage menu button and drag the pointer to the Purge Queues item. Release MENU to activate the Purge Messages window for the local MTA.
3. Click SELECT on the check box for All Incoming Messages to specify the queue affected by the purge.
4. Click SELECT on the Purge button to remove all the messages waiting in incoming queues.
Click SELECT to specify the queue affected
Click SELECT to purge the specified queue
Figure 14-6 Purging Incoming Messages
Purging All Outgoing Messages
Outgoing messages are messages sent by the local MTA to the other agents in your messaging system. To purge all the queues containing outgoing messages:
1. Open the Purge Messages window as described in “Purging All Incoming Messages.”
2. Click SELECT on the check box for All Outgoing Messages to specify the queue affected by the purge.
3. Click SELECT on the Purge button to remove all the messages waiting in outgoing queues.
158 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 14
Purging a Message Store
When you purge a message store, you remove either one or all the messages that are stored in a user’s information base. This feature can be used to free up disk space.
To purge messages in a message store user’s information base:
1. Click SELECT on the icon for the MS user group containing the MS user whose messages you want to purge.
2. Press MENU on the Manage menu button and drag the pointer to the Status item. Release MENU to activate the MS Group Status window, as shown in Figure 14-2 on page 150.
3. Click SELECT on a user name in the Users scrolling list.
4. Click SELECT on Show User Messages. The User Information Base scrolling-list is updated to display information about the first fifty messages in that user’s information base.
5. Click SELECT on the message(s) you want to purge, then click SELECT on Purge Selection. If the message(s) you want to purge is not displayed, click SELECT on Next Range to display the next fifty messages.
Note – You cannot purge user messages when the user is connected. Check the connection state of the user in the Users scrolling-list.
6. To purge the entire information base, click SELECT on Purge Mailbox.
Managing Your Messaging System with x400tool 159 14
Backing Up and Restoring Message Stores
With x400tool, you can back up some or all of the messages and delivery reports contained in your message store. This lets you keep an archive of messages, which you can restore (using x400tool) if necessary.
You can customize a backup of your message store to define: • Whose messages are backed up. You can back up messages for all message store users, users defined in a particular message store user group, or for individual users. • Whether you back up only messages, only delivery report, or both messages and delivery reports. • The time and date range of messages to be backed up. For example, you can back up only messages created since a particular date.
Note – To back up or restore a message store configuration, see Backing Up Your Configuration and “Restoring an Existing Configuration” on page 29.
Backing Up User Messages and Delivery Reports
1. If you are backing up individual users or a particular MS user group, click SELECT on the icon for that MS user group.
2. Press MENU on the Manage menu button and drag the pointer down and right to display the MS Mailbox Backup submenu. Release MENU over either All MS Users (to backup every user) or MS Users Group (to backup a group or individual users) to activate a file selection window.
3. Choose a directory where you want the data to be saved and enter a name for your backup file. Click SELECT on Select. The MS Users Mailbox Backup window is displayed, as shown in Figure 14-7 on page 161.
160 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 14
Figure 14-7 MS Users Mailbox Backup Window
4. If you are backing up specific users, click SELECT on the user names in the Group Users scrolling-list. By default, messages and reports for all users in a group are backed up.
5. Optionally, type your name or a description of the backup on the Backup Author input line. You can use what you type here to help you identify a backup file when you come to restore.
6. Click the checkboxes for Delivered Message and Delivered Report as necessary, to determine the type of message store entry to backup. By default, both messages and delivery reports are backed up.
7. If you want to backup data created within a particular time and date range, click SELECT to turn on Entry Creation Limits. The input lines for Start Creation and Stop Creation are enabled. Type the date and time to set the backup range.
8. Click SELECT on Backup to save the data.
Managing Your Messaging System with x400tool 161 14
Restoring User Messages and Delivery Reports
1. Press MENU on the Manage menu button and drag the pointer down and right to display the MS Mailbox Restore submenu. Release MENU over either All MS Users (to restore every user) or MS Users Group (to restore a group or individual users) to activate a file selection window.
2. Choose a directory and select a backup file, then click SELECT on Select. When you click Select, the MS Users Mailbox Restore window is displayed, similar to the backup window shown in Figure 14-7.
3. If you are restoring specific users, click SELECT on the user names in the Group Users scrolling-list. Only users that were backed up in the file you are restoring from are displayed.
4. Click SELECT on Delivered Message and Delivered Report as necessary, to determine the type of message store entry to restore. By default, whatever type of message store entry was backed up is selected.
5. If you want to restore data created within a particular time and date range, click SELECT to turn on Entry Creation Limits. The input lines for Start Creation and Stop Creation are enabled, showing the time and date range of the contents of the backup file. Type the date and time to set the restore range.
6. Click SELECT on Restore to restore the data.
162 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Managing Your Messaging System with Command-Line Tools 15
Journal Files page 163 Regenerating the Configuration from Text page 164 Using the MTA Database Tools page 166 Using x400trace page 167 Using x400decode page 170
This chapter describes how to use the command-line troubleshooting tools supplied with the Solstice X.400 Messaging Server.
The chapter assumes that you have already set up your messaging system, including your local server and (if applicable) the Solstice X.400 Internet Adaptor.
Journal Files
Journal files are automatically used to record messaging activity. These files are found in the directory /var/opt/SUNWconn/OSIROOT/spool. There are two files, journal1 and journal2. Each file holds up to 500 entries. Once one file is full, the Solstice X.400 Messaging Server switches to the other, alternating between the two every 500 entries. In this way a maximum of 1000 entries are recorded at any time.
163 15
An example journal file is shown below:
**------** 95/08/12 13:29:02 ==>[0] Solstice X.400 9.0 started 95/08/12 13:29:16 ==>[6] Connection indication from MTA SMTP_X400. 95/08/12 13:29:16 ==>[7] Connection response to MTA SMTP_X400. 95/08/15 09:02:37 ==>[2] Connection request to MTA MTA_paris. 95/08/15 09:02:37 ==>[9] Abort indication from MTA MTA_paris. 95/08/15 09:02:39 ==>[2] Connection request to MTA MTA_paris. 95/08/15 09:05:44 ==>[3] Connection confirm from MTA MTA_paris. 95/08/15 09:03:22 ==>[1] Solstice X.400 9.0 stopped
Note – P1 agents (SMTP_X400) are seen as MTAs in the journal file.
Regenerating the Configuration from Text
The file prefix.mhscf.text is created when you backup your MTA and message store configuration and each time you change your current configuration. It is a textual representations of the current configuration and is used by the software to build the configuration for each component of X.400. You can use this file to transfer the configuration to another machine without copying all the related configuration files or to regenerate a lost configuration.
The command-line utility x400_genconf regenerates the configuration from the text file. You can also use the Restore Config. option in x400tool (See “Restoring an Existing Configuration” on page 29).
Caution – Regenerating a configuration will overwrite the messages stored in a message store user mailbox. Before you restore a configuration, backup your ! message store as described in “Backing Up and Restoring Message Stores” on page 160.
To use x400_genconf to regenerate the configuration from the text file:
1. Stop the X.400 processes, as described in “Starting and Stopping X.400 Processes” on page 28.
2. Exit from x400tool. Press MENU in the title bar at the top of the tool and drag the pointer down and release it on Quit.
164 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 15
3. Make sure that you are logged in as root, or superuser.
4. Change to the directory where the text file is located. By default, this is /var/opt/SUNWconn/OSIROOT/mhs/conf:
hostname# cd /var/opt/SUNWconn/OSIROOT/mhs/conf
5. Regenerate the configuration using x400_genconf: hostname# /opt/SUNWconn/sbin/x400_genconf [mta] [ms] prefix.mhscf.text
where mta is used to regenerate only the MTA configuration, ms is used to regenerate only the message store configuration. By default, both the MTA and message store configurations are regenerated.
You might have to respond to some questions depending on your configuration, for example, to confirm that the configuration files can be overwritten.
6. When the configuration has been re-generated, restart the X.400 processes. See “Starting and Stopping X.400 Processes” on page 28.
7. Restart x400tool and restore your message store, if necessary.
If you copied this configuration from another system, you will have to update some of the addressing information.
Managing Your Messaging System with Command-Line Tools 165 15
Using the MTA Database Tools
Each Solstice X.400 MTA has several spool files, collectively known as the MTA database. The database contains a record of all transactions that occur in your messaging system.
The Solstice X.400 Messaging Server includes a script, x400dbrecover, that you can use to recover the MTA database. You might do this, for example, when there has been a power failure and you cannot restart your MTA.
To start x400dbrecover:
hostname# /opt/SUNWconn/sbin/x400dbrecover
The x400dbrecover script does the following:
1. Stops the X.400 processes.
2. Uses x400dbsave(1M) to backup the MTA database in a temporary directory.
3. Regenerates the configuration using x400_genconf(1M).
4. Restores the backup MTA database using x400dbload(1M).
5. Restarts the X.400 processes.
6. Removes the backup MTA database from the temporary directory.
For more information on the x400dbsave, x400dbload, and the x400dblist(1M) MTA database tools, see their online manpages.
166 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 15
Using x400trace
The Solstice X.400 Messaging Server tracing facility (x400trace) is used to return dynamic information recovered from the local MTA and message store.
To start x400trace:
hostname# /opt/SUNWconn/sbin/x400trace [-dfr] [-p
The command-line options are:
-d: Returns a full trace of ROSE and Association Control Service Elements (ACSEs).
-f: Returns a full buffer trace. Without this option, only the first twenty lines of a message bodypart is displayed.
-r: Suppresses the names of PDU service elements from the trace. This option is valid only when you specify the pdu filter.
Valid protocols are shown in Table 15-1. If you do not specify a -p option, then all protocols are traced.
Table 15-1 x400trace Protocols
Protocol Description p1 Traces P1 agents. p3 Traces communication between a UA or a message store and an MTA. p7 Traces communication between a UA and a message store.
Valid OSI processes are shown in Table 15-2.
Table 15-2 x400trace OSI Processes
Process Description osixapia Traces the ROSE component of the osixapia daemon. osimta Traces the local MTA.
Managing Your Messaging System with Command-Line Tools 167 15
Table 15-2 x400trace OSI Processes
Process Description osix400ms Traces the local message store. osismtpx400 Traces the local Internet mail adaptor. osix400mqa Traces the local message queue.
Valid filters are shown in Table 15-3.
Table 15-3 x400trace Filters
Filters Description debug Recovers a full trace of the remote operation service element (ROSE) and ACSE presentation. The -d command-line option has the same effect as this filter. events Returns status and error messages recovered from the local MTA, Solstice X.400 Internet Adaptor, and message store. pdu Returns ASN.1 decoding of incoming and outgoing messages. xom Returns XOM objects sent and received by the Solstice X.400 Internet Adaptor. rts Returns a trace from the reliable transfer service (RTS).
Trace Examples
This section provides some examples of using x400trace.
To display information on activity occuring in the messaging system:
hostname# x400trace events x400trace: Initialization in progress Tracing osimta osismtpx400 osix400mqa osix400ms x400trace: Initialization completed osix400ms 16:23:21[9973] MS Bind Request osix400ms 16:23:21[9973] MS Bind Confirmation osix400ms 16:23:21[9973] MessageSubmission Invoke Request osix400ms 16:23:21[9973] MTS Bind Request ...
168 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 15
To display information on activity occuring in the MTA only:
hostname# x400trace -i osimta events ./x400trace: Initialization in progress Tracing osimta ./x400trace: Initialization completed osimta 11:44:29[9973] MTS Bind Request osimta 11:44:29[9973] MTS Bind Confirmation ...
To trace all inbound and outbound PDUs, and redirect the output to a file:
hostname# x400trace pdu >trace.out
To trace inbound and outbound P7 PDUs: hostname# x400trace -p p7 pdu ./x400trace: Initialization in progress Tracing osimta osix400ms ./x400trace: Initialization completed osix400ms 11:56:41[9973] MS Bind Request
b0 3e MSBindArgument *[16] Length=62 (62) 31 3c *[MSBindArgument] Length=60 (60) 60 2e initiator-name Orname *[APPL 0: ORName] Length=46 (58) 30 2c *[StandardAttributeList] Length=44 (44) 61 04 Country *[APPL 1: CountryName] Length=4 (42) 13 02 [PrintableString] Length=2 (2) 4652 F R ...
Managing Your Messaging System with Command-Line Tools 169 15
Using x400decode
The x400decode utility decodes Protocol Data Units (PDUs). Input can be from standard input (stdin) or from a file, and can be in either binary or ASCII format. Output is returned to standard output (stdout).
To start x400decode:
hostname# /opt/SUNWconn/sbin/x400decode [-ar] [-s
The command-line options are: -a Specifies ASCII input. By default, input is in binary format. -r Specifies that x400decode returns raw ASN.1 output. -s
Table 15-4 x400decode Protocols
Protocol Description p1 Decodes P1 PDUs. p2 Decodes P2 PDUs.
file Specifies the name of an input file. By default, input is from stdin.
170 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Part 5 — Appendices
This part contains the following supplementary information: • Appendix A, “Error Messages,”contains information to help you diagnose and resolve problems with your messaging system. • Appendix B, “Technical Specification and Conformance Information,”contains a technical specification for the Solstice X.400 Messaging Server, and a brief description of the CCITT X.400 recommendations to which it conforms.
Error Messages A
Errors Returned by x400tool page 173 Errors Returned by the RFC1006 Driver Utilities page 182 Alarms Returned by the Messaging System page 184 Messages Returned by the OSI Alarmer page 189 Abnormal Events Returned by the Messaging System page 190 Errors Indicating Rejected RFC1006 Connections page 192
This appendix provides a list common error messages. Each message is presented with a brief description of the possible cause and a suggested action, if applicable. All messages, errors, events and trace information are logged in /var/SUNWconn/osinet/osilogd.log.
Errors Returned by x400tool
Agent name can only contain printable characters The name assigned to an agent must be printable (ASCII) characters.
Agent name must start with a letter The name assigned to an agent can contain digits, provided the name starts with an alphabetic character.
Alternate Recipient already exists You cannot assign two alternate recipients with the same O/R address.
173 A
An X.25/X.121 address must only contain digits X.25/X.121 addresses must contain numbers only; it must not contain non- numeric characters.
Another instance of the tool is already running Because x400tool interacts directly with the local server running on the system, you cannot start two instances of x400tool on the same machine.
Backing up the configuration will overwrite the following file(s): If you specify the name of an existing file to which the configuration backup is to be saved, then that file will be overwritten.
calloc system call failure (
Cannot close adaptor while it is running You must stop the Solstice X.400 Internet Adaptor process before you can stop the adaptor. Use /usr/SUNWconn/sbin/x400stop osismtpx400 to stop the adaptor process.
Cannot open internet adaptor You must start the Solstice X.400 Internet Adaptor process before you can start the adaptor. Use /opt/SUNWconn/sbin/x400start osismtpx400 to start the adaptor process.
Cannot close MTA
Cannot open MTA
Cannot close P1 user agent
Cannot open P1 user agent
174 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 A
Cannot close user agent
Cannot find the MTA server for group
Cannot open user agent
Cannot restore all the msg store users from this backup file The backup file you are restoring from was created for selected users in the MS users group. You cannot use this backup file to restore information for all the users in the group.
Can’t backup configuration x400tool was unable to backup the existing configuration to the specified file. Your file system may be full or the permissions may not be set correctly.
Can’t get MHS config file name x400tool was unable to recover the prefix that defines the name of the current configuration file.
Can’t open file: <filename> The specified file does not have the correct access permissions or pathname to be opened.
Can’t open new file: <filename> The specified file cannot be created. You may have specified an illegal name or pathname.
Can’t open/write file: <filename> - errno
Can’t update init file Indicates a severe internal error that occurred when updating the osimta.init file. If this error is returned frequently, contact your authorized service provider.
Error Messages 175 A
Can’t update xmh.ini file Indicates a severe internal error. If this error is returned frequently, contact your authorized service provider.
Can’t update xom.ini file Indicates a severe internal error. If this error is returned frequently, contact your authorized service provider.
Country & ADMD must be present The global domain identifier must have at least a country code and an ADMD defined. If the agent is not part of a recognized ADMD, you can enter a blank space character as the ADMD; however, you must not leave a null entry.
Default route already exists (not created) When you add an agent to the messaging system, x400tool attempts to create a default entry in the local routing table. The default entry is always based on the global domain identifier assigned to the agent. If an identical entry already exists, x400tool generates this warning to inform you that you must modify the routing table manually to add a route for the new agent. See “Modifying the Default Routing Table” on page 103 for detailed instructions.
Deleting incoming queue: failed There was an error while deleting the incoming message queue. Try again.
Deleting outgoing queue: failed There was an error while deleting the outgoing message queue. Try again.
Duplicate O/R name or Duplicate name You have created a routing table entry that matches an existing entry, or you have defined an agent with an O/R address that matches that of an existing agent.
Error: invalid MS server The server message store you specified for an MS users group is not defined. Make sure that it is listed in the Message Stores scrolling-list.
Error: invalid MTA server The server MTA you specified for an MS users group is not defined. Make sure that it is listed in the MTAs scrolling-list.
Error: maximum number of supported ms users is reached You cannot define a total of more than 250 MS users.
176 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 A
Error: maximum number of user groups is reached You cannot define more than 250 MS user groups.
Error: name is mandatory You must define a name for each agent in your messaging system. Agent names must not include space or tab characters.
Error: no body types supported A user agent has been defined without specifying any supported body types. This will prevent the local MTA from forwarding any mail to it. Enable at least one body type for the user agent. See “Specifying the Body Types Supported” on page 93 for more information.
Error: no content type supported A user agent has been defined without specifying any supported content types. This will prevent the local MTA from forwarding any mail to it. Enable at least one content type for the user agent. See “Specifying the Standard Content Types Supported” on page 94 for more information.
Error: no group name specified When adding a new MS users group, you must specify a name for the group before you add a user.
Error: no user selected When backing up or restoring an MS users group, you must select at least one user from the Group Users scrolling-list.
Error: non-numeric content type The value assigned to the non-standard content type defined for a user agent must be numeric.
Error: standard content type The value assigned to the non-standard content type defined for a user agent must not match one of the standard content types. Standard content types are: 0, 1, 2, 22, 35.
Error: too many non std content types You have defined more than the maximum number of non-standard content types allowed.
Error when creating
Error Messages 177 A
Error when opening
Error while removing message An error occurred when purging the message queues. If this error is returned frequently, contact your authorized service provider.
Error while saving users group information on .mhsgrp file An error occurred when writing to the current MS user text configuration file (filename.mhsgrp). Verify your file system then try again.
If this error is followed by the error message Cannot find ms server server_name, the server message store is no longer defined on your local machine. For example, you have deleted the message store from the x400tool configuration. Add the message store to your configuration, or select a different message store for the MS users group, then try again.
File error on <filename> (
Host name and address do not correspond You can enter a TCP/IP (RFC 1006) address as a numeric IP address (dot notation) or as a host name. If you enter a host name, x400tool retrieves the corresponding IP address by doing a gethostbyname.If you enter both a numeric IP address and a host name, the two addresses must be equivalent.
Host name or address must be present You can assign TCP/IP (RFC1006) addresses for remote MTAs as numeric addresses or host names. You must enter at least one.
Incompatible addressing data The X.400 address contains elements that do not combine to make a valid address. For example, a combination of a numeric-user-identifier (UA-ID) and a personal-name (PN). See “X.400 Addressing” on page 7 for a description of valid X.400 address types.
Initialization failed Indicates a severe internal error. If this error is returned frequently, contact your authorized service provider.
178 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 A
Internal Error (
Internet adaptor already exists:
Invalid ADMD code The ADMD code that you have entered was not found in the list of standard ADMD codes. You can choose to correct the code or to force x400tool to accept it.
Invalid country code The country code that you have entered was not found in the list of standard country codes. You can choose to correct the code or to force x400tool to accept it. If you use a non-standard country code, you may experience interworking problems.
Invalid hexadecimal number Use a number that only includes hexadecimal digits—0 through 9 and A through F.
Invalid host name:
Invalid IP address (must be a.b.c.d) Numeric IP addresses must be entered in a dot notation.
Invalid MS users groups file format The current MS user text configuration file (filename.mhsgrp) has become corrupted. Restore the affected MS Users group(s) from a previous backup.
Invalid MTA response Indicates a severe internal error. If this error is returned frequently, contact your authorized service provider.
Invalid restore summary file:
Error Messages 179 A
Invalid times: no value set When you select Entry Creation Limits while backing up or restoring an MS user mailbox, you must enter a time and date range.
Invalid User Id: must be an int (0,32767) Indicates a severe internal error. If this error is returned frequently, contact your authorized service provider.
malloc system call failure (
Message queues are currently not empty Please confirm
MTA or adaptor not found A configured local MTA or adaptor were not found as required in the backup configuration. Either try the restore again or backup a different configuration.
MTA process is not running properly Indicates a severe internal error. If this error is returned frequently, contact your authorized service provider.
Network address must be present You must specify an OSI network address when defining a remote MTA.
No more licenses available You cannot add any more MS users. Delete an MS user from your configuration before adding a new one, or purchase more MS user licenses.
NSAP must be an hexadecimal number X.25 and LAN addresses must be entered as hexadecimal numbers.
OSI Communication Platform not running If you did not install the RFC1006 driver, you cannot start x400tool unless the SunLink OSI Communication Platform (stack) is configured and running on your machine.
Process
180 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 A
Restart the MTA You need to start the local MTA before you can complete the current operation. Use x400tool to start it.
Routing ambiguous The routing is ambiguous or the format of the O/R address is not compliant with the X.400 specification. For example, the local MTA might not be able to distinguish between two possible destinations. Verify the routing defined and ensure that there is enough information to distinguish a unique route.
Routing impossible The local MTA cannot route the message. Verify the routing and ensure that the route has a valid and unique definition.
Select an MTA icon as default You need to select one of the remote MTAs in your messaging system when defining a default (“catch-all”) MTA. See “Setting a Default MTA” on page 80 for more information.
Statistics: unknown obj type
Surname is mandatory when adding other personal name attributes Personal names consist of four attributes: surname (S), given-name (G), initials (I), and generation-qualifier (GQ), of which only surname is mandatory.
Software has not been installed correctly: check the file /etc/opt/SUNWconn/OSIROOT or you have the variable $OSIROOT wrongly defined in your environment x400tool was unable to locate the expected files in the default directory. Either the files have been incorrectly installed, or the file /etc/opt/SUNWconn/OSIROOT is pointing to the wrong location. Alternatively, if you defined an environment variable $OSIROOT, check that it is pointing to the true location of the Solstice X.400 Messaging Server configuration files.
Too many message queue P1 users, Limit is 16 You can have a maximum of 16 P1 user agents defined to use the message queue interface.
Error Messages 181 A
Unable to locate OSIROOT directory x400tool was unable to locate the expected files in the directory defined by the file /etc/SUNWconn/OSIROOT.
X.25 address can only contain decimal digits Enter a numeric X.25 address.
x400tool Error (
Errors Returned by the RFC1006 Driver Utilities
rk6d Daemon Errors
rk6d: Could not find muxid
rk6d: Could not unlink The rk6d daemon cannot unlink a TCP stream. Reboot your system.
rk6d: Error on poll An error occured while rk6d daemon was waiting for information from the kernel module. Restart the rk6d daemon.
rk6d: Fatal error in admin An error occured when sending administration messages to the kernel module. Restart the rk6d daemon.
rk6d: Fatal error plumbing listen stream The rk6d daemon could not open a stream to the kernel module. Reinstall the SUNWrk6d package and try again.
rk6d: Fatal error plumbing streams An error occured when opening a TCP stream. Restart the rk6d daemon.
rk6d: Fatal error starting daemon An error occured when starting the rk6d daemon. There may be too many processes running on your system. Stop some processes then try again.
182 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 A
rk6d: Fatal error while waiting An error occured while rk6d daemon was waiting for information from the kernel module. Restart the rk6d daemon.
rk6d: Initial number of ctx exceeds maximum When you start the rk6d daemon manually, the initial number of TCP streams (set using the -i option) must be less than the maximum TCP streams value (set using the -m option).
rk6d: Initial number of ctx should exceed min free ctx When you start the rk6d daemon manually, the initial number of TCP streams (set using the -i option) must be more than the TCP streams “low- water” mark (set using the -l option).
rk6d: Min free ctx exceeds max free ctx When you start the rk6d daemon manually, the TCP streams “low-water” mark (set using the -l option) must be less than the TCP streams “high- water” mark (set using the -h option). rkstat Errors
rk6stat: Could not open device The rk6stat utility could not communicate with the kernel module. Reinstall the SUNWrk6d package and try again.
rk6stat: Error reading statistics:
rk6stat: Error resetting statistics:
rk6trace: Cannot start tracing Stop then restart the rk6trace utility. If this error is returned frequently, contact your authorized service provider.
rk6trace: Could not open trace device
Error Messages 183 A
rk6trace: Error in reading trace stream Stop then restart the rk6trace utility. If this error is returned frequently, contact your authorized service provider.
rk6trace: Error on trace stream Stop then restart the rk6trace utility. If this error is returned frequently, contact your authorized service provider.
rk6trace: Getmsg error
rk6trace: I_SRDOPT call
rk6trace: Poll error
Alarms Returned by the Messaging System
The following error messages are returned by the local MTA in the log file /var/SUNWconn/osinet/osilogd.log. Most of these error messages indicate a system error. If these errors are returned frequently, contact your authorized service provider.
ALARM ! File Error
184 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 A
ALARM ! File Error
<filename> Name of file causing error. Example: ALARM ! File error opening <filename>
ALARM ! Possible duplication to MTA
ALARM ! Database Error on <filename> Description: The messaging system was unable to handle the specified file. Action: Check the file and restart the local MTA. <filename> Name of file causing error.
ALARM ! Database Error on
Error Messages 185 A
ALARM ! Database Error on
ALARM ! OSIAM Internal Error CTX=-1 Description: The local MTA was unable to open the association because there were no contexts available. Action: Contact your authorized service provider if this error is returned frequently. Example: ALARM ! OSIAM Internal Error CTX-1
ALARM ! OSIAM Internal Error SAP=
186 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 A
ALARM ! OSIAM Internal Error SAP=
ALARM ! Unacceptable Dialogue Mode ! MTA
ALARM ! Maximum Number of Retries Reached, closing of MTA
Error Messages 187 A
ALARM ! Loopback detected Description: A loopback condition is detected—that is, the message is routed back to an MTA that has already passed on the message. The local MTA already appears in the trace information for the message. Action: Check the routing table. See “Modifying the Default Routing Table” on page 103.
ALARM ! Originator Control Failure MTA
188 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 A
ALARM ! Congestion critical state Description: The local MTA has been placed in a critical state because the space remaining in the spool file system has dropped below the predefined threshold. The local MTA will not accept any more message transfers; message transfers in progress will be completed. Action: Reduce the number of messages stored in the spool file system if possible. See “Purging the Message Queues” on page 156. If this error occurs frequently, it indicates that your spool file system is too small for the traffic supported by the local MTA. Increase the size of your spool file system or decrease the congestion thresholds. See “Setting the Type of Report Requested by Outgoing Messages” on page 61.
ALARM ! Invalid sequence of Trace Information Description: The timestamp sequence is incorrect. For example, incorrect time zone. By default the time tolerance is set to 255. This alarm may also result from the existence of more than one MTA of the same name in the same management domain. Action: Modify the time tolerance using the Time Tolerance options on the Tuning (Other) pop-up menu from the Local MTA Configuration window in x400tool. If this does not solve the problem, check that there are no MTAs with the same name in the management domain.
Messages Returned by the OSI Alarmer
The logging daemon, osilogd, reads and forwards OSI error and status messages depending on the rules it reads from its configuration file (/etc/opt/SUNWconn/osinet/osilogd.conf). All messages are sent to /dev/console. The following messages are also mailed to root: • The disk containing /var/opt/SUNWconn/OSIROOT/spool is nearly full
Error Messages 189 A
• The disk containing /var/opt/SUNWconn/OSIROOT/spool is full • The free disk space on /var/opt/SUNWconn/OSIROOT/spool is now big enough for the MTA to go back in normal state • One remote MTA is down, please check with x400tool the corresponding MTA and check the connection with that MTA
You can modify the /etc/opt/SUNWconn/osinet/osilogd.conf configuration file so that these messages are sent to an account other than to root:
1. Stop the osilogd daemon.
2. Modify the configuration file. For example, change occurances of mail root to mail user1.
3. Restart the osilogd daemon.
Abnormal Events Returned by the Messaging System
The following messages are returned by the messaging system in the log file /var/SUNWconn/osinet/osilogd.log when an abnormal event occurs.
These messages always indicate a fatal system error. Report them to your authorized service provider.
Abnormal remote MTA state [MTA
Abort Confirm from MTA
Abort indication from MTA
APDU Descriptor error
ASM Unknown Event EVT=
Body type error: body type
Connection is aborted by the provider
Connection is aborted by the remote user
Decoding error: -Status
190 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 A
Decoding error: [ASN1 status=
Error - Unknown:
Illegal application protocol MTA
Inhibition flag set MTA
Interaction file error: FIERR=
Invalid original MPDU error
Local User Error EVNT=
No free association MTA
Prot Error Num=
Protocol error STATE=
Protocol error: state=
Provider Abort NUM=
Refuse confirm from MTA
Refuse response issued
Remote RTS User Abort RTS=(
Some recipients in the MPDU are unreachable:
Still associations for MTA
Time-out RTS=(
Timer Block Id error - N_CNF
Transfer Resumption Reject (illegal seci)
Transfer Resumption Reject (illegal aci)
Unable to identify remote MTA
Unknown database: LUAG
Unknown Event Code EVT=
Unknown refuse reason code MTA
Error Messages 191 A
Unsupported Body Type
User Error:
Usrdata decoding failure
Warning! the following MTA is closed MTA
Errors Indicating Rejected RFC1006 Connections
If you use RFC1006 (TCP/IP) transport as provided by SunLink OSI, you may receive error messages indicating that connections have been rejected. This may be because SunLink OSI has a default connection pool size of 4. To avoid rejected connections, use ositool to increase the number of connections allowed per TCP/IP subnetwork. See the SunLink OSI Communication Platform Administrator’s Guide.
192 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Technical Specification and Conformance Information B
ITU (CCITT) MHS Recommendations Overview page 194 Solstice X.400 Messaging Server Feature List page 195
This appendix contains a technical specification for the Solstice X.400 Messaging Server. It includes a brief description of the ITU (formerly known as the CCITT) X.400 recommendations to which it conforms and a list of the implemented features.
For further information on standards conformance, see the Solstice X.400 Programming Reference Manual. For information on SNMP agent standards conformance, see the SunLink Messaging Management Administrator’s Guide.
The following abbreviations are used in the tables throughout this appendix:
n/a — not applicable
S — feature supported
N — feature not-supported
193 B
ITU (CCITT) MHS Recommendations Overview
X.400 MHS System Service and Overview: Describes in general terms how an originator interacts with a UA to prepare and receive messages, how a UA interacts with an MTA, and naming and addressing conventions. (ISO 10021-1)
X.402 MHS Overall Architecture: Describes the overall system architecture of the X.400 MHS including suggested configurations, naming, and addressing information. (ISO 10021-2)
X.403 MHS Conformance Testing: Provides guidelines and rules for conformance testing of MHS implementations.
X.407 MHS Abstract Service Definition: Specifies conventions used in distributed information processing. (ISO 10021-3)
X.408 MHS Encoded Information Type Conversion Rules: Provides guidelines for code and format conversion algorithms used in the MHS.
X.411 MHS MTS Abstract Service Definition and Procedures: Describes how the user can exchange messages with the MTS based on abstract service definitions and syntaxes. (ISO 10021-4)
X.413 MHS Message Store Abstract Service Definition: Describes how to implement a message store. (ISO 10021-5)
X.419 MHS Protocol Specifications: Describes the procedures used to exchange messages between the components of the MHS. Defines three protocols P1, P3, and P7. (ISO 10021-6)
X.420 MHS Interpersonal Messaging System: Describes the procedures and syntax used for the exchange of interpersonal messages (electronic mail). (ISO 10021-7)
194 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 B
Solstice X.400 Messaging Server Feature List
The following sections list the service elements defined in the 1988 revision of the ITU X.400 recommendations.
MT Service Elements (P1)
Table B-1 Basic Message Transfer Service Support
Out Out In In Message Transfer Basic Service Elements MTA Gway MTA Gway Access management SSSS Content type indication n/a n/a S S1 Converted indication n/a n/a S S2 Delivery time stamp indication n/a n/a n/a n/a Message identification S S3 SS3 Non-delivery notification SSSN4 Original encoded information types indication S S5 SS5 Submission time stamp indication SSSS User/UA capabilities registration n/a n/a S S
1. New RFC Header “Content-Type” 2. New RFC Header “X.400-Received” 3. New RFC Header “X.400-MTS-Identifier” 4. If sendmail fails to deliver the message, a negative delivery is returned as an IPM Message 5. New RFC Header “Original-Encoded-Information-Type”
Table B-2 Optional Message Transfer Service support
Out Out In In Message Transfer Optional Service Elements MTA Gway MTA Gway Alternate recipient allowed S N S N Alternate recipient assignment S N S N Content confidentiality N N Content integrity N N Conversion prohibition S N S S Conversion prohibition due to loss of information S N S S
Technical Specification and Conformance Information 195 B
Table B-2 Optional Message Transfer Service support
Out Out In In Message Transfer Optional Service Elements MTA Gway MTA Gway Deferred delivery S S1 SS1 Deferred delivery cancelation S N S N Delivery notification SSSS2 Designation of recipient by directory name S N n/a n/a Disclosure of other recipients S S3 SS4 Directory List expansion history indication n/a n/a S Directory List expansion prohibited S N n/a n/a Explicit conversion N n/a n/a Grade of delivery selection SSSS Hold for delivery n/a n/a N Implicit conversion n/a n/a Latest delivery designation S S5 SN Message flow confidentiality N N Message origin authentication N N Message security labeling N N Message sequence integrity N N Multi-destination delivery SSSS Non-repudiation of delivery N N Non-repudiation of origin N N Non-repudiation of submission N N Originator requested alternate recipient S N S N6 Prevention of non-delivery notification S S7 SN8 Probe S n/a S S Probe origin authentication n/a N Proof of delivery N N Proof of submission N N Redirection disallowed by originator S N S N Redirection of incoming messages Report origin authentication N N Requested delivery method S N
196 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 B
Table B-2 Optional Message Transfer Service support
Out Out In In Message Transfer Optional Service Elements MTA Gway MTA Gway Restricted delivery NNNN Return of content S S9 SS10 Secure access management n/a n/a
1. New RFC Header “Deferred-Delivery”. Managed by MTA but never by adaptor. 2. Indicates message received by sendmail but not necessarily delivered to recipient. A negative delivery report may still be returned after a positive delivery notification. 3. Always requested for outgoing messages. 4. New RFC Header “X.400-Recipients”. 5. New RFC Header “Latest-Delivery-Time”. 6. Not supported, but placed as a comment in the address field “X.400-Recipients”. 7. New RFC Header “Delivery-Report”, only on per message basis. 8. Sendmail interrogates the adaptor to see if it can route the message. Since the local routing may not be the final one, this report has no real meaning. 9. An adaptor parameter determines whether “return of content” is requested in the message or managed locally. 10. Return of content will be performed by the IPM message carrying the negative delivery report.
IPM Service Elements
Table B-3 Basic Inter-Personal Message Service Support
Out Out In In Message IPM Service Elements MTA Gwy MTA Gwy IP-message identification SSSS
Table B-4 Optional Inter-Personal Message Service Support
Out Out In In Message IPM Service Elements MTA Gwy MTA Gwy Additional physical rendition N n/a Authorizing users indication SSSS Auto-forwarded indication n/a n/a S S Basic physical rendition n/a n/a
Technical Specification and Conformance Information 197 B
Table B-4 Optional Inter-Personal Message Service Support
Out Out In In Message IPM Service Elements MTA Gwy MTA Gwy Blind copy recipient indication SSSS Body part encryption indication S S1 SS1 Counter collection n/a N Counter collection with advice n/a N Cross-referencing indication SSSS Delivery via Bureaufax service N n/a Express Mail Service (EMS) N n/a Expiry date indication S S2 SS2 Forwarded IP message indication n/a n/a S S12 Importance indication S S3 SS4 Incomplete copy indication S S4 SS5 Language indication S S5 SS6 Message flow confidentiality N N Multi-part body S S6 SS7 Non-receipt notification request indication S N7 SN8 Obsoleting indication S S8 SS9 Ordinary mail N n/a Originator indication SSSS Physical delivery notification by MHS N n/a Physical delivery indication by PDS N n/a Physical forwarding allowed S S9 SS10 Physical forwarding prohibited S S10 SS10 Primary and copy recipients indication SSSS Receipt notification request indication S N8 SN8 Registered mail N n/a Registered mail to addressee in person N n/a Reply request indication S S10 SS11 Reply IP message indication SSSS Request for forwarding address N n/a Sensitivity indication S S11 SS12
198 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 B
Table B-4 Optional Inter-Personal Message Service Support
Out Out In In Message IPM Service Elements MTA Gwy MTA Gwy Special delivery N n/a Subject indication SSSS Undeliverable mail with return of physical message n/a n/a
1. New RFC header “Original-Encoded-Information-Types:” 2. New RFC header “Expiry-Date:”. No automatic action performed when date has expired. 3. New RFC header “Importance:” 4. New RFC header “Incomplete-Copy:” 5. New RFC header “Language:” 6. Generated and interpreted in SUN’s mailtool format. 7. May be implemented in next version. 8. New RFC header “Obsoletes” 9. Comment in the “X400-recipients:” header 10. Comment in address. 11. New RFC header “Sensitivity:” 12. IPM expanded in the RFC822 body, can only be interpreted visually.
Technical Specification and Conformance Information 199 B
Message Store Service Elements
Table B-5 Basic Message Store Service Support
Out Out In In Message Store Service Elements MTA Gwy MTA Gwy Stored message deletion S n/a S n/a Stored message fetching S n/a S n/a Stored message listing S n/a S n/a Stored message summary S n/a S n/a
Table B-6 Optional Message Store Service Support
Out Out In In Message Store Service Elements MTA Gwy MTA Gwy Stored message alert S n/a S n/a Stored message auto-forward S n/a S n/a
200 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 Index
Numerics ASN.1, 168 1984 version, 85, 93 association, 47, 76 1988 version, xxii, 7, 70, 85, 93, 195 association control service element (ACSE), 167 1992 version, xxii, 70 association retention timeout, 48 attachments, 15 A attributes, 7, 8 abnormal events, 190 categories, 7 abnormal transfers, 146 keys, 7 acceptor checkpoint size, 53 audit, 61 access control, 42, 68, 92, 97 authentication failures, 145 access unit, 3 added features, xx B address conversion, 122 back to normal, 63 ADMD, 6, 8, 10, 44, 69, 85 backup administrative management domain, See address, 72 ADMD configuration, 29 alarms, 184 message store, 160 alias, 13, 74, 134 billing, xx, 5, 6, 64 alternate recipient, 104 binaries, 23 alternate recipients, 104 Blue Book (CCITT), xxii application entity qualifier, 74 body types, 85, 89, 93 application process title, 74 bodypart, 4, 5, 116 application programs, 3 architectural attributes, 7 C ASCII message, 5 CCITT, xx, xxii, 7, 193
201 cetables file, 112 document set, xxii characters allowed, xxiii domain, 6 charges, 6 address, 113, 134 client, See user agent (UA) ADMD, 6 global identifier, 6, 69, 102 configuration PRMD, 6 backup, 30 regenerate, 160 domain-defined restore, 29 attributes, 7, 10, 11, 87 identifiers, 138 congested state, 63 congestion thresholds, 62 connection E request, 147 EDI, 94 response, 147 EDI messages, 5 CONS network interface, 71, 91, 142 EDIFACT, 5 content electronic messages, xxii return, 117 end-users, 1 types, 85, 94 envelope, 4 country-name, 8, 10 environment variables, 24 critical state, 63 error messages, 173 custom mail header, 135 Ethernet, 142 executable program files, 23 D external content type, 94 database files, 31 default F associations, 76 MTA, 80, 106 FDDI, 71 pseudo host name, 116, 118 file prefix, 29 route, 80, 81, 129 filter option, 127 routing entries, 103 flags, 19 default connection pool size, 192 formatted address, 12 delivery report, 19, 61 G system, 19 directory access protocol (DAP), 20 G3 (fax format), 93 directory name, 13, 74 G4 (fax format), 93 directory service, See X.500 gateway, 3 directory system agent (DSA), xx, 20, 73 gateway, See Internet adaptor icon, 26 gen_sendmail.cf, 112, 130 directory user agent (DUA), xx, 20 geographical attributes, 7 distinguished name (DN), 13, 74 given-name, 10 distribution list, 7, 20 global DNS, 118 domain identifier, 6, 44, 69, 98, 102,
202 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 129 length of name, xxiii X.400 domain, 6, 7, 15 letter, 4 license, 112 H LLC1, 71, 142 header, 4, 5, 135 local routing table, 14, 80, 129 user agent, 91 I log files, 31, 173 IA5 (text format), 93 logging daemon, 189 idle association timeout, 48, 78 incoming messages, 49 M information base, 14, 31, 149, 159 mail initiator checkpoint size, 53 host, 113, 114, 131 international characters, 15, 116, 136 server, 113 Internet adaptor, xvii, 15, 16, 111 mail, 133 address conversion, 122 mailbox, 16, 18 icon, 26 mailer program, 18 testing, 121 mailtool, 15, 133 Internet mail, 111, 126, 133 address, 17 management application, xx application, 18 management domain, 6, 102 domain, 15, 18 mapping tables, 126, 128, 132 domain address, 113, 116 master configuration, 29 mailer program, 18 max remote associations, 77 Internet-style addresses, 130 MCIMAIL, 6 interpersonal messaging protocol (P2), 4 message invalid access (MA) interface, 89 address, 79 elements, 17 characters, xxiii handling system (MHS), 1 invoicing, 5, 6 header, 5 IP address, 118 queues, 48 IPM service elements, 197, 200 tracking, xx, 64 transfer protocol (P1), 4 ISO 10021, 194 transfer system map, 26 ISO 6937 format, 94 message adaptor, 3 ITU, xxii, 193 See Also Internet adaptor message gateway, 89 J message queue interface, 97 journal files, 163 message store (MS), xvii, 3, 14, 83 icon, 26 L name, 42, 67, 84 protocol (P7), 4 LAN, 72, 142 user group, 14
Index 203 message transfer agent (MTA), xvii, 3, 6 numeric O/R address, 11 database, 31, 166 icon, 26 name, 42, 54, 67 O message transfer system (MTS), 3 O/R address, 7, 9, 10, 13, 20, 101, 104 messaging client, See user agent (UA) O/R name, 13 messaging server, 3 ODA, 94 See Also message transfer agent Office Documentation Architecture - see (MTA), message store (MS) ODA MIME, 15, 117 operation protocol data unit (OPDU), 56 minor synchronization, 53 organizational attributes, 7 mixed format, 94 organizational-unit, 10 mnemonic O/R address, 10 organizational-unit-names, 10 modifying sendmail.cf,119 organization-name, 10 monologue, 77 originator, 4 MS service elements, 200 originator/recipient address, 7 MT service elements (P1), 195 OSI mt_open(), 96 address, 54, 71, 72, 74 displaying, 142 MTS access protocol (P3), 4 communication platform multimedia attachments, 15 (stack), xvii, 21, 192 multiple end-users, 7 reference model, xxii Multipurpose Internet Mail Extensions, OSI alarmer, 189 See MIME OSI stack starting, 24 N OSI transport, 24 name length, xxiii osi_trace,79 name service, 118 osimta, 25, 167 new features, xx osismtpx400, 129 NIS, 16, 118 osix400mail,17 NIS+, 118 osix400mqa,25 non-delivery report, 61 osix400ms, 25, 168 non-standard content type, 95 osixapia, 167 non-urgent outgoing messages, 17 messages, 49 queue stay-time, 50 P normal P1, 4, 71, 142 messages, 49 access, 97 queue stay-time, 50 applications, 97 state, 63 user name, 96 notation, 9 users, 37, 89, 96 NSAP, 72 P2, 4, 85, 93, 94
204 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 P22, 4, 85, 93, 94 user agent, 91 P3, 4, 5, 71, 85, 142, 167, 170 remote operations service (ROSE) P7, 4, 71, 142, 167, 170 flow control options, 56 password, 42, 87, 92 resource management options, 57 tracing, 167 personal attributes, 7, 87 representing O/R addresses, 9 personal-name, 8, 10 restore physical delivery, 12 configuration, 29 postal message store, 160 O/R address, 12 MTA database, 166 primary IP address, 118 retry connection timeout, 48 print configuration, 30 RFC 1006, 71, 142 private management domain, 6 driver, xvii, xx PRMD, 6, 8, 10, 44, 69 rejected connections, 192 processes RFC 1148, 126 starting and stopping, 25, 28 RFC 1327, 19, 111, 126 product-specific RFC 1341, 15 spool directory, 17 RFC 822, 15, 19, 111, 126 protocol data unit (PDU), 21 RFC 987, 19, 126 pseudo host name, 16, 115, 116, 118, 130, rk6d,21 134 rk6stat,21 PTT, 6 rk6trace,21 purge, 31 router, See message transfer agent (MTA) mail queue, 156 message store, 159 routing, 14 algorithm, 106 messages, 3, 115 Q table, 14, 80, 95, 99, 129 queues, 48, 97 RTS directory, 97 busy indications, 145 size, 97 inactivity timeout, 53 tracing, 168 R version, 70 recipient, 4 alternate, 104 S recovery attempts delay, 48 security options, 54 refresh interval, 143 send test message, 123 regenerating the configuration, 164 sendmail, 15, 16, 18, 112 relative distinguished name (RDN), 13 sendmail.cf, 16, 112, 119, 130, 133 relaying messages, 3 sent reliable transfer service - see RTS data, 46 remote data threshold, 48 MTA, 80 message threshold, 48
Index 205 messages, 46 synchronization, 53 server, See messaging server service T charges, 6 T.100, 93 elements, 15, 195 T.101, 93 session layer, 58 connection timer options, 59 T.61, 93 functional unit options, 60 TCP/IP, 21, 71, 72, 142, 192 protocol options, 59 teletext, 93 sfd (simple format document), 93 telex, 93 shortage condition, 46 terminal identifier, 87 SMTP, xvii terminal O/R address, 11 SNMP agent, xvii, xx, 193 test sorting office, 14 address conversion, 122 special abbreviations, 138 association, 77 message, 123 spool directory, 16, 17, 31 third-party users, 37, 96, 104 files, 31, 166 thresholds, 47, 76 spreadsheet, 64 time tolerance, 62 standard attributes, 7 timer unit, 50 start rule, 132 tool properties, 143 starting x400tool transfer charges, 6 locally, 25 translating addresses, 122 remotely, 26 transport layer interface (TLI), 21 state two way, 77 congested, 63 type of access, 97 connected, 78 typical X.400 MHS, 1 critical, 63 disconnected, 78 normal, 63 U status unacceptable dialog mode, 146 Internet adaptor, 149, 151 unconfirmed delivery, 61 local MTA, 145 undefined body type, 93 message store, 149 unidentified content type, 94 printing, 144 remote MTA, 146 UNIX mail, 111, 126, 133 user agent, 153 mailer program, 18 windows, 143, 144 UNIX-style addresses, 130 supplementary info, 117 unreachable MTA, 79 supported urgent body types, 85, 93 delivery, 19, 135 standard content types, 85, 94 queue, 49 surname, 10 queue stay-time, 50
206 Solstice X.400 Messaging Server Administrator’s Guide—February 1996 user agent (UA), 3, 104 x400dblist, 166 name, 91 x400dbload, 166 type, 91 x400dbrecover, 166 x400dbsave, 166 V x400decode, 170 valid characters, xxiii x400-gate, 16 version x400tool,23 RTS, 70 x400trace, 167 X.400, 70 examples, 168 videotex, 93 XAPIA, 96 voice, 93 network access, 97
W Y WAN, 71, 142 ypmatch, 118
X X.121, 5, 11, 80, 87 X.25, 71, 72, 142 X.25 address, 72 X.400 addresses, 7, 122, 138 flags, 19 headers, 135 mail, 3 mail domain, 17 overview, 4 recommendations, xxii, 193 version, 70 X.402, 7, 194 X.403, 194 X.407, 194 X.408, 194 X.411, 194 X.413, 194 X.419, 194 X.420, 194 X.435, 5 X.500, xx, 13, 20 X/Open, 96 x400_genconf, 164
Index 207 208 Solstice X.400 Messaging Server Administrator’s Guide—February 1996