solstice x.400 messaging server 9.0 administrator's guide

Solstice™ X.400 Messaging Server 9.0Administrator’s Guide

A Sun Microsystems, Inc. Business

Part No: 802-5045-10Revision A, February 1996

2550 Garcia AvenueMountain View, CA 94043U.S.A.

PleaseRecycle

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 meanswithout 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 ownedsubsidiary of Novell, Inc., and from the Berkeley 4.3 BSD system, licensed from the University of California. Third-partysoftware, 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 insubparagraph (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.

TRADEMARKSSun, Sun Microsystems, the Sun logo, SunSoft, the SunSoft logo, SunLink, Solstice, and Solaris are trademarks or registeredtrademarks of Sun Microsystems, Inc. in the United States and other countries. UNIX is a registered trademark in the UnitedStates and other countries, exclusively licensed through X/Open Company, Ltd. OPEN LOOK is a registered trademark ofNovell, 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 othercountries. SPARCcenter, SPARCcluster, SPARCompiler, SPARCdesign, SPARC811, SPARCengine, SPARCprinter, SPARCserver,SPARCstation, SPARCstorage, SPARCworks, microSPARC, microSPARC-II, and UltraSPARC are licensed exclusively to SunMicrosystems, 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 userinterfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, whichlicense also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written licenseagreements.

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 APARTICULAR PURPOSE, OR NON-INFRINGEMENT.

THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES AREPERIODICALLY ADDED TO THE INFORMATION HEREIN. THESE CHANGES WILL BE INCORPORATED IN NEWEDITIONS OF THE PUBLICATION. SUN MICROSYSTEMS, INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES INTHE PRODUCT(S) AND/OR THE PROGRAMS(S) DESCRIBED IN THIS PUBLICATION AT ANY TIME.

iii

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

iv Solstice X.400 Messaging Server Administrator’s Guide—February 1996

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 LocalMessaging Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Specifying Your Local Server Name . . . . . . . . . . . . . . . . . . . . . . 42

Setting an Access Control Password . . . . . . . . . . . . . . . . . . . . . . 42

Specifying Your Global Domain Identifier . . . . . . . . . . . . . . . . . 44

5. Tuning Your LocalMessaging Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Contents v

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 System 65

Adding or Changing Information About a Remote MessagingServer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

vi Solstice X.400 Messaging Server Administrator’s Guide—February 1996

Configuring Routes to a Remote MTA . . . . . . . . . . . . . . . . . . . . 80

Setting a Default MTA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

8. Adding Message Store User Information to Your MessagingSystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

Contents vii

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 Adaptor112

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 Manually119

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

viii Solstice X.400 Messaging Server Administrator’s Guide—February 1996

Modifying the sendmail Configuration File for the InternetAdaptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Using the gen_sendmail.cf Script . . . . . . . . . . . . . . . . . . 130

Modifying sendmail.cf Manually . . . . . . . . . . . . . . . . . . 131

13. Sending and Receiving Internet Mail Through the InternetAdaptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Sending Messages Using Internet Mail Applications . . . . . . . . 133

Addressing Messages Through the Solstice X.400 InternetAdaptor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

Contents ix

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 Tools163

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

x Solstice X.400 Messaging Server Administrator’s Guide—February 1996

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

xi

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

xii Solstice X.400 Messaging Server Administrator’s Guide—February 1996

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

Figures xiii

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 theX.400 Internet Adaptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Figure 12-3 Internet Mail Message Received Through theX.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

xiv Solstice X.400 Messaging Server Administrator’s Guide—February 1996

xv

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 theX.400 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Table 9-2 Standard Content Types Defined by theX.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

xvi Solstice X.400 Messaging Server Administrator’s Guide—February 1996

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

xvii

Preface

This manual explains how to configure and maintain the SolsticeTM X.400Messaging 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 messagestore process.

• An RFC1006 driver, enabling you to run Solstice X.400 products without theSunLink OSI Communications Platform (Stack).

• An SNMP (simple network management protocol) agent, enabling you tomonitor 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 todevelop local access messaging applications. See the Solstice X.400Programming Reference Manual for more information.

The Solstice X.400 Internet Adaptor is an X.400-to-Internet mail gateway. Youcan use this to handle the exchange of electronic messages between Internetmail applications (for example, mailtool ) and the X.400 domain.

This manual is intended for system administrators who are familiar with theSolarisTM operating environment. It assumes that you have installed theproduct software and license, as described in Installing and Licensing SolsticeX.400 Products.

xviii Solstice X.400 Messaging Server Administrator’s Guide—February 1996

How This Manual is OrganizedThis 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 SolsticeX.400 Internet Adaptor, and the configuration tool x400tool .

Chapter 1, “Introducing the Solstice X.400 Messaging System,” provides anoverview of X.400 Message Handling Systems. It also introduces the SolsticeX.400 Messaging Server and the Solstice X.400 Internet Adaptor, and describestheir components.

Chapter 2, “Starting and Using x400tool,” describes how to start theOPEN LOOKTM administration tool for the Solstice X.400 Messaging Server andthe Solstice X.400 Internet Adaptor (x400tool ), and provides an overview ofhow to use it.

Chapter 3, “Overview of Configuring Your Messaging System,” gives asummary 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 yourmessaging system.

Chapter 4, “Configuring Your Local Messaging Server,” describes how to usex400tool to set up your local MTA and your local message store.

Chapter 5, “Tuning Your Local Messaging Server,” describes how to usex400tool 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,” describeshow to tune and test remote server associations. It also describes how toconfigure routes to remote MTAs manually.

Chapter 8, “Adding Message Store User Information to Your MessagingSystem,” describes how to use x400tool to add information about users ofyour message store.

xix

Chapter 9, “Adding Third-Party Agents to Your Messaging System,”describes how to use x400tool to add third-party user agents (UAs) and P1agents (for example, message gateways) to your messaging system.

Chapter 10, “Routing Between Messaging Components,” describes how touse x400tool to modify the default routing tables to handle complex routingbetween 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 InternetAdaptor.

Note – You do not need to read this part if you do not have a license for theSolstice X.400 Internet Adaptor.

Chapter 11, “Configuring the Solstice X.400 Internet Adaptor,” describes howto use x400tool to set up a Solstice X.400 Internet Adaptor to exchangeelectronic 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 routesmanually, and how to modify the sendmail configuration file.

Chapter 13, “Sending and Receiving Internet Mail Through the InternetAdaptor,” describes how to use UNIX mail tools to send and receive messagesthrough the Solstice X.400 Internet Adaptor.

Part 4 - Managing Your Messaging System

This part describes how to manage and monitor the components in yourmessaging system.

Chapter 14, “Managing Your Messaging System with x400tool,” describeshow to use x400tool to maintain your messaging system and to gatherinformation 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.

xx Solstice X.400 Messaging Server Administrator’s Guide—February 1996

Part 5 - Appendices

This part includes the following supplementary information:

Appendix A, “Error Messages,” contains information to help you diagnoseand 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 abrief description of the ITU X.400 recommendations to which it conforms.

New Features of the Solstice X.400 Messaging ServerThe 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 theSolstice X.400 Messaging Server contains a directory user agent (DUA), thatenables your messaging applications to use X.500 directory names as well asX.400 addresses. For more information, see “X.400 Use of X.500 DirectoryServices” on page 20.

• A set of MTA database tools to list, backup, and restore the temporary MTAdatabase. These tools are described in “Using the MTA Database Tools” onpage 166.

• An RFC1006 driver, giving you the option of running the Solstice X.400Messaging Server over TCP/IP without the SunLink OSI CommunicationsPlatform (stack). For more information see “Introducing the RFC1006Driver” on page 21”.

• An SNMP agent to monitor and analyze your messaging components from asingle location, using a management application such as Solstice MessagingManager. The agent is described in the Solstice Messaging ManagementAdministrator’s Guide.

• A message tracking facility, enabling you to store a permanent record ofmessages processed by your local server. You can then, for example, use thisinformation to calculate a charge (or bill) for your users. See “EnablingMessage Tracking” on page 64.

xxi

The Solstice X.400 Product RangeThe 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 messagingsystem. It includes a Directory-Service-enabled MTA, a message store (witha license for twenty users), and an SNMP Agent.

• Solstice X.400 User Mailboxes provide additional MS User licenses, enablingup to 250 users to connect to your message store.

• The Solstice X.400 Internet Adaptor is an optional component of the SolsticeX.400 Messaging Server. It is an X.400/Internet mail gateway.

• The Solstice Messaging Manager communicates with SNMP Agents. From asingle location, you can monitor and analyze the components of yourmessaging system.

• The Solstice X.400 Client Toolkit is a messaging toolkit, which you can use todevelop X.400 applications that have remote access to a messaging server.

Figure P-1 The Solstice X.400 Product Range

MS User

UNIX Mail

User Agent Directory Service

SolsticeMessagingManager

Solstice X.400 Messaging System

Solstice X.400ClientToolkit

Solstice X.400Internet Adaptor

Solstice X.400User Mailbox

SNMPAgent

MTA DUA

Message Store

xxii Solstice X.400 Messaging Server Administrator’s Guide—February 1996

Product DocumentationThe 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 Answerbookssupplied with the CD-ROM. Installing and Licensing Solstice X.400 Productsdescribes how to install the Answerbooks.

If you are using the SunLink OSI Communications Platform (Stack) instead ofthe 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 RecommendationsThe Solstice X.400 Messaging Server implements the ITU (formerly known asCCITT) X.400 MHS recommendations. The Solstice message store implementsthe 1988 revision of the recommendations; the Solstice message transfer agent(MTA) implements the 1992 revision. The recommendations specify a methodof exchanging electronic messages between diverse systems, based upon theprinciples of the OSI reference model. For an overview of theserecommendations, see Appendix B, “Technical Specification and ConformanceInformation”. The complete CCITT 1988 X.400 recommendations are containedin the CCITT Blue Book: Data Communications Networks Message HandlingSystems Recommendations X.400—X.420 (Volume VIII, Fascicle VIII.7) November1988.

xxiii

Restrictions on Messaging System Component NamesThe following characters must not be used for any of the names describingmessaging system components:

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 than16 characters long.

What Typographic Changes MeanThe following table describes the typographic changes used in this book.

Invalid Characters Description

@ “at” symbol

/ forward slash

\ backslash

# hash or pound sign

space

-> tab

Table P-1 Typographic Conventions

Typeface orSymbol Meaning Example

AaBbCc123 The names of commands,files, and directories;on-screen computer output

Edit your .login file.Use ls -a to list all files.machine_name% You have mail.

AaBbCc123 What you type, contrastedwith on-screen computeroutput

machine_name% suPassword:

AaBbCc123 Command-line placeholder:replace with a real name orvalue

To delete a file, type rm filename.

AaBbCc123 Book titles, new words orterms, or words to beemphasized

Read Chapter 6 in User’s Guide.These are called class options.You must be root to do this.

xxiv Solstice X.400 Messaging Server Administrator’s Guide—February 1996

Shell Prompts in Command ExamplesThe following table shows the default system prompt and superuser promptfor 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 #

Part 1 — Introducing Solstice X.400 andits Configuration Tool

This part has three chapters:

• Chapter 1, “Introducing the Solstice X.400 Messaging System,” providesan overview of X.400 Message Handling Systems. It also introduces theSolstice 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 theadministration tool (x400tool ) for the Solstice X.400 Messaging Server andthe Solstice X.400 Internet Adaptor , and provides an overview of how touse the tool.

• Chapter 3, “Overview of Configuring Your Messaging System,” gives asummary of the steps to follow to configure your messaging system.

1

Introducing the Solstice X.400Messaging System 1

This chapter provides an overview of X.400, the Solstice X.400 MessagingServer and the Solstice X.400 Internet Adaptor, and introduces the terminologyused to describe their components.

Overview of an X.400 Message Handling SystemFigure 1-1 on page 2 shows the components of a typical X.400 MessageHandling System. This system is used to transfer electronic messages from oneend user to another.

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

2 Solstice X.400 Messaging Server Administrator’s Guide—February 1996

1

Figure 1-1 The X.400 Message Handling System Model

InternetAdaptor

Message Transfer

MessageTransfer Agent


MessageTransfer Agent User Agent


MessageStore

User Agent

Internet Mail

Internet Mail

3rd PartyAccess Unit

Postal Service,Fax, etc.

System (MTS)

User Agent

Local

Introducing the Solstice X.400 Messaging System 3

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 ServersA messaging server consists of the following components:

• Message Transfer Agent (MTA)Message transfer agents are the X.400 routers. They handle the routing ofelectronic messages. A collection of MTAs is called a message transfersystem (MTS).

Your local MTA is the MTA running on your local machine. It handlesthe routing of electronic messages between user agents (applicationprograms) and remote MTAs. It is the focal point through which allmessages pass through your local messaging system.

Remote MTAs are the message transfer agents with which your localMTA can communicate directly. They handle the routing and relaying ofelectronic messages throughout the X.400 domain.

• Message Store (MS)A message store acts as an intermediary between MTS users and anMTA. It stores X.400 messages, and lets users manipulate and sendmessages in a variety of ways. Without a message store, UAs mustconnect to an MTA and explicitly request to receive messages.

A message store accepts delivery of messages on behalf of a UA andstores the messages for subsequent viewing, retrieval, and forwarding.The MS provides a UA with additional functionality compared to directdelivery to the MTS. For example, an MS can send alerts to a UA when itreceives a certain message.

• Message AdaptorA message adaptor (or message gateway) handles the translation ofelectronic message formats between dissimilar mail systems—forexample, between Internet mail and X.400 mail.

• Access Units (AU)An access unit provides the direct interface between other communicationsystems (such as fax or postal services) and the messaging system.


1

The X.400 MHS ProtocolsA messaging system uses protocols to reliably transport messages from oneend user to another. The X.400 message handling system uses the followingprotocols:

• Message Transfer Protocol (P1)The message transfer protocol defines the structure used to transport anelectronic message (the “envelope”) between end users. It includes theaddresses 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 containsinformation about the message (for example, originator and recipientaddresses, 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 betweenthe 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. Itallows 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 exchangedbetween end users.


1

Figure 1-2 Exchanging Messages Between Users

The Solstice X.400 Messaging Server also supports the exchange of EDImessages as defined by X.435. This protocol defines a wide range of electroniccommercial communications. For example, a bill (or invoice) that is exchangedbetween end users. This might be a message consisting of a header that containsinformation about the message (for example, originator and recipientaddresses, date, subject) and a body that contains the content of the bill (forexample, an EDIFACT, X.121, or ASCII message).

Refer to the CCITT X.435 Recommendation and the Solstice X.400 ProgrammingReference Manual for more information on EDI messaging.

Message Transfer Protocol (P1)

Interpersonal Messaging Protocol (P2, P22)

User AgentUser Agent


P3(internal)

Remote MessageTransfer Agent

MessageStore

Message Store Protocol (P7)

MTS Access Protocol (P3)

Local Messaging Server


1

X.400 Management DomainsThe purpose of the X.400 MHS recommendations is to create a global X.400domain within which communicating systems throughout the world canexchange electronic messages. This global X.400 domain is divided intocountries and each country is further divided into management domains—that is,one or more MTAs (and any associated UAs) governed by a controllingorganization.

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 PostalTelegraph and Telephone (PTT) Agency or a non-national organization.

• A PRMD is controlled by any other type of organization; for example, aprivately-owned company.

An ADMD (such as ATLAS or MCIMAIL) is typically divided into PRMDs. Ingeneral, the ADMD handles all messages that are either exchanged betweenPRMDs or exchanged across international boundaries. However, since theADMD charges for its services and since not all PRMDs are controlled by anADMD, there are exceptions to this rule.

Each MTA is assigned a global domain identifier that specifies the country, theADMD, and (optionally) the PRMD in which the MTA is located as shown inFigure 1-3. This is the minimum information required to identify a given MTA.

Figure 1-3 The Global Domain Identifier for an MTA

Country=US

ADMD=MCI

PRMD=USHQ


1

X.400 AddressingAn originator/recipient ( O/R) address specifies the information needed todeliver a message to an end user. It is analogous to the address used to direct aletter within the postal service.

An O/R address consists of a list of attributes that describe the end user andlocate that end user within the global X.400 domain. If there are multiple endusers, the O/R address describes a distribution list.

Attributes contained in an O/R address are defined by recommendation X.402and are generally divided into the four categories shown in Table 1-1.

Domain-defined attributes are attributes that fall outside the scope of theCCITT recommendations. These attributes are interpreted only within theconfines of the domain in which they are defined, but are transmitted as part ofthe address in the same way as standard attributes. The Solstice X.400Messaging Server supports both standard and domain-defined attributes.

In a text representation (for example, for addressing within Internet mail) eachattribute is represented by a code (or key) to which an appropriate value isassigned. Table 1-2 on page 8 lists the standard attribute keys and a descriptionof each attribute as defined by the 1988 revision of X.402. Keys may berepresented in uppercase or lowercase. Attribute values may be represented inprintable text format (TXT), teletext format (TLTX), or numeric format (NUM) asindicated. Note that the Solstice X.400 Internet Adaptor does not supportteletext format O/R addresses.

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 theend user belongs; for example, organization name,organizational unit

Architectural Attributes Attributes that describe the environment to which theorganization belongs; for example, PRMD, X.121 address

Geographical Attributes Attributes that describe the physical location of the enduser; for example, country, postal code


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 <num> organizational unit name (<num>=1-4) X X

PN personal name X X

S surname (mandatory) X X

G given name X X

I initials X X

GQ generation qualifier X X

PRMD private domain name X X

T-ID terminal identifier X

T-TYPE terminal type X

PD_SERVICE physical delivery service name X

PD-C physical delivery country name X X

PD-CODE physical delivery postal code X X

PD-EXT-ADDRESS physical delivery extension address components X X

PD-OFFICE physical delivery office name X X

PD-OFFICE-NUM physical delivery office number X X

PD-PN physical delivery personal name X X

PD-O physical delivery organization name X X

PD-ADDRESS physical delivery unformatted postal address X X

PD-STREET physical delivery postal street address X X

PD-BOX physical delivery postal box address X X

PD-RESTANTE physical delivery poste restante address X X

PD-UNIQUE physical delivery unique postal name X X

PD-LOCAL physical delivery local postal attributes X X

NET-NUM extended network address X X

DD<num> domain defined attribute X X X


1

Representing O/R Addresses

There are two notations used for representing O/R addresses. Of these, themore widely accepted notation separates the component attributes by a slash(/) character.

By convention, O/R addresses are often represented in an order similar to thatused for postal addresses as shown in the example in Figure 1-4.

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

From: Originator’s NameStreet AddressTownCountry

Recipient’s Name

Company Name

Street Address

Country

Town

/C=FR/ADMD=ATLAS/PRMD=EUROHQ/O=MKTG/S=DUPONT/


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 theInternet Adaptor” for a description of how to use X.400 O/R addresses whensending messages using Internet mail applications such as mail or mailtool .

Mnemonic O/R AddressThis is the most common type of O/R address. It identifies the user and theadministrative domain within which the user is located. By definition, allattributes are assigned text (or teletext) format values. A mnemonic O/Raddress 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 theADMD 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) — mandatorygiven-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 amnemonic O/R address. If you use organizational unit names, the order of theattributes can be important. You can use either numbered organizational unitnames (OU1, OU2, etc.) or unnumbered organizational unit names. Numberedorganizational 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/


1

Unnumbered organizational unit names are interpreted in the order in whichthey appear, numbered from the side nearest the country code:

Numeric O/R AddressA numeric O/R address identifies the user and the ADMD within which theuser is located using numeric attributes only. It consists of the followingcomponent attributes:

• One country-name (C) and one administration-domain-name (ADMD),both of which must be assigned numeric values. This identifies the ADMDwithin which the user is located.

• One numeric-user-identifier (UA-ID) and (optionally) aprivate-domain-name (PRMD).

• Optionally, one or more numeric domain-defined attributes (DD).

Terminal O/R AddressA terminal O/R address identifies a user by means of a network addressand some other optional information. It consists of the following componentattributes:

• 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 isaccessed. If one of these attributes is specified, the other must also bespecified.

• Optionally, one private-domain-name (PRMD). It is required only whenthe country-name and administration-domain- name are present.

• Optionally, one or more domain-defined attributes (DD). They arerequired only when the country-name and administration-domain- nameare present.

/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/


1

Postal O/R AddressA postal O/R address identifies the user by means of the user’s postaladdress (street address, postal code, etc.) and is used to physically deliver amessage to a user.

Postal O/R addresses are not directly applicable to the Solstice X.400Messaging Server and physical-delivery attributes are not supported byx400tool . Although the Solstice X.400 Messaging Server supportsmessages that present a postal O/R address, it does not base any of itsrouting decisions on the physical-delivery attributes.

The X.400 recommendations specify a formatted postal O/R address that iscomposed 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)


1

X.400 Addressing Using X.500 Directory Services

If your network has access to an X.500 Directory Service, your user agents canspecify an O/R name for the address of the message recipient. An O/R namecan 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. Adirectory name is a unique way to identify an entry in an X.500 Directory.

There are two types of directory name:

• Distinguished NameEach entry in an X.500 Directory is named by an ordered sequence ofattributes know as relative distinguished names (RDNs). A distinguished nameis a sequence of RDNs that uniquely represent the entry. An exampledistinguished 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 distinguishedname format, the MTA queries the Directory Service to determine therecipient’s O/R address.

• AliasAn alias is a “user-friendly” abbreviation of a distinguished name. Itprovides a shorthand way of referring to an entry in an X.500 Directory. Anexample alias is:

jsinclair

When a UA submits a message with an alias for the recipient address, theMTA 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 SolsticeX.400 MTA uses an X.500 Directory Service to translate a directory name (be ita distinguished name or an alias) into an X.400 O/R address.


1

Routing Messages in the X.400 DomainAn MTA functions like a traditional postal service sorting-office—sorting themessages for delivery, based on the recipient address.

When it receives a message, the MTA compares the list of attributes in the O/Raddress against the entries in its local routing table. If the O/R address (or partof the O/R address) matches one of the entries, the message is forwarded tothe agent associated with the matching entry. This can be any one of therecognized components in the messaging system.

Refer to Chapter 10, “Routing Between Messaging Components” for detailedinstructions on defining entries in the routing table used by your local MTA.

The Solstice X.400 Message StoreThe Solstice X.400 message store (MS), as supplied with the Solstice X.400Messaging Server, can be configured to handle up to 250 individual users, eachwith its own information base of messages. These users can be located on thesame machine as the message store (local users) or on other machines (remoteusers).

To manage information about message store users, and to avoid enteringsimilar configuration information again and again, you define message store usergroups. A message store user group is a collection of message store users. Youcan 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 (yourfirst message store), and another called Engineers (your second message store).

For each message store user group that you define, you also specify whichMTA is serving that group. For example, the message store user group Salescould be served by the local MTA, while the message store user groupEngineers could be served by a remote MTA.

In practice, however, message store user groups should be served by the localMTA. This prevents unnecessary network traffic. For example, suppose amessage store user sends a message to a user in the same message store usergroup. The message is routed by the serving MTA. If this MTA is remote, themessage is routed from the local system to the remote system and then backagain to the local system.


1

The Solstice X.400 Internet AdaptorOne of the optional features of the Solstice X.400 Messaging Server is theSolstice X.400 Internet Adaptor. This handles the exchange of mail messagesbetween 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 serviceelements to equivalent X.400 addresses and service elements, and adds anyadditional information required to route messages across the global X.400domain. It provides support for the transfer of MIME (Multipurpose InternetMail Extensions) attachments as defined by RFC 1341, and incorporatesadditional mail features such as international character set and Sun multimediaattachment support.

Routing Messages in the Internet Mail Domain

This section provides an overview of UNIX mail handling services and routingin the Internet mail domain. Refer to the Solaris documentation for a detaileddescription of the Internet mail system.

The routing of messages within the Internet mail domain is handled by thesendmail daemon as shown in Figure 1-5.

Figure 1-5 Routing Messages in the Internet Mail Domain

UNIX Mail

/bin/mail

sendmail

/var/mail

UNIX Mail

sendmail


1

When sendmail receives a message (from either a local UNIX mail applicationor from a remote sendmail daemon) it expands and parses the recipientaddress using the information in its local configuration file (sendmail.cf ).

• If the message cannot be delivered locally, the message is relayed betweensendmail daemons based on the recipient address and the information inthe 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 retrievedwith 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 thesendmail 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 whichis an alias for the machine on which the adaptor is running. This alias must beentered in the NIS database (or in /etc/hosts if NIS is not running). It mustalso be registered in the local configuration file (sendmail.cf ) for thesendmail daemon running on the same machine as the adaptor. (Note that thelocal sendmail.cf is modified automatically with a default pseudo hostname—x400-gate —when the Solstice X.400 Messaging Server is installed.)Refer to Chapter 11, “Configuring the Solstice X.400 Internet Adaptor” formore information.

Routing messages between the Internet mail domain and the X.400 maildomain 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 mailapplication or from a remote sendmail daemon) it expands and parses therecipient address, using the information in its local configuration file(sendmail.cf ). If the message cannot be delivered locally, it is relayedbetween sendmail daemons based on the recipient address and the pseudohost name located in the NIS database (or the local /etc/hosts if NIS isnot running) until it reaches the machine on which the adaptor is located.


1

2. Routing the message to the adaptor running on the machine.The sendmail daemon running on the same machine as the adaptorrecognizes the message based on the pseudo host name entered in its localconfiguration file (sendmail.cf ). As a result, it calls the X.400 mailerprogram osix400mail in place of the UNIX mailer program /bin/mail .

Instead of writing the message directly into the recipient’s mailbox, the X.400mailer osix400mail writes the message into a product-specific spooldirectory (/var/SUNWconn/OSIROOT/spool ) where it can be accessed andparsed by the Solstice X.400 Internet Adaptor. The Solstice X.400 InternetAdaptor translates Internet address and message elements into X.400equivalents and passes the outgoing message to the local MTA for deliveryacross the X.400 domain. Figure 1-6 shows how outgoing messages are routedfrom the Internet mail domain to the X.400 mail domain through the SolsticeX.400 Internet Adaptor.

Figure 1-6 Routing Mail from Internet Mail to X.400 Mail


InternetAdaptor

sendmailsendmail

osix400mail

/var/SUNWconn/OSIROOT/spool

Internet Mail


1

Routing Messages from X.400 to Internet Mail

When the Solstice X.400 Internet Adaptor receives an incoming message fromthe local MTA, it converts the X.400 address and message elements intoInternet mail equivalents. It passes the message directly to the local sendmaildaemon, which handles the routing in the Internet mail domain based on theinformation in its local configuration file and the NIS database.

When the message reaches the machine on which the mailbox for the recipientis located, the sendmail daemon calls the UNIX mailer program /bin/mail .This writes the message into the recipient’s mailbox from where it can beretrieved using an Internet mail application (such as mailtool ).

Figure 1-7 shows how incoming messages are routed from the X.400 maildomain to the Internet mail domain through the Solstice X.400 InternetAdaptor.

Figure 1-7 Routing Messages from X.400 Mail to Internet Mail


InternetAdaptor

sendmailsendmail

/var/mail

Internet Mail

/bin/mail


1

Supported Mail Header Fields

The Solstice X.400 Internet Adaptor translates the mail headers that are used tocarry additional information and to modify the behavior of the mail deliverysystem for each message—for example, to mark the message for urgentdelivery or to request a delivery report. It supports all the mail headersspecified within RFC 822, and additional headers specified in RFC 987 andRFC 1327. Header fields are mapped according to the rules defined in RFC1327.

Table 1-3 lists the most commonly used mail header fields that can be used toset 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 detailedinstructions on how to set mail header fields from within Internet mailapplications.

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


1

X.400 Use of X.500 Directory ServicesThe MTA supplied with the Solstice X.400 Messaging Server contains an X.500directory user agent (DUA). This uses the directory access protocol (DAP) tocommunicate with directory system agents (DSAs), such as the DSA suppliedwith the Solstice X.500 Directory Server. A collection of DSAs make up anX.500 Directory Service, which is accessed by an MTA as shown in Figure 1-8.

Figure 1-8 MTA Use of an X.500 Directory Service

A Directory Service contains information about, for example, messagingsystem users. It can provide a translation of user-friendly names to OSInetwork 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.500Directory Services” on page 13.

• Expand Distribution List (DL) information. DL expansion is more efficientwhen relying on a distributed directory.

To enable your MTA to use a directory service, you must first add informationabout 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 moreinformation.


DSA

DUA

Directory Service

DAP

DSA

DSA


1

Introducing the RFC1006 DriverThe Solstice X.400 Messaging Server and the Solstice X.400 Client Toolkitinclude an RFC1006 driver. The driver implements the RFC1006 protocol,which enables these OSI applications to run over TCP/IP. The RFC1006 drivercan be used instead of the OSI Communication Platform (Stack) below thetransport layer interface (TLI), as shown in Figure 1-9.

Figure 1-9 RFC1006 Driver and Higher Layer Entities

If you want to run the Solstice X.400 Messaging Server or the Solstice X.400Client Toolkit over TCP/IP only, replace the OSI Stack with the RFC1006driver. 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 startedautomatically whenever you reboot your machine. You can fine-tune theconfiguration of the rk6d daemon by editing its configuration file(rk6d.conf(4) ), or by stopping the daemon then restarting it manuallywith some command-line options.

• The rk6stat(1M) utility displays statistical information.

• The rk6trace(1M) utility traces incoming and outgoing Protocol DataUnits (PDUs).

For more information on the RFC1006 driver utilities, see their manpages.

Application

Presentation

Session

TCP/IP

RFC1006 RFC1006 Driver

X.400 Product Daemon

Transport Layer Interface (TLI)

X.400 Application

User Space

Kernel Space


1

23

Starting and Usingx400tool 2

This chapter describes how to start the OPEN LOOK graphical user interfacefor the Solstice X.400 Messaging Server (x400tool ), and introduces itsprimary components.

x400tool is used to configure and maintain your messaging system. Beforestarting to use x400tool , read Chapter 1, “Introducing the Solstice X.400Messaging System”, which introduces the terms and concepts presentedthroughout this manual.

Note – Throughout this manual, it is assumed that you accepted the defaultbase directory (/opt ) for the Solstice X.400 Messaging Server executable fileswhen 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.

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


2

Before You StartBefore you start to use x400tool :

1. Ensure that you have installed the software and licenses for the SolsticeX.400 products you have purchased.

2. Make sure that the transport provider is running:

a. If your messaging applications use an OSI transport provider, makesure that the SunLink OSI stack is configured and running.

If the stack is not running, start it manually by typing:

Refer to the Installing and Licensing SunLink OSI and the SunLink OSICommunication Platform Administrator’s Guide for detailed instructions.

b. If your messaging applications use the RFC1006 driver, make sure thatthe rk6d daemon is running.

If the daemon is not running, start it manually by typing:

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

hostname# ps -ef | grep osinetdroot <pid> <timestamp> /usr/sbin/osinetd

hostname# /etc/rc2.d/S90osinet start

hostname# ps -ef | grep rk6droot <pid> <timestamp> /usr/sbin/rk6d

hostname# /etc/rc2.d/S90rk6 start

Starting and Using x400tool 25

2

Starting x400tool on Your Local MachineTo 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.400Messaging Server, these processes should already be started. You can verifythis by typing:

If the Solstice X.400 processes are not running, start them manually by usingx400start :

Note – If you do not have a license for the Solstice X.400 Internet Adaptor, youdo not need to start the osismtpx400 process.

3. Start x400tool by typing:

Starting x400tool on a Remote MachineIf you want to use x400tool to configure a remote machine as a messagingserver, you can start x400tool remotely so that it is displayed on the monitorof your local machine.

# ps -ef |grep osiroot <pid> <timestamp> osimta osimta osimtaroot <pid> <timestamp> osismtpx400 osismtpx400 osismtpx400root <pid> <timestamp> osix400mqa osix400mqa osix400mqaroot <pid> <timestamp> osix400ms osix400ms osix400ms... other osi processes

hostname# /opt/SUNWconn/sbin / x400start osimta osix400mqa osix400ms osismtpx400

hostname# /opt/SUNWconn/sbin/x400tool &


2

To start x400tool remotely:

1. On your local machine, disable access restrictions for the remote machineso you are able to display x400tool on your local monitor.

2. Log in to the remote machine as root or superuser.

3. Ensure that the Solstice X.400 processes are running on the remotemachine. Start the processes manually if required.

Note – If you do not have a license for the Solstice X.400 Internet Adaptor, youdo not need to start the osismtpx400 process.

4. On the remote machine, start x400tool so that it is displayed on yourlocal monitor.

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 thefirst time you started x400tool on your machine, you will see the followingicons:

• An icon labeled local server that represents your (unconfigured) local MTAand 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 youstart x400tool for the first time.

localhost% $OPENWINHOME/bin/xhost + remotehost

remotehost# /opt/SUNWconn/sbin/x400start osimta osix400mqa osix400ms osismtpx400

remotehost# /opt/SUNWconn/sbin/x400tool -display localhost:0 &


2

To modify the configuration of any of the components in your messagingsystem, double-click SELECT on its icon to activate the associatedconfiguration window.

Figure 2-1 x400tool : Main Window

x400tool has three pull-down menus that can be used to modify, test, andmanage the system:

• The Configure menu is used to modify the configuration of your messagingsystem. It also contains options used to backup and restore theconfiguration.

• The Test menu is used to check the associations between components andthe routing of electronic messages throughout your messaging system.There is also an option to check the conversion of addresses made by theSolstice X.400 Internet Adaptor.

• The Manage menu is used to maintain the elements of your messagingsystem and to recover status information. It is also used to backup andrestore individual message store user mailboxes.


2

Starting and Stopping X.400 Processes

The Processes item is used to start and stop X.400 processes, such as the MTA andmessage store. The Process manager window is shown in Figure 2-2.

1. Click SELECT on the Processes... button to activate the X.400 ProcessManager 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 onStart.

Figure 2-2 x400tool : Starting and Stopping Processes

Click SELECTto display detailedinformation whenstarting a process


2

Backing Up Your Configuration

The Backup Config item is used to save your current MTA and message storeconfiguration to a set of files. By default, configuration files are saved in thedirectory /var/opt/SUNWconn/OSIROOT/mhs/conf , but you can specify analternative location. The configuration is saved under a number of filesidentified by the same file prefix. The file prefix.mhscf defines the name andlocation of all other configuration files. You specify a prefix to identify theconfiguration when you backup the files. The configuration that is displayedwhen you start x400tool for the first time is saved in the file/var/opt/SUNWconn/OSIROOT/mhs/conf/master.mhscf.text . Abackup of this initial configuration is contained in master.mhscf.text.ref .

1. Stop the message store process osix400ms if it is running. See “Startingand Stopping X.400 Processes” on page 28.

2. Press MENU on the Configure menu button and choose the BackupConfig 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 yourconfiguration.

4. Click SELECT on Backup to save your configuration to file.

Note – To backup a message store user mailbox, see “Backing Up andRestoring Message Stores” on page 160.

Restoring an Existing Configuration

The Restore Config item is used to load an existing MTA and message storeconfiguration from file. You can use this facility to restore the masterconfiguration /var/opt/SUNWconn/OSIROOT/mhs/conf/master.mhsc f.text .

Caution – Restoring a configuration will overwrite the messagesstored in a message store user mailbox. Before you restore aconfiguration, backup your message store as described in“Backing Up and Restoring Message Stores” on page 160.

!


2

1. Press MENU on the Configure menu button and choose the RestoreConfig 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 afile called prefix.text , all of the configuration files that start with this prefixwill 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, thenrestarts the processes.

Note – To restore a message store user mailbox, see “Backing Up and RestoringMessage Stores” on page 160.

Printing Your Configuration

The Print option is used to format and print the current configuration. You canprint to any local printer or to a file.

1. Press MENU on the Configure menu button and drag the pointer to thePrint item. Release MENU to activate the print selection window.

2. Choose the name of a printer from the pull-down menu, or specify thename of a file.If there are no printers configured for your system, then you can only printto a file.

3. Click SELECT on Print to print the configuration.


2

Locating x400tool Files

Several files are associated with the Solstice X.400 Messaging Server. Thesefiles can be divided into the following categories:

• Spool or log files that contain a record of all transactions that occur in yourmessaging 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 “Usingthe MTA Database Tools” on page 166.

• MS database files that contain the components of a message store usersinformation 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 becomesvery long, use symbolic links to another directory where there is more room.Ensure that any directories that are symbolically linked have the correct accessrights.

To display the location of the files associated with your current configuration:

♦ Press MENU on the Configure menu button and drag the pointer to theFile Info item. Release MENU to activate the Current Configurationwindow.This displays the base directories in which the spool and database files arelocated.

Caution – Do not delete the files in your spool directory. Use the “purge”option (see “Purging the Message Queues” on page 156) to remove unwantedmessages completely.

!


2

33

Overview of Configuring YourMessaging System 3

This chapter provides an overview of the steps required to configure a messagetransfer agent (MTA), an X.400 message store, and a Solstice X.400 InternetAdaptor. It also summarizes the steps you should follow to add informationabout remote X.500 directory system agents (DSAs) and third-party or P1 useragents to your messaging system.

Adding Information about Messaging ServersDepending 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.

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


3

Local Message Store Using a Local MTA

The simplest and most common way to install and configure the Solstice X.400Messaging Server is to have your message store user groups served by theMTA on the same system. This configuration is shown in Figure 3-1.

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 YourLocal Messaging Server”.You do not need to add any information in this step that is specific to themessage store.

2. Add remote MTA information to your configuration, as described inChapter 6, “Adding Remote Server Information to Your MessagingSystem”.In this step, you enter P1 MTA address information so that the local andremote MTAs can communicate.

3. Add message store user information to your configuration, as described inChapter 8, “Adding Message Store User Information to Your MessagingSystem”.In this step, you create a message store user group, add information aboutthe users in the group, and define the local MTA as the MTA serving thegroup.

Local MessageTransfer Agent

P1

LocalMessage Store


Messaging Server

User Group

Overview of Configuring Your Messaging System 35

3

Local Message Store Using a Remote MTA

Figure 3-2 shows a message store user group using an MTA running onanother system.

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 inChapter 6, “Adding Remote Server Information to Your MessagingSystem”.In this step, you enter P3 MTA address information so that the messagestore can communicate with the remote server (the remote MTA). You donot need to add any P1 MTA address information.

3. Add message store user information to your configuration, as described inChapter 8, “Adding Message Store User Information to Your MessagingSystem”.In this step, you define the users of the message store, and define a remoteMTA as the MTA serving the group.

4. On the remote system, follow the steps summarized in “Local MTA Usinga Remote Message Store” on page 36.

P3Message

Transfer Agent

LocalMessage Store

User Group

Remote Usersof Local MS


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 youmust define the message store user group on both the remote system and thelocal system.

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 YourLocal Messaging Server”.You do not need to add any information in this step that is specific to themessage store.

2. Add remote message store information to your configuration, as describedin Chapter 6, “Adding Remote Server Information to Your MessagingSystem”.In this step, you enter P3 MS address information so that messages receivedby the local MTA for a message store user can be forwarded to the remotesystem where the message store is located.

3. Add message store user information to your configuration, as described inChapter 8, “Adding Message Store User Information to Your MessagingSystem”.In this step, you define the local users of the remote message store anddefine the remote message store as the message store serving the group.

4. On the remote system, follow the steps summarized in “Local MessageStore Using a Remote MTA” on page 35.

P3Remote

Message StoreLocal MessageTransfer Agent

User Group

Local Usersof Remote MS

Overview of Configuring Your Messaging System 37

3

Adding Information about the Internet Mail AdaptorOnce you have configured your local messaging server, you can configure yourSolstice X.400 Internet Adaptor.

1. Configure your local MTA, as described in Chapter 4, “Configuring YourLocal Messaging Server”.

2. Configure the Internet Adaptor as described in Chapter 11, “Configuringthe Solstice X.400 Internet Adaptor”.

Adding Information about User Agents and DSAsBelow is a summary of the steps you should follow to configure the SolsticeX.400 Messaging Server for X.500 directory system agents (DSAs), andthird-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 yourmessaging system.You can develop your own user agents and P1 user agents (using theSunLink 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, ifrequired.When you add agents to the messaging system, default entries are made inthe local routing table; however, you may need to modify these entries toimprove the granularity of the routing algorithm. Refer to Chapter 10,“Routing Between Messaging Components” for detailed instructions.


3

Part 2 — Configuring Your MessagingServer

This part has seven chapters:

• Chapter 4, “Configuring Your Local Messaging Server,” describes how touse x400tool to set up your local MTA and message store.

• Chapter 5, “Tuning Your Local Messaging Server,” describes how to usex400tool to tune your local MTA and message store.

• Chapter 6, “Adding Remote Server Information to Your MessagingSystem,” describes how to use x400tool to add remote MTAs, messagestores, and DSAs to your messaging system.

• Chapter 7, “Testing and Tuning Connections to a Remote MTA,” describeshow to test and tune remote server associations. It also describes how toconfigure routes to remote MTAs manually.

• Chapter 8, “Adding Message Store User Information to Your MessagingSystem,” describes how to use x400tool to add information about users ofyour message store.

• Chapter 9, “Adding Third-Party Agents to Your Messaging System,”describes how to use x400tool to add third-party user agents (UAs) andP1 agents to your messaging system.

• Chapter 10, “Routing Between Messaging Components,” describes how touse x400tool to modify the default routing tables to handle complexrouting between components in your messaging system.

41

Configuring Your LocalMessaging Server 4

This chapter describes how to use x400tool to name your local messagingserver (the local MTA and local message store) and to specify the globaldomain identifier for your local MTA. It assumes that you have already startedx400tool . Refer to Chapter 2, “Starting and Using x400tool” for detailedinstructions.

When you start x400tool for the first time, your messaging system mapshows an icon representing an unconfigured local messaging server. You mustadd information for your own local MTA and message store.

Specifying Your Local Server Name page 42

Setting an Access Control Password page 42

Specifying Your Global Domain Identifier page 44


4

Specifying Your Local Server NameThe local server name is used to identify the local MTA and message store. Inthe case of an MTA, it is the name on which remote MTAs base the acceptanceof an association request if access control is enabled. It is not part of the X.400address and is not used for routing messages.

You must give this name to other system administrators who want to add your localserver to their messaging systems.

To specify your local server name:

1. Double-click SELECT on the local server icon to activate the Local ServerConfiguration 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 PasswordThe access control mechanism is used to verify the source of a message. Itdepends 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 isenabled. See “Enabling and Disabling Access Control for a Remote MTA” onpage 68 for detailed instructions.

• The local MTA configuration determines what is transmitted when accesscontrol is enabled. Access control can be based on the name of the initiatingMTA only, or on the name and password of the initiating MTA.

• The access control algorithm is summarized in Table 4-1. Note that thisalgorithm can be further modified by setting the advanced securityparameters discussed in “Tuning the Security Options” on page 54.

Configuring Your Local Messaging Server 43

4

By default, the local MTA access control is set OFF. Passwords must not containmore than 62 characters. If you do not set a password, a null password istransmitted.

You must give this password to other system administrators who want to add yourlocal MTA to their messaging systems.

To set your access control password:

♦ From the Local Server Configuration window, click SELECT to disable orenable access restrictions, and enter a password (if required).If you set a password, it will be sent to all remote MTAs that have accesscontrol enabled.

Figure 4-1 Setting an Access Control Password for the Local MTA

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

Type passwordClick SELECT


4

Specifying Your Global Domain IdentifierThe global domain identifier locates your local MTA within the global X.400domain. It consists of a country code, an ADMD, and an optional PRMD. Referto “X.400 Management Domains” on page 6 for a more detailed description ofthe global domain identifier.

You must give this global domain identifier to other system administrators who wantto 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 domainidentifier for your local MTA as shown in Figure 4-2.

• Type a country code and ADMD. If necessary use the domain help to locatethis information. If your local MTA does not require an ADMD in its X.400address, 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.

Figure 4-2 Specifying the Global Domain Identifier for the Local MTA

Use the Domain Helpto identify the countrycode and ADMD

45

Tuning Your LocalMessaging Server 5

This chapter describes how to use x400tool to set advanced local serverconfiguration features. It assumes that you have already set up your localserver, as described in Chapter 4, “Configuring Your Local Messaging Server”.

Note – Tuning your local messaging server is optional; your local servershould operate correctly using the default values.

The advanced configuration options for your local server are used to define therelationship between the local server and the remote MTAs in the localmessaging system. In particular, they are used to set the thresholds at whichcertain events occur.

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


5

Tuning AssociationsAn association is like a link between two MTAs. Once an association isestablished, it is maintained until either there are no more messages waiting tobe exchanged between the two MTAs, or one of the predefined thresholds isreached.

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 ofcurrent associations approaches this limit, the local MTA enters a shortagecondition.

Your local MTA reacts to a shortage condition by trying to share its resourcesequally between the other components in the messaging system as shown inFigure 5-1. During a shortage condition, the local MTA closes associationsautomatically when the sent data or sent messages thresholds are reached.

Figure 5-1 Resource Sharing During a Shortage Condition

The association is releasedautomatically in order toservice other agents

Tuning Your Local Messaging Server 47

5

To modify the behavior of associations between your local MTA and theremote MTAs in your messaging system, follow these steps:

1. Double-click SELECT on the local Server icon to activate the Local ServerConfiguration window.

2. Click SELECT on the MTA Tuning... button.

3. Press and drag MENU on the Tuning pull-down menu, and release MENUover the Association item.

4. Press and drag SELECT on the sliders to change the thresholds andtime-outs as shown in Figure 5-2.You can also type the values directly on the input line for each option.

Figure 5-2 Tuning the Association Thresholds

Drag SELECT on the slider

Type the valueon the input lineand press Return


5

Sent Data Threshold: Defines the maximum quantity (in multiples of 10Kbytes) of data sent over a single association before the association is closedautomatically. This threshold is applied only when there is a high demand forassociations (shortage condition).

Sent Message Threshold: Defines the maximum number of messages sent overa single association before the association is closed automatically. Thisthreshold is applied only when there is a high demand for associations(shortage condition).

Retry Connection Timeout: Defines the delay between a failed associationattempt and the next retry.

Idle Association Timeout: Defines the maximum amount of time that anassociation is allowed to remain idle (no messages transmitted) before theassociation is closed automatically.

Recovery Attempts Delay: Defines the delay between a failed messagedelivery attempt and the start of the recovery process initiated by the localMTA (outgoing messages).

Association Retention Timeout: Defines the maximum delay permittedbetween a failed message delivery attempt and the start of the recovery processinitiated by the remote MTA (incoming messages).

Once you have finished tuning the basic association options described in thissection, 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 themessaging system. Messages that are waiting to be sent to a remote MTA areplaced in one of its queues according to the priority (non-urgent, normal, orurgent) assigned in the message header. (See “Defining a Custom MailHeader” on page 135 for instructions on assigning the priority to a messageusing mailtool .)

The Other Options are used to define the conditions under which the localMTA will open another association with a remote MTA. For outgoingmessages, the local MTA bases its decision on the number of messages in eachqueue and the time that messages have spent in the queue.


5

You can also define the algorithm used to determine the priority assigned to aremote MTA when it requests an association for an incoming message. Whenthe local MTA receives a number of simultaneous association requests itaccepts the request from the remote MTA with the highest priority first.

1. From the Association Tuning window, click SELECT on the OtherOptions... button.

2. Press and drag SELECT on the sliders to change the thresholds and theMTA priority as required.You can also type the values directly on the input line for each option. Inthis 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 thenumber 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 waitingin the urgent (high-priority) queue before an association is opened with theremote MTA.

Normal Messages: Defines the total number of messages that must be waitingin the normal (unspecified-priority) queue before an association is opened withthe remote MTA.

Non-Urgent Messages: Defines the total number of messages that must bewaiting in the non-urgent (low-priority) queue before an association is openedwith the remote MTA.

Total Number of Messages: Defines the total number of messages that must bewaiting in all three queues (urgent, normal, and non-urgent) before anassociation is opened with the remote MTA.


5

Figure 5-4 shows the default values assigned to thresholds based on the timespent 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 inthis 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 beforean 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) queuebefore an association is opened.

Non-Urgent Queue Stay-Time: Defines the maximum time (stay-time X timerunit) that messages are allowed to spend in the non-urgent (low-priority)queue before an association is opened.


5

Figure 5-5 shows the default values assigned to options which determine thepriority of remote MTA associations:

Figure 5-5 Remote MTA Association Priority

These options define the relative importance of the factors used to determinethe priority assigned to a remote MTA when it requests an association. Threefactors are considered:

Number of Messages: Defines the multiplier applied to the number ofmessages waiting in the queue.

Size of Messages: Defines the multiplier applied to the size of the messageswaiting in the queue.

Time Spent in Queue: Defines the multiplier applied to the time messageshave spent in the queue.

Once you have finished tuning the Other association options described in thissection, apply your configuration by clicking SELECT on the Apply button.


5

Tuning the Reliable Transfer ServiceThe reliable transfer service (RTS) is used to ensure the safe delivery ofmessages. To tune the reliable transfer service:



3. Press and drag MENU on the Tuning pull-down menu, and release MENUover 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


5

RTS Inactivity Timeout: Defines the maximum delay allowed between theopening of an association and the start of activity. If no activity occurs withinthis specified delay, the association is closed automatically.

Initiator Checkpoint Size: Defines the checkpoint size proposed by your localMTA for outgoing messages. Regular synchronization marks (or checkpoints)are normally sent during message transmission. This allows the RTS to recoverbroken messages from the last checkpoint received. The checkpoint size (theamount of data sent between checkpoints) is a negotiated parameter proposedby the association initiator.

Acceptor Checkpoint Size (if proposed=0): Defines the checkpoint size forincoming 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 notuse synchronization.

• If you set this value to >0, your local MTA will propose this checkpoint sizeto the remote MTA. The remote MTA may choose to reject the proposal.

Acceptor Checkpoint Size (if proposed>0): Defines the maximum checkpointsize for incoming messages accepted by your local MTA. The checkpoint sizeproposed 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 minorcheckpoints.

Required Session Version: Defines the session layer protocol version requiredby the local MTA for all incoming messages. This may be version 1 only, orboth version 1 and 2. For sessions with a remote 1988 system, you should setthis option to both version 1 and 2.

Once you have finished tuning the Reliable Transfer Service options describedin this section, apply your configuration by clicking SELECT on the Applybutton.


5

Tuning the Security OptionsThe security options are used to modify the basic access control mechanism.Refer to “Setting an Access Control Password” on page 42 and “Enabling andDisabling Access Control for a Remote MTA” on page 68 for detailedinstructions on enabling and disabling access control for each remote MTA.

To tune the security options:



3. Press and drag MENU on the Tuning pull-down menu, and release MENUon the Security item.

4. Press and drag MENU on the MTA connection validation pull-downmenu and release MENU over the desired validation system as shown inFigure 5-7.This option determines which elements the local MTA uses to check thesource of incoming messages during the association negotiation phase. Thelocal 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 OSIaddress elements.

Figure 5-7 Setting the MTA Connection Validation

Drag and release MENU


5

5. Click SELECT on the check boxes to define the restrictions placed uponthe originator/recipient (O/R name) that identifies the user agent that sentthe incoming message.When a message is submitted by a user agent, the local MTA verifies theoriginator O/R address and applies the routing algorithm defined by theentries in its routing table.

• If you check “must be local” the originator O/R address must match anentry in the routing table used by the local MTA, and this entry must pointto a local user agent.

• If you check “must belong to requesting agent” the originator O/R addressmust match an entry in the routing table used by the local MTA. Thematching entry must be associated with the user agent that submitted themessage.

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.

Click SELECT


5

Tuning the Remote Operations ServiceThe Remote Operation Service Element (ROSE) is a request-reply protocol usedby 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 eachexchange of information, ROSE creates a queue to store these OPDUs. This actsas a buffer for the application entity. When the application entity finishesprocessing an OPDU, it reads the next OPDU from the queue.

ROSE has several configurable parameters. The default value for eachparameter is usually sufficient for ROSE to work efficiently. However, you maydecide to fine-tune the ROSE parameters, depending on your particularenvironment.

To tune ROSE:


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 MENUon the Remote Operations Service item.

4. Press and drag SELECT on the sliders to change the ROSE parameters asshown in Figure 5-9 on page 57.You can also type the values directly on the input line for each option. Inthis case, you must press Return to enter each typed value into the database.

ROSE Flow Control OptionsWindow Size: Defines the initial number of OPDUs that can be exchangedbetween application entities.

Receive Queue Size: Defines the maximum number of OPDUs that ROSE canstore in each incoming queue.

Ready Timer: Sets the time that ROSE waits for a reply after it sends a requestto an application entity.


5

ROSE Recovery OptionsThese parameters are included for possible future use.

ROSE Resource Management OptionsDefault Block Size: Defines the maximum size of data that ROSE transmits ina block. This is only used if the block size is not defined elsewhere.

Memory Data Size: Defines the maximum amount of message data ROSEstores in memory. If the amount of data is greater than this size, ROSE savesthe data in a file. Specify a value of 0 to force ROSE to save in files all the datait 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.


5

Tuning the Session LayerThe session layer manages and synchronizes communication betweenend-users. If there is a problem with either the originator or the recipient, thesession layer uses its synchronization points to determine from where it shouldresume the data exchange. You can tune session layer parameters to changehow the session entity deals with data received or sent.

To tune the session layer:


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 MENUon the Session item.

4. Modify the session layer options as shown in Figure 5-10.

Figure 5-10 Tuning the Session Layer


5

Session Connection Timer OptionsTimeout: Defines the time (in seconds) during which a session connection canwait for an accept, after which the connection aborts.

Initiator Reuse Timeout: If the transport connection can be reused (accordingto the outcome of the Propose Reuse of TC protocol negotiation), when thetimeout between the termination of a session connection and the initiation ofanother session connection expires, the associated transport connection isterminated. This timeout specifies how long to maintain the transportconnection open after the associated session connection is closed, if theconnection was initiated locally.

Acceptor Reuse Timeout: If the transport connection can be reused (accordingto the outcome of the Propose Reuse of TC protocol negotiation), when thetimeout between the termination of a session connection and the initiation ofanother session connection expires, the associated transport connection isterminated. This timeout specifies how long to maintain the transportconnection open after the associated session connection is closed, if theconnection was initiated remotely.

Protocol OptionsClick SELECT on the checkboxes to switch the following protocol options on oroff:

Version 1: Specifies length restrictions on PDUs.

Version 2: Specifies no length restriction for PDUs.

Extended Concatenation: Allows the extended concatenation of PDUs andTPDUs.

Accept Reuse of TC: Accepts the reuse of a transport connection (TC) whenproposed by the remote system.

Attempt Reuse of TC: Proposes to the peer session entity that the transportconnection should be used again after the specified timeout. If the peer sessionentity accepts, the transport connection can be reused. If you choose thisoption, make sure that the Accept Reuse of TC is also set on.


5

Try to Reuse TC: Specifies that new connection requests can attempt to reuse atransport connection to the peer session entity. If you choose this option, makesure that the Propose Reuse of TC is also set on. The peer session entity mustalso allow reuse of transport connections. Ensure that the Accept Reuse of TCand Propose Reuse of TC are both selected if you choose this option.

Include SSAP-ID: Adds the session service access point identifier to the ACSPDU (Session layer Protocol Data Unit Accept PDU).

Use TRS Expedited: Specifies that the Transport Expedited Data serviceshould be used if it is available.

Functional Unit OptionsThe functional unit options are for debugging purposes. The default is that allfunctional units are supported by the local session entity. These can beoverridden by negotiated values. These options do not normally need to beupdated.

Once you have finished tuning the session options described in this section,apply your configuration by clicking SELECT on the Apply button.


5

Setting the Type of Report Requested by Outgoing MessagesYou can set the types of reports that may be requested by a user agent whensending messages to the local MTA.

There are three types of reports that may be requested by a user agent whensending 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. Traceinformation for the delivered message is also requested.



3. Press and drag MENU on the Tuning pull-down menu, and release MENUover the Other item.

4. Press and drag MENU on the Report Request pull-down menu and releaseMENU to define the type of report requested by outgoing messages asshown in Figure 5-11.

Figure 5-11 Defining the Report Request

Drag and release MENU


5

Tuning the MTA Timer ToleranceThe MTA timer tolerance (error margin) is applied to all timer values checkedby the local MTA—for example, trace information. Altering this parameter canhelp accommodate problems that occur when MTAs have their clock or timezone set incorrectly. Messages that claim to have been sent before they arrivedare normally rejected as errors; however, you can increase the tolerance withinwhich 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 theType of Report Requested by Outgoing Messages” on page 61.

2. Drag SELECT on the slider (or type in the value on the input line) todefine the Time Tolerance as shown in Figure 5-12.

Figure 5-12 Defining the Timer Tolerance

Tuning Congestion ThresholdsCongestion thresholds determine the disk space thresholds at which your localMTA passes from normal to critical to congested state. Depending on theamount of space remaining in your spool file system, your local MTA mayrefuse to accept further incoming messages.

To tune the congestion thresholds:


2. Click SELECT on the increment/decrement buttons (or type the value onthe input line) to define the congestion thresholds as shown in Figure 5-13on page 63.

Drag SELECT


5

Figure 5-13 Tuning the Congestion Thresholds

Normal to Critical: Defines the disk space threshold (in Kbytes) at whichyour local MTA passes from a normal to a critical state. If you have less thanthis amount of disk space left in your spool file system, the situation isconsidered critical and the local MTA will limit the amount of incomingdata.

Critical to Congested: Defines the disk space threshold (in Kbytes) at whichyour local MTA passes from a critical to a congested state. If you have lessthan this amount of disk space left in your spool file system, the situation isconsidered congested and the local MTA will refuse all incoming data.

Back to Normal: Defines the disk space threshold (in Kbytes) at which yourlocal MTA passes from a critical or congested state, and returns to a normalstate. You must have at least this amount of disk space left in your spool filesystem before your local MTA will lift the restrictions placed on incomingdata.

When specifying values for these parameters, the relationship between thethree thresholds should be:

Back to Normal > Normal to Critical > Critical to Congested

Current Congestion State: Displays the current state of your spool filesystem.• 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.

Click SELECT


5

Enabling Message TrackingYour local MTA generates billing information each time a message isprocessed. This information is stored temporarily, before being overwritten bylater billing information. Message tracking lets you keep a permanent record ofeach 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/x400billsdirectory and translated into a text file. You can then, for example, read thisinformation into a spreadsheet application and use it to calculate a charge (orbill) for your users.

For more information on billing information and message tracking, see theREADME file in the /opt/SUNWconn/mhs/examples/billing directory.

To enable or disable message tracking:


2. Click SELECT on the Message Tracking On or Off button.By default, message tracking is off.

65

Adding Remote Server Informationto Your Messaging System 6

This chapter describes how to use x400tool to add information about remotemessaging servers to your local messaging system. A remote server can be aremote message transfer agent (MTA), a remote message store, or both aremote MTA and message store. This chapter also describes how to addinformation about a remote X.500 directory system agent (DSA).

This chapter assumes that you have already configured your local messagingserver as described in Chapter 4, “Configuring Your Local Messaging Server”.Your local server can only communicate directly with remote servers that areadded to your local messaging system.

You must obtain information about the remote MTA or message store from the systemadministrator who set it up.

Adding or Changing Information About a Remote Messaging Server page 66

Adding Information About an X.500 DSA page 73


6

Adding or Changing Information About a Remote Messaging ServerTo add or change information about a remote MTA or message store to yourmessaging 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 Agentsubmenu.

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 inFigure 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 inFigure 6-1 on page 67.

3. Enter or change information about the remote server as described in thefollowing subsections:

Note – Some of this information is not required, depending on whether theremote server includes an MTA.

Once you have completed the steps described in this section, apply yourremote server configuration by clicking SELECT on the Apply button. Thisadds the remote server to your messaging system and adds a default route tothe routing table used by the local server (provided an identical route does notexist). The default route is based on the global domain identifier for the remoteserver. See “Configuring Routes to a Remote MTA” on page 80 for moreinformation.

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

Adding Remote Server Information to Your Messaging System 67

6

Specifying a Name and Type for the Remote Server

The remote server name identifies it within your messaging system. It is notpart of the X.400 address and is not used for routing messages.

1. From the Remote Server Configuration window, type a name for thisremote server on the Name input line.The name you use must be unique within your configuration. You cannotmodify this name once your configuration is applied.

2. Click SELECT on the Server Type buttons to specify whether the server isan MTA, a message store, or both an MTA and a message store.

Figure 6-1 Remote Server Configuration Window


6

Enabling and Disabling Access Control for a Remote MTA

The access control mechanism depends on the configuration of both the localand remote MTA:

• The remote MTA configuration determines whether access control isenabled for that MTA. The system administrator responsible for the remote MTAmust also enable access control and provide you with its password, if access controlis required.

• The local MTA configuration determines what is transmitted when remoteaccess control is enabled. Access control can be based on the name of theinitiating MTA only, or on the name and password of the initiating MTA.(Refer to “Setting an Access Control Password” on page 42 for detailedinstructions on setting the password for your local MTA.)

The access control algorithm is summarized in Table 6-1. Note that thealgorithm can be modified by setting the advanced security parametersdiscussed in “Tuning the Security Options” on page 54.

Note – If you enable access control for a remote MTA, you must obtain itspassword from the system administrator who set it up.

♦ From the Remote Server Configuration window, click SELECT on theAccess Control buttons to disable or enable access restriction, and enter apassword (if required).This is the password that the local MTA must receive from the remote MTAbefore it will accept an association for an incoming message.

Table 6-1 Access Control Algorithm

Remote MTA Access Control

Access control OFF Access control DISABLED

Access control ON Access control ENABLED


6

Specifying the Global Domain Identifier of a Remote MTA

The global domain identifier identifies the remote MTA within the global X.400domain. It consists of a country code, an ADMD, and an optional PRMD. Referto “X.400 Management Domains” on page 6 for a more detailed description ofthe global domain identifier. You do not need to specify a global domainidentifier when the remote server is a message store.

You must obtain the global domain identifier for the remote MTA from the systemadministrator who set it up.

♦ From the Remote Server Configuration window, enter the global domainidentifier 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 notrequire an ADMD, then insert a space.

• Type your PRMD on the input line. If the remote server is not part of aPRMD, you can leave a null PRMD entry. Do not insert a blank space.

Figure 6-2 Specifying the Global Domain Identifier for a Remote MTA



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 1992version of the X.400 recommendations; however, it can exchange messageswith systems that comply to previous versions.

• Choose 1984 X.400 Version Support if the remote MTA complies to the 1984version. This disables the input line for the OSI presentation selector. This isthe default option.

• Choose 1988 X.400 Version Support if the remote MTA complies to the 1988or 1992 version. This is the case if the remote MTA is running a SolsticeX.400. This enables the input line for the OSI presentation selector and theability to select the Reliable Transfer Service version.

To choose the X.400 Version Support:

♦ From the Remote Server Configuration window, click SELECT on 1984 or1988 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 numberof associations will also change accordingly, if you have not previously alteredthem. You should verify that the number of associations is correct for yourchosen supported X.400 version. (See “Tuning the Remote MTA AssociationOptions” 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 toa remote MTA. The RTS 1984 version interfaces directly with the session layer,whilst RTS 1988 interfaces with the presentation layer. You will not normallyneed to change the default option. Check with your remote systemadministrator for the version of RTS. To select the RTS version:

♦ From the Remote Server Configuration window, click SELECT on 1984 or1988 to select the Reliable Transfer Service Version.If you have selected 1984 X.400 version support, you cannot change thisoption.


6

Specifying the OSI Address of the Remote Server

Your local messaging server uses an OSI address to reach the remote serveracross the OSI network. If you have a message store that is served by a remoteMTA, then the message store also uses the OSI address to reach the MTA. TheOSI address of an MTA or message store depends on how the remote server isphysically attached to the OSI network.

You must obtain the OSI address for a remote server from the system administratorwho set it up.

A remote server can be attached to the OSI network through the followingnetwork 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 remoteserver indicating the transport layer connection.

If the remote server uses different OSI addresses for incoming and outgoingmessages you must create two remote servers in your messaging system. Yourlocal MTA and message store will send messages to one remote server andreceive messages from the other.

Depending on how you want to configure your messaging system to usemessage stores, you may need to enter more than one OSI address. Use thetable below to determine which types of OSI address are valid. Refer to“Adding Information about Messaging Servers” on page 33 for moreinformation 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 localmessage store user group

Message Store only P3 MS Address

MTA and MS Any combination


6

To enter the components of the OSI address for a remote server:

1. From the Remote Server Configuration window, enter the required OSIaddresses.• 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 ofnetwork 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) orin hexadecimal format (hex).

4. Enter each layer of the OSI address.You must obtain the OSI address for the remote server from the systemadministrator who set it up.

• For an OSI address for an X.25 interface, type the entire X.25 addressincluding the subaddress (without any internal prefixes) on the networkaddress 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 incharacter or hexadecimal.

• For an OSI address for a TCP/IP (RFC 1006) interface, you can enter eitherthe network address in Internet format (dot notation) on the networkaddress input line, or the host name that corresponds to this address onthe host name input line. The network address is recovered from the NISmap using gethostbyname(3N) .

5. Optionally, if the remote server is an MTA and the machine on which itresides 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 isunreachable via the first address.


6

Adding Information About an X.500 DSAUsing x400tool , you can add information about an X.500 directory systemagent (DSA) to your messaging system. Refer to “X.400 Use of X.500 DirectoryServices” on page 20 for more information on DSAs.

If there is a configured Solstice DSA or Solstice DUA installed on the samesystem as your messaging server, you can use x400tool to importinformation about the Directory Service into your messaging system.

1. Double-click SELECT on the Directory icon to activate the RemoteDirectory (X.500) Access window as shown in Figure 6-3.

Figure 6-3 Remote Directory (X.500) Window


6

2. Click SELECT on Import Configuration.x400tool reads configuration information from the Solstice DUA or DSAand 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 yourmessaging server, you can enter remote DSA information manually:

1. Double-click SELECT on the Directory icon to activate the RemoteDirectory (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 thePassword 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, ifrequired.These are relative distinguished names. Include both the attribute type andvalue. You must obtain them from the system administrator who set up theremote DSA.

6. Drag MENU on the network type pull-down menu to choose the type ofnetwork 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) orin hexadecimal format (hex).

8. Enter each layer of the OSI address.See “Specifying the OSI Address of the Remote Server” on page 71. Youmust obtain the OSI address for the remote DSA from the systemadministrator who set it up.

9. Click SELECT on Apply.

75

Testing and Tuning Connections to aRemote MTA 7

This chapter describes how to use x400tool to tune and test remote MTAassociations. It also describes how to manually configure routes to remoteMTAs.

This chapter assumes that you have already set up a remote server asdescribed in Chapter 6, “Adding Remote Server Information to YourMessaging System”.

Tuning the Remote MTA Association Options page 76

Testing an MTA Association page 77

Configuring Routes to a Remote MTA page 80


7

Tuning the Remote MTA Association OptionsThe remote MTA Association Management parameters are used to restrict thenumber of simultaneous associations that are created between your local MTAand the remote MTA.

1. Double-click SELECT on the remote server icon to activate the RemoteServer Configuration window.

2. Click SELECT on the Associations button to activate the Remote MTAAssociations 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 0 1 0 1

1988 1 0 1 0

Testing and Tuning Connections to a Remote MTA 77

7

Remote MTA Association Management OptionsMax. Local Associations: Defines the maximum number of simultaneousassociations that your local MTA can open with the remote MTA (associationinitiated by the local MTA). Note that Two Way associations have priority overMonologue associations.

• Two way: Defines the maximum number of simultaneous associations thatyour local MTA can open with the remote MTA to send and receivemessages.

• Monologue: Defines the maximum number of simultaneous associationsthat your local MTA can open with the remote MTA to send messages only.

Max. Remote Associations: Defines the maximum number of simultaneousassociations that the remote MTA can open with your local MTA (associationinitiated by the remote MTA). Note that Two Way associations have priorityover Monologue associations.

• Two way: Defines the maximum number of simultaneous associations thatthe remote MTA can open with your local MTA to send and receivemessages.

• Monologue: Defines the maximum number of simultaneous associationsthat 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 selectionson the Remote MTA window to confirm the overall configuration.

Testing an MTA AssociationOnce you add a remote MTA to your messaging system, you can test theconfiguration with the trigger option. This tests whether your local MTA canreach the remote MTA across the OSI network. It does not test whetherelectronic messages are correctly routed to this MTA or whether they can bedelivered 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 asa local MTA (local server) in the remote messaging system to which itbelongs.


7

• The local MTA defined in your local messaging system must be defined as aremote MTA (remote server) in the remote messaging system. It does nothave to be open to respond to the trigger.

• The access control parameters must be set coherently between the local andremote MTAs in both messaging systems.

• The remote MTA must be open. Highlight the remote MTA, press MENU onthe 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 wantto test.

2. Press MENU on the Test menu button and drag the pointer to the Triggeritem. Release MENU to activate the Trigger Remote MTA window.

3. Click SELECT on the Trigger button to test the association between yourlocal MTA and the remote MTA as shown in Figure 7-2.

Figure 7-2 Using the Trigger

If the trigger is successful, the local MTA will open an association with theremote MTA and the current connection state will change to connected. Thisshows that the remote MTA is configured correctly and will be able to receiveelectronic messages from your local MTA.

The association remains open for the time specified by the Idle AssociationTimeout for your local MTA. By default, this is one minute. (Refer to “TuningAssociations” on page 46 for detailed instructions on how to alter this delay.)

Remote MTA name

Local MTA name


7

If the trigger is unsuccessful, the current connection state is marked as eitherdisconnected 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 remoteMTA is closed. It must be reopened before you can try another trigger attempt.Refer to “Displaying Status Information” on page 143 for detailed instructionson how to reopen a closed MTA.

Figure 7-3 Unsuccessful Trigger Attempt

The probable cause of the unsuccessful trigger attempt is shown in the statusbar at the bottom of the window. The most common causes of a failed triggerare:

Remote MTA refuses connection: This occurs if there is a problem with theaccess control mechanism (for example, passwords not set correctly) or if yourlocal MTA is not included in the remote messaging system configuration.

Remote OSI address invalid: The local MTA was unable to reach the specifiedremote MTA with the OSI address elements provided. Check that you enteredthe correct OSI address. Use osi_trace to examine the connection attempt.

Connection state afteran unsuccessful trigger


7

Configuring Routes to a Remote MTAWhen you add a remote MTA to your messaging system, x400tool attemptsto create a default entry in the local routing table. This table is used by yourlocal MTA to determine the forwarding address for each message that itreceives. The default route for the remote MTA is based upon its global domainidentifier.

If x400tool cannot create a default route (because, for example, an identicalroute already exists in the routing table) you will have to modify the routingtable to add an entry that improves the granularity of the routing mechanism.

For example, if two remote MTAs are defined with the same global domainidentifier, the local MTA will not create a default route for the second one. Youmust create a new entry in the routing table and add a discriminating attribute(for example, organization name, organizational unit name) to the route so thatyour local MTA can forward messages correctly to both systems.

Refer to Chapter 10, “Routing Between Messaging Components” for detailedinstructions 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 MTAuses it as the destination for all messages that it fails to route based on theentries in its routing table. This mechanism works efficiently for X.121addresses 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 otherMTAs in the messaging system that route messages based on the organizationname 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 systemthat includes a remote MTA with the route/C=FR/A=ATLAS/P=CORP/O=MKTG/, you must ensure that the default MTAhas 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 onan X.121 address only. The remote MTA that you choose for the default MTAmust support routing decisions based on the X.121 address.


7

You can choose any of the remote MTAs in your messaging system as thedefault MTA. Ideally, the default MTA should point to a public X.400 providersince they maintain comprehensive and up-to-date routing tables that increasethe 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 youwant as your default MTA.

2. Press MENU on the Configure menu button and drag the pointer to theDefault MTA item.

3. Activate the submenu and choose Set to configure the remote MTA as thedefault MTA.

Note – If you change the configuration of a default MTA, such that it is nolonger the default MTA, it will route messages as normal. That is, messagesthat match its default route will continue to be routed through it.


7

83

Adding Message Store UserInformation to Your MessagingSystem 8

This chapter describes how to use x400tool to add information aboutmessage store users. It assumes that you have already set up a local or remotemessage transfer agent (MTA).

See “The Solstice X.400 Message Store” on page 14 for a description of how themessage store works.

Creating a Message Store User GroupFor a minimum message store configuration you must create at least onemessage 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 hasparameters that are common to all users of that group. For example, they sharethe same organizational attributes, geographical attributes, serving MTA, andserving message store.

Creating a Message Store User Group page 83

Configuring Message Store User Information page 86


8

To create a message store user group:

1. Press MENU on the Configure menu button and drag the pointer todisplay the New Agent submenu. Release MENU over MS Users Group.The MS Users Group Configuration window is displayed, as shown inFigure 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 isnot used for routing messages.

Adding Message Store User Information to Your Messaging System 85

8

3. Press and drag MENU on the X.400 O/R Address Type pull-down menuand release it to define the type of X.400 address.See “Representing O/R Addresses” on page 9 for information on the typesof X.400 address.

4. Enter the global domain identifier for the message store as shown inFigure 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 ADMDin 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 aPRMD, 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 anyorganizational attributes.

6. If necessary, click SELECT on Body and Contents to change the supportedbody and content types.In most cases, you will not need to change the default settings. By default, amessage 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 theStandard Content Types Supported” on page 94.

7. If necessary, click SELECT on Alternate Recipient to define an alternaterecipient address.See “Specifying Alternate Recipients” on page 104 for information on howto specify an alternate recipient for a message store user group.

8. If you are adding users of a remote message store, click SELECT on themessage store that this group is served by in the Message Storesscrolling-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 theMTAs scrolling-list.If the message store is served by a remote MTA, you must have alreadyentered a P3 MTA address. See Chapter 6, “Adding Remote ServerInformation to Your Messaging System”.

Before you can apply the message store user group, you must add at least onemessage store user.


8

Configuring Message Store User InformationFor 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 AddUser.The MS User Configuration window is displayed, as shown in Figure 8-2.

Figure 8-2 Message Store User Configuration Window

The X.400 O/R Addresscomponents you enteredin the group configurationwindow are displayed here

Adding Message Store User Information to Your Messaging System 87

8

2. Type a name and password for the message store user on the User Nameinput 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 mandatorywhile others are conditional. See Table 8-1 for a summary of mandatory (M)and conditional (C) parameters.

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, youcannot change the message store or the MTA serving the group.

5. Click SELECT on Apply to add the message store user group to yourconfiguration.

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,Given Name, Initials, Generation

M n/a n/a

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 C1 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.


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 theMS 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 onpage 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 theMS 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 theDelete Agent item. Release MENU to activate a confirmation window.Deleting a message store user group will also delete all message store userscontained in that group.

89

Adding Third-Party Agents to YourMessaging System 9

This chapter describes how to add local or remote user agents (UAs) and X.400MT (P1) users (for example, message gateways) to your messaging system. Itassumes 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 AgentsUser 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.400Messaging Server; however, you can add a third-party UA to your messagingsystem by giving it an identifying name and specifying the body types andcontents that it uses.

Refer to the Solstice X.400 Programming Reference Manual for detailedinformation regarding the development of X.400-compatible user agents andX.400 MT (P1) users using the Message Access (MA) and Message Transfer(MT) interfaces.

Adding and Configuring Third-Party User Agents page 89

Adding and Configuring X.400 MT (P1) Agents page 96


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 Agentsubmenu.

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

Adding Third-Party Agents to Your Messaging System 91

9

Specifying the User Agent Name and Type

The user agent name identifies the user agent within your messaging system. Itis 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 connectedthrough the XAPIA MA interface directly to the local MTA. A remote UA isconnected 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 obtainone from other suppliers.

1. Double click SELECT on the user agent icon to activate the User AgentConfiguration 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 applyyour configuration. You cannot modify this name once it is applied.

3. Click SELECT on the User Agent Type buttons to specify whether the UAis local or remote.If you specify a remote user agent, a User Agent Address window isdisplayed:

a. Enter the OSI address for the remote user agent.The presentation, session and transport selectors should be the same asthose 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 onwhich subnetwork type you select, additional address information isrequired. For example, if you select X.25, you must enter the X.121address, or if you select CONS X.25 1984, you need to enter the NSAPaddress. For a LAN, you can enter the NSAP in character or hexadecimalformat.


9

Enabling and Disabling User Agent Access Control

The access control mechanism is dependent upon the configuration of the boththe user agent and its local server:

• The user agent configuration determines whether access control is enabledfor that UA. If access control is enabled, the local messaging server checksthe identity of the UA sending the message before it will accept theconnection.

• The local server configuration determines what is transmitted when accesscontrol is enabled. Access control can be based on the name of the initiatingagent only, or on the name and password of the initiating agent.

Note that this algorithm can be modified by setting the advanced securityparameters 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 AgentConfiguration window, if it is not already displayed.

2. Click SELECT to disable or enable access restriction, and enter apassword (if required) as shown in Figure 9-2.This is the password that the local server expects to receive from the useragent before it will accept an association for an outgoing message.

Figure 9-2 Enabling and Disabling Access Control for a User Agent

Click SELECT Type password


9

Specifying the Body Types Supported

Body types define the format in which the bodyparts of messages aretransmitted. Bodyparts may be either binary data or text. An undefinedbodypart is treated as binary data. You can prevent the local server fromforwarding bodyparts that the user agent is unable to process by specifying thebody types that the user agent supports.

Note that the body type definition is only relevant if either X.400 1984 (P2) orX.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 AgentConfiguration window, if it is not already displayed.

2. Click SELECT on one or more of the check boxes associated with the bodytypes 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 acceptmessages 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 the1984 revision of the X.400 recommendations.


9

Specifying the Standard Content Types Supported

You can prevent the local server from forwarding messages that the user agentis 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 AgentConfiguration window.

2. Click SELECT on the check boxes associated with the supported standardcontent types that the user agent supports.The possible content types are described in Table 9-2.

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 asaccents. It is the equivalent of the teletext format.

Table 9-2 Standard Content Types Defined by the X.400 Recommendations

Content Type Description

X.400 1984(P2)

Standard content type 2. Indicates that the user agent will accept InterpersonalMessages (used to exchange electronic mail between end-users) conforming to the 1984revision of the X.400 recommendations.

X.400 1988(P22)

Standard content type 22. Indicates that the user agent will accept InterpersonalMessages (used to exchange electronic mail between end-users) conforming to the 1988revision of the X.400 recommendations.

Unidentified Standard content type 0. Indicates that the user agent will accept messages of anunidentified (or unknown) content type. The user agent may or may not be able toprocess the message.

External Standard content type 1. Indicates that the user agent will accept messages whosecontent type is not defined by the X.400 recommendations.

EDI Standard content type 35. Indicates that the user agent will accept EDI messages (usedto exchange billing information between end-users).

Table 9-1 Standard Body Types Defined by the X.400 Recommendations

Body Type Description


9

Specifying the Non-Standard Content Types Supported

You can also specify the non-standard content types (content types not definedby the X.400 recommendations) supported by your third-party user agent.These are used for end-to-end communication between user agents and relyupon 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 AgentConfiguration window.

2. Type a numeric content type identifier on the Value input line as shown inFigure 9-3.The code must be recognized as a content type by the user agent. Its valuemust not correspond to any of the standard content types, or any othernon-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 thescrolling-list.

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 tomodify the routing table used by the local server to add at least one route forthe user agent. Refer to Chapter 10, “Routing Between MessagingComponents” for detailed instructions.

Enter the non-standard

Click SELECT on Add

content type code


9

Adding and Configuring X.400 MT (P1) AgentsAn X.400 MT (P1) agent relies upon the X.400 message transfer (MT) service forthe exchange of electronic messages between X.400-compatible systems.Message transfer agents (MTAs) and message adaptors are typical examples ofX.400 P1 users.

The Solstice X.400 Internet Adaptor is a native P1 user agent; however, you canalso add third-party P1 user agents to your local server configuration. Theseshould be developed using the XAPIA message transfer (MT) interface definedby X/Open. Refer to the Solstice X.400 Programming Reference Manual forfurther details.

Adding a Third-Party P1 Agent

You define a third-party P1 agent by giving it a name and specifying its globaldomain identifier. By default, a new P1 agent is assigned the same globaldomain identifier as the local MTA.

To add a third-party P1 agent to your messaging system:


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 yourmessaging system. It is not part of the X.400 address and is not used forrouting messages; it is used as the client name in the mt_open function of theXAPIA message transfer (MT) interface.

To specify the P1 User name:

1. Double-click SELECT on the P1 user icon to activate the P1 UserConfiguration 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 toapply your configuration. You cannot modify this name once it is applied.


9

Enabling and Disabling P1 User Access Control

The P1 user access control mechanism has the same dependencies as the useragent access control mechanism, as described in “Enabling and Disabling UserAgent 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 UserConfiguration window.

2. Click SELECT to disable or enable access restriction, and enter apassword (if required.This is the password that the local MTA must receive from the P1 userbefore 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 usethe P1 protocol to access the MTA.

• For other applications which do not use XAPIA, you should use themessage queue interface. This architecture reflects that of third party MTAs(non-XAPIA), which use message queues to interface between P1applications and their MTAs. You can specify a maximum of 16 P1 users thatuse the message queue interface.

Note – By default the incoming messages are queued in:/var/SUNWconn/OSIROOT/spool/ p1_username/in_queueand the outgoing messages are queued in:/var/SUNWconn/OSIROOT/spool/ p1_username/out_queueSometimes these message queues can become large and may cause problemsby being in this location. To avoid these problems, create a symbolic linkbetween 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 XAPIAMessage Transfer Interface or Message Queues item, as shown inFigure 9-4.


9

2. Release the MENU button on the appropriate access type.For XAPIA P1 applications, choose the XAPIA Message Transfer Interfaceitem, for access from other types of P1 applications, choose the MessageQueues item.

Figure 9-4 Specifying the Type of P1 Access

3. Press Apply to save the changes and return to the P1 user configurationscreen.

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, anew 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 UserConfiguration window.

2. Enter the global domain identifier for the remote MTA as shown inFigure 9-5.By default, the P1 user is assigned the same global domain identifier as yourlocal MTA. If you need to modify the default global domain identifier:


9

• Type a country code and ADMD. If necessary use the domain help to locatethis information. If your local MTA does not require an ADMD in its X.400address, 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.

Figure 9-5 Specifying the Global Domain Identifier

Once you have completed the basic configuration steps described in thissection, apply your P1 user configuration by clicking SELECT on the Applybutton. This adds the P1 user to your messaging system and adds a defaultroute to the routing table used by the local server (provided an identical routedoes not exist).

Configuring Routes to a P1 Agent

When you add a new P1 user to your messaging system, x400tool attemptsto create a default entry in the local routing table. If x400tool cannot create adefault route, you will have to modify the routing table manually.

For example, if you already have a remote MTA defined with the same globaldomain 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 discriminatingattribute (organization name, organizational unit name, etc.) to the route sothat your local MTA can forward messages correctly to both systems.



Type the PRMDon the input line


9

101

Routing Between MessagingComponents 10

This chapter describes how to use x400tool to modify and test the routingtable used by the local messaging server. It also explains how to add alternaterecipicients for message store user groups, user agents, and P1 agents.

Routing in the X.400 DomainAn MTA functions like a traditional postal service sorting office—sortingmessages for delivery based on their addresses. The MTA compares thecomponent attributes of each O/R address against the entries in its localrouting table. Each entry associates a given list of attributes with one of therecognized components in the messaging system. All messages with an O/Raddress (or part of an O/R address) that matches one of these lists of attributeswill be forwarded to the same destination.

Routing in the X.400 Domain page 101

Default Routing Entries page 103

Specifying Alternate Recipients page 104

Testing the Routing Algorithm page 106


10

The default routing entries for components added to a messaging system arealways based on the global domain identifier. For example, suppose your localmessaging 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 byyour local server with /P=HQ/A=ATLAS/C=FR/ as part of their O/R addresswill 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 withinthe same management domain, they will have the same global domainidentifier. To differentiate between the routing to these components, you mustmodify the routing tables used by your local server.

For example, the MTAs servicing the European headquarters for a companyare all located within the same management domain and have the same globaldomain identifier /P=EUROHQ/A=ATLAS/C=FR/. To differentiate betweenMTAs within the same global domain, the routing algorithm is expanded toinclude the organizational attribute:

Figure 10-1 Example Routing Entries

Messages for members of the sales and marketing groups are relayed throughone MTA; messages for members of the product development or test groupsare relayed through another.

/C=FR/A=ATLAS/P=EUROHQ/O=MKTG/

/C=FR/A=ATLAS/P=EUROHQ/O=PRDEV/

/C=FR/A=ATLAS/P=EUROHQ/O=TEST/

Routing entries for the remote MTAhandling messages for the sales andmarketing groups

Routing entries for the remote MTAhandling messages for the productdevelopment and test groups

/C=FR/A=ATLAS/P=EUROHQ/O=SALES/

Routing Between Messaging Components 103

10

Default Routing EntriesWhen 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. Thedefault route is based upon the global domain identifier for the newcomponent and in many cases this information will be sufficient to allow yourlocal 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 foran identical entry. If one already exists, the default entry is not created andx400tool 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 therouting algorithm.

Modifying the Default Routing Table

The routing table for the local MTA is composed of groups of entries. Eachgroup of entries is associated with one of the components in the localmessaging system.

The Routing window has a scrolling-list that contains the current routingentries 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 thecomponents 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 theModify Routing item. Release MENU to activate the Routing window.

3. If you are modifying an existing routing entry, click SELECT on one ofthe entries in the scrolling-list to highlight it and display its componentattributes.


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 tofind this information, if required. If the component is not part of anestablished ADMD you must enter a blank space.

5. Specify any other attributes that will be used to sort the messages sent tothe selected component.Refer to the description of O/R addresses in “X.400 Addressing” on page 7for 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 localmessaging system.

2. Click SELECT on one of the entries in the scrolling-list to highlight it anddisplay its component attributes.

3. Click SELECT on Delete to remove the selected entry from the scrolling-list.

Specifying Alternate RecipientsYou can define an alternate O/R address for each user agent and message storeuser group in your messaging system. These O/R addresses are used by thelocal server if it cannot route a message to the component defined by the O/Raddress contained in the message.

For example, if the message contains a body part of a type that is notsupported by the user agent specified by the O/R address in the message, thelocal MTA will forward the message to the alternate recipient address if one isdefined.

The alternate recipient is usually a system administrator, or someone chargedwith ensuring that the redirected message reaches its ultimate destination.


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 ModifyRouting 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 GroupConfiguration 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 yourconfiguration.

Figure 10-2 Creating an Alternate Recipients


10

Testing the Routing AlgorithmYou can use x400tool to test the routing algorithm defined by the entries inthe local routing table. This feature does not send any messages; it tells you ifthe local MTA would be able to route a message based on a given O/Raddress.

To test the routing algorithm:

1. Press MENU on the Test menu button and drag the pointer to the TestRouting 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 7for description of the valid O/R address types.

3. Click SELECT to check the box for Use Default MTA, if you want to allowthe local MTA to use the default (“catch-all”) MTA to route messages thatit 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 wantthe local MTA to make use of any alternate recipients you may havedefined.

5. Click SELECT on Test to see if the local MTA is able to route messagescontaining the specified O/R address.

There are three possible results:

Routing Possible: If the local MTA is able to route the message it displays astatus message in the bottom-left corner of the Test Routing window. Thismessage includes the name of the component that would have received themessage, based on the current routing algorithm.

Routing Ambiguous: If the routing algorithm generates an ambiguousresult—for example, if the local MTA is unable to distinguish between twopossible destinations— or if the format of the O/R address is not compliantwith the X.400 specification, x400tool generates an error message. This mayoccur 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 allx400tool generates an error message.


10

Figure 10-3 Testing the Routing Algorithm

Click SELECT totest the routing

Status message indicatesthat routing wouldhave been successful


10

Part 3 — Configuring and Using YourInternet Mail Adaptor

This part has three chapters. You do not need to read this part if you do nothave a license for the Solstice X.400 Internet Adaptor.

• Chapter 11, “Configuring the Solstice X.400 Internet Adaptor,” describeshow to use x400tool to set up a Solstice X.400 Internet Adaptor toexchange electronic messages between the Internet mail domain and theX.400 domain.

• Chapter 12, “Testing and Tuning the Solstice X.400 Internet Adaptor,”describes how to test the configuration of your Solstice X.400 InternetAdaptor. It also describes how to modify mapping tables, how to configureroutes manually, and how to modify the default sendmail configuration file(sendmail.cf )

• Chapter 13, “Sending and Receiving Internet Mail Through the InternetAdaptor,” describes how to use Internet mail applications to send andreceive Internet mail messages through the Solstice X.400 Internet Adaptor.

111

Configuring the Solstice X.400Internet Adaptor 11

This chapter describes how to use x400tool to set up a Solstice X.400 InternetAdaptor to handle the exchange of messages between Internet mailapplications and the X.400 domain. It assumes that you have already set upyour local server as described in Chapter 4, “Configuring Your LocalMessaging Server”.

The Solstice X.400 Internet Adaptor is an optional component of the SolsticeX.400 Messaging Server.

The Solstice X.400 Internet Adaptor is an implementation of RFC1327. It mapsInternet mail (RFC 822) addresses and service elements to equivalent X.400addresses and service elements, and adds any additional information requiredto route messages across the global X.400 domain. Refer to “The Solstice X.400Internet Adaptor” on page 15 for a detailed description of the adaptor and howit works.

Note – In previous versions of Solstice X.400, the Solstice X.400 InternetAdaptor was called the X.400/SMTP Gateway.

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


11

Before You StartBefore you start to configure your Solstice X.400 Internet Adaptor, ensure thatyou have the required software, and determine your local Internet domainaddress.

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 hasa separate license from the Solstice X.400 Messaging Server.

• OpenWindows 3.1 or later, and in particular the file cetables which isused by the Solstice X.400 Internet Adaptor. To check that the file cetablesis available on your machine, type:

• The sendmail daemon. This is used by Internet mail applications such asmail and mailtool . To check that the sendmail daemon is running onyour machine, type:

The sendmail daemon uses the configuration file sendmail.cf . Whenyou install the Solstice X.400 Messaging Server software, this file is modifiedautomatically (using the script gen_sendmail.cf ) to add a default pseudohost name and X.400-specific rules. However, if sendmail.cf does notexist, or if you have a customized version of the file, the modification willfail. Refer to “Modifying the sendmail Configuration File for the InternetAdaptor” on page 130 for instructions of how to use the gen_sendmail.cfscript and how to add the necessary modifications manually.

hostname% ls $OPENWINHOME/lib/cetables/cetables/usr/openwin/lib/cetables/cetables

hostname% ps -ef | grep sendmailpid timestamp /usr/lib/sendmail -bd -q1h

Configuring the Solstice X.400 Internet Adaptor 113

11

Determining Your Internet Domain Address

Your Internet mail domain address is equivalent to an X.400 global domainidentifier. It locates the machine on which your adaptor is running within theglobal Internet mail address space. A typical Internet mail domain name lookslike this:

Your local Internet mail domain address is defined within the sendmailconfiguration file (/etc/mail/sendmail.cf ) located on your mail host (oron 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 onyour network. This is the machine that receives mail from outside your localdomain; it is also the machine that receives mail that the local domain cannotdeliver.

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 firstdelivered to the mail server, and not directly to the client machine.

Refer to your Solaris documentation for a detailed description of thecomponents of an Internet mail system and the addresses used to routemessages between them.

To determine the Internet domain address for your local machine:

• If /var/mail is mounted remotely, determine the name of your mailserver:

If /var/mail is mounted remotely, the mount point displayed with thename of the mail server (mail_server). This is where you will find your localInternet domain address.

Division.Company.COM

hostname% mount | grep spool/tmp_mnt/var/spool/mail on mail_server:/var/spool/mail datestamp


11

• If your /var/mail is located on your own machine, determine the nameof your mail host.

The name of the mail host (mail_host) follows the IP address. This is whereyou will find your local Internet domain address.

• Look for your Internet domain name in the sendmail.cf configurationfile on either your mail server (if your mailbox is mounted remotely) or onyour mail host (if your mailbox is mounted locally).

On machines running Solaris 2.x, this file is /etc/mail/sendmail.cf .

Make a note of the local Internet domain address (local_domain_address) inthe last line of text. You will need to know this when configuring youradaptor.

You can use x400tool to show you how this address is converted to an X.400address in the adaptor (see “Testing the Solstice X.400 Internet Adaptor” onpage 122).

hostname% ypmatch mailhost hosts129.123.123.12 mail_host mailhost

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.COMDm<local_domain_address>


11

Adding Solstice X.400 Internet Adaptor InformationThe Solstice X.400 Internet Adaptor Configuration window (shown inFigure 11-1) is used to define the way in which messages and addresses aremapped between Internet mail and X.400 mail applications. It is also used todefine the Internet domain address and pseudo host name that sendmail usesfor 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 SolsticeX.400 Internet Adaptor Configuration window shown in Figure 11-1.

Figure 11-1 The Solstice X.400 Internet Adaptor Configuration Window


11

2. Drag and release MENU to define the default character set that is used tomap between Internet mail and X.400 mail bodyparts (the content of themessage).The default value is ISO8859-1. Note that the ASCII character set does notsupport international (8-bit) characters. International characters arerepresented by the nearest ASCII (7-bit) character.

3. Drag and release MENU to define the default body type created when amessage that contains international characters is received from Internetmail.Under most circumstances, you should choose the default value of ISO6937as 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 contain8-bit characters, an IA5 (7-bit) body part is created automatically.

4. Enter the local Internet domain address for the adaptor on the Local UNIXMail Domain input line.This is the domain name that you recovered from the sendmail.cf file onyour mail host or mail server. See “Determining Your Internet DomainAddress” on page 113 for detailed instructions.

5. Enter the pseudo host name that will be used to route messages fromInternet mail applications to the adaptor.Use the default pseudo name x400-gate , or enter a new name. The localUNIX mail daemon (sendmail ) will route all messages identified by thepseudo host name to the Solstice X.400 Internet Adaptor.

The pseudo host name must be entered in the /etc/hosts file on your NISserver (or on your local machine if you are not running NIS) as an alias ofthe machine running the adaptor. See “Adding the Pseudo Host Name tothe NIS Database” on page 118 for information on how to do this.

If you modify the default pseudo host name, the change must also beregistered in the sendmail.cf file on your mail host (if /var/mail islocated locally) or on your mail server (if /var/mail is located remotely).


11

6. Click SELECT on the checkboxes to enable or disable the optionalconfiguration parameters.These are described in Table 11-1.

Once you have completed the basic configuration steps described in thissection, apply your Solstice X.400 Internet Adaptor configuration by clickingSELECT on the Apply button.

If you modified the default pseudo host name you will see a message warningyou that you must modify the sendmail.cf file on your local machine. If youdo not authorize x400tool to modify this file, you must edit it manually tochange the pseudo host name for your adaptor. See “Modifying sendmail.cf toAdd a Pseudo Host Name Manually” on page 119 for more information. If youhave a standard sendmail.cf file, then you can usually allow thesendmail.cf file to be changed automatically.

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 bein uppercase. If this option is enabled, the Solstice X.400 Internet Adaptorautomatically converts any lowercase country codes to uppercase characters.

Manage ContentReturn Locally

Preserves the content of failed deliveries. By default, your adaptor requestsnegative-delivery reports and content return for the messages it sends to themessaging system. The negative-delivery report normally contains the content ofthe original message; however, the only way to guarantee this is to set ManageContent Return Locally. This preserves a local copy of an outgoing message untila positive-delivery report is received.Note: This facility can be costly, in terms of both disk space and network chargesimposed by ADMDs. The file system used by the local server to spool messagescan fill with local copies of outgoing messages that are only deleted when apositive-delivery report is received. In addition, you may be charged for thereturn of positive-delivery reports by some ADMDs.

DisableSupplementaryInfo

Prevents the adaptor from providing supplementary information when itgenerates a non-delivery report.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 MIMECompliance

If this feature is enabled, incoming messages from the X.400 domain areconverted to be MIME-compliant when they are output to Internet mail.


11

Adding the Pseudo Host Name to the NIS DatabaseThe pseudo host name is an alias for the machine on which the adaptor isrunning. 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 ifyou 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. Addthe pseudo host name to the line where the primary IP address and hostname for your local machine is defined:

For example, if the host name for your local machine (the machine on whichthe adaptor is running) is papyrus , and you accepted the default pseudohost name proposed by x400tool (x400-gate ), the entry in /etc/hostswould be:

2. If you are running NIS, you need to build a new NIS database thatincludes the pseudo host name for the adaptor.

3. Verify that the pseudo host name for the adaptor is registered correctly inthe Name Service database by using ypmatch(1) :

IP address localhost pseudo hostname

IP address papyrus x400-gate

hostname# cd /var/yphostname# make

hostname# ypmatch pseudo hostname hostsIP address localhost pseudo hostname


11

Modifying sendmail.cf to Add a Pseudo Host Name ManuallyIf you changed the default pseudo host name while configuring the SolsticeX.400 Internet Adaptor, you need to register this change in/etc/mail/sendmail.cf on your local machine. If you did not authorizex400tool 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 , toedit the file /etc/mail/sendmail .

2. Search for the text string CXx400-gate and replace the default pseudohost name (the text after CX) with the pseudo host name you assigned foryour adaptor.

3. Save your modifications (overriding the read-only protection) and exit thetext editor.

4. Find out the process id (pid) for the sendmail daemon.

5. Kill the sendmail daemon and then restart it so that it uses the modifiedconfiguration file.

hostname# ps -ef | grep sendmailowner pid timestamp /usr/lib/sendmail -bd -q1h

hostname# kill -15 pidhostname# /usr/lib/sendmail -bd -q1h

CXpseudo host name CXx400-gate

# 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


11

121

Testing and Tuning the SolsticeX.400 Internet Adaptor 12

This chapter describes how to use x400tool to test and tune your SolsticeX.400 Internet Adaptor. It also describes how to customize the sendmailconfiguration file (/etc/mail/sendmail.cf ) manually so that the sendmaildaemon recognizes the Solstice X.400 Internet Adaptor. For more general anddetailed information on how to customize sendmail.cf , see your Solarisdocumentation.

This chapter assumes that you have already set up your adaptor as describedin Chapter 11, “Configuring the Solstice X.400 Internet Adaptor”.

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


12

Testing the Solstice X.400 Internet AdaptorYou 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 expectedit. 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.400address in the expected way, or that X.400 addresses are converted to correctInternet addresses, you should check them with the Address Conversionoption.

1. Press and drag MENU down the Test menu and release it over the TestAddr 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

Testing and Tuning the Solstice X.400 Internet Adaptor 123

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 adaptorconversion.If you enter an X.400 address, the available components are displayed in thescroll list. Press SELECT to choose each component and then enter its valuein the address field.

4. When you have entered the complete address, press SELECT on Test todisplay the conversion that would be made in the adaptor.Check that the address displayed is correct. Note that the correct addressconversion is only possible if you have configured the adaptor. That is, if theaddress that you try to test is not a real or configured system, then theconversion result will include unknown characters. These characters aredefined in RFC987 and RFC1327.

Sending a Test Message

When you are sure that the address is correct and that you have configured theadaptor, you should test that it works by sending a message to yourself, via theadaptor.

Send a message using your own Internet mail address, specifying the adaptorusing the pseudo host name that you assigned to it. For example, if youassigned the default pseudo host name proposed by x400tool (x400-gate )then the address would be:

Figure 12-2 on page 124 shows the mailtool compose window that is used tosend a mail message to test the Solstice X.400 Internet Adaptor. The localInternet mail address is the login name of the recipient (jsmith ) and theInternet mail domain address is the pseudo host name assigned to the adaptor(x400-gate ).

recipient_name@x400-gate


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 receivedthrough the Solstice X.400 Internet Adaptor. The full message header showshow the message is routed between systems and how the local Internet mailaddress is converted into an equivalent X.400 O/R address.


12

Figure 12-3 Internet Mail Message Received Through the Solstice X.400 InternetAdaptor


12

Modifying the Mapping Tables

The Solstice X.400 Internet Adaptor translates SMTP (RFC 822) addresses andmessage elements to X.400 equivalents. This is done based on the mappingsdefined in RFC 1327 (superseding RFC 987 and RFC 1148) which provide fortransparent conversion between Internet mail and X.400 domains. In particular,the Solstice X.400 Internet Adaptor translates addresses using the standardmapping tables developed by the COSINE MHS project. These tables complyto RFC 1327 and are distributed globally under the auspices of the MHSCoordination Service.

There are three mapping tables:

• rfc1148-mapping1: contains standard mappings between X.400 addressesand 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 mustbe 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/SMTPConfiguration window.

2. Click SELECT on the Mapping Tables button to activate the MappingTable Editor.

3. The Load Translation Table File window is displayed when you open thiswindow. If this window is already open, then drag and release MENU onthe File manu button to activate it. Choose one of the mapping tablesfrom the list and click SELECT on Load.Figure 12-4 shows the mapping table editor with a mapping table loaded.

Caution – You should not modify the mapping tables supplied with SolsticeX.400 Messaging Server other than under exceptional circumstances. Alteringthese mapping tables will affect the operation of your Solstice X.400 InternetAdaptor.!


12

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 subsetof all possible mappings. The filter can be a regular expression.

For example, set the Country filter ON and enter the appropriate countrycode for the X.400 domain in which you are interested—in the exampleshown in Figure 12-5 on page 128, FR for France was entered.

Click SELECT on Apply to display the mappings associated with thiscountry.

X.400 domain address

Internet mail domain address


12

Figure 12-5 Mapping Editor Filter

You can use the mapping table editor to insert new mappings, change existingmappings, 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 tableat 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.

Filter criterion

Click SELECT toapply the filter


12

Replacing a Deleted Solstice X.400 Internet AdaptorThere is an unconfigured Solstice X.400 Internet Adaptor in your messagingsystem by default when you first start x400tool .

You can only have one Solstice X.400 Internet Adaptor in your messagingsystem at any one time; however, if you delete the default adaptor, you canreplace it by adding a new Solstice X.400 Internet Adaptor:


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 StoppingX.400 Processes” on page 28.

4. Configure the new adaptor as described in Chapter 11, “Configuring theSolstice X.400 Internet Adaptor”.

Configuring Routes to the Solstice X.400 Internet AdaptorWhen you add a new Solstice X.400 Internet Adaptor to your messagingsystem, 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 foreach message it receives. The default route for the Solstice X.400 InternetAdaptor is based on the global domain identifier assigned to the local MTA.

If x400tool cannot create a default route (because, for example, an identicalroute already exists in the routing table) you will have to modify the routingtable 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 globaldomain identifier, the local MTA will not create a default route for the SolsticeX.400 Internet Adaptor. You must create a new entry in the routing table andadd some discriminating attribute (organization name, organizational unitname, etc.) to the route so that your local MTA can forward messages correctlyto both systems.



12

Modifying the sendmail Configuration File for the Internet AdaptorUnder most circumstances, sendmail.cf must be modified in order to sendmail to X.400 recipients using Internet-style addresses of the form:

When you install the Solstice X.400 Messaging Server software, thesendmail.cf file is modified automatically using the scriptgen_sendmail.cf . You can also run this script manually; for example, whenyou change your sendmail.cf file and want to reapply the X.400-specificrules, or to apply the X.400-specific rules to a subsidiary sendmailconfiguration file.

Using the gen_sendmail.cf Script

To run the gen_sendmail.cf script, type:

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.400Internet Adaptor. It then adds X.400-specific definitions to the start rules. Thescript ends by ensuring that all the other lines of sendmail.cf are leftuntouched by the modifications.

recipient_name@domain_name

hostname# /opt/SUNWconn/bin/gen_sendmail.cf


12

Modifying sendmail.cf Manually

If you have a customized version of the sendmail.cf file, the automaticmodification at installation may fail. You can still make the required changes tosendmail.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 withthe following entries:

2. In sendmail.cf , replace the entry CXpseudo_hostname with the name ofthis file:

On your mail host (provided this is not the machine on which the adaptor isrunning):

1. Create the file /etc/mail/x400domains with the following entries:

2. Edit sendmail.cf to add the following entries:

pseudo_hostnamedomain_name

pseudo_hostnamedomain_name

FX/etc/mail/x400domainsDYpseudo_hostname

CX<pseudo host name>

# 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/var/SUNWconn/OSIROOT/mhs/conf/x400domains


12

3. Edit sendmail.cf to add the following lines after the start rule S0:

4. Edit the mapping tables used by the Solstice X.400 Internet Adaptor tomap X.400 and Internet mail addresses. See “Modifying the MappingTables” on page 126 for detailed instructions.

• In the mapping table rfc11848-mapping1 , add an entry to map from theUNIX domain to the X.400 domain.

• In the mapping table rfc11848-mapping2 , add an entry to map from theX.400 domain to the UNIX domain.

R$*<@$*$=X.LOCAL>$* $#$M $@$Y $:$1<@$2.$3>[email protected]$*<@$+.$=X.$+>$* $#$M $@$Y $:$1<@$2.$3.$4>$5user@mhs-hostR$*<@$=X.$+>$* $#$M $@$Y $:$1<@$2.$3>$4user@mhs-hostR$*<@$+.$=X>$* $#$M $@$Y $:$1<@$2.$3>$4user@mhs-hostR$*<@$=X>$* $#$M $@$Y $:$1<@$2>$3user@mhs-host

domain_name x400_address

x400_address domain_name

133

Sending and Receiving Internet MailThrough the Internet Adaptor 13

This chapter describes how to use Internet mail applications (such as mail(1)and mailtool ) running in Solaris environments to send and receive messagesthrough the Solstice X.400 Internet Adaptor. It assumes that you have alreadyset up your messaging system, including your local MTA and Solstice X.400Internet Adaptor.

For detailed information on setting up a mail service entirely within theInternet domain, see your Solaris documentation.

Sending Messages Using Internet Mail ApplicationsInternet mail applications rely on the sendmail(8) daemon to route messagesbetween users. After the sendmail daemon has been reconfigured (bymodifying sendmail.cf ), you can use, for example, mail , mailx , ormailtool to exchange mail messages directly with the X.400 domain throughthe Solstice X.400 Internet Adaptor.

Note – You cannot use an X.500 directory name for the address of the recipientwhen sending messages through the Internet Adaptor.

Sending Messages Using Internet Mail Applications page 133

Mapping X.400 and Internet Addresses page 138


13

Addressing Messages Through the Solstice X.400 Internet Adaptor

To address mail to a recipient through the Solstice X.400 Internet Adaptor, youneed to specify the local address of the recipient and the domain address of theadaptor. The complete domain address for the Solstice X.400 Internet Adaptorcomprises the pseudo host name (alias) assigned to the adaptor, and thedomain 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 afull X.400-style address.

For example, to use mail(1) or mailx(1) to send a message to a recipientRoger Blake whose local mail alias is rblake through a Solstice X.400 InternetAdaptor with a pseudo host name x400-gate , located in the domainDivision.Company.COM:

To use mail or mailx to send a message to the same recipient by specifyingthe full X.400 O/R address:

When addressing messages through an adaptor located within the sameInternet mail domain, you do not need to specify the full domain name for theSolstice X.400 Internet Adaptor. For example:

Note that you can check the way that the adaptor converts the Internet addressinto an X.400 address using the Address Conversion feature. See “Testing theSolstice X.400 Internet Adaptor” on page 122.

host% mail [email protected]:testThis is a test message.

host% mail /S=rblake/O=XYZ/A=BT/C=UK/@x400-gate.Division.Company.COMSubject:testThis is a test message.

host% mail /S=rblake/O=XYZ/A=BT/C=UK/@x400-gateSubject:testThis is a test message.

Sending and Receiving Internet Mail Through the Internet Adaptor 135

13

Using X.400 Mail Header Fields in mailtool

X.400 mail header fields are used to carry additional information and tomodify the behavior of the mail delivery system on a per-message basis—forexample, to mark the message for urgent delivery. See “Supported Mail HeaderFields” on page 19 for more information.

You set the X.400 header fields that you can use from within mailtool bydefining 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 MENUon 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 onpage 19 for details.

5. Click SELECT on the Add button to place the customized header in thescrolling-list.

6. Click SELECT on the Apply button to apply your changes and add thecustom headers to the compose window.

Figure 13-1 Defining a Custom Mail Header


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 theinternational character sets supported by the Sun Internet mail applications.

When a message that includes international characters is set entirely within theInternet mail domain, the service element X-Sun-Charset is set automaticallyto ISO-8859-1 . Figure 13-3 on page 137 shows the full header of a messagecontaining international characters and sent to a recipient in the UNIX maildomain.

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 elementOriginal-Encoded-Information-Types and set to ISO-6937-Text . ISO-6937 provides full IA5 (ASCII), Teletext (T.61 a subset of ASCII), plusinternational (8 bit) characters. Figure 13-4 on page 137 shows the samemessage sent through the adaptor.

Sending and Receiving Internet Mail Through the Internet Adaptor 137

13

Figure 13-3 International Characters in the Internet Mail Domain

Figure 13-4 International Characters Through the Solstice X.400 Internet Adaptor


13

Mapping X.400 and Internet AddressesSome Internet mail addresses contain ASCII characters that are not directlymapped to X.400 address elements. Abbreviations are used to representcharacters such as “@”, “%”, and “!”, which appear commonly in Internet mailaddresses. Table 13-1 lists these special abbreviations:

For example, to map an Internet mail address of the [email protected] , the country, ADMD, and PRMD pointto the Solstice X.400 Internet Adaptor that accesses the X.400 mail domain. TheInternet mail address can be specified by using the domain-defined identifierDD.RFC-822 , as shown below:

Table 13-1 X.400 Abbreviations

X.400Abbreviation ASCII Character

(a) @ at character

(p) % percentage

(b) ! exclamation (bang)

(q) “ double-quotes

(u) _ underscore

(l) ( left parenthesis (bracket)

(r) ) right parenthesis (bracket)

/C=US/A=MCI/P=XYZ/DD.RFC-822=avon(b)kerr(a)Division.Company.COM/

Part 4 — Managing Your MessagingSystem

This part contains the following chapters:

• Chapter 14, “Managing Your Messaging System with x400tool,” describeshow to use x400tool to maintain your messaging system and to gatherinformation about the current status of its component parts.

• Chapter 15, “Managing Your Messaging System with Command-LineTools,” describes how to use the command-line recovery, tracing, andstatistics tools.

141

Managing Your Messaging Systemwithx400tool 14

This chapter describes how to use x400tool to maintain your messagingsystem 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.

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


14

Displaying OSI Addressing InformationSystem adminstrators who want to add your MTA or message store to theirmessaging systems need information about the OSI addresses of your localcomponents. The Local Server Configuration window displays the OSIaddresses and protocols by which your server can be reached. This informationis based on the running OSI stack configuration, unless the RFC1006 driver isinstalled.

To display address and protocol information of your local MTA and messagestore, follow these steps:


2. Press and drag MENU on the Protocol pull-down menu, and releaseMENU 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 byremote system administrators who are configuring an MTA and want toadd your MTA to their messaging system.

• P3 server displays the P3 address of your MTA. This information is neededby remote system administrators who are configuring a message store andwant to add your MTA to their messaging system.

• P3 client/P7 displays the P3 address of your message store. Thisinformation is needed by remote system administrators who areconfiguring an MTA or a message store and want to add your messagestore to their messaging system.

3. Press and drag MENU on the Access pull-down menu, and release MENUto select a network interface.The address for your local server depends on how your machine isphysically connected to the network. It can be attached to the X.400 domainthrough 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.

Managing Your Messaging System with x400tool 143

14

Displaying Status InformationThere is a status window associated with each component of your messagingsystem. These windows display the status of the component, current at thetime that the window was last refreshed. Status windows can be refreshedautomatically at specific intervals or refreshed manually. The behavior of thestatus windows is determined by setting the x400tool properties.

Changing the Tool Properties

The tool Properties affect the way in which x400tool status windows arerefreshed. The Properties window in shown in Figure 14-1.

1. Click SELECT on the Properties... button to activate the Tool Propertieswindow.

2. Click SELECT on either Automatic or Manual to set the refreshmechanism 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 toset a value for the interval, or type a value and press Return.

• If you choose Manual, you must use the “Refresh” button on each statuswindow to update the display every time you want to see the most recentinformation.

3. Click SELECT on Apply, Reset, or Default.The default value is 20 seconds.

Figure 14-1 x400tool : Changing the Tool Properties

Click SELECT

Drag SELECTon the slider


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 theStatus item. Release MENU to activate the associated status window.

Note – You can only view status information if statistics collection is switchedon. (Statistics collection is on by default). See “Stopping and Starting StatisticsCollection” 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 mostrecent status for one of the messaging components, you can use the refreshbutton 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 givencomponent 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 specifythe name of a file.

4. Click SELECT on Print to print the status information.


14

Displaying the Status of the Local MTA

The local MTA status window displays the information about the flow ofmessages 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 receivedby the local MTA) and outgoing messages (messages sent by the local MTA)at the time the window was last refreshed. The information is displayed asthe total number of messages of each type (urgent, normal, non-urgent, andnotifications) and the volume of data (in bytes) held in each queue.

• A summary of the total traffic flow (messages sent and received) throughthe local MTA since it was last restarted, and the total number ofassociations open at the time the window was last refreshed.

• A summary of the total failed transfers and errors occurring since the localMTA was last restarted.

Number of currentassociations

The total number of associations open between thelocal MTA and other components in the messagingsystem at the time the window was last refreshed.

Total number of messagessent by local MTA

The total number of messages sent by the localMTA to other components in the messagingsystem.

Total number of messagesreceived by local MTA

The total number of messages received by the localMTA from other agents (MTAs, adaptors, or useragents) in the messaging system.

Authentication failuressent

The number of times that the local MTA has rejectedan association indication from a remote MTAbecause the OSI address or password presented wasincorrect.

Authentication failuresreceived

The number of times that a remote MTA hasrejected an association request from the local MTAbecause the OSI address or password presented wasincorrect.

RTS busy indications sent The number of RTS (reliable transfer system) busyindications sent by the local MTA to remote MTAs.


14

Displaying the Status of a Remote MTA

The remote MTA status window displays information about the performanceof the association between the local MTA and a given remote MTA, as seenfrom the local MTA.

Use the remote MTA status window to examine:

• The current state of the queues for outgoing messages—that is, messagessent from the local MTA to the remote MTA—at the time the window waslast refreshed. The information is displayed as the total number of messagesof each type (urgent, normal, non-urgent, and notifications) and the volumeof data (in bytes) in each queue.

• A summary of the traffic flow (messages sent and received) between thelocal MTA and the remote MTA since the local MTA was last restarted, andthe total number of associations open at the time the window was lastrefreshed.

RTS busy indicationsreceived

The number of RTS (reliable transfer system) busyindications received by the local MTA from remoteMTAs.

Abnormal transfers whensending

The number of abnormal transfers that occurredwhen the local MTA was sending outgoingmessages.

Abnormal transfers whenreceiving

The number of abnormal transfers that occurredwhen the local MTA was receiving incomingmessages.

Unacceptable dialog modereceived

The number of times that a connection was refusedwith the reason “unacceptable dialog mode”. Forexample, a two-way connection was attempted witha remote MTA that is configured for monologueonly.


The total number of associations open betweenthe local MTA and the remote MTA at the time thewindow was last refreshed.


The total number of messages sent by the localMTA to the remote MTA.


14

• The current state of the remote MTA at the time the window was lastrefreshed, and a summary of the of the connection negotiation between thelocal MTA and the remote MTA since the time that the local MTA was lastrestarted.

• A summary of the failed transfers and errors associated with the selectedremote MTA since the local MTA was last restarted.


The total number of messages received by thelocal MTA from the remote MTA.

Total number of bytes sentby local MTA

The total number of bytes sent by the local MTAto the remote MTA.

Total number of bytesreceived by the local MTA

The total number of bytes received by the localMTA from the remote MTA.

Current state The current state of the remote MTA (open orclosed) and the current state of the association (ifthe remote MTA is open).

Connection requests sent The number of times that the local MTA hasissued a connection request to the remote MTA.

Connection responsesreceived

The number of times the remote MTA hasresponded to a connection request from the localMTA.

Connection indicationsreceived

The number of times that the local MTA hasreceived a connection indication from a remoteMTA requesting an association.

Connection confirmationsent

The number of times that the local MTA has sent aconnection confirmation in response to aconnection request from the remote MTA.

Authentication failures sent The number of times that the local MTA hasrejected an association indication from theselected remote MTA because the OSI address orpassword presented was incorrect.


The number of times that the selected remoteMTA has rejected an association request from thelocal MTA because the OSI address or passwordpresented was incorrect.


14

RTS busy indications sent The number of RTS (reliable transfer system) busyindications sent by the local MTA to the selectedremote MTA.


The number of RTS (reliable transfer system) busyindications received by the local MTA from theselected remote MTA.


The number of abnormal transfers that occurredwhen the local MTA was sending outgoingmessages to the selected remote MTA.


The number of abnormal transfers that occurredwhen the local MTA was receiving incomingmessages from the selected remote MTA.

Connection abort sent The number of times that the local MTA hasgenerated a connection abort to request thebreaking of a connection.

Connection abort indicationreceived

The number of times that the local MTA hasreceived a connection abort request from theselected remote MTA.


The number of times that a connection wasrefused with the reason “unacceptable dialogmode”. For example, a two-way connection wasattempted with a remote MTA that is configuredfor monologue only.


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 aboutthe 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 informationabout 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.


14

Figure 14-2 MS Group Status Window


14

Displaying the Status of the Solstice X.400 Internet Adaptor

The Solstice X.400 Internet Adaptor status window displays information aboutthe performance of the association between the local MTA and the SolsticeX.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 sentfrom the local MTA to the adaptor (or P1 agent). The information isdisplayed as the total number of messages of each type (urgent, normal,non-urgent, and notifications) and the volume of data (in bytes) in eachqueue.

• A summary of the traffic flow (messages sent and received) between thelocal MTA and the adaptor since the local MTA was last restarted, and thetotal number of associations open.

• The current state of the adaptor (or P1 agent), and a summary of the of theconnection negotiation exchanged between the local MTA and the adaptorsince the time that the local MTA was last restarted or the statisticscollection was started.


The total number of associations open betweenthe local MTA and the adaptor (or P1 agent).


The total number of messages sent by the localMTA to the adaptor (or P1 agent).


The total number of messages received by thelocal MTA from the adaptor (or P1 agent).

Total number of bytes sentby the local MTA

The total number of bytes sent by the local MTAto the adaptor.

Total number of bytesreceived by the local MTA

Total number of bytes received by the local MTAfrom the adaptor.

Current state The current state of the adaptor (open or closed)and the current state of the association (if theadaptor is open).

Connection requests sent The number of times that the local MTA hasissued a connection request to the adaptor.


14

• A summary of the failed transfers and errors associated with the selectedremote MTA since the local MTA was last restarted.


The number of times the adaptor has respondedto a connection request from the local MTA.

Connection indicationsreceived

The number of times that the local MTA hasreceived a connection indication from a adaptorrequesting an association.

Connection confirmationssent

The number of times that the local MTA has sent aconnection confirmation in response to aconnection indication from the adaptor.

Authentication failures sent The number of times that the local MTA hasrejected an association indication from theadaptor because the OSI address or passwordpresented was incorrect.


The number of times that the adaptor has rejectedan association request from the local MTA due toan incorrect address or password.

RTS busy indications sent The number of RTS (reliable transfer system) busyindications sent by the local MTA to the adaptor.


The number of RTS busy indications received bythe local MTA from the adaptor.


The number of abnormal transfers that occurredwhen the local MTA was sending outgoingmessages to the adaptor.


The number of abnormal transfers that occurredwhen the local MTA was receiving incomingmessages from the adaptor.

Connection abort sent The number of times that the local MTA hasgenerated a connection abort to request thebreaking of a connection with the adaptor.

Connection abort indicationreceived

The number of times that the local MTA hasreceived a connection abort request from theadaptor.


The number of times an error occurred when thelocal MTA was negotiating the handshakingapplied to the exchange of messages.


14

Displaying the Status of a User Agent

The user agent status window displays information about the performance ofthe 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 sentfrom the local MTA to the user agent. The information is displayed as thetotal number of messages of each type (urgent, normal, non-urgent, andnotifications) and the volume of data (in bytes) in each queue.

• A summary of the traffic flow (messages sent and delivered) between thelocal MTA and the selected user agent since the local MTA was last restartedexpressed in terms of the number of messages and the total number of bytesof data.

• The current state of the user agent, and a summary of the connectionnegotiation exchanged between the local MTA and the user agent since thetime that the local MTA was last restarted.

Messages Submitted The number of messages sent from the UA to thelocal MTA.

Messages Delivered The number of messages sent from the local MTAto the UA.

Bytes Submitted The number of bytes sent from the UA to the localMTA.

Bytes Delivered The number of bytes sent from the local MTA tothe user agent.

Current state The current state of the UA (open or closed) andthe current state of the association (if the UA isopen).

Connection requests sent The number of times that the local MTA hasissued a connection request to the UA.


The number of times the UA has responded to aconnection request from the local MTA.

Connection indicationreceived

The number of times that the local MTA hasreceived a connection indication from the UArequesting a connection.


14

Stopping and Starting Statistics CollectionThe information displayed in the x400tool status windows is based on datarecovered from the messaging system. You can improve the performance ofyour 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 StopCollecting 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 StartCollecting item. Release MENU to start collecting statistics.

Opening and Closing AgentsClosing an agent breaks its association with the local MTA, but does notremove the agent from the messaging system. It will not be recognized by thelocal MTA or by any other agent. You cannot close your local server.

While an agent is closed, it will neither accept nor forward messages. Incomingmessage transfers in progress when an agent is closed are aborted and anon-delivery message is generated.

Connection confirmationssent

The number of times that the local MTA has sent aconnection confirmation in response to aconnection indication from the UA.

Notification indicationsreceived

The number of times that the local MTA hasreceived a notification indication from the UA.


14

Opening a Closed Agent

An agent can be closed either automatically or manually. To reopen an agentafter 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 theOpen Agent item. Release MENU to reopen the closed agent.

Figure 14-3 Closed Message Transfer Agent Icon

Closing an Open Agent

An agent can be closed either automatically or manually. It might be closedautomatically if it does not respond to the local MTA after a specified time, andthere 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 theClose Agent item. Release MENU to close the open agent.

Figure 14-4 Open Message Transfer Agent Icon

Symbol indicatingthat the agent isclosed temporarily

A blank space indicates that theagent is open


14

Purging the Message QueuesPurging message queues removes either one or all the messages that arecurrently waiting to be delivered. This is a risky undertaking because there isno way to determine the content of the messages in the queue and there is thechance that you will destroy valuable correspondence. However, underexceptional circumstances, this feature can be used to unblock your messagingsystem 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 aremote MTA that is unable to cope with it, the message may block the queueand trap a number of smaller messages behind it. In this case, you shouldpurge the first message in the queue to resolve the problem. You will lose thecontents of the first message, but the other messages will be delivered correctly.

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 aseparate queue. You can purge the first message in the queue without affectingthe 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 InternetAdaptor, P1 agent, or user agent.

2. Press MENU on the Manage menu button and drag the pointer to thePurge Queues item. Release MENU to activate the Purge Messageswindow for the local MTA.

3. Click SELECT on the First Message button to specify the first messageonly.

4. Click SELECT on the Purge button to remove all the messages waiting inoutgoing queue for the selected agent.

Caution – Do not delete the files associated with the mail queues (or any otherfiles associated with the Solstice X.400 Messaging Server). Always use thepurge option if you need to clear the message queues.!


14

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 messagingsystem, you can purge all the messages queued for one agent without affectingthe 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 FirstMessage in the Queue” on page 156.

2. Click SELECT on the All Messages button to specify the queues affectedby the purge.

3. Click SELECT on the Purge button to remove all the messages waiting inoutgoing queue for the selected agent.

Click SELECT to specifythe first message only

Click SELECT to purgethe specified queues


14

Purging All Incoming Messages

Incoming messages are messages sent by the other agents in your messagingsystem to the local MTA. To purge all the queues containing incomingmessages:

1. Click SELECT on the icon for the local MTA.

2. Press MENU on the Manage menu button and drag the pointer to thePurge Queues item. Release MENU to activate the Purge Messageswindow for the local MTA.

3. Click SELECT on the check box for All Incoming Messages to specify thequeue affected by the purge.

4. Click SELECT on the Purge button to remove all the messages waiting inincoming queues.

Figure 14-6 Purging Incoming Messages

Purging All Outgoing Messages

Outgoing messages are messages sent by the local MTA to the other agents inyour messaging system. To purge all the queues containing outgoing messages:

1. Open the Purge Messages window as described in “Purging All IncomingMessages.”

2. Click SELECT on the check box for All Outgoing Messages to specify thequeue affected by the purge.

3. Click SELECT on the Purge button to remove all the messages waiting inoutgoing queues.

Click SELECT to specifythe queue affected

Click SELECT to purgethe specified queue


14

Purging a Message StoreWhen you purge a message store, you remove either one or all the messagesthat are stored in a user’s information base. This feature can be used to free updisk 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 userwhose messages you want to purge.

2. Press MENU on the Manage menu button and drag the pointer to theStatus item. Release MENU to activate the MS Group Status window, asshown 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 informationabout the first fifty messages in that user’s information base.

5. Click SELECT on the message(s) you want to purge, then click SELECT onPurge Selection.If the message(s) you want to purge is not displayed, click SELECT on NextRange to display the next fifty messages.

Note – You cannot purge user messages when the user is connected. Check theconnection state of the user in the Users scrolling-list.

6. To purge the entire information base, click SELECT on Purge Mailbox.


14

Backing Up and Restoring Message StoresWith x400tool , you can back up some or all of the messages and deliveryreports contained in your message store. This lets you keep an archive ofmessages, 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 messagestore users, users defined in a particular message store user group, or forindividual users.

• Whether you back up only messages, only delivery report, or both messagesand delivery reports.

• The time and date range of messages to be backed up. For example, you canback up only messages created since a particular date.

Note – To back up or restore a message store configuration, see Backing UpYour 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 andright to display the MS Mailbox Backup submenu. Release MENU overeither All MS Users (to backup every user) or MS Users Group (to backupa 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 namefor your backup file. Click SELECT on Select.The MS Users Mailbox Backup window is displayed, as shown inFigure 14-7 on page 161.


14

Figure 14-7 MS Users Mailbox Backup Window

4. If you are backing up specific users, click SELECT on the user names inthe 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 BackupAuthor input line.You can use what you type here to help you identify a backup file when youcome to restore.

6. Click the checkboxes for Delivered Message and Delivered Report asnecessary, 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 daterange, click SELECT to turn on Entry Creation Limits.The input lines for Start Creation and Stop Creation are enabled. Type thedate and time to set the backup range.

8. Click SELECT on Backup to save the data.


14

Restoring User Messages and Delivery Reports

1. Press MENU on the Manage menu button and drag the pointer down andright to display the MS Mailbox Restore submenu. Release MENU overeither All MS Users (to restore every user) or MS Users Group (to restorea 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 theGroup Users scrolling-list.Only users that were backed up in the file you are restoring from aredisplayed.

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, showingthe time and date range of the contents of the backup file. Type the date andtime to set the restore range.

6. Click SELECT on Restore to restore the data.

163

Managing Your Messaging Systemwith Command-Line Tools 15

This chapter describes how to use the command-line troubleshooting toolssupplied 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 InternetAdaptor.

Journal FilesJournal files are automatically used to record messaging activity. These files arefound in the directory /var/opt/SUNWconn/OSIROOT/spool . There are twofiles, journal1 and journal2 . Each file holds up to 500 entries. Once one fileis full, the Solstice X.400 Messaging Server switches to the other, alternatingbetween the two every 500 entries. In this way a maximum of 1000 entries arerecorded at any time.

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


15

An example journal file is shown below:

Note – P1 agents (SMTP_X400) are seen as MTAs in the journal file.

Regenerating the Configuration from TextThe file prefix.mhscf.text is created when you backup your MTA andmessage store configuration and each time you change your currentconfiguration. It is a textual representations of the current configuration and isused 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 withoutcopying all the related configuration files or to regenerate a lost configuration.

The command-line utility x400_genconf regenerates the configuration fromthe text file. You can also use the Restore Config. option in x400tool (See“Restoring an Existing Configuration” on page 29).

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.400Processes” on page 28.

2. Exit from x400tool .Press MENU in the title bar at the top of the tool and drag the pointer downand release it on Quit.

**-----------------------------------**95/08/12 13:29:02 ==>[0] Solstice X.400 9.0 started95/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

Caution – Regenerating a configuration will overwrite the messages stored ina message store user mailbox. Before you restore a configuration, backup yourmessage store as described in “Backing Up and Restoring Message Stores” onpage 160.

!

Managing Your Messaging System with Command-Line Tools 165

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 :

5. Regenerate the configuration using x400_genconf :

where mta is used to regenerate only the MTA configuration, ms is used toregenerate only the message store configuration. By default, both the MTAand message store configurations are regenerated.

You might have to respond to some questions depending on yourconfiguration, for example, to confirm that the configuration files can beoverwritten.

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 updatesome of the addressing information.

hostname# cd /var/opt/SUNWconn/OSIROOT/mhs/conf

hostname# /opt/SUNWconn/sbin/x400_genconf [mta] [ms] prefix.mhscf.text


15

Using the MTA Database ToolsEach Solstice X.400 MTA has several spool files, collectively known as the MTAdatabase. The database contains a record of all transactions that occur in yourmessaging system.

The Solstice X.400 Messaging Server includes a script, x400dbrecover , thatyou 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 :

The x400dbrecover script does the following:

1. Stops the X.400 processes.

2. Uses x400dbsave(1M) to backup the MTA database in a temporarydirectory.

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 thex400dblist(1M) MTA database tools, see their online manpages.

hostname# /opt/SUNWconn/sbin/x400dbrecover


15

Using x400trace

The Solstice X.400 Messaging Server tracing facility (x400trace ) is used toreturn dynamic information recovered from the local MTA and message store.

To start x400trace :

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 linesof a message bodypart is displayed.

-r : Suppresses the names of PDU service elements from the trace. This optionis valid only when you specify the pdu filter.

Valid protocols are shown in Table 15-1. If you do not specify a -p option, thenall protocols are traced.

Valid OSI processes are shown in Table 15-2.

hostname# /opt/SUNWconn/sbin / x400trace [-dfr] [-p <protocols>] [-i <osi_processes>] [<filters>]

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.

Table 15-2 x400trace OSI Processes

Process Description

osixapia Traces the ROSE component of the osixapia daemon.

osimta Traces the local MTA.


15

Valid filters are shown in Table 15-3.

Trace Examples

This section provides some examples of using x400trace .

To display information on activity occuring in the messaging system:

osix400ms Traces the local message store.

osismtpx400 Traces the local Internet mail adaptor.

osix400mqa Traces the local message queue.

Table 15-3 x400trace Filters

Filters Description

debug Recovers a full trace of the remote operation service element (ROSE) andACSE presentation. The -d command-line option has the same effect asthis 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 InternetAdaptor.

rts Returns a trace from the reliable transfer service (RTS).

hostname# x400trace eventsx400trace: Initialization in progressTracing osimta osismtpx400 osix400mqa osix400msx400trace: Initialization completedosix400ms 16:23:21[9973] MS Bind Requestosix400ms 16:23:21[9973] MS Bind Confirmationosix400ms 16:23:21[9973] MessageSubmission Invoke Requestosix400ms 16:23:21[9973] MTS Bind Request...

Table 15-2 x400trace OSI Processes

Process Description


15

To display information on activity occuring in the MTA only:

To trace all inbound and outbound PDUs, and redirect the output to a file:

To trace inbound and outbound P7 PDUs:

hostname# x400trace -i osimta events./x400trace: Initialization in progressTracing osimta./x400trace: Initialization completedosimta 11:44:29[9973] MTS Bind Requestosimta 11:44:29[9973] MTS Bind Confirmation...

hostname# x400trace pdu >trace.out

hostname# x400trace -p p7 pdu./x400trace: Initialization in progressTracing osimta osix400ms./x400trace: Initialization completedosix400ms 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...


15

Using x400decode

The x400decode utility decodes Protocol Data Units (PDUs). Input can befrom standard input (stdin ) or from a file, and can be in either binary orASCII format. Output is returned to standard output (stdout ).

To start x400decode :

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 <skip_length>

Start the decode skip_length bytes into the file. This option is validonly when you specify the file option.

-p <protocol>

Valid protocols are shown in Table 15-4.

file

Specifies the name of an input file. By default, input is from stdin .

hostname# /opt/SUNWconn/sbin/x400decode [-ar] [-s <skip_length>] [-p <protocol>] [file]

Table 15-4 x400decode Protocols

Protocol Description

p1 Decodes P1 PDUs.

p2 Decodes P2 PDUs.

Part 5 — Appendices

This part contains the following supplementary information:

• Appendix A, “Error Messages,”contains information to help you diagnoseand resolve problems with your messaging system.

• Appendix B, “Technical Specification and ConformanceInformation,”contains a technical specification for the Solstice X.400Messaging Server, and a brief description of the CCITT X.400recommendations to which it conforms.

173

Error Messages A

This appendix provides a list common error messages. Each message ispresented 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 charactersThe name assigned to an agent must be printable (ASCII) characters.

Agent name must start with a letterThe name assigned to an agent can contain digits, provided the name startswith an alphabetic character.

Alternate Recipient already existsYou cannot assign two alternate recipients with the same O/R address.

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


A

An X.25/X.121 address must only contain digitsX.25/X.121 addresses must contain numbers only; it must not contain non-numeric characters.

Another instance of the tool is already runningBecause x400tool interacts directly with the local server running on thesystem, you cannot start two instances of x400tool on the same machine.

Backing up the configuration will overwrite the following file(s): <list of files>If you specify the name of an existing file to which the configuration backupis to be saved, then that file will be overwritten.

calloc system call failure (<errno>)Indicates a severe internal error. If this error is returned frequently, contactyour authorized service provider.

Cannot close adaptor while it is runningYou must stop the Solstice X.400 Internet Adaptor process before you canstop the adaptor. Use /usr/SUNWconn/sbin/x400stop osismtpx400 tostop the adaptor process.

Cannot open internet adaptorYou must start the Solstice X.400 Internet Adaptor process before you canstart the adaptor. Use /opt/SUNWconn/sbin/x400start osismtpx400to start the adaptor process.

Cannot close MTA <name>The remote MTA cannot be closed. This might happen for example, if theremote MTA has been removed. Restart x400tool .

Cannot open MTA <name>The remote MTA cannot be opened. This might happen for example, if theremote MTA has been removed. Restart x400tool .

Cannot close P1 user agent <agent>You must stop the MT user application associated with the P1 user agentbefore it can be closed.

Cannot open P1 user agent <agent>You must start the MT user application associated with the P1 user agentbefore it can be opened.

Error Messages 175

A

Cannot close user agent <name>You must stop the MA user application associated with the specified useragent before it can be closed.

Cannot find the MTA server for group <groupname>The Server MTA for the MS users group <groupname> is no longer definedon your local machine. For example, you have deleted the MTA from thex400tool configuration. Select a different Server MTA for the MS usersgroup, or quit and restart x400tool .

Cannot open user agent <name>You must start the MA user application associated with the specified useragent before it can be opened.

Cannot restore all the msg store users from this backup fileThe backup file you are restoring from was created for selected users in theMS users group. You cannot use this backup file to restore information forall the users in the group.

Can’t backup configurationx400tool was unable to backup the existing configuration to the specifiedfile. Your file system may be full or the permissions may not be set correctly.

Can’t get MHS config file namex400tool was unable to recover the prefix that defines the name of thecurrent configuration file.

Can’t open file: <filename>The specified file does not have the correct access permissions or pathnameto be opened.

Can’t open new file: <filename>The specified file cannot be created. You may have specified an illegal nameor pathname.

Can’t open/write file: <filename> - errno <errno>The specified file does not have the correct access permissions or pathnamefor it to be opened or written to.

Can’t update init fileIndicates a severe internal error that occurred when updating theosimta.init file. If this error is returned frequently, contact yourauthorized service provider.


A

Can’t update xmh.ini fileIndicates a severe internal error. If this error is returned frequently, contactyour authorized service provider.

Can’t update xom.ini fileIndicates a severe internal error. If this error is returned frequently, contactyour authorized service provider.

Country & ADMD must be presentThe global domain identifier must have at least a country code and anADMD defined. If the agent is not part of a recognized ADMD, you canenter a blank space character as the ADMD; however, you must not leave anull entry.

Default route already exists (not created)When you add an agent to the messaging system, x400tool attempts tocreate a default entry in the local routing table. The default entry is alwaysbased on the global domain identifier assigned to the agent. If an identicalentry already exists, x400tool generates this warning to inform you thatyou must modify the routing table manually to add a route for the newagent. See “Modifying the Default Routing Table” on page 103 for detailedinstructions.

Deleting incoming queue: failedThere was an error while deleting the incoming message queue. Try again.

Deleting outgoing queue: failedThere was an error while deleting the outgoing message queue. Try again.

Duplicate O/R name or Duplicate nameYou have created a routing table entry that matches an existing entry, or youhave defined an agent with an O/R address that matches that of an existingagent.

Error: invalid MS serverThe server message store you specified for an MS users group is notdefined. Make sure that it is listed in the Message Stores scrolling-list.

Error: invalid MTA serverThe server MTA you specified for an MS users group is not defined. Makesure that it is listed in the MTAs scrolling-list.

Error: maximum number of supported ms users is reachedYou cannot define a total of more than 250 MS users.

Error Messages 177

A

Error: maximum number of user groups is reachedYou cannot define more than 250 MS user groups.

Error: name is mandatoryYou must define a name for each agent in your messaging system. Agentnames must not include space or tab characters.

Error: no body types supportedA user agent has been defined without specifying any supported bodytypes. 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 BodyTypes Supported” on page 93 for more information.

Error: no content type supportedA user agent has been defined without specifying any supported contenttypes. This will prevent the local MTA from forwarding any mail to it.Enable at least one content type for the user agent. See “Specifying theStandard Content Types Supported” on page 94 for more information.

Error: no group name specifiedWhen adding a new MS users group, you must specify a name for the groupbefore you add a user.

Error: no user selectedWhen backing up or restoring an MS users group, you must select at leastone user from the Group Users scrolling-list.

Error: non-numeric content typeThe value assigned to the non-standard content type defined for a useragent must be numeric.

Error: standard content typeThe value assigned to the non-standard content type defined for a useragent must not match one of the standard content types. Standard contenttypes are: 0, 1, 2, 22, 35.

Error: too many non std content typesYou have defined more than the maximum number of non-standard contenttypes allowed.

Error when creating <directory> mkdir: <message>See message. The pathname or access permissions might be incorrect.


A

Error when opening <directory> opendir: <message>See message. The pathname or access permissions might be incorrect.

Error while removing messageAn error occurred when purging the message queues. If this error isreturned frequently, contact your authorized service provider.

Error while saving users group information on .mhsgrp fileAn error occurred when writing to the current MS user text configurationfile (filename.mhsgrp ). Verify your file system then try again.

If this error is followed by the error message Cannot find ms serverserver_name, the server message store is no longer defined on your localmachine. For example, you have deleted the message store from thex400tool configuration. Add the message store to your configuration, orselect a different message store for the MS users group, then try again.

File error on <filename> (<action> : <errno>)There was an error acting on the specified file. See the action message for thetype of error. For example, if action is chmod, then the access permissions areset incorrectly.

Host name and address do not correspondYou can enter a TCP/IP (RFC 1006) address as a numeric IP address (dotnotation) or as a host name. If you enter a host name, x400tool retrievesthe corresponding IP address by doing a gethostbyname. If you enter botha numeric IP address and a host name, the two addresses must beequivalent.

Host name or address must be presentYou can assign TCP/IP (RFC1006) addresses for remote MTAs as numericaddresses or host names. You must enter at least one.

Incompatible addressing dataThe X.400 address contains elements that do not combine to make a validaddress. For example, a combination of a numeric-user-identifier (UA-ID)and a personal-name (PN). See “X.400 Addressing” on page 7 for adescription of valid X.400 address types.

Initialization failedIndicates a severe internal error. If this error is returned frequently, contactyour authorized service provider.

Error Messages 179

A

Internal Error (<error description>)Indicates a severe internal error. If an internal error is returned frequently,contact your authorized service provider.

Internet adaptor already exists: <string>You cannot add more than one Solstice X.400 Internet Adaptor to the localmessaging system.

Invalid ADMD codeThe ADMD code that you have entered was not found in the list of standardADMD codes. You can choose to correct the code or to force x400tool toaccept it.

Invalid country codeThe country code that you have entered was not found in the list ofstandard country codes. You can choose to correct the code or to forcex400tool to accept it. If you use a non-standard country code, you mayexperience interworking problems.

Invalid hexadecimal numberUse a number that only includes hexadecimal digits—0 through 9 and Athrough F.

Invalid host name: <errno>You can enter a TCP/IP (RFC 1006) address as a numeric IP address (dotnotation) or as a host name. If you enter a host name, x400tool retrievesthe corresponding IP address by doing a gethostbyname . Host namesmust correspond to a valid IP address.

Invalid IP address (must be a.b.c.d)Numeric IP addresses must be entered in a dot notation.

Invalid MS users groups file formatThe current MS user text configuration file (filename.mhsgrp ) has becomecorrupted. Restore the affected MS Users group(s) from a previous backup.

Invalid MTA responseIndicates a severe internal error. If this error is returned frequently, contactyour authorized service provider.

Invalid restore summary file: <errno>An error occurred when reading the selected backup file. Check thepathname and access permissions of the file then try again.


A

Invalid times: no value setWhen you select Entry Creation Limits while backing up or restoring an MSuser 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, contactyour authorized service provider.

malloc system call failure (<errno>)There was an error while allocating space. Check that there is enough diskspace available.

Message queues are currently not emptyPlease confirm <name> deletion

There are still some messages in the queue that you want to delete. Confirmthat you still want to delete the message queue.

MTA or adaptor not foundA configured local MTA or adaptor were not found as required in thebackup configuration. Either try the restore again or backup a differentconfiguration.

MTA process is not running properlyIndicates a severe internal error. If this error is returned frequently, contactyour authorized service provider.

Network address must be presentYou must specify an OSI network address when defining a remote MTA.

No more licenses availableYou cannot add any more MS users. Delete an MS user from yourconfiguration before adding a new one, or purchase more MS user licenses.

NSAP must be an hexadecimal numberX.25 and LAN addresses must be entered as hexadecimal numbers.

OSI Communication Platform not runningIf you did not install the RFC1006 driver, you cannot start x400toolunless the SunLink OSI Communication Platform (stack) is configuredand running on your machine.

Process <name> is not runningThe specified process needs to be started. Use x400tool to start it.

Error Messages 181

A

Restart the MTAYou need to start the local MTA before you can complete the currentoperation. Use x400tool to start it.

Routing ambiguousThe routing is ambiguous or the format of the O/R address is not compliantwith the X.400 specification. For example, the local MTA might not be ableto distinguish between two possible destinations. Verify the routing definedand ensure that there is enough information to distinguish a unique route.

Routing impossibleThe local MTA cannot route the message. Verify the routing and ensure thatthe route has a valid and unique definition.

Select an MTA icon as defaultYou need to select one of the remote MTAs in your messaging system whendefining a default (“catch-all”) MTA. See “Setting a Default MTA” onpage 80 for more information.

Statistics: unknown obj type <name>Indicates a severe internal error. If this error is returned regularly, pleasereport the occurrence to your authorized service provider.

Surname is mandatory when adding other personal name attributesPersonal names consist of four attributes: surname (S), given-name (G),initials (I), and generation-qualifier (GQ), of which only surname ismandatory.

Software has not been installed correctly: check the file/etc/opt/SUNWconn/OSIROOT or you have the variable $OSIROOT wronglydefined 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 thatit is pointing to the true location of the Solstice X.400 Messaging Serverconfiguration files.

Too many message queue P1 users, Limit is 16You can have a maximum of 16 P1 user agents defined to use the messagequeue interface.


A

Unable to locate OSIROOT directoryx400tool was unable to locate the expected files in the directory definedby the file /etc/SUNWconn/OSIROOT .

X.25 address can only contain decimal digitsEnter a numeric X.25 address.

x400tool Error (<error description>)Indicates a severe internal error. If an internal error is returned frequently,contact your authorized service provider.

Errors Returned by the RFC1006 Driver Utilities

rk6d Daemon Errors

rk6d: Could not find muxid <n> in listThe identifier of a TCP stream to be closed does not correspond with theidentifier of an open TCP stream. Restart the rk6d daemon.

rk6d: Could not unlinkThe rk6d daemon cannot unlink a TCP stream. Reboot your system.

rk6d: Error on pollAn error occured while rk6d daemon was waiting for information from thekernel module. Restart the rk6d daemon.

rk6d: Fatal error in adminAn error occured when sending administration messages to the kernelmodule. Restart the rk6d daemon.

rk6d: Fatal error plumbing listen streamThe rk6d daemon could not open a stream to the kernel module. Reinstallthe SUNWrk6d package and try again.

rk6d: Fatal error plumbing streamsAn error occured when opening a TCP stream. Restart the rk6d daemon.

rk6d: Fatal error starting daemonAn error occured when starting the rk6d daemon. There may be too manyprocesses running on your system. Stop some processes then try again.

Error Messages 183

A

rk6d: Fatal error while waitingAn error occured while rk6d daemon was waiting for information from thekernel module. Restart the rk6d daemon.

rk6d: Initial number of ctx exceeds maximumWhen you start the rk6d daemon manually, the initial number of TCPstreams (set using the -i option) must be less than the maximum TCPstreams value (set using the -m option).

rk6d: Initial number of ctx should exceed min free ctxWhen you start the rk6d daemon manually, the initial number of TCPstreams (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 ctxWhen 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 deviceThe rk6stat utility could not communicate with the kernel module.Reinstall the SUNWrk6d package and try again.

rk6stat: Error reading statistics: <syserror>Stop then restart the rk6stat utility. If this error is returned frequently,contact your authorized service provider.

rk6stat: Error resetting statistics: <syserror>Stop then restart the rk6stat utility. If this error is returned frequently,contact your authorized service provider.

rk6trace Errors

rk6trace: Cannot start tracingStop then restart the rk6trace utility. If this error is returned frequently,contact your authorized service provider.

rk6trace: Could not open trace device <syserror>The rk6trace utility could not open a device. Reinstall the SUNWrk6dpackage and try again.


A

rk6trace: Error in reading trace streamStop then restart the rk6trace utility. If this error is returned frequently,contact your authorized service provider.

rk6trace: Error on trace streamStop then restart the rk6trace utility. If this error is returned frequently,contact your authorized service provider.

rk6trace: Getmsg error <syserror>Stop then restart the rk6trace utility. If this error is returned frequently,contact your authorized service provider.

rk6trace: I_SRDOPT call <syserror>Stop then restart the rk6trace utility. If this error is returned frequently,contact your authorized service provider.

rk6trace: Poll error <syserror>Stop then restart the rk6trace utility. If this error is returned frequently,contact your authorized service provider.

Alarms Returned by the Messaging SystemThe following error messages are returned by the local MTA in the log file/var/SUNWconn/osinet/osilogd.log. Most of these error messagesindicate a system error. If these errors are returned frequently, contact yourauthorized service provider.

ALARM ! File Error <oper> <filename>

Description: Indicates a file error detected by the local MTA. If the error isdue to a message file, processing is abandoned for this file inorder to protect the rest of the messaging system.

Action: You may need to purge the message queues in order to clear ablocked message. See “Purging the Message Queues” onpage 156.

Error Messages 185

A

<oper> Type of operation in progress when the error occurred; one of:closing creating deleting linkingopening reading seeking writing

<filename> Name of file causing error.

Example: ALARM ! File error opening <filename>

ALARM ! Possible duplication to MTA <mta_id> MPDU Id: <mpdu_id>

Description: Indicates that the sent MPDU may be duplicated after an errorwhich occurred during a critical phase in the transfer.

<mta_id> Remote MTA identifier.

<mpdu_id> MPDU identifier.

Action: Warn the recipient system administrator, who can delete theduplicate message.

Example: ALARM ! Possible duplication to MTA 9 MPDU Id:</FR/ATLAS/XYZCORP/10/04/93>

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 <oper> <msg_id> <ln1> <msg> <dest> <file> <ln2>

Description: The messaging system detected an error when trying to create,replace, or delete a message descriptor.

Action: Contact your authorized service provider if this error is returnedfrequently.

<oper> Type of operation in progress when the error occurred:creating replacing deleting

ALARM ! File Error <oper> <filename>


A

<msg_id> Message identifier.

<ln1> Length of entire message.

<msg> Message type; one of:non deferred list deferred listurgent message to normal message tonotification to non urgent message toincoming APDU queue

<dest> Destination (outgoing messages only):remote MTA: MTA <mta_id>user agent: LUAG <luag_id>

<file> File name or file names (if any).

<ln2> Length of file (specified by <file>).

Example: ALARM ! Database error creating</FR/ATLAS/XYZCORP/20/03/93/>length= 750 urgent message to MTA 2file p000003 length=250file p000004 length=500

ALARM ! OSIAM Internal Error CTX=-1

Description: The local MTA was unable to open the association becausethere were no contexts available.

Action: Contact your authorized service provider if this error isreturned frequently.

Example: ALARM ! OSIAM Internal Error CTX-1

ALARM ! OSIAM Internal Error SAP=<sap> MTA=<mta_id>

Description: Indicates that the specified SAP could not be accessed becauseit was invalid or closed.

<sap> SAP (service access point) number.

ALARM ! Database Error on <oper> <msg_id> <ln1> <msg> <dest> <file> <ln2>

Error Messages 187

A


Action: Contact your authorized service provider if this error isreturned frequently.

Example: ALARM ! OSIAM Internal Error SAP=2 MTA=3

ALARM ! Unacceptable Dialogue Mode ! MTA <mta_id>

Description: The remote MTA refused an association because of an errorduring the negotiation phase. For example, the local MTArequested a two-way association from an MTA that onlysupports monologue connections.Messages to be delivered are kept in the relevant queue and thelocal MTA will continue to accept messages for this destination.


Action: Redefine the association parameters for the remote MTA. See“Tuning the Remote MTA Association Options” on page 76.

Example: ALARM ! Unacceptable Dialogue Mode ! MTA=3

ALARM ! Maximum Number of Retries Reached, closing of MTA <mta_id>

Description: The local MTA has exceeded the maximum number ofunsuccessful association establishment retries. The remoteMTA is closed. All pending messages are rerouted and no newmessages will be forwarded.


Action: Check the configuration and reopen specified remote MTA. See“Displaying Status Information” on page 143.

Example: ALARM ! Maximum number of retries reached,closing of MTA 4

ALARM ! OSIAM Internal Error SAP=<sap> MTA=<mta_id>


A

ALARM ! Loopback detected

Description: A loopback condition is detected—that is, the message isrouted back to an MTA that has already passed on the message.The local MTA already appears in the trace information for themessage.

Action: Check the routing table. See “Modifying the Default RoutingTable” on page 103.

ALARM ! Originator Control Failure MTA <mta_id> MD <domain_id>

Description: An incoming message was deleted because the originatingdomain identifier is not associated with the specified remoteMTA. The message is discarded and a non-delivery report isgenerated.


<domain_id> Global domain identifier for the originating MTA.

Action: Check the configuration for the specified remote MTA. See“Specifying the Global Domain Identifier of a Remote MTA” onpage 69.

Example: ALARM ! Originator Control Failure MTA 2 MD/FR/ATLAS/XYZCORP/

Error Messages 189

A

Messages Returned by the OSI AlarmerThe logging daemon, osilogd , reads and forwards OSI error and statusmessages 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 isnearly full

ALARM ! Congestion critical state

Description: The local MTA has been placed in a critical state because thespace remaining in the spool file system has dropped below thepredefined threshold. The local MTA will not accept any moremessage transfers; message transfers in progress will becompleted.

Action: Reduce the number of messages stored in the spool file systemif possible. See “Purging the Message Queues” on page 156.If this error occurs frequently, it indicates that your spool filesystem is too small for the traffic supported by the local MTA.Increase the size of your spool file system or decrease thecongestion thresholds. See “Setting the Type of ReportRequested by Outgoing Messages” on page 61.

ALARM ! Invalid sequence of Trace Information

Description: The timestamp sequence is incorrect. For example, incorrecttime zone. By default the time tolerance is set to 255. Thisalarm may also result from the existence of more than one MTAof the same name in the same management domain.

Action: Modify the time tolerance using the Time Tolerance options onthe Tuning (Other) pop-up menu from the Local MTAConfiguration window in x400tool . If this does not solve theproblem, check that there are no MTAs with the same name inthe management domain.


A

• The disk containing /var/opt/SUNWconn/OSIROOT/spool isfull

• The free disk space on /var/opt/SUNWconn/OSIROOT/spool isnow big enough for the MTA to go back in normal state

• One remote MTA is down, please check with x400tool thecorresponding MTA and check the connection with that MTA

You can modify the /etc/opt/SUNWconn/osinet/osilogd.confconfiguration file so that these messages are sent to an account other than toroot :

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 SystemThe 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 authorizedservice provider.

Abnormal remote MTA state [MTA <mta_id>]

Abort Confirm from MTA <mta_id> Reason code=<code>

Abort indication from MTA <mta_id> Reason code=<code>

APDU Descriptor error

ASM Unknown Event EVT=<code>

Body type error: body type <description>

Connection is aborted by the provider

Connection is aborted by the remote user

Decoding error: -Status <asn1_status> Index <asn1_index>

Error Messages 191

A

Decoding error: [ASN1 status=<errno>] Index <asn1_index>

Error - Unknown: <description>

Illegal application protocol MTA <mta_id>

Inhibition flag set MTA <mta_id>

Interaction file error: FIERR=<status>

Invalid original MPDU error

Local User Error EVNT=<event> RTS=(<ctx>,<st>)

No free association MTA <mta_id>

Prot Error Num=<num> RTS=(<ctx>,<st>)

Protocol error STATE=<current_state> [MTA=<mta_id>]

Protocol error: state=<current_state>

Provider Abort NUM=<num> RTS=(<ctx>,<st>)

Refuse confirm from MTA <mta_id> Reason code=<code>

Refuse response issued

Remote RTS User Abort RTS=(<ctx>,<st>)

Some recipients in the MPDU are unreachable: <description>

Still associations for MTA <mts_id>

Time-out RTS=(<ctx>,<st>)

Timer Block Id error - N_CNF

Transfer Resumption Reject (illegal seci)

Transfer Resumption Reject (illegal aci)

Unable to identify remote MTA

Unknown database: LUAG <ident>

Unknown Event Code EVT=<code>

Unknown refuse reason code MTA <mta_id> Reason code=<code>


A

Unsupported Body Type

User Error: <description>

Usrdata decoding failure

Warning! the following MTA is closed MTA <mta_id>

Errors Indicating Rejected RFC1006 ConnectionsIf you use RFC1006 (TCP/IP) transport as provided by SunLink OSI, you mayreceive error messages indicating that connections have been rejected. Thismay be because SunLink OSI has a default connection pool size of 4. To avoidrejected connections, use ositool to increase the number of connectionsallowed per TCP/IP subnetwork. See the SunLink OSI Communication PlatformAdministrator’s Guide.

193

Technical Specification andConformance Information B

This appendix contains a technical specification for the Solstice X.400Messaging Server. It includes a brief description of the ITU (formerly known asthe CCITT) X.400 recommendations to which it conforms and a list of theimplemented features.

For further information on standards conformance, see the Solstice X.400Programming Reference Manual. For information on SNMP agent standardsconformance, 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

ITU (CCITT) MHS Recommendations Overview page 194

Solstice X.400 Messaging Server Feature List page 195


B

ITU (CCITT) MHS Recommendations OverviewX.400 MHS System Service and Overview: Describes in general terms how anoriginator interacts with a UA to prepare and receive messages, how a UAinteracts with an MTA, and naming and addressing conventions.(ISO 10021-1)

X.402 MHS Overall Architecture: Describes the overall system architecture ofthe X.400 MHS including suggested configurations, naming, and addressinginformation.(ISO 10021-2)

X.403 MHS Conformance Testing: Provides guidelines and rules forconformance testing of MHS implementations.

X.407 MHS Abstract Service Definition: Specifies conventions used indistributed information processing.(ISO 10021-3)

X.408 MHS Encoded Information Type Conversion Rules: Providesguidelines for code and format conversion algorithms used in the MHS.

X.411 MHS MTS Abstract Service Definition and Procedures: Describes howthe user can exchange messages with the MTS based on abstract servicedefinitions and syntaxes.(ISO 10021-4)

X.413 MHS Message Store Abstract Service Definition: Describes how toimplement a message store.(ISO 10021-5)

X.419 MHS Protocol Specifications: Describes the procedures used toexchange messages between the components of the MHS. Defines threeprotocols P1, P3, and P7.(ISO 10021-6)

X.420 MHS Interpersonal Messaging System: Describes the procedures andsyntax used for the exchange of interpersonal messages (electronic mail).(ISO 10021-7)

Technical Specification and Conformance Information 195

B

Solstice X.400 Messaging Server Feature ListThe following sections list the service elements defined in the 1988 revision ofthe ITU X.400 recommendations.

MT Service Elements (P1)

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-1 Basic Message Transfer Service Support

Message Transfer Basic Service ElementsOutMTA

OutGway

InMTA

InGway

Access management S S S S

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 S S3

Non-delivery notification S S S N4

Original encoded information types indication S S5 S S5

Submission time stamp indication S S S S

User/UA capabilities registration n/a n/a S S

Table B-2 Optional Message Transfer Service support

Message Transfer Optional Service ElementsOutMTA

OutGway

InMTA

InGway

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


B

Deferred delivery S S1 S S1

Deferred delivery cancelation S N S N

Delivery notification S S S S2

Designation of recipient by directory name S N n/a n/a

Disclosure of other recipients S S3 S S4

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 S S S S

Hold for delivery n/a n/a N

Implicit conversion n/a n/a

Latest delivery designation S S5 S N

Message flow confidentiality N N

Message origin authentication N N

Message security labeling N N

Message sequence integrity N N

Multi-destination delivery S S S S

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 S N8

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



OutGway

InMTA

InGway


B

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 negativedelivery 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 maynot be the final one, this report has no real meaning.

9. An adaptor parameter determines whether “return of content” is requested in the message ormanaged locally.

10. Return of content will be performed by the IPM message carrying the negative delivery report.

IPM Service Elements

Restricted delivery N N N N

Return of content S S9 S S10

Secure access management n/a n/a

Table B-3 Basic Inter-Personal Message Service Support

Message IPM Service ElementsOutMTA

OutGwy

InMTA

InGwy

IP-message identification S S S S

Table B-4 Optional Inter-Personal Message Service Support


OutGwy

InMTA

InGwy

Additional physical rendition N n/a

Authorizing users indication S S S S

Auto-forwarded indication n/a n/a S S

Basic physical rendition n/a n/a



OutGway

InMTA

InGway


B

Blind copy recipient indication S S S S

Body part encryption indication S S1 S S1

Counter collection n/a N

Counter collection with advice n/a N

Cross-referencing indication S S S S

Delivery via Bureaufax service N n/a

Express Mail Service (EMS) N n/a

Expiry date indication S S2 S S2

Forwarded IP message indication n/a n/a S S12

Importance indication S S3 S S4

Incomplete copy indication S S4 S S5

Language indication S S5 S S6

Message flow confidentiality N N

Multi-part body S S6 S S7

Non-receipt notification request indication S N7 S N8

Obsoleting indication S S8 S S9

Ordinary mail N n/a

Originator indication S S S S

Physical delivery notification by MHS N n/a

Physical delivery indication by PDS N n/a

Physical forwarding allowed S S9 S S10

Physical forwarding prohibited S S10 S S10

Primary and copy recipients indication S S S S

Receipt notification request indication S N8 S N8

Registered mail N n/a

Registered mail to addressee in person N n/a

Reply request indication S S10 S S11

Reply IP message indication S S S S

Request for forwarding address N n/a

Sensitivity indication S S11 S S12



OutGwy

InMTA

InGwy


B

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.

Special delivery N n/a

Subject indication S S S S

Undeliverable mail with return of physical message n/a n/a



OutGwy

InMTA

InGwy


B

Message Store Service Elements

Table B-5 Basic Message Store Service Support

Message Store Service ElementsOutMTA

OutGwy

InMTA

InGwy

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

Message Store Service ElementsOutMTA

OutGwy

InMTA

InGwy

Stored message alert S n/a S n/a

Stored message auto-forward S n/a S n/a

201

Index

Numerics1984 version, 85, 931988 version, xxii, 7, 70, 85, 93, 1951992 version, xxii, 70

Aabnormal events, 190abnormal transfers, 146acceptor checkpoint size, 53access control, 42, 68, 92, 97access unit, 3added features, xxaddress conversion, 122ADMD, 6, 8, 10, 44, 69, 85administrative management domain, See

ADMDalarms, 184alias, 13, 74, 134alternate recipient, 104alternate recipients, 104application entity qualifier, 74application process title, 74application programs, 3architectural attributes, 7ASCII message, 5

ASN.1, 168association, 47, 76association control service element

(ACSE), 167association retention timeout, 48attachments, 15attributes, 7, 8

categories, 7keys, 7

audit, 61authentication failures, 145

Bback to normal, 63backup

address, 72configuration, 29message store, 160

billing, xx, 5, 6, 64binaries, 23Blue Book (CCITT), xxiibody types, 85, 89, 93bodypart, 4, 5, 116

CCCITT, xx, xxii, 7, 193


cetables file, 112characters allowed, xxiiicharges, 6client, See user agent (UA)configuration

backup, 30regenerate, 160restore, 29

congested state, 63congestion thresholds, 62connection

request, 147response, 147

CONS network interface, 71, 91, 142content

return, 117types, 85, 94

country-name, 8, 10critical state, 63custom mail header, 135

Ddatabase files, 31default

associations, 76MTA, 80, 106pseudo host name, 116, 118route, 80, 81, 129routing entries, 103

default connection pool size, 192delivery

report, 19, 61system, 19

directory access protocol (DAP), 20directory name, 13, 74directory service, See X.500directory system agent (DSA), xx, 20, 73

icon, 26directory user agent (DUA), xx, 20distinguished name (DN), 13, 74distribution list, 7, 20DNS, 118

document set, xxiidomain, 6

address, 113, 134ADMD, 6global identifier, 6, 69, 102PRMD, 6

domain-definedattributes, 7, 10, 11, 87identifiers, 138

EEDI, 94EDI messages, 5EDIFACT, 5electronic messages, xxiiend-users, 1envelope, 4environment variables, 24error messages, 173Ethernet, 142executable program files, 23external content type, 94

FFDDI, 71file prefix, 29filter option, 127flags, 19formatted address, 12

GG3 (fax format), 93G4 (fax format), 93gateway, 3gateway, See Internet adaptorgen_sendmail.cf , 112, 130geographical attributes, 7given-name, 10global

domain identifier, 6, 44, 69, 98, 102,

Index 203

129X.400 domain, 6, 7, 15

Hheader, 4, 5, 135

IIA5 (text format), 93idle association timeout, 48, 78incoming messages, 49information base, 14, 31, 149, 159initiator checkpoint size, 53international characters, 15, 116, 136Internet adaptor, xvii, 15, 16, 111

address conversion, 122icon, 26testing, 121

Internet mail, 111, 126, 133address, 17application, 18domain, 15, 18domain address, 113, 116mailer program, 18

Internet-style addresses, 130interpersonal messaging protocol (P2), 4invalid

address, 79characters, xxiii

invoicing, 5, 6IP address, 118IPM service elements, 197, 200ISO 10021, 194ISO 6937 format, 94ITU, xxii, 193

Jjournal files, 163

LLAN, 72, 142

length of name, xxiiiletter, 4license, 112LLC1, 71, 142local

routing table, 14, 80, 129user agent, 91

log files, 31, 173logging daemon, 189

Mmail

host, 113, 114, 131server, 113

mail , 133mailbox, 16, 18mailer program, 18mailtool , 15, 133management application, xxmanagement domain, 6, 102mapping tables, 126, 128, 132master configuration, 29max remote associations, 77MCIMAIL, 6message

access (MA) interface, 89elements, 17handling system (MHS), 1header, 5queues, 48tracking, xx, 64transfer protocol (P1), 4transfer system map, 26

message adaptor, 3See Also Internet adaptor

message gateway, 89message queue interface, 97message store (MS), xvii, 3, 14, 83

icon, 26name, 42, 67, 84protocol (P7), 4user group, 14


message transfer agent (MTA), xvii, 3, 6database, 31, 166icon, 26name, 42, 54, 67

message transfer system (MTS), 3messaging client, See user agent (UA)messaging server, 3

See Also message transfer agent(MTA), message store (MS)

MIME, 15, 117minor synchronization, 53mixed format, 94mnemonic O/R address, 10modifying sendmail.cf , 119monologue, 77MS service elements, 200MT service elements (P1), 195mt_open(), 96MTS access protocol (P3), 4multimedia attachments, 15multiple end-users, 7Multipurpose Internet Mail Extensions,

See MIME

Nname length, xxiiiname service, 118new features, xxNIS, 16, 118NIS+, 118non-delivery report, 61non-standard content type, 95non-urgent

messages, 49queue stay-time, 50

normalmessages, 49queue stay-time, 50state, 63

notation, 9NSAP, 72

numeric O/R address, 11

OO/R address, 7, 9, 10, 13, 20, 101, 104O/R name, 13ODA, 94Office Documentation Architecture - see

ODAoperation protocol data unit (OPDU), 56organizational attributes, 7organizational-unit, 10organizational-unit-names, 10organization-name, 10originator, 4originator/recipient address, 7OSI

address, 54, 71, 72, 74displaying, 142

communication platform(stack), xvii, 21, 192

reference model, xxiiOSI alarmer, 189OSI stack

starting, 24OSI transport, 24osi_trace , 79osimta , 25, 167osismtpx400 , 129osix400mail , 17osix400mqa , 25osix400ms , 25, 168osixapia , 167outgoing messages, 17

PP1, 4, 71, 142

access, 97applications, 97user name, 96users, 37, 89, 96

P2, 4, 85, 93, 94

Index 205

P22, 4, 85, 93, 94P3, 4, 5, 71, 85, 142, 167, 170P7, 4, 71, 142, 167, 170password, 42, 87, 92personal attributes, 7, 87personal-name, 8, 10physical delivery, 12postal

O/R address, 12primary IP address, 118print configuration, 30private management domain, 6PRMD, 6, 8, 10, 44, 69processes

starting and stopping, 25, 28product-specific

spool directory, 17protocol data unit (PDU), 21pseudo host name, 16, 115, 116, 118, 130,

134PTT, 6purge, 31

mail queue, 156message store, 159

Qqueues, 48, 97

directory, 97size, 97

Rrecipient, 4

alternate, 104recovery attempts delay, 48refresh interval, 143regenerating the configuration, 164relative distinguished name (RDN), 13relaying messages, 3reliable transfer service - see RTSremote

MTA, 80

user agent, 91remote operations service (ROSE)

flow control options, 56resource management options, 57tracing, 167

representing O/R addresses, 9restore

configuration, 29message store, 160MTA database, 166

retry connection timeout, 48RFC 1006, 71, 142

driver, xvii, xxrejected connections, 192

RFC 1148, 126RFC 1327, 19, 111, 126RFC 1341, 15RFC 822, 15, 19, 111, 126RFC 987, 19, 126rk6d , 21rk6stat , 21rk6trace , 21router, See message transfer agent (MTA)routing, 14

algorithm, 106messages, 3, 115table, 14, 80, 95, 99, 129

RTSbusy indications, 145inactivity timeout, 53tracing, 168version, 70

Ssecurity options, 54send test message, 123sendmail , 15, 16, 18, 112sendmail.cf , 16, 112, 119, 130, 133sent

data, 46data threshold, 48message threshold, 48


messages, 46server, See messaging serverservice

charges, 6elements, 15, 195

session layer, 58connection timer options, 59functional unit options, 60protocol options, 59

sfd (simple format document), 93shortage condition, 46SMTP, xviiSNMP agent, xvii, xx, 193sorting office, 14special abbreviations, 138spool

directory, 16, 17, 31files, 31, 166

spreadsheet, 64standard attributes, 7start rule, 132starting x400tool

locally, 25remotely, 26

statecongested, 63connected, 78critical, 63disconnected, 78normal, 63

statusInternet adaptor, 149, 151local MTA, 145message store, 149printing, 144remote MTA, 146user agent, 153windows, 143, 144

supplementary info, 117supported

body types, 85, 93standard content types, 85, 94

surname, 10

synchronization, 53

TT.100, 93T.101, 93T.61, 93TCP/IP, 21, 71, 72, 142, 192teletext, 93telex, 93terminal identifier, 87terminal O/R address, 11test

address conversion, 122association, 77message, 123

third-party users, 37, 96, 104thresholds, 47, 76time tolerance, 62timer unit, 50tool properties, 143transfer charges, 6translating addresses, 122transport layer interface (TLI), 21two way, 77type of access, 97typical X.400 MHS, 1

Uunacceptable dialog mode, 146unconfirmed delivery, 61undefined body type, 93unidentified content type, 94UNIX mail, 111, 126, 133

mailer program, 18UNIX-style addresses, 130unreachable MTA, 79urgent

delivery, 19, 135queue, 49queue stay-time, 50

Index 207

user agent (UA), 3, 104name, 91type, 91

Vvalid characters, xxiiiversion

RTS, 70X.400, 70

videotex, 93voice, 93

WWAN, 71, 142

XX.121, 5, 11, 80, 87X.25, 71, 72, 142X.25 address, 72X.400

addresses, 7, 122, 138flags, 19headers, 135mail, 3mail domain, 17overview, 4recommendations, xxii, 193version, 70

X.402, 7, 194X.403, 194X.407, 194X.408, 194X.411, 194X.413, 194X.419, 194X.420, 194X.435, 5X.500, xx, 13, 20X/Open, 96x400_genconf , 164

x400dblist , 166x400dbload , 166x400dbrecover , 166x400dbsave , 166x400decode , 170x400-gate, 16x400tool , 23x400trace , 167

examples, 168XAPIA, 96

network access, 97

Yypmatch, 118

solstice x.400 messaging server 9.0 administrator's guide

Documents