Implementing X.400 Backbones a Guide for Planners and Support Staff

Implementing X.400 Backbones A Guide for Planners and Support Staff

David Ferris Cemil Betanov

Ferris Research information for planners and implementers of enterprise messaging Copyright ©1995 by Ferris Research, Inc. All rights reserved. Reproduction prohibited without permission. No part of this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, photocopying, mechanical, recording, known today or hereafter invented—without the prior written permission of Ferris Research.

The material contained herein is based on information Ferris Research believes is reliable, but its accuracy and completeness cannot be guaranteed. No liability is assumed for the use of any materials presented herein, nor for any errors or ommisions which may remain.

Table of Contents

Sponsor Credits

Preface iii How the Report is Organized iii Development Method iv Product Assessments iv Development Team vii David Ferris, Editor and Principal Investigator vii Cemil Betanov, Co-Author vii About Ferris Research viii Authors' Thanks ix

Executive Summary xi Report Highlights xii Alternative Technologies xii Message Transfer System xii Directories xiii Gateways xiii APIs xiii Management xiii X.400 UAs xiv ADMDs xiv Other xv

1. Introduction 17 1.1 Messaging System Services 17 Fundamental Services 19 Message Preparation Services 19 Message Store Services 20 Transport Services 20 Directory Lookup Services 21 Message Status Services 22 Directory Support Services 23 Gateway Services 23 Automated Housekeeping Services 24 User Account Housekeeping Services 25 General Management Services 25 User Agent & API Services 25 User Agents 25 APIs 26

1.2 What's an X.400 Backbone?T 26 Evolution as Integrator of Non-X.400 Systems 27 Why Point-to-Point Gateways are Impractical 2828 The Backbone Approach 3030 Message Switches, or E-Mail Integration Sofiware 3131 Basic Backbone Features 3232 Backbone Requirements 3232 1.3 The Backbone as Vehicle for PC E-Mail Reliability 3333 Reasons for PC E-Mail Unreliability 3333 How an X.400 Backbone Can Improve Reliability 3434 1.4 Backbone Components 3535 Backbone Connecting Non-X.400 Systems 3535 E-Mail Systems Connecting to the Backbone 3636 Underlying Data Communications Links 3636 Where Messaging Services are Provided 3737

2. X.400 Technology Background, Part I 4141 2.1 Message Format 4141 The P1 Protocol 4141 The P2 Protocol 4141 The P22 Protocol 4343 The PO Protocol 4343 The FEDI Protocol/X.435 4343 Body Parts 4343 Delivery Notifications 4343 Receipt Notifications 4444 2.2 User Agent & Message Store 4545 Transit Via Message Store 4646 Transit Via Direct MTA Submission 4646 Access By Non-X.400 User .Agents 4747 2.3 Message Transfer Agent 4747 MTA-MTA Authentication 4848 Security by Limiting Correspondents 4949 2.4 ADMDs & PRMDs 4949 2.5 Addresses 5050 Mnemonic ORAddress 5050 X.400 Addresses and Routing 5252 X.400 Addresses Are Hierarchical 5252 Values Usually Lower Case 5252 Domain Defined Attributes (DDAs) 5353 2.6 File Transfer and Conversion 5454 Unspecified File Attributes 5454 Large Files 5454 Transfer Cost 5555 File Conversion 5555 2.7 Directory Services 5555 The X.500 Directory 5555 X.500 Architecture 5656 X.500 Problems 5757 Directory Synchronization Within An Organization 5858 Directory Propagation 6060

Copyright 1995 by Ferris Research, Inc. All rights reserved. Reproduction prohibited without permission. 2.8 Distribution Lists 60 Management Issues 60 Recommendations 61 2.9 More on Addresses 62 What The Problems Are 62 Absurdity of Including ADMD Names 62 A=Single Space 63 Organizations with Multiple ADMDs 63 ADMD Attribute in PRMD-PRMD Connections 64 Country Attribute and Multinational Organizations 64 Indigestible 0= and OU= Information 64 Address Format Recommendations 65 Yardstick: Internet Addresses 65 Industry Simplification Attempts Going Nowhere 65 Address Convention Recommendations 66 EMA's Standard Mailbox Recommendations 67 Auto Answer Mailbox 68 Directory Services Mailbox 68 Helpdesk Mailbox 68

3. X.400 Technology Background, Part II 69 3.1 Data Communications Links 69 Messaging Protocols 69 Transport Protocols 70 X.25 70 Asynchronous Protocol Specification 71 APS Relevance & Status 71 Summary 72 3.2 1984, 88, 92 Specifications 72 Differences Between 84 and 88 Versions 73 Connecting 1984 and 1988 Systems 73 3.3 X.API Association 74 Goal: Hide X.400 Complexity From Programmers 74 3.4 Connecting to An ADMD 75 X.25 75 Installation & Planning Effirts 75 Dialup Connections 76 3.5 Support for EDI 76 X.435 Basics 78 3.6 Security 78 US Government Restrictions 79 Interoperability 80 3.7 Connecting To Customers & Trading Partners 80 Alternatives to X400 Connections 80 X.400 External Connectivity Benefits 81 PRMD-PRMD Connection Benefits 82 PRMD-ADMD Connection Benefits 82 Making The Physical Connection 83 Internet As PRMD-PRMD Connection 83 X.400 Connectivity Shortcut: Service Provider's X.400 Gateway 83 SMTP/MIME and the Internet 86 SMTP/MIME As Backbone 86 Standards Definition Faster Than ISO 87 SMTP/MIME Advantages As Backbone 87 SMTP/MIME Disadvantages As Backbone 89 PC E-Mail Everywhere 90 Advantages Of PC E-Mail Everywhere 90 Disadvantages Of PC E-Mail Everywhere 91

4. Directory Services 93 4.1 What's a Directory? 93 System Directories 94 Messaging Directories 95 Employee Directory 95 Special-Purpose Directories 95 4.2 The Messaging Directory 95 What Information is Stored? 96 The Important Issues 96 4.3 Address Lookup 97 Lookup Tightly Integrated With Application 97 General-Purpose Directory Query 98 4.4 User Administration 99 Centralized vs. Distributed Administration 99 Role of Human Resource Database 101 Distributed Personnel c Network Management 101 Autonomous Divisions with own HR 101 International Organizations 101 Product Support for Centralized Administration 102 Administration-by-Mail 102 Initial Directory Load 102 Other Database Connections 102 4.5 External Access 103 Role of X.500 103 Proprietary Access Control for X.500 104 Access by Autonomous Divisions 104 4.6 MTA Routing 105 Routing Table Maintenance is a Major Scalability Obstacle 105 Bad Solution: Put Routing Information in Addresses 107 Bad Solution: Routing Hubs 108 Problems of Hub-and-Spoke Architectures 110 Good Solution: Directory-Based Routing 110 Advantages of Direct Routing 110 Occasions When Relaying Makes Sense 111 X.500 is Focus of Action 112 ISODE Consortium Approach 112

5. Directory Synchronization 115 5.1 Propagation vs. Synchronization 115 Name and Address Translation is Also Required 116 5.2 How Directory Synchronization Works 117 The Master Directory 117 The Synchronization Process 117 International and Cross-Division Synchronization 120 Directory Propagation 121 5.3 Product Solutions 122

Copyright ©1995 by Ferris Research, Inc. All rights reserved. Reproduction prohibited without permission. Avoid Building Your Own Directory Synchronization 122 Lotus/SoftSwitch's Directory Synchronization 123 How it Works 123 Strengths 124 Weaknesses 125 Retix' DX 125 5.4 Implementation Issues 126 Use Third Party Packages if You Can 126 Filtering & Security 126 Verification Tools. 127 Role of X.500 127 Synchronization Frequency 127 Multi-Tier Synchronization 127 Centralized Administration 128 Don't Confuse With Message Flow 128

6. Address Translation 129 6.1 Survey of Address Formats 129 BeyondMail, ON Technology's eMAII, Notework 129 cc:Mail 130 CompuServe 130 MCI Mail 130 Microsoft Mailfbr PC Networks 131 PROFS/OV 131 QuickMail 131 SMTP/Internet 132 X.400 132 6.2 Basic Translation Concepts 132 Naming Conventions Also Demand Translations 133 Inflexibility of Older Systems 134 Benefits of Name and Address Translation 134 Three Key Translation Requirements 135 How Address Translation Works 135 6.3 Table-Based Translation 135 6.4 Rules-Based Translation 136 Eg: Mapping X.400 Addresses to cc:Mail Addresses 136 Eg: Mapping cc:Mail Addresses to X.400 Addresses 137 .Fg: Mapping X.400 Addresses to SMTP/Internet 137 Eg: DDAs Used To Generate X.400 Addresses 138 Administrator-Selectable Rules 138 Administrator-Defined Rules 138 6.5 How Rules Apply 139 Centralized Translation Required 140 6.6 Autoregistration 142 6.7 Inline Addressing 142 6.8 Translation Problems 143 General 144 No Administrator-Selectable Translation Rules 144 Table-Based Translation Very Laborious to Maintain 144 External Mail Not Delivered 144 Sloppy Naming Conventions 144 Administrator-Selectable Translation Rules Inadequate 145 Duplicate Names 145 Non-Unique Translations 146 MTA Routing Confused by DDAs 146 Multi-Hop Name Translation 146 Co-Recipient Address Translation 147 Autoregistration and Inline Addressing 148 Cryptic Autoregistration Names and Addresses 148 Table Entries Proliferate 149 Multiple Addressesibr Same Person 149 Inline Addressing Easy to Get Wrong 149 Inline Addressing Creates Confusing Messages 149

7. File Transfer & Conversion 151 7.1 Viewers 151 7.2 How File Transfer Works 153 PC E-Mail File Transfer Is Messy 154 X.400 File Transfer Is Messier 154 Body Part 1A5Text/ASCII 155 Body Part Type 14 155 Body Part Type 15 155 File Transfer Body Part 156 7.3 Preserving File Attributes Across X.400 Gateways 156 From Non-X.400 to X.400 156 Tunneling 157 From X.400 to Non-X.400 158 7.4 Large Message Transfer Problems 158 Message Too Large For The System 158 System Breakdowns 159 Service Provider Charges 159 Everyone Gets Delayed 159 7.5 Desktop File Conversion 160 Possible Locations of File Conversion 160 Stand-Alone General-Purpose Conversion Packages 161 Built-In General-Purpose Conversion Packages 161 High End Graphics Conversion Packages 161 7.6 Backbone File Conversion 162 Strategic Advantages of Backbone Conversion 162 How Backbone-Based Conversion Works 163 What the Snags Are 163 Two Important Suggestions 163 7.7 Main Conversion Problems 164 Unknown File Format 164 Fonts Not Available 164 More Complex Documents 164 Basic Graphics 164 Advanced Graphics 165 Spread Sheet Macros 165 Crossing Platforms 165 Out of Date Converters 166 Features Not Translatable 166 OLE Files 167

8. X.400 Gateway Services 169 Main Gateway Functions 169

Copyright CO1995 by Ferris Research, Inc. All rights reserved. Reproduction prohibited without permission. Some Services Can Be Provided Elsewhere 171 Gateways Must Be Customizable 171 8.1 Main Interpersonal Message Conversion Problems 171 International Character Sets 172 Multiple Text Body Parts 172 Special Characters, Embedded Figures, OLE Objects 172 Fonts & Text Layout 172 8.2 Address Translation 173 8.3 File Transfer and Conversion 173 8.4 Tunneling 174 8.5 Directory Synchronization 175 8.6 Notification Processing 175 X.400 to Non-X.400 Processing 175 Non-X.400 to X.400 Processing 176 Transfers Over a Backbone 176 8.7 Message Tracking 177 8.8 Gateway Security 178 8.9 Auxiliary Element Conversion 179 8.10 Special Character Handling 180 DDA Handling 180 Currency 181 8.11 Main Standalone Gateway Selection Criteria 181 Address Translations 181 One-Off Addressing 181 Single Space ADMDs 181 Cost 182 Feasibility 182 File Transfer 182 Delivery Notification 182 Boundary Conditions 183 Tunneling 183 International Character Sets 183 Multiple Text Body Parts 183 Performance 183 File Size Limits 184 Directory Synchronization 184 Vendor Technical Support 184 Integrated Administration 184 Ease Of Installation 185 Extensibility 185 Vendor Development Skills & Future Vision 185 Commitment 185

9. External X.400 Connectivity 187 9.1 On-site Requirements 188 General Requirements 189 X.400 Backbone Requirements 190 Addressing 190 9.2 Direct Connections to Trading Partners 190 Making The Physical Connection 191 Direct Connection Advantages 191 Direct Connection Disadvantages 191 9.3 Connecting To An ADMD 192 ADMD Selection Criteria 192 Correspondents' ADMDs 193 International Connectivity 194 Non-X.400 Services Provided By ADMD 195 Costs 196 Installation Support 196 Post-Installation Support 197 Education 197 Technical Support for Trading Partners 197 Billing 198 Ancillary Services 198 9.4 Selecting An X.25 Carrier 198 X.25 Primer 198 Points of Presence 199 X.25 Advantages 199 Use With X400 200 Costs 200 Tips on Reducing Packet Charges 201 Selection Considerations 201 When To Get X.25 From Your ADMD 201 When To Have Different X.25 and X.400 Carriers 202 9.5 Installation Planning 202 Hardware & Software Checklist 203 Use A Step-By-Step Approach 204 9.6 Major Installation Steps 205 Order Line & Equipment 205 Configure System/Gateway Box or Software 205 Test X.25/Dialup/TCP-IP Link 205 Initial X.400 Tests 206 Test PRMD-ADMD Interoperability 206 Configure MTA Directory 207 Stress Testing 208 Train Help Desk & Operations 208 Pilot 209 Support Trading Partners As Necessary 209 Cutover & User Training 209 Post-Production Support 210 Reminder: Vendor Support 210 9.7 Stress Testing 211 Address Transparency 211 One-Off Addressing 211 Single Space ADMDs 211 Delivery Notifications 212 Boundary Conditions 212 Tunneling 213 International Character Sets 213 Multiple Text/Body Parts 213 Performance 214 Large File Attachments 214 9.8 Virtual PRMDs 214 Pricing 215 Advantages 215 Disadvantages 216 Summary 216

Copyright ©1995 by Ferris Research, Inc. All rights reserved. Reproduction prohibited without permission. 10. Messaging Support Tasks 217 What's Messaging Management? 217 10.1 Basic Concepts& Facilities 218 Management Monitor & Alerts 218 Service Guarantees 218 Structure of Guarantees 219 Structure of Future Guarantees 220 Statistics & Log Analysis 221 Troubleshooting Tools 222 Problem Message Queues 222 Probes 222 Loop Detection 222 Physical Network Problems 223 Thresholds 223 10.2 Major Support Tasks 224 Support Tasks Vary Greatly 224 Size of Support Staff: Planning Guidelines 224 Top Ten Support Tasks 225 Add/Change/Move/Delete Accounts 225 Programming & Utilities Development 226 Ad Hoc Applications Support 226 Returned/Disappeared Messages 227 Installation/Major Upgrades 227 Training 227 Troubleshoot Workstation Environments 227 Invalid Directory Lookups 227 File Viewing & Conversion 228 Forgotten Passwords 228 10.3 Message Management Task Checklist 229 IFIP Messaging Management Definition 229 EMA Messaging Management Committee Definition 230 Our Approach: Base on Messaging Tasks 230 Types of Staff Required 230 Basic User Support 231 User Adds, Moves, Changes, Deletes 231 Message Stores & BBS 232 Directory & Distribution Lists 234 Transport & Gateways 235 External Connectivity 236 Fault Management 239 Primary Diagnostic Methods 239 Performance & Capacity Management 241 Security 241 Suggestions for Operational Security 241 Message Access Controls Beyond Tour Premises 243 Chargeback 244 Chargeback System Development Methodology 244 Inventory Management 245 Housekeeping 245 10.4 Checklist of Additional Support Tasks 246 Training & Consulting 246 Management Utility Development 248 Policies & Procedures 248 Technology Planning & Staff Management 250 11. Messaging Management 253 11.1 A Management Standards Primer 253 Network Management Model 254 Why Management is Often Proprietary 255 SNMP Management 256 The Protocols 256 Reasons for Popularity 257 SNMP Versions 257 General-Purpose Management Application Environments 258 Vendor Enhancements 258 CMIP 259 Summary 259 MADMAN's MTA, DSA, and MS MIBs 260 11.2 Messaging Mangement Standards 260 Network Services Monitoring MIB 260 MTA Monitoring MIB 260 X.500 DSA Monitoring MIB 261 Message Store MIB 264 MADMAN Assessment 264 Infonet Software's MADMAN Implementation 264 EMA's Messaging Management Committee 266 User Requirements Definition 267 Technical Sub-Committee 267 Assessment 268 ISO/ITU X.400 Management 268 IFIP E-Mail Management 270 EMA's Inter-MTA Message Trace 270 Trace Message Request Format 271 Trace Message Reply Format 271 DMTF, Document Management 272 11.3 Some Important Mail Management Products 272 Probe Monitors 272 How Probes Are Used 273 Types Of Probe 274 X.400's Built-In Probe Support 275 Strengths 275 Weaknesses 275 Baranof Software's MailCheck 275 Strengths 275 Weaknesses 276 Mail Monitor by Lotus/SoftSwitch 276 Strengths: 276 Weaknesses: 276 Log Monitors 277 Strengths 277 Weaknesses 277 Lotus' cc:Mail View 278 How it Works 278 Strengths 280 Weaknesses 280 ABS' Gateway Manager 281 How It Works 281 Strengths 282 Weaknesses 282

Copyright ©1995 by Ferris Research, Inc. All rights reserved. Reproduction prohibited without permission. 11.4 Key Future Developments 282 Limited Cross-System Management 282 Better Intra-System Utility Integration 283 Standard MIBs With Proprietary Extensions 283 Growing Use of SNMP 283 Use of General-Purpose Management Application Environments 284 Control and Configuration With Proprietary Applications 284 Proprietary Applications Under Open View Node Manager 284 Use of Applications-Oriented Management Environments 284 HP's OperationsCenter 285 Most Management Will Remain Proprietary 286 11.5 Top Ten Performance Bottlenecks, & Solutions 287 Large File Transfers 287 Solutions 288 Message Store Congested/Full 288 Solutions 289 DOS MTA Stops Working 289 Solutions 289 Message Flow Inconsistent With Traffic Flows 290 Solutions 290 Message Flow Inconsistent With Physical Network 290 Conflicts With WAN Design 290 Conflicts With Local LAN 291 Solutions 292 MTA Accessing Message Store Over WAN 293 Solution 293 Congested Routing Hubs 293 Solutions 293 Dial-in Users With Slow Lines 294 Solution 294 Gateway Thruput 294 Solutions 294 Too Many Users On A File Server 294 Solutions 295

12. X.400 User Agents 297 12.1 X.400 UA Products 297 Market Penetration 298 User Functionality 299 Special X.400 UA Features 299 Technical Summary 301 12.2 X.400 UA Strengths 302 User Perspective 302 Distributed, World-Wide Directory 302 Multiplatform Support 302 Connectivity With Arbitrary Third Parties 302 Flexible File Transfer 303 Reduced Feature Mapping Problems 303 Advanced Messaging Features 303 Handling Files of Indeterminate Format 304 Faster Access to Public Key Cryptography 304 No Difference Between LAN and Remote Versions 304 Support Perspective 304 Wide Choice of Transport, Message Store, and Directory Suppliers 304 Choice of Other UA Suppliers 305 Less Dependence on Product/Vendor Survivability 305 Directory Management Much Simpler 305 Competition Between Vendors 305 Greatly Simplified Management With OSI and TCP/IP 305 Single Management Technology 306 No File Redirection Overhead 306 12.3 X.400 UA Weaknesses 306 Small Market Share Issues 306 Vendor Financial Stability 306 Few Tightly Integrated Applications 306 Keeping Up-to-Date 307 Limited Support by Third Party Products 307 Documentation 308 X.400 Model Inadequacies 308 Flat, Read-Only Message Store 308 Limited Message Store Intelligence 308 Interpersonal Messages Only in ASCII 308 File Attributes Lost During Transfer 309 X.400 Address Complexity 309 Support Issues 309 More Technical Expertise Required 309 Different UA and Transport Vendors 309 Proprietary Enhancements Dilute Standards Benefits 310 12.4 Who Uses XA00 UAs? 310 TCP/IP and Standards-Based Orientation 311 Greenfield Sites 311 Organizations Satisfying GOSIPs 311 X.500-Struck 311 12.5 Future X.400 UA Market Share 312

13. API Access 313 Programmatic vs. File-Based APIs 314 Overview of Popular APIs 314 13.1 File-Based APIs 315 The NetWare MHS API 317 How It Works 317 CMC, MAPI as Alternatives to SMF 318 cc:Mail's Import/Export 319 Microsoft's FFAPI 319 13.2 Programmatic APIs 320 Programmatic API Strengths 321 File-Based API Strengths 322 Programmatic APIs Generally Superior 322 CMC or Common Messaging Calls 322 Simple Send 323 Future Outlook 324 VIM 324 More Sophisticated Than CMC 325 VIM v2.0 326 Microsoft's MAPI 326 Simple vs Extended MAPI 326

Copyright ©1995 by Ferris Research, Inc. All rights reserved. Reproduction prohibited without permission. MAPI Services 327 Most Corporate Developers Will Use Only The CMC Subset 327 Service Provider Interfaces 327 X.400 Implications 328 X.APIA's X.400/X.500 APIs 329 Object Management API: XOM 329 Message Store API:.XMS 329 Directory Services API: XDS 330 Message Transfer API: XMT 330 Message Access API: MIA 331 X.API Strengths 331 X.API Weaknesses 331 Relevance to Corporate Developers 332 13.3 API Alternatives 332 DDE 332 Forms Routing and Workflow Packages 332 DBMS Extensions 333 13.4 Which API Should You Select? 334 Avoid APIs If You Can 334 Is A Simple Send Enough? 334 Check Required Functionality 335 Programmatic Rather Than File-Based APIs 335 Try to use CMC 335 CMC Doesn't Imply Portability 335 Avoid MAPI 335 Check Inhouse Programming Skills 336 Avoid the X.APIs 336

14. Case Studies 337 Ministry of Agriculture, Fisheries and Food X.400 UAs & X.500 Directory 337 Computing Environment 337 Messaging Environment 339 Why X.400? 339 System Design 340 Message Transfer System 340 Routing 340 Addressing 342 Message Store Architecture 343 Gateways 343 Directories 343 Architecture 343 Updating The Directory 345 Synchronization With Other E-Mail Directories 345 External Connectivity 345 ADMD Connections 345 Internet Connections 346 Management 347 Traffic 347 Service Guarantees 348 1984 vs. 1988 UAs 348 Authors' Observations 349 System Design 349 Management 349 Other 350 Richard Syrett (1947 - 1995) 350 Florida Power Corporation 352 Computing Environment 352 Messaging Environment 352 Why OpenMail? 353 Why X.400 As Transport? 354 System Implementation 354 Message Transfer Architecture 354 Gateways 356 Directory Synchronization 356 Addressing 357 Addressing Idiosyncracies 357 Mail-Enabled APIs 358 Migration Utilities 358 External Connectivity 358 Observations & Suggestions 358 Dutch Ministry of Transport 361 Computing Environment 361 Messaging Environment 361 Why X.400? 362 Why Go With A Single Vendor? 363 Message Transfer System 363 MTAs 363 Unreliability of DOS-Based MTAs 363 Addressing 364 Routing 365 Message Stores 365 1988 Message Stores & Remote User Access 366 Directories 366 GroupVVise/X.400 Directory Synchronization 367 Only A One-Way Process 367 Gateways 367 SMTP/MIME 367 Group Wise 368 Enhancement Plans 369 Authors' Observations Sc Suggestions 369 Addresses & Routing 369 Directory Synchronization 370 User Agents 370 Remote Support 370 Scalability 371

15. Product Reviews 373

16. Glossary 375

Copyright 1995 by Ferris Research, Inc. All rights reserved. Reproduction prohibited without permission. 17. Bibliography 387 17.1 X.400 Recommendations 387 X.400 Recommendations 387 X.400 .RFCs 388 18.2 X.500 References 389 X.500 Recommendations 389 X.500 RFCs 389 18.3 Chapter References 390 X.400 Technology Background, Part I 390 X.400 Technology Background, Part II 390 Directory Services 390 Directory Synchronization 391 File Transfer And Conversion 391 External Connectivity 391 Messaging Support Tasks 392 Messaging Management 392 API Access 392 18.4 Electronic Retrieval 393 X.400/X.500 Recommendations 393 .17/ P 393 E-Mail 394 Gopher 394 Asynchronous Protocol Specification 394 P 394 RFCs 395 it P 395 E-Mail 395 Gopher 395 NIST 395

Vendor Yellow Pages 397

Figure A End User Interviewees v Figure B Vendor Interviewees vi Figure 1.1 Fundamental Messaging Services 18 Figure 1.2 User Agent & API Services 26 Figure 1.3 Unconnected E-Mail Systems 28 Figure 1.4 Gateways Connecting E-Mail Systems 29 Figure 1.5 Gateway Proliferation 30 Figure 1.6 E-Mail Systems Connected by a Backbone 31 Figure 1.7 Physical Structure of an X.400 Backbone 36 Figure 1.8 Location of Fundamental Messaging Services 37 Figure 1.9 Location of User Agent & API Services 39 Figure 2.1 X.400 Message Format 42 Figure 2.2 X.400 Delivery Notification Format 44 Figure 2.3 X.400 UA, Message Store, & MTA 45 Figure 2.4 Interconnected MTAs Form the Messaging Network 48 Figure 2.5 Connecting PRMDs via an ADMD 50 Figure 2.6 X.400 Address Attributes 51 Figure 2.7 X.500 Directory Components 56 Figure 2.8 X.500 Information Retrieval Methods 58 Figure 2.9 Master Directory Used for Address Mapping 59 Figure 3.1 Technical Summary of X.400 Transport Stacks 72 Figure 3.2 X.APIA Specs 74 Figure 3.3 EDI Interchange Using X.400 77 Figure 3.4 Main X.400 Security Services 79 Figure 3.5 Connecting to the Outside World with X.400 81 Figure 3.6 Service Provider Runs X.400 Gateway 84 Figure 3.7 Internet Messaging Connectivity 88 Figure 4.1 Nexor's PC-DUA 98 Figure 4.2 LOTUS/SoftSwitch's Query-by-Mail 99 Figure 4.3 Centralized vs Distributed Administration 100 Figure 4.4 ISODE Consortium's X.500 Access Controls 104 Figure 4.5 Simple MTA Layout 106 Figure 4.6 New York MTA's Routing Table 106 Figure 4.7 0/R Addresses Containing Routing Information 107 Figure 4.8 Typical Routing Hub Hierarchy 108 Figure 4.9 X.500 Routing Entry for an MTA 113 Figure 5.1 Typical Master Directory Entry 118 Figure 5.2 Directory Synchronization Components 119 Figure 5.3 International and Inter-Division Synchronization 120 Figure 5.4 Hybrid Multi-Level Synchronization 121 Figure 5.5 Lotus/SoftSwitch LMS Architecture 123 Figure 5.6 Lotus/SoftSwitch Synchronization Message Format 124 Figure 6.1 Name and Address Formats Vary Among E-Mail Systems 133 Figure 6.2 Table-Based Translation With an MS Mail/MCI Mail Gateway 136 Figure 6.3 Retix' Administrator-Selectable Rules 138 Figure 6.4 Retix' Administrator-Defined Rules 139 Figure 6.5 A Translation Rules Set 140 Figure 6.6 Address Translation Directory 141 Figure 6.7 Lotus/SoftSwitch Inline Addressing 144 Figure 6.8 Multi-Gateway Address Transformation 147 Figure 6.9 Co-Recipient Address Translation 148 Figure 7.1 Using a Viewer 152 Figure 7.2 How File Attachments are Handled: PC E-Mail vs. X.400 153 Figure 7.3 Preserving Attachment Properties Across Gateways 157 Figure 7.4 Places Where File Conversion Can Occur 160 Figure 7.5 Preserved Text Characteristics 165 Figure 7.6 Common Graphics Formats 166 Figure 8.1 Main Message Elements Processed by a Gateway 169 Figure 8.2 Multiple Body Part Handling 173 Figure 8.3 Life Without Tunneling 174 Figure 8.4 Message Tracking With GroupWise 177 Figure 8.5 Special Character Mappings in DDAs 180 Figure 9.1 Typical X.400 External Connection 188 Figure 9.2 Connecting a Backbone to the Public X.400 Network 189 Figure 9.3 Typical ADMD Message Transfer Costs 191 Figure 9.4 US ADMD Connectivity 193 Figure 9.5 Virtual Multi-Country ADMD 195 Figure 9.6 X.25 Provides On-Demand Links 200 Figure 9.7 ADMD Connectivity Installation Steps 203 Figure 9.8 Virtual PRMDs 215 Figure 10.1 Typical Network Map 219 Figure 10.2 Top Ten Time-Consuming Support Tasks 226 Figure 10.3 Typical Support Task Mix 228 Figure 10.4 Basic User Support Tasks 232 Figure 10.5 User Add, Change, Move, Delete Tasks 233 Figure 10.6 Message Store & BBS Support Tasks 235 Figure 10.7 Directory & Distribution List Support Tasks 236 Figure 10.8 Transport & Gateway Support Tasks 237 Figure 10.9 External Connectivity Support Tasks 238 Figure 10.10 Fault Management Tasks 240

Copyright ©1995 by Ferris Research, Inc. All rights reserved. Reproduction prohibited without permission. Figure 10.11 Performance & Capacity Management Tasks 242 Figure 10.12 Access Control & Public Key Cryptography Tasks 243 Figure 10.13 Chargeback Tasks 244 Figure 10.14 Inventory Management Tasks 246 Figure 10.15 Housekeeping Tasks 247 Figure 10.16 Training and Consulting Tasks 248 Figure 10.17 Management Utility Development Tasks 249 Figure 10.18 Policy & Procedure Tasks 250 Figure 10.19 Technology Planning and Staff Management Tasks 251 Figure 11.1 Network Management Architecture 254 Figure 11.2 MADMAN's Network Services MIB 261 Figure 11.3 MADMAN's MTA MIB 262 Figure 11.4 MADMAN's X.500 DSA MIB 263 Figure 11.5 Browsing a MADMAN MIB 265 Figure 11.6 Plotting MADMAN MIB History 266 Figure 11.7 MailCheck's Main Monitor Screen 273 Figure 11.8 Event Log From Lotus/SoftSwitch's Mail Monitor 274 Figure 11.9 cc:Mail View's Network Map 279 Figure 11.10 Drilling Down For Message Store Details 280 Figure 11.11 HP's OperationsCenter 286 Figure 11.12 Message Flow Conflict With WAN 291 Figure 11.13 Message Flow Conflict With LAN 292 Figure 12.1 cc:Mail User Agent 298 Figure 12.2 X.400 User Agent for Windows 300 Figure 12.3 X.500 Browser With X.400 User Agent 301 Figure 13.1 Use of Messaging APIs 314 Figure 13.2 Major Messaging APIs 315 Figure 13.3 File-Based APIs 316 Figure 13.4 cc:Mail Import/Export Calls 317 Figure 13.5 Message in NetWare MHS SMF-71 Format 318 Figure 13.6 Message in cc:Mail Import/Export Format 319 Figure 13.7 Message in Microsoft FFAPI Format 320 Figure 13.8 Programmatic API Logic 321 Figure 13.9 CMC Calls 323 Figure 13.10 CMC Simple Send 324 Figure 13.11 VIM User Dialog Boxes 325 Figure 13.12 A VIM Simple Send 326 Figure 13.13 Main MAPI Calls 328 Figure 13.14 The X.APIA's Directory Access API 330 Figure 13.15 Mail Enabling With DDE Calls 333 Figure 13.16 Mail Enabling With Forms Routing Packages 334 Figure 13.17 Oracle's Built-In Send Command 335 Figure 14.1 MAFF's Computing Environment 338 Figure 14.2 MAFF's MTA-MTA Layout 341 Figure 14.3 MAFF's UNIX Servers 342 Figure 14.4 MAFF's DSAs 344 Figure 14.5 MAFF Traffic 347 Figure 14.6 OpenMail Architecture 353 Figure 14.7 Florida Power's MTA Layout 355 Figure 14.8 The Dutch Ministry's Local Computing Platform 362 Figure 14.9 Message Transfer Architecture 364

Reliable and significant research is an expensive undertaking. To help keep the costs down for report purchasers, we offer vendors the opportunity to become a charter sponsor. We wish to ACCORDANCE express our thanks to Accordance, Data Connection, Enterprise Solutions, Lo- tus, Microsoft, NET-TEL, NEXOR, Novell, Tandem, Worldtalk, and 011111:4 ' I ZOOMIT for their support in this way. 1 11211111 k,L1-711 -11 In return for a set financial grant, each vendor receives a complementary copy of the report, the right to have their logo displayed in promotional ENTERPRISE SOLUTIONS LIMITED materials, the right to distribute brief extracts of the report for marketing purposes, and an objective review of their products or services (sponsors have no editorial rights of any kind.) In Lotus. addition, each report includes a flyer describing the sponsor's products or Microsoft services in the X.400 field.

*TEL BIS lllll MMMMMM INNS AITANDEM

Worldtalk® NEWOR

M NOVELL MOM/ GroupWare-

Preface

Here, we explain the structure of the report, how it was developed, and the qualifications of the people and organizations involved. We also thank the many people who participated in the work.

How the Report is Organized We first explain the different services provided by a messaging system. Not all of these require a lot of involvement by technical or administrative support staff. Eg, the folder hierarchy in a user's message store is mostly maintained by the user. In this report, we focus on the things that support people must get involved with. We concentrate mainly on issues that often end up being significant headaches, or which need careful attention if they're not to become a significant headache, namely: • Directory services and specifically, directory synchronization • Address translation • File transfer and conversion • X.400 gateways • External X.400 connectivity • Support tasks • Messaging management Then we discuss the pros and cons of X.400 user agents, and various APIs. We present a series of product reviews, and conclude with three case studies.

iii Preface

We don't spend a lot of time on things which, because of their newness or crudeness, are not yet of much practical concern for support staff. Thus, for example, we are brief on chargeback, which isn't widespread at present.

Development Method The authors conducted 70 in-depth interviews, lasting one to four hours, with messaging backbone planners, implementers, and support staff (figure A). The main thrust of these interviews was to understand the interviewee's messaging environment, the problems they had encountered or anticipated relating to X.400 technology, and how these problems could be resolved. Not all interviewees had X.400 backbones: eg, we interviewed some people about messaging support tasks, about the role of directory-based routing, about MAPI, and about file transfer issues. They also conducted 62 interviews with vendor and service provider technical and marketing management (figure B ). These also lasted between one and four hours. Here, the emphasis was on understanding the vendor's offerings, and how the product line would evolve. Interviewees expressed many interesting thoughts, and they often had original and profound insights. However, views are never specifically attributed, so many people aren't getting the credit they deserve. We agreed to keep all opinions and advice confidential so that interviewees could speak candidly about what was working and what wasn't, and because many organizations prohibit staff from commenting publicly about products. In-depth product literature, including technical manuals, was obtained from leading vendors and studied. The authors also studied the X.400 and X.500 specifications, the X.API standards, and related IETF Requests for Comments. The case studies were reviewed by representatives of the organizations concerned. Finally, each chapter was reviewed for accuracy by two external X.400 experts, NEXOR's Julian Onions and Digital Equipment's Donald Livengood.

Product Assessments The main body of the report illustrates its points by reference to any relevant products, whether or not the vendor concerned paid any sponsorship fee. Vendors who paid a sponsorship fee also receive a separate evaluation of their product in the second part of this report.

FIGURE A END USER INTERVIEWEES

a Oita

3M Marcie Kroschel, Paul Peterson Abbott Labs Terry Paskiewicz, Janet Pierce Aerospace Corporation Gary Marshall, Charles Wolverton Aetna Life Li-Hwa Ting Allied Signal Karen Day American Airlines Bob Skinner Amoco Brian Foster Bell South Bob Stevens Boeing Craig Dupler Chase Manhattan Mary Flannery, Julia Lesko Citicorp Cindy Ross Commonwealth Edison Don Basta Comsat Dale Crosnicker, Jim Trotz Corning Lily Wilson Dutch Ministry of Transport Toine Wayers Exxon Durwin Sharp Fannie Mae Jay Jenkins Fidelity Investments Albert Uy Florida Power Ted Kimer, Jim Wells GTE Service Trudy Heatherly Hughes Aircraft Rich Payne Kaiser Permanents Gary Wilkerson Kemper Securities Joel Tapp Martin Marietta Nancy Cox Mervyn's Bob Finnegan Minnesota Power Dennis Hamsher Multex Systems Jim Tousignant National Medical Enterprises Gary Clift Northwestern Mutual Life Blane Woodard People's Natural Gas Jean Stockton Perot Systems Bill Scherer Precision Professional Services Mark Russell Ross Products Kurt Sanders Ryder System Pat Berastegui Sandoz Phil Eden Saskatchewan Property Management Barry Parker Sasktel Ben Checkowy, Rick Edwards ServiceMaster Verlin Karstens Sonat Services Warren Crow State of Wisconsin Theresa Healy Steelcase John Schmieder Sun Life of Canada Joanne Cutler Taco Bell Elizabeth Tesslof Target Rick Geissler Texaco Don Price UK Ministry of Agri, Fish, & Food John McKinnon, Richard Syrett US Army Corp of Engineers York Yarbro US Department of Energy Gene Hughes, Charlie Smith US Environmental Protection Agency Fred Kastner, Greg Williams US National Oceanic & Atmos. Admin. Rob Swisher US Naval Air Warfare Center Brenda Blowers Westinghouse Savannah River Terry Woodward

70 users were interviewed about issues relating to X.400 backbones; of which 8 requested anonymity. Preface

FIGURE B VENDOR INTERVIEWEES Op tat tin:

Adobe Brian Grady Aladdin David Schargel Amadeus Systems David Edgar Apple Andy Lauta Automated Business Solutions Steve Schmiedeskamp Banyan Jeff Bernard, Alex Cullen Baranof Peter Zimmer CE Software Ned Horvath Control Data Systems Bob Anderson Dataquest Chuck Stegman Dataviz Robert Hoxie Delrina Technology Bert Amato, Leo Stutman Digital Equipment Donald Uvengood, Rick Sanders Enterprise Solutions Karl Klessig, Ed Owens Hewlett-Packard Roy Dalpra, Matt O'Donnell, Andrew Ransom Innosoft Ned Freed ISOCOR David Knight ISODE Consortium Steve Kille JetForm Rob Lucier Kandu Ken Lathan Keyword/FTP Bob Gardner Linkage Paul Saunders Lotus Hugo Beck, Steve Cappo, Betsy Chapman, Neil Gehani, Russ Hill, Greg Loux, Kate McKeown, Sayuri Sharper, Mark Szelenyi, David Ziskind, Mike Zisman Mastersoft Karl Forster Microsoft Stuart Schifter, Bill Skilton, Bill Sornsin, Todd Warren, Chris Williams Microsystems Software Steve Karl son Novell Ron Cully, John Gailey, Eldon Greenwood, Phil Schacter Oracle Dave Michaud Qualcomm John Noerenberg Radicati Group Sara Radicati SITA Dave Brown, Jim Zavorski Softarc Scott Welch StarNine Technology Rusty Rahm Systems Compatibility Scott Norder Tandem Sue Lebeck Vector Directory Bill Lucas Worldtalk Simon Khalaf, John Weald

62 vendor interviews were conducted during research for this report.

Ferris Research believes the assessments are independent and objective, rather than biased promotional pieces. To prepare them, we: • Made it a condition of sponsorship that no sponsor would have any editorial rights, and that all reviews would contain an objective assessment of both strengths and weaknesses.

• Interviewed vendor product management and technical support staff. • Studied marketing materials and technical manuals. • Interviewed users on a confidential basis, asking them how they were using the products, and what they thought about them. • Asked the vendor's main competitors to review our draft analysis, and point out things that were misleading, or things we'd missed out. • Asked the vendor to review our draft, and point out any factual mistakes, and opinions they disagreed with. Where we were persuaded of the validity of their points, we made corresponding changes.

Development Team David Ferris and Cemil Betanov researched and wrote this report. Ferris was mainly responsible for the executive summary; preface; chapters 1, 4 through 6, and 10 through 13; and the product assessments. Betanov was mainly responsible for chapter 9, the glossary, bibliography, and index, and for providing a sounding board for all other chapters. Chapters 2, 3, 7, 8, and 13 were a shared endeavor. Ferris acted as editor for the entire report.

David Ferris, Editor and Principal investigator David Ferris writes and edits the Ferris E-Mail Analyzer, a monthly series of white papers analyzing problems which face messaging professionals. He edited and coauthored Implementing Directories, and Integration of PC E-Mail, research reports also published by Ferris Research. According to PR firm Regis McKenna, he is the most frequently quoted e-mail industry analyst. He has been an advisory board member of Comdex, Interface, and NetWorld. A British national, Mr. Ferris came to the US to do a Ph.D. in philosophy at Stanford University, California. He got involved in artificial intelligence, and helped develop the world's first production expert system. He has an MS in Computer Science from Stanford, and has been an enthusiastic e-mail user since the technology's inception in 1974. He divides his time between San Fran- cisco and London, and can be reached at [email protected].

Cemil Betanov, Co Author Cemil Betanov designed, developed and put into production X.400 messaging carrier services for ITT World Communications, Western Union, AT&T, and TRT

vii Preface

Communications. He wrote Introduction to X.400, published in 1993 by Artech House. He holds an MS in Computer Science from Columbia University. He is currently interested in the development of gateways and directories between dis- similar messaging environments, in the management of such systems, and in the use of messaging services over the Internet. He can be reached at [email protected]

About Ferris Research Ferris Research is a research firm specializing in electronic messaging and related technologies. Our offerings in the messaging field include: • A white paper series, the Ferris Messaging Analyzer. This monthly publication provides analysis and practical insight for computer professionals planning, implementing, and supporting messaging technologies. • Research reports and information services. Our current offerings are Implementing X.400 Backbones, a 400+ page report and information service; and Implementing Messaging Directories, a 250+ page report and information service. • Consulting. Telephone and in-person consulting. Over 500 large organizations are regular clients, including Abbott Labs, Bell South, Central Intelligence Agency, Deere & Company, Exxon, FMC, Glaxo, Helene Curtis, Inchcape, J.P. Morgan, Kraft, Los Angeles Times, Monsanto, NASA, Ocean Spray, Polaroid, Royal Insurance, Sun Life, Telecom Finland, US Postal Service, Valmet, Westinghouse, Xerox, Yorkshire Water, Ziff-Davis. Ferris researchers are the most widely-quoted industry analysts, according to PR firm Regis McKenna. Many consulting firms are clients, including Arthur Andersen, Booz Allen, Coopers & Lybrand, Ernst & Young, Gartner Group, KPMG, Meta Group, Rand Corporation. We have over 100 vendor clients, including AT&T, Banyan, Control Data, Digital Equipment, Enterprise Solutions, Fischer International, General Magic, Hewlett- Packard, IBM, JetForm, Keyword, Lotus, Microsoft, Novell, Oracle, Premenos, RAM Mobile Data, SoftArc, Tandem, Unisys, Verimation, Worldtalk, Xcellenet, ZOOMIT. If you need further information on Ferris services, or want to be on our mailing list, call us on +1 415 986 1414. Or e-mail us at [email protected].

Authors' Thanks The authors are deeply grateful for the time, advice, interest, and moral support provided by the interviewees listed in figures A and B. They provided many perceptive insights. Many of our conclusions and recommendations were arrived at solely through their hard-earned experience. Without them, this report would literally not have been possible. We also want to thank: • Our sponsors Accordance, Data Connection, Enterprise Solutions, Lotus, Microsoft, NET-TEL, NEXOR, Novell, Tandem, Worldtalk, and ZOOMIT. It took a long time to do this report, and the research and marketing was expensive. Without their financial support and moral encouragement, the report would not exist. • Julian Onions and his colleagues at NEXOR, and Digital Equipment's Donald Livengood, for their suggestions and corrections. • Michael Miley, for acting as final editor and copy editor. His experience as a professional journalist, and knowledge of messaging technology, made his contribution very valuable. • Anja McClellan, for developing the diagrams, preparing the copy for printing, and managing much of the overall production process. • Barak Kassar, for his help in developing and implementing the marketing plan. • Iwona Gasinska, for designing the covers and advising on final layout and typography.

Executive Summary

Large organizations must connect a variety of different messaging systems, and one common approach to doing so is to implement an X.400 backbone. Simply put, this refers to connecting everything through the use of a common message format, as defined by the X.400 standard. X.400 backbones are attractive because: • A wide choice of products, with varying functionality and price, is available from many vendors. • Products from different vendors work well together. • The technology is in its youth, and is likely to be mainstream for at least 15 years. • Many governmental organizations are standardizing on X.400. • There's good support for binary file transfers. • Some X.400 systems scale well, with such features as large message stores, highly reliable componentry, and centralized management. • The X.500 distributed directory integrates easily and naturally with X.400. • Reliable world-wide connectivity is in place. • The technology works well with TCP/IP and OSI networks. • EDI messages can be sent over X.400. This report explains the technology involved. Most of it describes practical issues of concern to people designing and maintaining an X.400 backbone. The report also assesses various X.400 products. It is based on extensive research, including over 130 in-depth interviews with vendors and messaging professionals.

xi Executive Summary

In the following, we summarize some of the most important conclusions and recommendations.

Report Highlights

Alternative Technologies • SMTP/MIME is cheaper, world-wide connectivity is far better, addresses are usually simpler, standards definition is streamlined, there's very lively experimentation with new technology, and vendors take the rules of open computing to heart. However, there are no delivery notifications, message routing is unpredictable, and there are unpredictable delivery delays; and until MIME is widespread, file transfer is difficult. • Standardizing on a single PC e-mail system is also an alternative. There's very high functionality, much greater market share, many integration problems become trivial, and it's easier to find or train knowledgeable technical staff. But PC e-mail scales poorly and the support costs are usually high. Besides, many organizations will acquire/merge with other organizations and end up with a heterogeneous messaging environment.

Message Transfer System • Most organizations design their X.400 networks with a hub-and-spoke hierarchy. This is a serious mistake. It's much better to allow direct connections between end MTAs. Vendors can help by making directory-based routing available. • Large files transiting the backbone usually cause significant delays. • MTA routing facilities are generally crude. Eg, many MTAs do not allow routing based on personal name attributes, or message size, or time of day. • Many customers adopt X.400 address conventions that incorporate routing information. This is a serious mistake. • Most WAN connectivity is over X.25. TCP/IP and dialup will gradually replace this. • Deployment of dialup communications using the APS standard will greatly reduce cost and complexity. • File attributes such as name and size are generally thrown away. This causes much inconvenience. From 1996, the implementation of body part 15 should make file transfer and processing much simpler.

Directories • For the next 2-3 years, most organizations will adopt directory synchronization as the main directory integration approach. • Directory synchronization is usually highly customized. Standardized approaches, such as that of Retix' DX, are not popular. • X.500 is a superior approach, but is still at an experimental stage. By 1997 it will be proven, and will gradually begin to replace directory synchronization.

Gateways • Many X.400 gateways have poor address translation facilities, and a correspondingly large number of address translation problems. • Many gateways only support 1984 interpersonal messages. • Gateways between X.400 and non-X.400 systems are the source of many support problems. Some of the most important things to check for in an X.400 gateway are address translation, 1-off addressing, single space ADMDs, cost, whether it actually works in your environment, file transfers, and delivery notification handling.

APIs • MAPI will be widely used to access X.400. • Most APIs, MAPI included, are too complex to be used by most programmers. • CMC calls are a practical access mechanism. So are simple, proprietary access APIs such as cc:Mail's Import/Export and Microsoft Mail's FFAPI. • Most X.400 backbone access will be by means of higher level interfaces provided by applications. • APIs, including MAPI and the X.APIs, should be avoided if possible. If they must be used, and a Simple Send suffices, this should be used.

Management • The main support tasks are account administration, programming and utilities development, responding to ad hoc applications questions, and helping users with returned or "disappeared" mail. • Management of remote sites is greatly improved if TCP/IP is widely deployed with UNIX machines running MTAs and message stores. Among other things, a remote login capability is invaluable. • Good work is being done to define message tracking standards. Useful

XIII Executive Summary

implementations will begin to appear in 1996. • SNMP vl will predominate over SNMP v2 and CMIP as management protocol for several years. • The MADMAN MIBs will be widely implemented. However, they will be of limited value, due to their intentionally limited scope. • Over the longer term, centralized, general-purpose messaging management environments are a sine qua non for scalability. Such technology is in its infancy. HP's OperationsCenter is the best example of the state of the art. • Through the year 2000, expect to use a series of different messaging management tools, one set for each connected environment. Cross- system management will be rare, mainly limited to message tracking.

X.400 UAs • It's attractive to deploy X.400 user agents with an X.400 backbone, because no gateways are involved. • It is difficult and usually unwise to mix 1984 and 1988 user agents in a single system. Conversion between the two is not a gradual process. • The 1988 message store is crude—just a flat in-tray. Messages can't be inserted or stored in a folder hierarchy, and message stores have limited intelligence. • UA vendors provide proprietary enhancements to make up for the shortcomings; this greatly reduces multi-vendor interoperability. • X.400 UAs are most attractive to organizations with a strong TCP/IP and standards-based orientation; that are new to e-mail and messaging; that want to adopt GOSIP requirements; and that have a strong desire to use X.500.

ADMDs • ADMDs are shooting themselves in the foot. Because they are squabbling about settlements, they have limited connectivity with other ADMDs and often messages can't be delivered. The requirement to specify an ADMD name in an X.400 address makes addressing unnecessarily complex. The cost of sending messages is too high. • ADMDs offer little added value. Long-term, they will probably be dispensed with entirely. Organizations will send X.400 messages directly to each other, over the Internet.

Other • Most X.400 addresses are unnecessarily complex and should be simplified. • X.400 is implemented on TCP/IP networks much more often than on OSI networks. • 1988 message stores are rare. • The technology is far from stable. Important new developments will occur for the foreseeable future, such as the release of X.400-based transports from Lotus and Microsoft, better support for file attachments, new APIs, APS connectivity, X.500 integration, a much richer message store, security based on public key cryptography, more flexible PRMD to PRMD connections, and better ADMD connectivity. (An update service is available for this report. Contact Ferris Research at +1 415 986 1414 for details.)

Chapter 1

Introduction

A messaging system moves chunks of information between people, between programs, or between people and programs. Many different steps are involved in message transfers, especially if they take place over a messaging backbone (defined later). In this chapter, we review the main services offered by a messaging system and then we explain what a backbone is.

1.1 Messaging System Services A messaging system moves around chunks of information. These chunks can contain readable messages, binary files, spreadsheets, word processor documents, databases, and so on. The services provided by a messaging system to do these transfers we call fundamental services. In the special case where the information being transferred is a note going from person to person—possibly accompanied by one or more files—the message is known as an electronic mail or e-mail message. E-mail professionals tend to call these interpersonal messages or IPMs. Today's systems almost always provide special services for this sort of message, such as: • Carbon copy and blind carbon copy, and • Confidentiality information (eg, private, company confidential, or nonclassified). Messaging systems can also be used simply to transfer files. This is usually implemented as a special case of an interpersonal message. We should also note that

17 1 Introduction

some messaging systems understand how to prepare and dissect EDI messages. All these specific uses of a messaging system—for e-mail, file transfer, and EDI applications—we call user agent services. Finally, there are services which actually let you use the features we've just discussed. User agents let human beings access the messaging system, and APIs or application programming interfaces let programs access it.

Fundamental Services The ten groups of services shown in figure 1.1 all deal with the gory details of getting a message of arbitrary type from sender to recipients:

Message Preparation Services These let you specify the general-purpose components of a message: • Who the recipients are. • The message priority—that is, how fast it should be transferred. • The nature or type of any enclosure. Eg, it might be an interpersonal mes-

FIGURE 1.1 FUNDAMENTAL MESSAGING SERVICES

Message Specify recipients Preparation Specify priority Services Specify nature or type of enclosure Authentication & encryption Rare Will be

Message Create & delete folders Partially Store Move & delete messages 9 Services Automated assistant services Rare Access control Message store reorganization Message store backup/archive/restore 9 Transport Message routing 9 9 Services MTA-MTA transfer 9 External connectivity 9 9 Access control 9 MTA log reset/archive/restore 9 Directory Address lookup 9 9 Lookup User-friendly name lookup 9 Services Ancillary identification information lookup 9 9 Distribution list lookup 9 9

Address translation lookup Preferred file format lookup Rare MTA routing lookup Rare Authentication & encryption lookup Rare Will be Other interesting information lookup 9

Message Request delivery notifications 9 Status Request receipt notifications 9 Services Message tracking Rare 9 Message trace & recovery Rare 9

Directory Entry maintenance 9 Support External access (outgoing/incoming) Rare Will be Services Custom field definition Rare Access control Rare Directory propagation 9 9 Directory synchronization 9 9 Directory reorganization 9

Gateway Interpersonal message conversion 9 Services Address translation File attribute conversion Special character conversion 9 Delivery notification conversion 9 Receipt notification conversion 9 Tunneling Access control 9 Gateway log reset/archive/restore 9

Automated User chargeback Crude 9 Housekeeping Directory propagation Services Directory synchronization Directory reorganization 9 Message store reorganization Message store backup/archive 9 MTA log reset/archive 9 Gateway log reset/archive 9 Time services System activity reporting 9

User Account Account creation/change/deletion 9 Housekeeping Distribution list management Services User moves Proofs of delivery Crude Restore message store 9 User chargeback Crude 9

General Fault management Crude 9 Management Performance and capacity management Crude Services Restore MTA & gateway log 9 Time services

This shows the main services that must be provided by a messaging system in order to move around general-purpose chunks of information. The chart also indicates whether the service is typically provided today, and whether it's a big headache for technical support staff.

19 1 Introduction

sage, an EDI message, a meeting request, a purchase request form, or a binary file of undefined type. • Authentication & encryption. A new development is to build facilities into the messaging system which allow the receiver to confirm who sent a message, confirm that the message has not been altered, prove to third parties that the sender really did authorize the message, and to ensure that no unauthorized parties have been able to read the message.

Message Store Services Message store services provide a location to store messages before transmission or upon receipt. A message store, also known as a post office, is a collection of user mailboxes. The main tasks are: • Creating and deleting message folders. Increasingly, the message store consists of a user-defined folder hierarchy. • Moving messages around within the folder hierarchy, and deleting them. • Automatic assistant processing. A recent trend is to provide a simple rules definition and processing facility. Eg, users can specify that certain types of arriving messages should be placed in particular folders, that certain types of messages should be deleted, and that while the user's away a reply should be generated telling the sender of the user's absence. • Access Control. A mailboxes in a message store is often thought of as being "owned" by a single user, so the access controls are simple in that case. However, it's clear that many mailboxes will be shared, eg, one containing an engineering change bulletin board. There needs to be a way of defining who's allowed to access the folders of a message store and the individual messages they contain, and what type of access is allowed (eg, read only vs. delete vs. update, etc).

• Message store backup/archive/restore.

Transport Services

Transport services move a message from sender to recipients. The most important thing here is the MTA, or message transfer agent. This is a program which can pick up a message from a message store or another MTA, and then transfer the message to another MTA or message store. To get from sender to recipients, in general a message will have to go through a network of MTAs. That often means that a series of MTA-MTA hops will be needed. The main transport tasks are: • Message routing. This is where an MTA decides which other MTAs a mes-

sage needs to be sent to. Alternatively, an MTA can decide that it's the final MTA in a transmission, and deposit the message in a recipient's message store. • Message transfer. This is the business of actually moving a message from one MTA to another, or between an MTA and a local message store. This often takes place over dialup lines, X.25, a LAN, a connected set of NetWare LANs, or a TCP/IP network. • External connectivity. Some messages will need to be sent out of your organization. Likewise, some messages will arrive from the outside world. Normally this entails connecting to a public X.400 carrier or ADMD, or to the world-wide Internet. • Access control. Some messages should not be passed through the network. • MTA log reset/archive/restore. Useful for troubleshooting.

Directory Lookup Services Directory lookup services provide access to a repository of information used in a messaging system. This can encompass many different types of things, but in particular, a messaging directory lets people and programs look up: • Mailbox addresses. These are character strings which enable a messaging system to uniquely identify a mailbox. They're usually somewhat computer- ish in appearance. Eg: Smith, John@SFP01 JSMITH/SYMMGW/MSMNET [email protected] C=us; A=mci; P=xyz inc; S=smith; G=john • Mailbox names: the user-friendly names used to identify mailboxes. Eg: Smith, John John Smith John R. Smith, Jr • Ancillary identification information. This is typically things like department, location, and telephone number. • Distribution lists, and the ability to see who's in them. • The different e-mail address formats someone might have. Eg, John Smith might be variously known as Smith, John@SFP03 SFVM1SYM(JRSMITH) [email protected],mli C=us; A=mci; P=xyz inc; S=smith; G=john in your organization's cc:Mail, PROFS/OV, Internet, and X.400 systems, respectively.

21 1 Introduction

• Someone's preferred file formats. Eg, their preferred word processing format is WordPerfect v5.1, and their preferred spread sheet format is Lotus 1-2-3 v4.1. This is useful when working out whether—and if so how—to automatically convert a sent file. • MTA routing information for a given message recipient. Today, routing information is usually put in a table which is "hard-wired" into each MTA, but there's a small trend to put this sort of information into a directory. Expect the small trend to become a torrent before long, because as we shall see, it significantly improves system reliability, performance, and maintainability. • Information to do with message authentication and encryption—notably, people's public keys, encryption certificates, and revocation lists. • Other interesting information. The messaging directory can be a convenient place to make other useful information generally available, like people's fax numbers, legal names, social security IDs, boss's name, salary, date of com- mencement of employment, etc. Most of today's messaging systems actually consist of a series of special-purpose directories. For example, gateways often contain information about the different address formats a person might have, and another directory lets you look up someone's address based on their name or department. However, there's a trend to put messaging information into the main computer system directory—eg, Banyan's Intelligent Messaging uses the StreetTalk directory, and Novell is gradually putting NetWare Global MHS directory information into NetWare Directory Services.

Message Status Services These let you determine what's happened to a message: • You can specify whether a delivery notification should be generated upon placing a message in the recipient's message store. • You can specify whether a receipt notification should be generated when the recipient reads or opens a message. • Message tracking. This is where the system tells a user where a message is and its status. For example, this is useful if a message hasn't arrived when expected, or if you're sending someone a notice that you need to change tomorrow's meeting. • Message tracing and recovery. These services indicate where a message is from the standpoint of technical support staff (eg, in MTA 32's error queue), and provide a method of getting a stuck message on its way again.

Directory Support Services A number of directory support services are also required: • Entry maintenance. You need to be able to add, delete, and change directory entries. • External access. You may want people outside your organization to be able to access internal directory information. Conversely, your staff probably needs to be able to access outside directories. • Custom field definition. Organizations need to be able to add their own custom fields to a directory, such as "Employee ID" or "Telephone Number" or "Mail Stop". • Access control. Messaging directories today have relatively few constraints on who can view the entries. Crude facilities are available to limit who can create, change, or delete entries. Over the next few years, expect a normal range of access controls to become available. • Directory propagation, synchronization, and reorganization. These are discussed in the section on automated housekeeping services.

Gateway Services Gateway services convert between the formats of different messaging systems (eg, between PROFS and cc:Mail). The main services are: • Interpersonal message conversion. This includes things like the interpersonal text itself, and privacy indicators. • Address translation. This makes sure recipients see addresses in the FROM:, CC:, BCC:, and other fields in the format to which they're accustomed. • File attribute conversion. Information about a file being transferred, such as its length, name, and creating application, needs to be converted between formats. • Special character handling. Unusual characters such as periods, umlauts, accent graphs, and so on, may need to be converted. • Receipt and delivery notification conversion. These special messages must be converted between formats. • Tunneling. Suppose someone sends a message to another person who uses the same e-mail system. If the message has to traverse a different e-mail system along its journey, some special characteristics of the messages are likely to be filtered out. For example, colored and blinking characters, and rich text in general, are likely to be lost in the body of an interpersonal message. A technique called tunneling allows the full preservation of a message from end to end, even though it transits a different messaging system.

23 1 Introduction

• Access control. It should be possible to stop some messages from passing between two systems.

• Gateway log reset/archive/restore. Useful for troubleshooting.

Automated Housekeeping Services Automated housekeeping services deal with repetitive maintenance chores that should be processed automatically. They encompass a variety of services, the main ones being: • User chargeback. Tools are rudimentary today, and generally have to be custom coded. This will clearly become an area of growing importance over the next few years. • Directory propagation. Different directories within PC and other distributed e-mail systems need to be coordinated. This means periodically sharing update information between the directories. • Directory synchronization. The different directories used by different types of messaging systems (eg, PROFS/OV, cc:Mail, ALL-IN-I, etc) need to be coordinated. This means periodically sharing update information. Because of the different address formats, it's more complex than directory propagation (which takes place just within a single system). • Directory reorganization. Directories are special-purpose databases, and as such, they need periodic tuning to reduce fragmentation and improve performance. • Message store reorganization. They likewise need tuning, to reduce fragmentation and improve performance. • Message store backup/archive. • MTA log reset/archive. • Gateway log reset/archive. • Time services. Many different components of a messaging system need to keep track of the time, in order to time-stamp messages, logs, and so on. Periodically, clocks must be validated and if necessary, corrected. • System activity reporting. A wide variety of reports about messaging system operations must be produced. These encompass issues such as delivery times, message size by day and time of day, message volumes by day and time of day, and so on. The entries in this list are duplicated in other categories; we've clustered them here to emphasize that they should be automated.

User Account Housekeeping Services User account housekeeping services provide for the largely clerical tasks of creating and maintaining user accounts. • Account creation/change/deletion. This involves things like assigning an address, a user-friendly alias, and message store space; reestablishing services when passwords are lost; configuring MTA routing tables; and granting public and private keys and authentication certificates. • Distribution lists must be managed. • User moves. When users move location, a number of tasks may be required, such as moving a message store, setting up autoforwarding, reconfiguring MTA tables, updating directory entries, and moving personal directories. • Proofs of delivery. Audit trails may be required to establish that a message was sent to and delivered to a particular recipient. • Message store restore. • User chargeback.

General Management Services General management services alert support staff when there are problems with the system, and help them diagnose the cause of a problem. When possible, they also provide warnings in advance, so that fixes can be developed before users are affected.

User Agent & API Services Finally, a messaging system provides ways of getting at the services we've just described (figure 1.2):

User Agents These are programs that human beings can use—ie, user interfaces or, in the jargon, user agents. Several user agents are likely to be provided, which let the user: • Browse the message store • Prepare and read interpersonal messages • Prepare and receive file transfers • Access the directory, mainly for addressing purposes • View arriving files

25 1 Introduction

FIGURE 1.2 USER AGENT & API SERVICES

Reality ajar ice n

User Message store browse UA V Agent Interpersonal message UA I Services File transfer UA V V Directory browser V j File viewers & format converters V V Package UAs: group scheduling, bbs, EDI, etc V V Custom UAs: forms routing, EDI, database query, etc V V

API Service APIs

In addition to moving around undefined chunks of information, most messaging systems understand how to process particular types of information. These are shown as User Agent Services. API Services provide access to the system for programs.

• Convert files between different formats Third party software packages—eg, group scheduling packages, EDI packages, and bulletin board systems—also provide ways of accessing the messaging system's services. Customer-developed mail-enabled applications also provide ways of accessing the messaging system. Forms routing, EDI, and database-query-by-form are common examples.

APIs APIs let programs access the messaging system and its application services without those programs having to know much about the implementation details. Typical calls let a program prepare a message, send a message, retrieve a message from a message store, and delete a message in a message store.

1®9 What's an 2.400 Backbone? A messaging backbone is a mixture of hardware, software, and data communications links used to connect different messaging systems. Typically, the systems being connected are different proprietary packages, like PROFS/0V, cc:Mail, and ALL-IN-1. In rare circumstances, the term also refers to a general-purpose method

of connecting the messaging systems of autonomous groups within an umbrella organization, where each of the groups uses the same package. Backbones work by converting all messages into a common format. This is often a version of the format defined by the X.400 standard, in which case the backbone is known as an X.400 backbone. That's a fairly concise definition of a backbone. To give a clearer picture of what backbones are and how they evolve, we now look at the case of a fictional-buttypical organization.

Evolution as Integrator of Non-X.400 Systems Let's suppose the organization is a mainstream IBM customer, with an IS department running the mainframes. At some point in the mid-1980s, IS sets up a new application called PROFS. This provides e-mail and calendaring. It becomes widely entrenched in the organization. Everybody uses it, except the engineering department, which has a VAX minicomputer with its VMSmail e-mail system. Eventually, the engineering department installs a NetWare LAN. Some of the engineers start using ON Technology's eMAIL package on the LAN. Unfortunately, eMAIL users cannot easily exchange messages with VMSmail users, and none of the engineers can exchange messages with PROFS users (figure 1.3). The engineers come up with a solution. They write a gateway program that connects VMSmail to ON Technology's eMAIL. They also bring in a gateway that allows PROFS and VMSmail to exchange messages. This setup allows ON Technology users to exchange messages with PROFS users, although via an indirect route (figure 1.4). This solution works, but causes problems: • Users complain that messages between PROFS and ON Technology's eMAIL are sometimes lost. • Everybody's messages are delayed at one time or another. • Sometimes the PROFS/VMSmail gateway stops working, and nobody knows why. • Knowing how to send a message from one platform to the other is not easy. It requires a lot of handholding to get users started. • The engineer in charge of the gateways spends a lot of time on the phone helping users, and not enough time checking errors in logs and minding the systems in general. • Users discover through trial and error that when they send word processor files, they have to remove all the formatting, or else the message is lost. Most

27 1 Introduction

FIGURE 1.3 UNCONNECTED E-MAIL SYSTEMS

User User User PROFS User User User

User User VMSmail User User

ON User Technology's User eMAIL

User User

In large organizations, various e-mail systems are put in place without central planning or coordination. Each system is an island: it can't exchange messages with the other e-mail systems.

users resort to sending all documents except trivial correspondence via interoffice mail. In short, the e-mail system isn't delivering on its promise. To resolve the problem, the company sets up an action committee. The committee analyzes the situation, and decides that cc:Mail should be selected as the corporate standard. New e-mail installations will use cc:Mail. However, PROFS, VMSmail, and ON Technology eMAIL users can't be forced to give up their current e-mail systems: they must be left to migrate as they choose. Thus, until everyone's moved over to cc:Mail, three new gateways are needed (figure 1.5).

Why Point-to-Point Gateways are impractical It is not unusual to find many e-mail systems like this within a large organization. A likely continuation of the scenario is that it is later discovered that a geographically separate division uses yet another e-mail system—Transfer, which runs on Tandem non-stop machines. To accommodate Transfer, four gateways are really needed, from Transfer to each of the existing e-mail systems.

Thus, with this approach, there's a proliferation of gateways. Some shortcuts are possible, as figure 1.4 illustrates, where VMSmail acts as intermediary. However, in general you need n(n-1)/2 gateways to connect n different e-mail systems. As soon as n exceeds 2 or 3, the use of point-to-point gateways becomes impractical: • Some gateways support features not supported by others. Because so many different gateways from different vendors are involved, there's no consistency in what works and what doesn't. • Because the gateways come from different vendors, they work in different ways. • When an exchange doesn't work, you have to deal with several products. This provides finger-pointing opportunities for the vendors involved. • A given e-mail system pair may not have a gateway available between them. Or you may only be able to choose a low function gateway that is poorly supported. • The gateways don't work together. This means you have to do a lot of redundant work, developing and maintaining services for the different environments.

FIGURE 1.4 GATEWAYS CONNECTING E-MAIL SYSTEMS 1111111111111

User User User PROFS User User User

PROFS/ VMSmail Gateway User

User VMSmail User User ON MHS/ User Technology's _ VMSmail

eMAIL Gateway User User User

User

The first attempt to connect e-mail systems is often accomplished by installing pairwise gateways. This causes problems as the number of e-mail systems increases.

29 1 Introduction

FIGURE 1.5 GATEWAY PROLIFERATION

User User User PROFS User User User

PROFS/ User DEC m ail Gateway User

User User VMSmail User TechnoONlogy 's VMSmM HS/ ail User eMAILU ser Gateway User User

cc:Mail' V MSm a il Gateway cc Al ail/ PROFS Gateway

User cc:Mail/ M HS cc:Mail User Gateway User User

Without a backbone, it becomes progressively harder to connect new gateways. You often end up needing n(n-/)/2gateways to connect n different e-mail systems.

• For each e-mail system pair, you need someone that has a deep understanding of both systems.

The Backbone Approach A good way of avoiding these proliferating gateways is to adopt an e-mail or messaging backbone (figure 1.6). If this makes you think about ethernet backbones and other physical plant elements, stop right there. All we mean by an e-mail backbone is that it's a common format used to connect the different environments, together with various add-on conversion and management services. So each e-mail system connects to the backbone via a gateway. The gateway converts between the formats used by the end e-mail system (eg, PROFS) and the format used by the backbone system. In the case of an X.400 backbone, the common format is X.400, whereas an SMTP backbone uses SMTP as the common format.

You don't get gateway proliferation with a backbone approach. In general, it takes n different gateways to connect n different e-mail systems. Thus in the scenario described above, the addition of the Tandem based system requires the addition of a single gateway, and it provides connectivity with all the other systems.

Message Switches, or E-Mail Integration Software It's an enormous help if a backbone's gateways are designed to work well with each other. A number of vendors specialize in providing special integration software, which connects a variety of different e-mail systems. They provide a selection of gateways and other connection software; the different components work in a similar way, and are configured and managed in similar ways. Such integration software is often called a message switch, a term we find confusing. We tend to use the expression message integration software instead. Integration

FIGURE 1.6 E-MAIL SYSTEMS CONNECTED BY A BACKBONE

Use r User ser Use User PROFS User VMSma r

User User Use

PROFS/ VMSmail/ X X.400 Gate400wa y ateway

X.400 Backbone

M HS/ X.400 X.400 Gateway Gateway

User User Use ON User Technology's , cc:Mail eMAIL User User User User User User

With a backbone, an additional e-mail system needs at most one gateway. Messages between systems always cross two gateways. These gateways, however, are optimized to work with each other.

31 1 Introduction

software always works by converting everything into a common format, and hence, many of the problems of using point-to-point gateways disappear. The market for messaging integration software is dominated by SoftSwitch, now owned by Lotus. SoftSwitch Central is mainframe-based software that integrates different mail systems; it uses a version of IBM's SNADS protocol as the canonical form. Lotus/SoftSwitch' latest offering, LMS, uses a version of X.400 instead. Other integration software vendors include Alisa Systems, Amadeus Systems, Boston Software Works, Digital Equipment, and Worldtalk. They all offer a selection of gateways into the backbone's common format, with end-to-end conversion of features.

Basic Backbone Features Thus, a backbone will always move messages between different systems. And assuming the backbone is being used to connect different messaging systems, it will also provide: • General message format conversion • Interpersonal message format conversion Plus you can expect some of the following: • Address translation (into the formats most common to a given user) • Directory synchronization tools • File format conversion • Usage and diagnostic reports and utilities • A crude ability to check the status of in-transit messages

Backbone Requirements The major requirements of a backbone are: • It should be able to connect to all or most of the e-mail systems used by your organization. • The backbone should have easy to use APIs, so that mail-enabled applications can access it, and so you can build connections to unusual in-house mail systems. • The backbone should provide system management facilities for centralized or distributed management. Management includes capabilities to control systems, receiving alarms at centralized locations, modifying the network configuration, etc. • It should allow for scalability, expansion, and distributed operation. Smaller nodes to cover locations with less activity should be feasible. A small incre-

mental usage should not require the doubling of a multi-million dollar investment. Multi-node systems should have both local and central controls so that system administration can be optimized to take maximum advantage of local and corporate resources. • It should provide for fault-tolerant operation with no single point of failure that could disable substantial part of the network. • It should be able to use different types of physical links (dialup, X.25, ethernet, token ring, frame relay, etc) and transport mechanisms (OSI protocols, TCP/IP, IPX, XNS, NetBUEI, etc). • It should provide adequate security mechanisms to allow for operational integrity as well as a secure business information exchange.

1.3 The Backbone as Vehicle for PC E-Mail Reliability We saw that the main reason people turn to a backbone is to connect different types of e-mail systems. Recently, people have also moved to X.400 backbones to try to make their PC e-mail systems more reliable. There's a perception—incorrect as it turns out—that X.400 is intrinsically more scalable than PC e-mail.

Reasons for PC E-Mail Unreliability A PC e-mail system starts to have reliability problems once it reaches somewhere between 2,000 and 5,000 mailboxes. There are a variety of reasons for this, notably: • Message stores reside in shared file servers. These devices have no real processing power. Thus, most of the work is done by workstation PCs. This usually limits you to about 100 users per file server. • Since there are many different message stores, routing is especially complex. You usually have to route messages through central hubs, and these become major bottlenecks. When the hubs go down, traffic is greatly restricted. • MTAs usually run on DOS machines. These will periodically stop working for various reasons, and until they are brought back on stream, traffic through them stops. • Message store compaction utilities must be run periodically on workstations. While they run, the message store concerned is unlikely to be available. • There is little ability to generate alerts at a central console. Administrators only become aware of problems when they get calls from users complaining that messages aren't getting through.

33 1 Introduction

The result is that it's hard to give service guarantees like: 99% of all messages will arrive within 10 minutes; you will be notified within 20 minutes of any messages that do not arrive within 10 minutes. The best you can usually achieve is something like: 98% of all messages will arrive within 45 minutes. In the jargon, PC e-mail systems are said not to scale well, or to have poor scalability. For users and applications demanding a messaging system with reliability approximating that of the phone system, this is clearly an unsatisfactory state of affairs. This is particularly easy to see when you consider placing orders for a just- in-time manufacturing line. Manufacturing will need to know whether or not a message has been delivered, and it will need to know this in a timely way. Even a .01% chance that the message takes 5 days to get through will be unacceptable Wan alert is not quickly generated. A further problem is that the difficulties translate into a heavy technical support cost. Running a post office, including end user support, for 100 users typically takes about a quarter of a system administrator's time. That's 20 to 30 full time support staff, or their equivalent in part-time people, per 10,000 mailboxes. For a detailed analysis of the scaleability requirements of a distributed messaging system, see the September 1994 Ferris E-Mail Analyzer.

How an X.400 Backbone Can Improve Reliability All vendors, X.400 or otherwise, are working hard to improve scalability, and some X.400 products now have a number of excellent facilities in this regard. HP's OpenMail is one example. Message stores and MTAs run under UNIX, and messages are transported over an organization's existing TCP/IP network. This means that: • Message stores are intelligent, and can run on very powerful hardware. They can thus support far more users, and offer have much higher performance and reliability. • MTAs are more reliable and have better bandwidth. • There are many fewer points where breakdowns can occur. An SNMP- based fault management system helps to locate and fix problems. Features such as these result, for suitable environments, in a more scalable and supportable system.

1.4 Backbone Components We now describe the main components of an X.400 backbone (figure 1.7). For the moment, we focus on the transfer and receipt of messages, and ignore the provision of directory services.

Backbone Connecting Non-X.400 Systems The heart of the system is the backbone transport. This is a series of geographically separate programs which route messages, hop by hop, to their destination. All the messages are in X.400 format. In the jargon, it's a network of X.400 message transfer agents, or MTAs. At the next level are a series of gateways which connect non-X.400 systems into the backbone transport. Today, the main functions of the gateways are to convert between X.400 and non-X.400 message formats, and to convert address formats into a form easily digested by a recipient. Level three consists of the network of message routers within each of the connected messaging systems. In the case of mini- and mainframe-based e-mail systems, the routing is usually trivial, since everyone connects to a single machine. With PC email systems, there may be many proprietary MTAs. cc:Mail's Router program is a common example, as is Microsoft Mail's External program. In the case of PC e-mail, the MTA programs usually run in a dedicated PC under DOS or OS/2. The next level is that of message stores. Arriving messages are deposited into these by the local MTA of the e-mail system concerned. Likewise, outgoing messages are placed here before being picked up and transported onwards by the local MTA. Today, message stores are normally implemented as a passive file system on a computer hard disk; for PC e-mail, that means on a shared file server. PC e-mail message stores are often known as post offices. A new trend is to give the message store its own processing power. Level five corresponds to the programs used by users to access the messaging system. These may be interpersonal messaging and file transfer packages like cc:Mail or MS Mail; or EDI packages; or they could be programs which access the system through an API, such as a forms routing application. In the case of a PC e-mail system, these programs run in a PC, and connect to the message store over a LAN.

35 1 Introduction

E-Mail Systems Connecting to the Backbone The right hand side of figure 1.7 illustrates how X.400 e-mail systems connect to an X.400 backbone. The layout is simpler, because no gateways are involved. It also becomes a matter of debate whether the X.400 system's network of MTAs are part of the backbone—arguably an attached X.400 system's transport simply extends the backbone. Alternatively, it could be deemed a specialized extension to the backbone network, with its own management tools.

Underlying Data Communications Links Underlying data communications links vary greatly. In principal, the main components of a messaging system don't care about how bits are moved from place to place—this is left to other, lower levels pieces of systems software.

FIGURE 1.7 PHYSICAL STRUCTURE OF AN X.400 BACKBONE

MTA Level 1: Network X.400 Backbone Transport

Level 2: Gateway .. Gateway Gateways

Level 3: MTA MTA Individual Messaging Network Network System Transports

Level 4: Message Message ...... e Message Stores Store Store

Level 5: UA UA UA .. UA User Agents Non-X.400 Environment All X.400 Environment Non-X.400 systems connect to an X.400 backbone using gateways. X.400 systems, shown on the right, don't need a connecting gateway.

For example, non-X.400 MTAs often simply need to be able to establish a file redirection capability with another MTA's inbound and outbound queues. An intervening LAN can use many types of wiring and adapter boards—it's irrelevant which ones. Pure X.400 MTAs are more fussy, but those of them that support TCP/IP as connection method are likewise insulated from the details of how bits are physically transferred.

Where Messaging Services are Provided A specific messaging service may be provided at a number of places. For example: • Management of a message store folder hierarchy takes place at an end messaging system. • Tunneling (explained later) takes place at gateways—the point of connection of an end messaging system to the backbone. • File format conversion can take place in a backbone, in a gateway, or in an end messaging system (typically at a user workstation). • Performance management services are everywhere. Figures 1.8 and 1.9 elaborate.

FIGURE 1.8 LOCATION OF FUNDAMENTAL MESSAGING SERVICES

i.oup Service :Backbone? :stem?:

Message Message Specify recipients Specify Preparation priority Specify nature or type Services of enclosure Authentication & encryption

Message Create & delete folders 9 Store Move & delete messages 9 Services Automated assistant services 9 Access control ,/ Message store reorganization 9 Message store backup/archive/restore 9 Transport Message routing ,/ ,/ Services MTA-MTA transfer 1 / External connectivity V n/a J Access control ,/ 1 i MTA log reset/archive/restore ,/ n/a J

37 1 Introduction

Directory Address lookup 9 9 Lookup User-friendly name lookup 9 Services Ancillary identification information lookup 9 Distribution list lookup 9 9 9 Address translation lookup 9 9 Preferred file format lookup 9 9 9 MTA routing lookup 9 9 Authentication & encryption lookup 9 Other interesting information lookup 9 9

Message Request delivery notifications 9 Status Request receipt notifications 9 Services Message tracking 9 9 9 Message trace & recovery 9 9 9

Directory Entry maintenance Maybe Maybe 9 Support External access (outgoing/incoming) Will be 9 Services Custom field definition 9 Access control 9 9 9 Directory propagation 9 Directory synchronization 9 9 9 Directory reorganization 9 9

Gateway Interpersonal message conversion 9 Services Address translation 9 File attribute conversion 9 Special character conversion 9 Delivery notification conversion 9 Receipt notification conversion 9 Tunneling 9 Access control 9 Gateway log reset/archive/restore 9

Automated User chargeback Housekeeping Directory propagation Services Directory synchronization Directory reorganization 9 Message store reorganization Message store `Cc, `Cs backup/archive MTA log reset/archive 9 CCC Gateway log reset/archive 9 Time services Will be Will be Will be System activity reporting

User Account Account creation/change/deletion 9 Housekeeping Distribution list management 9 9 9 Services User moves 9 9 9 Proofs of delivery 9 9 9 Message store restore 9 User chargeback 9 9 9

General Fault management 9 9 9 Management Performance and capacity 9 9 9 management 9 9 9 Services MTA & gateway log restore 9 9 9

A messaging service can be located in one or more components of the backbone, a gateway, or an end messaging system

FIGURE 1.9 LOCATION OF USER AGENT & API SERVICES 1. ______

()cation -- Gate- ay?

User Message store browse UA 9 Agent Interpersonal message UA 9 Services File transfer UA 9 Directory browser 9 File viewers & format converters 9 Package UAs: group scheduling,bbs, EDI etc 9 Custom UAs: forms routing, EDI, database query etc 9 API Service APIs 9 Partial 9

User agent services are provided in the messaging systems which connect to the backbone, not the backbone itself.

Chapter 2

2. X.400 Technology Background, Part I

In this chapter, we explain the basic concepts of an X.400 messaging system. We look at message formats, user interfaces, message stores MTAs, ADMDs and PRMDs, address structures, file transfer, directory services, and distribution lists.

2.1 Message Format X.400 messages have a very complex internal structure, and we don't go into all the details. Nevertheless, it's necessary to have a high level understanding of what messages look like.

The P1 Protocol A message consists of two parts (figure 2.1). The first—also known as the PI header—contains things like the sender's X.400 address (in case a delivery notification needs to be sent back), recipients' X.400 addresses, and a trace field indicating the message's flow from one message switch to the next. The second part contains the information being sent from sender to recipient. It is generally referred to as the content.

The P2 Protocol The content is structured according to the information carried. For example, a message could carry an EDI interchange. Nevertheless, the designers of X.400 expected most first generation messages to be from human senders to human recipients. Therefore, the first class of message type they designed was for interpersonal messages or IPM. Since this was initially the only class designed for, even

41 2 Technology Background, Part I

messages that did not fall into this category, ie, messages sent from one computer application to another, were generally labeled as interpersonal messages. An interpersonal message is sometimes also called a P2 message. Thus figure 2.1 also illustrates a P2 message with a P1 header An interpersonal message has two parts—an IPM header and an IPM body—in just the same way that a business letter has two parts. The header contains information such as sender's or recipients' X.400 addresses or telephone numbers. It is important to note that the addresses found in the IPM header are also functionally analo- gous to those found at the beginning of a business letter. Namely, they are not used for routing purposes within the postal system (the envelope's label does that). Hence, they are optional.

FIGURE 2.1 X.400 MESSAGE FORMAT

Message ID Originator's address Recipient's addresses Priority P1 header Content type

Content ID Business letterhead Originator's ID IPM Recipients' IDs Header Importance

Interpersonal Content message (IPM) Notes, word processor files, drawings, tlTAINif1 CAD files,

any type of data

X.400 messages consist of two parts: the header, and the content. Often, the content is an interpersonal message or IPM.

Omitting them may be bad form, but has no consequence on the message handling. At any rate, from a practical perspective, the designer of the mail system composing the message decides what information to put into the header on the user's behalf, so users do not have much of a choice here. User organizations may have a decision to make when they program applications to use application program interfaces or APIs to gain access to the mail system. We look at APIs in more detail later.

The P22 Protocol The P22 message is a new message type introduced with the CCITT's 1988 recommendations, and is the 1988 version of the P2 message. There are several differences between a P2 message and a P22 message, and a 1984 user agent cannot deal with a P22 message (1988-conformant user agents can, however).

The PO Protocol A PO message is a message with an undefined content type. The most common use of PO is to transfer EDI messages. It has a normal P1 header and looks just like figure 2.1, except that, typically, there's an EDI interchange in the content field instead of an interpersonal message.

The PFD, Protocol/X.435

The P EDI message type also has a normal P1 header, but carries specially formatted EDI information in the body. This encompasses an EDI interchange, as well as accompanying information such as specifications or technical drawings. CCITT recommendation X.435 defines the protocol. See chapter 3, section 5, for a more detailed discussion.

Body Parts The body of the P2 message can contain anything. Now, suppose that a sender wants to send three files to a recipient. The files cannot simply be concatenated. They need to be carried in the message, but need to be logically kept apart. X.400 provides a mechanism for this: each file is carried in a separate body part Each body part is assigned a separate body part type designator.

Delivery Notifications When a user sends a message to a recipient, he or she may wish to know whether the recipient received the message. More than likely, the sender will want to know

43 2 Technology Background, Part I

if the recipient could not receive the message. To handle these cases, X.400 generates delivery notifications or DNs (figure 2.2). The default in X.400 is to always send back a negative delivery notification if a message cannot be delivered, and not to send back a notification if the message is successfully delivered. A user can override that, and ask for a delivery notification even if the message is successfully delivered. A delivery notification contains information related to a particular message delivery. If negative, it also indicates a reason code, although the reason code is not usually very descriptive. In many first generation implementations, users commonly always requested a delivery notification—not receiving a notification was an indication of a problem somewhere in the system. Many people still do this as a matter of habit.

Receipt Notifications Receiving a delivery notification indicates that the message was deposited into the recipient's mailbox. It does not indicate that the recipient read the message, or that the recipient is even aware of the message's presence in his or her mailbox. This is in contrast to a service provided by many early electronic mail systems, where the sender gets a message, typically called a read receipt, when the recipient actually reads the message. To provide a solution to this discrepancy, X.400 has receipt notifications or RNs.

FIGURE 2.2 X.400 DELIVERY NOTIFICATION FORMAT

Notification ID P1 header Originator's address (to whom notification is being sent)

ID of message being acknowledged

Content

Payload

X.400 provides for delivery/nondelivery notifications.

A receipt notification is a message that is generated when a recipient reads a message, and it is sent to the sender like any other e-mail message. The definition of RNs creates some implementation problems—the most important of which is that the generator gets billed for it, when he/she never requested that the RN be sent. Also, when a message goes through a gateway, an RN may be generated even though the recipient has yet to read the message. Nevertheless, RNs can be useful in particular situations. For example, two applications that use X.400 to communicate can use receipt notifications to indicate to the other party that a particular message was acted upon.

2.2 User Agent & Message Store A user agent or UA is a user's interface into the X.400 messaging network (figure 2.3). In the X.400 purist's view, a UA is a program with two interfaces: • The first assists the user to compose the message, for example by providing a

FIGURE 2.3 X.400 UA, MESSAGE STORE, & MTA

User & PC (acting as UA) Computer system/LAN server

P3 Protocol if separate

(a) UA interfacing with MTA.

User & PC (acting as UA) Computer system/LAN server

P7 Protocol if separate

(b) UA interfacing with MTA via MS.

A user agent or UA lets the user prepare messages, and access the message transfer system.

45 2 Technology Background, Part I

word processor type interface, allowing the user to type a text, specify recipients, etc. • The second interface is to the X.400 messaging system. When the user is finished composing the message, he or she hits the Send key. At that point the UA pulls all the necessary information together, and creates an X.400 formatted message. One of two things then occurs:

Transit Via Message Store The message can be sent to a message store (figure 2.3.b). This is software, often running on a different computer, that stores messages. Users can search the store for messages meeting specified criteria, retrieve messages, and delete messages. Having received a message, the message store normally submits it to another process, the message transfer agent or MTA. This software may be co-resident with the message store or on a separate computer. The MTA determines what other MTA to send the message on to, and duly transmits it. Conversely, when an MTA receives a message, it determines whether the recipient is local, in which case it places the message in the user's message store. Later, the user can process the message using their user agent software. Messages going between user agent and message store, where the user agent and message store are on different machines, are wrapped up in a special envelope, known as the P7protocol. If the two processes run on the same machine, messages are submitted by simply placing them in the other process's in queue. This typically amounts to putting a file into a shared directory.

Transit Via Direct MTA Submission Alternatively, a user agent can submit its message directly to an X.400MTA (figure 2.3.a), with no intervening message store. As before, the MTA decides where to send the message on to. Conversely, if the MTA receives a message for a local user, the user can read it directly from the MTA using a user agent. Messages which go directly between a user agent and an MTA, where the user agent and MTA are on different machines, are encapsulated in a special format known as the P3 protocol. If the two processes run on the same machine, messages are submitted by placing them in the other process's in queue. This typically amounts to putting a file into a shared directory.

Access By Non-X.400 User Agents Most user interfaces currently available on the market are not true X.400 UAs. This is partly because many users started to use a particular interface before the introduction of X.400 into their environments. For example, they may have been using PROFS, and did not or could not change their interface simply because X.400 came along. It also has a lot to do with marketing inertia. In the case of LAN e-mail, proprietary approaches simply happened to get significant market awareness first, and now many organizations have standardized on products like cc:Mail or Microsoft Mail. The fact that users are committed to non-X.400 interfaces has probably had a chilling effect on the pace of development of native X.400 UAs. There are a handful of offerings on the market, from such vendors as Boldon James, Digital, Enterprise Solutions, ISOCOR, and MaXware. Less than 1% of today's e-mail users actually use an X.400 UA; they prefer packages like cc:Mail, Microsoft Mail, and PROFS/OV instead.

2.3 Message Transfer Agent The MTA (figure 2.4) routes messages through an X.400 system, and the messaging network is essentially made up of interconnected MTAs. More specifically, the MTA interacts with other MTAs, and UAs and message stores, to send messages to them and receive messages from them. The MTA: • Determines whether to keep a message locally, or whether to forward it to another MTA. In the latter case, the MTA determines which MTA to transfer the message to. • Delivers messages to a user's message store or UA. • Relays messages on to the next MTA. • Stores messages safely while it has responsibility for them. • Generates nondelivery notifications when it determines an address is incorrect. • Generates delivery notifications when the recipient's UA reads the message or when the message is deposited in the recipient's message store. • Expands distribution lists. The X.400 standard does not address many important requirements, and as a result there can be significant differences between products. Eg, differentiating features include hardware platforms supported, whether multiple concurrent MTA processes are allowed, remote configuration support, and whether the MTA can select routes based on an X.500 lookup.

47 2 Technology Background, Part I

FIGURE 2.4 INTERCONNECTED MTAS FORM THE MESSAGING NETWORK

UA UA MS MTA

MTA UA MS MTA

UA MS MTA MTA MS UA

MTAs are responsible for routing messages though the messaging network. For practical reasons, they are often organized in a hub-and-spoke layout.

MTA-MTA Authentication When two X.400 MTAs connect, there is a fairly complex authentication process between them. They exchange their MTA names and MTA passwords. This is in addition to a number of other parameters that need to be exchanged, such as lower level protocol information. In case of an X.25-based connection, the network provides an additional level of validation. Nevertheless, MTAs are not immune to interceptions. A determined party can make their MTA impersonate another MTA. Also, periodic password changes would provide a higher level of security, but most MTA implementations are not designed with the intention of doing this. Note that the use of MTA Name and MTA Password parameters is not mandatory. However, when connecting to third parties, it's usually best to insist upon their use, in both directions.

Security by Limiting Correspondents Additional security mechanisms are possible if your MTAs are configured to accept messages only from pre-configured sources, eg, only from certain companies or even from certain X.400 addresses. If somebody from another organization sends a message, your MTA can send the message to an operator, or cancel the message and generate a non-delivery notification.

2.4 ADMDs & PRMDs An organization's in-house X.400 network is known as a Private Management Domain or PRMD. To send a message between two different organizations or PRMDs, the normal thing is to connect them by one or more intervening public X.400 networks. There are many such public service providers. Some of the best known US firms are Advantis, ATTmail, GEIS, Infonet, MCI, and Sprint, and they are active in many countries. Outside the US you can often choose from a mix of carriers: several US-based ones, plus one run by the government-sponsored PTT. In the jargon, these public X.400 carriers are known as Administrative Management Domains, or ADMDs for short. Figure 2.5 illustrates how PRMDs A and D might exchange messages, by being connected through two ADMDs, which are themselves connected. Both PRMDs and ADMDs are examples of X.400 messaging networks. As such, they're known as management domains or MDs. The relationship between ADMDs and PRMDs is defined slightly differently, depending on who you speak to. The CCITT is heavily influenced by PTT service providers and ADMD operators, and therefore provides an ADMD-centric view of the messaging world. Here, ADMDs sit between PRMDs, and provide the transfer services between PRMDs. The ISO also publishes a set of international standards relating to X.400. They are very similar to the recommendations published by the CCITT, but take a less ADMD-centric view of the world. As section chapter 2, section 9 discusses, taking an ADMD-centric view of messaging creates real problems with X.400 addresses.

49 2 Technology Background, Part I

FIGURE 2.5 CONNECTING PRM DS VIA AN ADMD

PRMD A ADMD B ADMD C

Messaging MTA MTA Messaging MTA MTA Messaging MTA Network Network Network

Messaging MTA Network

PRMD D Different organizations usually connect their X.400 networks using a public X.400 network, known as an ADMD. Up to two ADMDs may be used in any correspondence. 2.5 Addresses An X.400 address is a concatenation of objects called attributes, as listed in figure 2.6. There are also some rules about which attributes are mandatory and how they can be combined. The reason for allowing particular combinations is that these let you express particular address types, such as a postal address. In fact, most addresses in existence belong to the form called mnemonic ORAddress, or, more simply, O/R address. Here, the O/R stands for Originator/Recipient. We now look more closely at this type.

Mnemonic ORAddress An O/R address always has the attributes Country Name and ADMD Name. The optional fields are: • PRMD Name ("P=") • Organization Name ("0=") • Organizational Unit ("OU="; up to 4 occurrences) • Last Name ("S=") • First Name ("G=") • Initial ("I=") • Generational Qualifier • Domain Defined Attributes ("DDA:"; up to 4 occurrences)

FIGURE 2.6 X.400 ADDRESS ATTRIBUTES

10iffiiteiffarne

General Country name ("C=") ADMD name ("A=") PRMD name ("P=") Organization name ("0=") Organizational unit name ("OU="; up to 4 per address) First name ("G=.) Initial ("l=") Last name ("S=") Generational qualifier ("Q=") Domain—defined attribute (up to 4 DDA type and DDA value pairs) Common name ("CN=") Numeric user identifier Network address Terminal identifier Terminal type

Postal Physical delivery service Physical delivery country name Postal code Unformatted postal address Unique postal name Physical delivery personal name Physical delivery organization name Physical delivery office name Post office box address Street address Local postal attributes Extension postal ORAddress components Extension physical delivery address components

X.400 addresses can be made up of a wide variety of different attributes.

Of these, with the exception of any DDAs, at least one must be present. Thus A=telemail; C=us; DDA:FAX=2125551212 is not a valid address, whereas S=jones; A=telemail; C=us; DDA:FAX=2125551212 is valid. There are few hard rules on how to use attributes. The ADMD Name attribute refers to a service provider, the PRMD Name attribute to a private network— probably the name of your organization. Thus, addresses within a private corporate X.400 network must contain the PRMD Name attribute. If a PRMD uses several ADMDs as service providers, when a message is submitted to a particular ADMD, the ADMD name in the originator field must be that particular ADMD.

51 2 Technology Background, Part I

X.400 Addresses and Routing It is easy to see how attributes are used during the routing process by MTAs. Suppose a user with the address S=jones; P=xyz corporation; A=attmail; C=us sends a message to S=doe; P=abc; A=mci; C=us Here, the sender's local MTA inspects the recipient's address, but does not know where the PRMD called abc or the ADMD called mci is located. Inspecting the last two attributes, it decides that A=mci; C=us does not match its own attributes, and relays the message to its service provider, in this case ATTmail. To the MTA within ATTmail, the last two attributes, namely A=mci; C=us provide sufficient routing information, and it relays the message to MCI. The ATTmail MTA does not know whether indeed a PRMD called abc exists within the MCI ADMD, or whether that PRMD has a user with the surname doe. The MCI MTA, upon receiving the message, uses only the last three attributes, namely C=us; A=mci; P=abc, for routing purposes. It does know how to route the message to the MTA belonging to the PRMD called abc, but does not know whether that PRMD has a registered user with the name doe. Finally, when the message reaches the PRMD abc, the MTA within that PRMD knows how to find the mailbox belonging to user doe, and how to deposit the message into that mailbox.

X.400 Addresses Are Hierarchical As can be seen from the routing discussion, the address structure in X.400 is hierarchical. Each entity along the way interprets only a relevant subset of the address. This also implies that entities are free, within certain limits, to select any address structure that suits them. For example, the abc PRMD administrator can select any set of attributes for its user set, as long as the first three attributes are P=abc; A=mci; C=us. Selecting a good address structure is important, however, and we make address structure recommendations later in the report.

Values Usually Lower Case In X.400, attribute values are not sensitive to case, except for DDAs, defined below. In other words, there's no difference between: S=jones; P=xyz corporation; A=attmail; C=us and S=JONES; P=XYZ CORPORATION; A=ATTMAIL; C=US

but there is a difference between S=jones; P=xyz corporation; A=attmail; C=us; DDA: ID=Suej3773271 and S=jones; P=xyz corporation; A=attmail; C=us; DDA:id=suej3773271 By convention—following an EMA recommendation—in this report we put X.400 attribute values in lower case except for DDAs.

Domain Defined Attributes (DDAs) An optional element of an X.400 address can be used to address non-X.400 users. This is the domain defined attribute or DDA. This has two parts, the DDA type, and the DDA value. The type describes the nature of the variable used, and the value describes a specific address reference. For example: • The cc:Mail address Smith, John at Acme Corporation can be represented as P=acme; A=mci; C=us; DDA:ccMail=Smith, John • A telex number could be represented as C=us; A=mci; P=acme; DDA:TLX=6277382 • A PROFS/OV address could be P=acme; A=mci; C=us; DDA:profs=SFVM1(JRSMITH) • If Smith has an account with MCI's public e-mail service, with account number 123-4567, an X.400 representing this account might be: G=john; S=smith; A=mci; C=us; DDA:ID=1234567 • If Smith has an account with CompuServe's public e-mail service, with account number 75300,3400, an X.400 representing this account might be: G=john; S=smith; P=csmail; A=compuserve; C=us; DDA:ID=75300,3400 DDAs are the only attributes in an X.400 address that are case-sensitive. Up to four DDA's are possible in an X.400 address. Usually, DDA's have the form DDA:type=value, but sometimes a slight variations in syntax exist, such as DDA. type=value or DDA=type=value.

53 2 Technology Background, Part I

2.6 File Transfer and Conversion X.400 is specifically designed to be able to carry any kind of binary file, and a message can carry an indefinite number of such files. Figure 2.1 above showed how a number of such files can be included in an interpersonal message. Each binary file is typically wrapped in a separate body part. A number of difficulties arise with file transfer. We touch on the main issues now, and defer a more detailed discussion to chapter 7.

Unspecified File Attributes The most important problem relates to file attributes. While the 1984 recommendations indicate the basic type of a message's contents—binary, ASCII, or voice— the information provided is not sufficient. Eg, you can't tell what application created it, let alone what version of which application created it. Plus there's nowhere to put the name of the file, so there's a good chance this has been discarded, too. One way to resolve this problem is to put information either into the subject field or into a special body part created for that purpose (figure 7.3, page 157). This is a common workaround for 1984 based implementations. This can work well if all your UAs and gateways come from the same vendor. But what if they don't? Problems arise because the recipient needs to know where the originator put the information. It might be in the subject field, or in a body part specifically created for the purpose, or even somewhere else. It thus becomes practically impossible to do things like automatic file format conversion, or automatic booting of the creating application. There's a lot of work going on in this connection under the auspices of the EMA, and solutions are in sight. But for the immediate future, don't expect much information about a file to be sent along with the file.

Large Files Various X.400 profiles specify a maximum message length for a message of one or two million bytes. This is quite restrictive when one uses X.400 to exchange, for example, CAD/CAM files or color graphic images with fine resolution. You can't assume large files will get through. Large files also stress a messaging system. Testing is required to ensure that intervening systems and links have sufficient capacity.

Transfer Cost This becomes an issue when service providers are involved. The pricing for bulk file transfer is much less than that for short interpersonal messages, but the costs can still be stiff. $30 to $50 per megabyte is typical.

File Conversion When a file arrives, it may not be in a format that the recipient can use. In this case, the file must be converted. Conversion can take place at three places: at the sender or recipient's desktop, in a gateway, or in the backbone. Today, the sender usually ends up doing the job.

2.7 Directory Services X.400 systems, just like any other e-mail system, are more useful if they have directory services. In fact, they're especially important for X.400, because: • X.400 addresses are more messy than other types, and directory services help to hide them. • X.400 is designed to provide for world-wide connectivity, so directory services are needed to determine the addresses of people outside your own organization.

The X.500 Directory X.500 is another series of CCITT recommendations. It defines a global directory system, and was designed to accompany X.400. Many kinds of information can be stored, such as e-mail addresses, postal addresses, telephone numbers, hardware addresses, encryption certificates, line of business, and hair color. The remarkable thing about X.500 is that it is global and grows incrementally. Readers and ADMDs can add their directories to the global directory as they become ready. Let's now review some of the relevant jargon: • Service providers operate systems that provide directory services. They are said to operate Administrative Directory Management Domains or ADDMDs.

55 2 Technology Background, Part I

• Private companies operate Private Directory Management Domains or PRDMDs. • All these are interconnected, just as in X.400 ADMDs and PRMDs interconnect. The resulting interconnected, global system is called the Directory System or DS.

X.,500 Architecture So far as X.500 is concerned, there is only one directory, even though it's spread across many different computers and locations. Each part of the directory knows how to access other parts if it needs to. The main components are (figure 2.7): • The Directory Information Base, or DIB. This is a chunk of the Directory controlled by a single computer. • The Directory User Agent, or DUA. This is a program used by a human being or a program to access information stored in the Directory • The Directory System Agent, or DSA. This is a program running on the computer than controls a directory information base. It knows how to store,

FIGURE 2.7X.500 DIRECTORY COMPONENTS ...______

A human being uses a Directory User Agent to query a Directory System Agent. DSAs either access their local Directory Information Base, or automatically access remote DIBs using the Directory System Protocol.

query, and retrieve information there. Crucially, a DSA also knows how to connect to other DSAs when it needs to. Two standard protocols define how DUAs and DSA talk to each other: • The Directory System Protocol, or DSP, is used by DSAs to exchange information. • The Directory Access Protocol, or DAP, is used to define conversations between a DUA and a DSA. These protocols run over both ISO and TCP/IP transports (see the next chapter for more on what these are). Suppose a DSA receive a query against data not in its local DIB. It can find the information it needs using three methods (figure 2.8): • Chaining. Here the DSA gets the information it needs by going via another DSA, or a chain of other DSAs. • Referrals. Here the DSA tells the DUA (or another DSA) where it thinks the information is stored. • Multicasting. Here the DSA doesn't know where to get the information from, so it broadcasts out the request.

X.500 Problems X.500 is a very powerful technology which is beginning to make its impact felt. Nevertheless, it's not all plain sailing. For example: • The X.500 specification does not describe which information needs to be kept in the directory. If there is no uniformity regarding which information needs to be kept and be accessible, users do not know what is available, and what they can ask for. • X.500 is only beginning to address issues such as what information is private or public. The 1993 specification provides access controls, but implementations are not yet widespread. Corporations are worried that private information may become public through the directory. Consider the case of a headhunter who is searching for an engineer and obtains a directory listing of the engineering department of a company known for the quality of its people, or of competitors who are figuring project head counts, to infer how important it is. A number of important proof-of-concept trials are under way, notably the Paradise project, the NYSERNet/PSI White Pages project, the North American Directory Forum or NADF, and The Southern Company/COS pilot.

57 2 Technology Background, Part I

FIGURE 2.8 X.500 INFORMATION RETRIEVAL METHODS

DSA 1 DIB Request

Chaining Referral to DSA 2 Method

Request Information DSA 2 DIB

Relayed Relayed Request Request Request Referral Method Relayed Relayed Information Information Information

Request Broadcast No, sorry Request Multicasting Method No, Relayed sorry Information Information

A DSA can retrieve information from the Directory using three techniques.

Directory Synchronization Within An Organization Most large organizations have several different messaging systems. Given that most of them can't connect to X.500 today, another method must be used to ensure that users of one in-house messaging system can browse the names and addresses of users of other in-house systems. What happens is usually along the following lines: • All the different names and addresses are copied into a central master directory. For each user, this contains the different address formats that must be used to send mail to that user. • A subset of the master directory is then copied down to the local directory of each of the e-mail systems involved.

• When directory entries are added, deleted, or changed in any of the e- mail systems, corresponding changes are automatically made to the master directory. • Periodically, update information is sent down to the directories of each email system. The general term for this approach to directory services is directory synchronization. We discuss the topic in detail in chapter 5. Once directories are synchronized via a master directory, it is simple for users in one environment to address users in another. Suppose a corporation uses several messaging systems, including Novell's GroupWise and PROFS/OV. During the synchronization process PROFS addresses are created for GroupWise users and vice versa. Now a PROFS user can address a message to a GroupWise user using a user-friendly name or 8-by-8 address with a familiar structure. Figure 2.9 shows illustrative addresses in a master directory. Directory synchronization is an important and demanding issue in most installations that use X.400, since such installations tend to combine multiple messaging systems. One of the benefits of having X.400 everywhere—including the use of

FIGURE 2.9 MASTER DIRECTORY USED FOR ADDRESS MAPPING •••. ______

10 .0 Y41P9:

Unique ID 389653 GroupWise Name John Smith GroupWise Address JSMITH/SFSALES/WREGION PROFS/OV Name JRSMITH PROFS/OV Address SFVM1SYM(JRSMITH). cc:Mail Name Smith, John cc:Mail Address Smith, John Internet Name John Smith Internet Address [email protected] MS Mail Name John Smith MS Mail Address JRSMITH/GWSEGTWY/MSMNET X.400 Name John Smith X.400 Address G=john; S=smith; OU=groupwisegatewayl ; P=acme; A=mci; C=us Dept Widget Marketing Legal Name John R. Smith Tel # 415 986 1414 Fax # 415 986 5994

Use of a master directory is a good way to translate between different address formats. Here we see the master directory entry for John Smith. The directory also contains the user-friendly name for each messaging environment, and other useful information. In this case, Smith's "home" system is Novell's GroupWise.

59 2 Technology Background, Part I

X.400 user agents—is that when X.500 can be used, directory problems almost evaporate. However, most organizations are currently stuck with connecting a series of different messaging systems, very few if any of which speak X.500. Ultimately, an X.500- based approach is likely to replace directory synchronization. But right now, directory synchronization is a critical requirement for most large organizations. Because it is so important, and because it's a major source of headaches, we elaborate later on the topic.

Directory Propagation Within a given PC e-mail system, a further level of synchronization is typically required to spread directory information between the different post offices. This is a simpler form of directory synchronization because all the address structures are identical, and it tends to be known as directory propagation. Usually the PC e- mail system itself provides tools to do propagation within the system—cc:Mail's ADE and MS Mail's Dir Sync are common examples.

2.8 Distribution Lists Distribution lists—frequently referred to as Dihsallow a sender to send a message to a group of users by sending it to a single address, that of the DL. A utility, typically part of an MTA, recognizes the address in the message as a DL, and performs a DL expansion. During the expansion, it removes the DL from the message's address field, and inserts the individual addresses. For example, you could have a DL called "Sales". Addressing a message to the single address "Sales" would allow you to send a message to the three thousand salesmen working for your company, without entering three thousand addresses one by one. An individual address within a DL is called a DL member.

Management issues Distribution lists present several management issues: • Somebody must own and manage each DL. Not everybody should be able to change it. Often the owner is a user. • Imagine sending a message to three thousand recipients of a DL, and asking for read receipts. Your mailbox would be inundated by the receipts. X.400 deals with this problem by allowing receipts to be sent to an administrator or clerk instead of the sender. The administrator or clerk can them tabulate the

negative receipts or take action as necessary. • Access controls are necessary. You don't want anybody in your organization to casually send messages to your three thousand salespeople. • There can be substantial costs associated with the delivery of a message to members of a list. You need to monitor the use of large DLs, and ensure you can identify who to charge for the use of the list. • DLs should be treated like regular addresses. For example, if you maintain the list in an X.400 environment, your cc:Mail users should still be able to use it by sending a message as they would to any other X.400 user. DLs can be very complex, in particular when they contain addresses that represent other DLs. This poses technical problems (for example, by allowing circular references, and infinite expansion loops) and administrative problems (eg, senders may not realize they're sending to a list and will incur large carrier fees).

Recommendations • Keep DL names descriptive, so users know whether they are sending to a DL or to an individual. For example, an address like engineering may represent the engineering operator, or everyone in the engineering department. • You may want to have several levels of access control. Large DLs may be accessed only by specific individuals who manage their use, whereas smaller DLs may be accessible by everyone. • A chargeback proportional to use is very valuable, since DL use makes it easy to consume a lot of resources. • Watch out for DLs containing many members reached through fax or telex rather than e-mail—hard dollars to third parties are due, and the costs easily escalate. • DLs within DLs are very useful. For example, it is nice to have a DL called "Sales_DL" which contains two other DLs as members, "Sales_South_DL" and "SalesNorth_DL". • You may want to establish some procedures to prevent circular definitions.

61 2 Technology Background, Part I

2.9 More on Addresses We return for a closer look at X.400 addresses. First we look at the main problems you should be aware of, and then give some recommendations.

What The Problems Are Addressing is a problem in X.400 environments, because: • X.400 addresses, while very flexible, are long and unwieldy. Users don't like them. They do not fit neatly onto business cards. They are hard to communicate verbally, unlike phone numbers. • They're unnecessarily complex. For example, there is no good reason why an ADMD's name should have to be included; and many organizations include a lot of complex 0 and OU attributes. • Since they are long, they are very error-prone. It's easy to type them incorrectly. • Since they contain a lot of information, users tend to get assigned more than one address, and this creates a great deal of confusion. For example, if a PRMD connects to several ADMDs, the user may have several equivalent addresses, where only the ADMD name is different. • It's hard to shield X.400 users from the problems. Even though user- friendly aliases may be employed, users still have to fiddle with X.400 addresses to some degree. More specifically:

Absurdity of Including ADMD Names As we saw, a user's address contains the ADMD to which that user's PRMD is connected, as in: G=john; S=doe; P=abc; A=mci; C=us It's mad to have the ADMD name included. It's an irrelevance, like insisting that your postal address should have the name of your preferred package delivery service, or that your phone number should contain a name or number identifying your long distance carrier. Including the ADMD information in X.400 addresses makes nice free advertising for the ADMDs, no doubt. But it makes addresses harder to remember and use. Plus, it tends to lock the user into a given ADMD: if you want to swap ADMDs, you'll have to notify all your correspondents, otherwise mail they send to you (via the old ADMD) won't arrive.

A=Single Space It's not hard to see how to get rid of ADMDs in addresses. Basically, it requires every ADMD in a country telling the other ADMDs there about the PRMDs that connect to it. To illustrate, suppose A=mark400 (the ADMD operated by GEIS) receives a message addressed to S=doe; P=abc; A= ; C=us If mark400 knew that ABC used Telemail as its ADMD, mark400 could then pass the message to Telemail which, in turn, would pass it to ABC. Thus an ADMD outside the US that has a message for Doe could pass it to any ADMD within the US. The A= qualifier could be skipped entirely. There are some technical glitches which we will not delve into in any detail here. One example is that messages and delivery notifications may travel over vastly different routes, making quality control more difficult. To get rid of the ADMD information, it has been suggested that the ADMD value should be replaced by a single space, ie, the thing enclosed by the quotes in " ". Less visibly, others have suggested that it be replaced by an "X", or a "0" indicating you belong to no ADMD. There are some problems with these proposals. Entering a dummy A= qualifier is confusing and a waste of time. Plus a lot of parsing software gets confused by a single space. But it's better than having to put the actual ADMD name in. So we suggest you use the single-space approach if or when it becomes available. For an illustration, see chapter 14, the case study analyzing the UK Ministry of Agricul- ture, Fisheries, and Food.

Organizations with Multiple ADMDs A related issue is that users often have to have several different ADMDs. To see why, you need to know that for every ADMD, there are a number of other ADMDs it can't communicate with. Hence many organizations use several ADMDs, in order to maximise the number of people with whom they can exchange messages. This in turn is likely to mean that every user has two or more addresses! One or the other is used, depending on who's sending or receiving. This is bad enough, but the ambiguity raises a series of subtle infrastructure problems. For example: • Each message has an originator field, which is used by the messaging system to determine where to send delivery and nondelivery notifications. Thus, it

63 2 Technology Background, Part I

must be correct. Suppose that user DOE sends a message. If it's sent via Telemail, the message will include contain the originator address S=doe; P=abc; A=telemail; C=us On the other hand, if it's sent by MCI, the message will include the originator address S=doe; P=abc; A=mci; C=us Thus, the originator varies according to the message route! • Occasionally, gateways autoregister users, as we will discuss later. This means that users sending messages through a certain gateway may get autoregistered twice. Even worse, in the case of a large organizations that uses several service providers, users may get autoregistered seven or eight times.

ADMD Attribute in PRMD-PRMD Connections Consider what happens if two organizations work together very closely, and have decided to install a direct PRMD-PRMD connection, without going through an intervening ADMD. What do addresses look like? The problem is that X.400 requires you to put in the A= attribute. The single-space-or-X approach, just described, is a reasonable way of handling this, provided your software can process the A=" " or A="X".

Country Attribute and Multinational Organizations What if you're a multinational organization? You could let staff have different C=values, depending on their country. The trouble is, this will probably mean you have to deal with different ADMDs in each country. Plus, many users move from country to country, often on short assignments. Every time they move, their address changes. Worse still, people who correspond with the country-hopping user have to update their address books. It would be much simpler, and often a lot cheaper, to let external correspondents send to a single ADMD, and then let your internal network work out how to deliver the message to the recipient. However, this can be weird, too. Eg, do users in France really want to give their address as, say:

G=philippe; S=noiret; P=renault; A= attmail;

C=us Indigestible 0= and OU= Information Many creative messaging professionals have bestowed their users with addresses that include detailed routing information. You end up with addresses like: G=john; S=smith; OU2=nymta3; OU1=new york; 0=acme machinery; P=ami; A=attmail; C=us

This is fun for sadistic system designers with strong formal leanings, (not to mention masochistically inclined users), but dreadful to type in, and impossible to remember or guess. Life also gets unpleasant when users change departments, because their address probably changes. Often, messaging support staff inflict this pain because they think all the 0= and OU= routing information is supposed to be included in X.400 addresses. They're wrong about that, at least as far as the X.400 specification goes. Sometimes it's put in to make the management of routing tables easier, as discussed in chapter 4. Either way: think twice if you're tempted to suggest addresses with an 0= and one or more OU= fields.

Address Format Recommendations We round off this discussion with some recommendations on address conventions.

Yardstick: Internet Addresses Even through the X.400 address format is flexible and extensible, it is hard to remember, and not intuitive. Strangely enough, when X.400 first came along, around 1984, its addresses were perceived to be more user friendly than the much shorter, but numeric, telex numbers. The comparative yardstick has lately been Internet addresses, as in: [email protected] These are relatively easy to type and remember. They contain little routing information: John Smith at XYZ Corporation gets his mail whatever department or country he's in, provided he stays at XYZ. The Internet has a clever piece of internal infrastructure, known as the Domain Name System or DNS, which is used to transfer a message to its destination address. More precisely, DNS converts e- mail addresses into IP addresses.

Industry Simplification Attempts Going Nowhere There are movements, primarily within the Electronic Messaging Association—or EMA as it's usually known—to shorten addresses. The goal is to get to some Internet-like structure, mostly by chopping attributes. Unfortunately, members of the team reckon the efforts are going nowhere. It seems X.400 addresses will continue to be troublesome for the foreseeable future.

65 2 Technology Background, Part I

This is a great pity. Today, it often makes more sense to use X.400 than the Inter- net, especially because of the better security and relative ease in handling binary file transfers. But with today's technology, it's often necessary to type in entire address strings, rather than just enter attribute values into a formatted screen. The problem is compounded, because many organizations have unnecessarily unwieldy X.400 addresses. As a result, users often prefer to use an Internet address—there's less hassle involved.

Address Convention Recommendations We now present a series of guidelines for good X.400 address structures. In part, these draw upon the excellent recommendations found in the EMA's X.400 Reference Guide. • As a general matter, keep things as short and simple as you reasonably can. • Have addresses of the form: G=first name; S=last name; P=your organization name; A=ADMD name; C=country Ie, go from name to country. • If you really must have I's, O's and OU's, do them in the following order: G, I, S, 0, OU1, OU2, OU3, OU4, P, A, C. • Use upper case for the attribute qualifier names, and lower case for the values. • Use lower case in DDAs unless the case makes a difference. • Put DDA's at the end. • DDAs should be of the form DDA:type=value, not DDA=type=value or DDA. type=value • The given name should be the name the person normally introduces themselves, rather than their formal name. That way, it's easier for correspondents to guess the address. Thus suppose Chuck Swanson is legally known as Charles Andrew Swanson. We suggest he might be at G=chuck; S=swanson; P=xyz; A=mci; C=us rather than G=charles; S=swanson; P=xyz; A=mci; C=us • Likewise, the organization name should be short and as natural as possible. Put P=xyz if you introduce yourself as being from "XYZ" and not "XYZ Corporation". • Separate the fields by a semicolon followed by a space. • Try to avoid spaces inside an attribute value, eg, P="acme corp". While X.400 allows them, gateway parsers and non-X.400 user agents can easily get confused.

• Where ambiguities occur, it's best to ask users what they would like to have as a tiebreaker. A nickname or user-selected abbreviation often works well. If necessary, tiebreaker information can be inserted in DDA's. • Keep routing information out of the address. Avoid putting in O's and OU's. The names are easier to remember, plus the impact when a user moves internally is minimized. • Use A=single space if you can. Test well beforehand. • If you must have an OU but only need one OU, use OU1= rather than OU=. • Usually, avoid 2-digit field names. For given name, initial, surname, generation, organization, PRMD, ADMD and country use G, I, S, Q, 0, P, A, C respectively. • If there's some ambiguity about whether an attribute value contains a space, you may want to define one or more aliases so messages are handled appropriately. Eg, if your PRMD name is big corp, it's probably a good idea to define a bigcorp alias. As we discussed, the current state of technology make the following advice inapplicable: • Try to drop the ADMD reference entirely. • Given the shrinking world and the multinational nature of large organizations, avoid including any country information. Where user interfaces allow, users should be shielded from the X.400 address. For example, many products allow the user to browse through ordinary names, eg, Smith, Fred, possibly augmented by further identifying material such as the department name or employee ID. Users should able to point and click from such lists, without having to type in an underlying X.400 address. For further reading relating to the PRMD name, we recommend the EMA's white paper, Domain Name Registration.

EMA's Standard Mailbox Recommendations Another useful EMA publication, Requirements and Generally Accepted Practices for Operating a Production PRMD, describes some desirable standard functions:

67 2 Technology Background, Part I

Auto-Answer Mailbox This lets external parties determine whether they can communicate with a PRMD. A message should be addressed to: S=dirquery; P=prmd name; A=admd name; C=country name Turnaround should be instantaneous.

Directory Services Mailbox This provides directory information. A message should be addressed to: S=dirquery; P=prmd name; A=admd name; C=country name Turnaround should be instantaneous. The text within the message should have the form: FIND G=given_name; S=last_name Additional 0/R address elements can be added, using

A=admd name; OU1=ou_name; I=initial

etc Helpdesk Mailbox This provides general help on a wide variety of topics. A message should be addressed to: S=helpdesk; P=prmd name; A=admd name; C=country name

3. X.400 Technology Background, Part II

We now continue the technology backgrounder, looking at some more advanced issues. We end with a discussion of the pros and cons of an X.400 backbone versus other possibilities.

3.1 Data Communications Links The data communications technologies used in an X.400 network are a rather specialized topic, and people who are not data communications professionals will need extended study to become proficient. As a practical matter, messaging professionals usually never do this. Instead, they collaborate with data communications colleagues on planning, implementation, and support tasks.

We therefore present a high level summary of what's

involved. Messaging Protocols The various processes in an X.400 messaging system—notably user agents, MTAs, message stores, and directory components—have to communicate. As we've discussed, they do so by creating records with a standard format, which are passed between the communicating processes. We noted that the P1, P2, P3, and P7 protocols define the formats used by user agents, message stores, and MTAs to exchange information. If they run on the same computer, as for instance, MTAs and message stores often do, then the transmission of such protocols is relatively simple. It's like two subroutines passing parameters.

69 3 Technology Background, Part 2

Transport Protocols But if two communicating processes run on physically separate computers, the protocols must be transferred over a network. They are first put in a different envelope that provides for the special functions involved. This special envelope is known as a transport protocol. Transport protocols deal with navigating a packet over a computer network. For example, very long messages must be chopped up into more manageable lengths, so a transport protocol gives information on whether the message has been chopped up and if so, how to reassemble it. Transport protocols also include error checking information, in case a packet gets distorted during its journey. X.400 packets can be wrapped in two types of transport protocol: a TCP/IP transport, and an ISO transport. Once enclosed within a TCP/IP or ISO transport (protocol), an X.400 message can be transmitted over the computer network. It often passes over many different types of link. For example, an MTA might connect to another MTA over an Ethernet to a Cisco Router, then over a digital link to another Cisco Router, then through a token ring backbone to a bridge, and then over another token ring. The possibilities are extremely varied, and it's all handled by lower level software.

X.25 We now look at a special case. An X.25 network is a general-purpose network, and in many countries one or more public X.25 services are offered. For example, in the US, X.25 service providers include AT&T, MCI, and Sprint. If you want to connect two computers, you can do so using these services. Public X.25 networks throughout the world are connected, so it means you can use X.25 to connect two computers, pretty much wherever they are located. Some organizations run their own private X.25 network, although this is less common. X.25 can be used to connect the components of an X.400 network, provided the messaging protocols are first wrapped in an ISO protocol format. X.25 is frequently used to connect an in-house MTA to that of an ADMD. Note that X.25 use requires dedicated lines from your MTA to the point at which you connect to the X.25 carrier. This is expensive, and hard to set up. We discuss X.25 connectivity at greater length in chapter 9.

Asynchronous Protocol Specification Dialup communications are important, because they let two components of a messaging system connect cheaply and with a simple setup process. Unfortunately no standard way of doing this was available until recently. What this meant, for example, was that if a vendor wanted its MTA to be able to dial up another MTA and then exchange messages, it had to come up with its own way of doing so. Another vendor's MTA would be unlikely to understand the way information was being transmitted. In turn, this meant that if you wanted two MTAs to connect directly over dialup, the MTAs needed to come from the same vendor. So in 1992 and 1993, many major vendors got together to define the Asynchronous Protocol Specification, or APS. The first draft was published in June 1993, and defines a way that any two different X.400 components can communicate directly over ordinary telephone lines. It will also work over asynchronous, dialup X.25 connections. Because it's a formal, standard definition, the components can come from two different vendors. For example, APS allows an X.400 remote user agent, X.500 directory user agent, or X.400 MTA to connect to an X.400 message store, X.500 directory system agent, or X.400 MTA. However, the specification is not limited to these particular objects and their associated protocols. The processes being connected can run on any hardware platform and under any operating system. As with X.25, X.400 protocols are first wrapped in an ISO transport prior to APS transmission. In late 1994, APS was adopted by the International Telecommunication Union or ITU(see section 2 following), as its X.445 recommendation.

APS Relevance & Status The most important uses will be: • To connect to an ADMD over dialup. This is a lot cheaper and simpler than using the normal connection method, X.25. • To connect any two X.400 MTAs. As noted, the MTAs can be from different vendors. • To connect a user agent and a message store (eg, for when people are working out of the office). During 1995, expect APS support to become available. Vendors who have announced they'll bring out APS-compatible products include AT&T EasyLink, Digital, Enterprise Solutions, ISOCOR, Lotus/SoftSwitch, MaXware, Microsoft, Pacific Bell, SITA, and Tandem. We expect the technology to be widely deployed by the end of 1996.

71 3 Technology Background, Part 2

Summary • An X.400 network consists of user agents, message stores, MTAs, and directory components. • Messages are sent between the different components by putting them in a TCP/IP or ISO transport envelope. They can then be transmitted through a complex data communications network supporting those protocols. • Messages can be transferred over public X.25 networks. • Messages can be exchanged directly between different components over ordinary telephone lines. If you're using the APS standard, the things at either end can be from different vendors. For data communications professionals, the situation's summarized by figure 3.1.

3.2 1984, 88, 92 Specifications X.400 gets its name from a set of recommendations approved by the CCI11. This is an agency of the International Telecommunication Union or ITU. On March 1, 1993 the CCITT changed its name to Telecommunication Standardization Sector or TSS. The new name is taking a while to catch on, and we usually refer to the defining body as the CCITT instead of TSS.

FIGURE 3.1 TECHNICAL SUMMARY OF X.400 TRANSPORT STACKS

Application Layer Message Transfer Message Transfer Message Transfer Message Transfer Presentation Layer Session Layer Transport Layer Class 0 or 4 Class 4 Class 0/TCP Class O/TCP

14302114020:*

OSI Model over packet network over LAN over dialup over TCP/IP

X.400 can run over TCP/IP and ISO transports. Over X.25, APS, and TCP/IP, a Class 0 transport connection is used. Over a LAN, where packets can be dropped, a Class 4 transport connection provides additional reliability through built-in recovery mechanisms.

The CCITT has a plenary meeting every four years, where the members formally accept new recommendations or updated versions of old recommendations. Inci- dentally, the documents passed are not called standards but rather recommendations, because they are not formally enforced. The International Standards Orga- nization or ISO passes very similar specifications, and the long term goal is that the ISO and CCITT standards will be identical.

Differences Between 84 and 88 Versions The CCITT accepted the first version of the X.400 recommendations in the 1984 plenary session. They were not as consistent as could be, and apparently some of the work was rushed. This version became the basis for most implementations in existence today. The CCITT accepted a significantly updated series of recommendations in 1988. These recommendations were a complete rewrite of the 1984 recommendations. The difference was not only formal, but also functional. A number of substantial additions were made, notably: • The definition of the message store • Security related services, such as encryption and authentication • Use of the X.500 directory by X.400 • Ways of connecting 1984- and 1988-based systems

Connecting 1984 and 1988 Systems These additions are, of course, not known to 1984 based systems. Therefore, the 1988 recommendations were designed to be backwardly compatible. This means that when a 1988-based MTA relays a message to a 1984-based MTA, it has to remove all 1988 specific elements. This process is called downgrading. Sometimes downgrading isn't possible. For example, if a particular message uses a 1988 security feature, such as a request for proof that the message was indeed delivered to the recipient, a 1988-based MTA cannot downgrade. In such cases, the 1988 MTA cancels the message, and generates a nondelivery notification. The 1992 recommendations have only minor changes from the 1988 recommendations.

73 3 Technology Background, Part 2

3.3 X.API Association One of the initial problems facing X.400, which has slowed down the integration of X.400 into messaging environments, was that the recommendations were perceived to be too complex. This is true: • The structure of X.400 messages is based on a hard-to-understand formal grammar known as ASN.1. • Communications with an MTA are complex, and application programmers were unduly exposed to the process.

Goal: Hide X.400 Complexity From Programmers Ordinary programmers cannot be expected to learn X.400 internals in order to build messaging applications. So a group of X.400 vendors decided to create a relatively simple applications programming interface. In 1988, they formed the X.400 Application Program Interface Association or X.APIA, chartered to produce APIs for an X.400 environment. Recently, the X.APIA has been seen as a useful vehicle for the development of vendor-independent APIs outside the X.400 field. The organization's work has now involved such areas as a general-purpose API (the Common Messaging Calls or CMC), and an API for group scheduling. Figure 3.2 lists the work this august body has done so far in the X.400 field. We discuss these APIs in more detail in chapter 13, and compare them to alternatives.

FIGURE 3.2 X.APIA SPECS 11111111111111111

. . . ••• •••••., . . .

1990 Electronic Mail API (XMA, XMT) MTA access for UAs, gateways 1990 Directory Services API (XDS) X.500 directory access 1990 OSI Abstract Data Manipulation API (XOM) Mechanisms to manipulate objects used in the various APIs 1992 Message Store API (XMS) Access message store 1992 Object Set For EDI API Access EDI X.435 messages 1992 Common Messaging Calls API (CMC) Generic messaging system interface

The X.API Association has created a number of APIs for access to an X.400/X.500 messaging system. With its Common Messaging Calls, the group has recently started developing other types of industry-standard APIs.

3.4 Connecting To An ADMD One of the major issues that an organization needs to consider when setting up an X.400 network is how to connect its MTAs to those of its service providers. Currently, there are two ways of connecting to the ADMD, by: • X.25 • Dialup, using the Asynchronous Protocol Specification. In the future, it will probably also be possible to make connections using TCP/IP, through an Internet carrier. If you're connecting WANs within your own organization, you may also be able to connect MTAs using an extended LAN. However, in the remainder of this section, we concentrate on today's options for ADMD connectivity.

X25 Most PRMD-ADMD connections are made using an X.25 network, also known as a packet network. Generally, ADMDs either operate their own packet network or contract with a packet network operator to purchase capacity on such a network. A typical X.25 network has access locations, called points-of-presence or POP, in many geographical areas. Thus, X.25 connectivity requires a dedicated data line between the PRMD location where the MTA is located and the service provider's closest point-of-presence. Special synchronous modems connect the MTA to the permanent line.

Installation & Planning Efforts The first thing to note about X.25 connections is that specialized skills are required. Very few e-mail support people have these skills. In particular, you need to be familiar with: • ISO transport and network addressing protocols • Special synchronous modems • How to make an X.25 connection • How to coordinate with ADMD and X.25 carrier support • How to troubleshoot connectivity problems when they go wrong Setting up a dedicated line is a process with a long lead time, typically 45 to 60 days. Many parties, including the local phone company, usually need to get involved, so it is hard to reduce the elapsed time. If your packet provider claims they have a pull over the local phone company, and they will get it installed in 30 days, be grateful, but sceptical.

75 3 Technology Background, Part 2

The setup charges, need for planning, and plain inconvenience indicate that you must have a good grasp of what you are doing, and have planned everything well. You must also ensure that the applications requiring the connection will be satisfied. For example, suppose you incur the expense and inconvenience of setting up a connection for the purpose of, say, transmitting gigantic binary files to a correspondent halfway across the world. It would be moderately irritating if after installation you find that one of the service providers along the path restricts you to a maximum message size of one megabyte.

Dialup Connections The APS standard for dialup communications is now beginning to be implemented, and some ADMDs can be expected to support it before long. APS should be a significant stimulus for X.400. First, for many MTA-MTA connections, it will be much cheaper to install and operate than X.25. Also, the demand on technical staff is much less. They just need to know about ordinary asynchronous modems, and the dialup telephone system. They don't have to learn about specialized data communications technology and protocols. So expect to make widespread use of dialup connections to your ADMD.

3.5 Support for EDI

EDI is particularly well suited to X.400. Organizations using EDI are often connected to different EDI-specific messaging networks. Although these networks are interconnected, there are still connectivity limitations. Plus, you pay the price of a proprietary network. EDI messages will be a lot more widespread, and cheaper, when they are moved around with X.400. X.400 can carry any kind of data, and all that's needed for it to carry EDI traffic is to define how interchanges are put into a message. The receiving application, when unwrapping an X.400 message, must know where to look for an EDI part. There's a standard, known as X.435, which defines how EDI messages are put into an X.400 message. X.435 is not yet in widespread use, so for the moment there are three main ways of sending EDI messages (figure 3.3): EDI interchange within an interpersonal message (figure 3.3.a). In this case, the EDI interchange is put inside an interpersonal message as payload. The advantage of this approach is that no MTA along the path from sender to recipient knows that the contents are specially formatted. Of

course, the originating and receiving UAs must know to pack/unpack and interpret the interchange contents. At the present, this is by far the most common way of doing EDI over X.400. • EDI interchange within a PO message (figure 3.3.b). In this case, the message is sent in PO format, meaning essentially that it has an undefined content type. No IPM message header is utilized. Instead, the EDI interchange follows the P1 header. This approach should be straightforward, but it's possible that one of the MTAs along the path cannot handle a message of content type P0. In most cases, however, if tests go well, there should be no problem.

FIGURE 3.3 EDI INTERCHANGE USING X.400

Message ID Message ID Message ID Originator's address Originator's address Originator's address Recipients' Recipients' addresses Recipients' addresses Priority Priority addresses Priority Content type = P2 Content type = PO Content type = PE°,

Content ID Business EDI Heading Letterhead Originator Originator's ID Recipient EDI Recipients' IDs message type Importance Interchange sender

et ea izi.t,(

(a) (b) (c) within P2 within PO within P„, message message message (X.435) The most common method of sending EDI messages over X.400 is where they're buried in an interpersonal message (a). The X.435 specification defines a new content type (c).

77 3 Technology Background, Part 2

• X.435 (figure 3.3.c). The "standard" way of doing EDI over X.400 is defined by recommendation X.435, which we now discuss.

X.435 Basics CCITT Recommendation X.435 defines how EDI interchanges are carried across an X.400 network, The P2 message is replaced by a PEDI message. Some EDIspecific additional services, such as EDI notifications, are defined. The new services are completely transparent to the X.400 recommendations, and involve no changes to the underlying specifications.

A PEDI message can carry a number of body parts, but only the first body part can carry an EDI interchange. The EDI interchanges themselves must be in one of the following formats: EDIFACT, UNTDI, and ANSI X.12. The designers of X.435 limited the level of integration between EDI and X.400. For example, an EDI interchange, as defined by X.12, already carries addressing information. The X.400 envelope also carries addressing information. The redundancy simplifies gateways between X.435 and proprietary systems because it means that when converting from X.435 to a proprietary format, the whole interchange extracted from the P EDI message can be used without any further conversion. X.435 requires the 1988 implementation of X.400. Thus, in some environments, the requirement to support X.435 increases the need for a 1988 X.400 implementation. One could argue, on the other hand, that this requirement dampens the demand for X.435, and causes organizations to stick with their proprietary connections until they feel that 1988 implementations of X.400 are sufficiently mature.

3.6 Security The 1984 X.400 recommendations provide for the transfer of binary files. Thus, any kind of content can be encrypted and treated as a binary file. However, the originator and recipient must agree on the encryption mechanism used, encryption keys, and so on. So encryption is only rarely used in 1984 implementations. One of the most important new aspects of the 1988 recommendations are a wide variety of powerful security services (figure 3.4). The main goals are to: • Ensure that unauthorized parties cannot interpret correspondence. • Ensure that documents cannot be altered in transit and cannot be forged.

FIGURE 3.4 MAIN X.400 SECURITY SERVICES scriptio

Content confidentiality Content cannot be read by anybody but sender or recipient Content integrity Once a message is "sealed" nobody can change its contents Message origin authentication Recipient has proof of who sent the message Message security labeling All MTA, MAs, and UAs must enforce message security label requirements Message sequence integrity Determine whether messages received in the order sent by sender Nonrepudiation of delivery Recipient cannot deny that s/he received message Nonrepudiation of origination Sender cannot deny that s/he sent message Nonrepudiation of submission Sender cannot deny that and when s/he submitted message Proof of delivery MTA provides proof that it delivered message Proof of submission Sender has proof that s/he submitted message Report origin authentication Recipient has proof of which MTA originated a delivery/nondelivery report

1988 X.400 offers very powerful security features, with the intent that public key cryptography be used.

• Ensure that when a sender sends a message, he or she cannot later claim not to have sent it. • Ensure that when a recipient receives a message, he or she cannot later claim not to have received it. • Make it hard for unauthorized parties to analyze traffic patterns. These features also have the potential of increasing demand for 1988-based implementations. Yet, 1988 security is appearing only slowly. Why?

US Government Restrictions The 1988 spec does not describe how to encrypt messages. They do, however, strongly imply the use of a method called public key cryptography. The major algorithms are patented by a company called RSA Data Security. It's an excellent encryption method. So good, in fact, that even security agencies of the US government, with megamips of processing power at their disposal, cannot break it. They are worried by the technology, because they want the ability to eavesdrop on criminals and others with interests different from those of the US. There are two big impacts on X.400. First, the US government limits the export of MTAs and other equipment which use public key encryption. Second, it tries to limit the length of the keys that can be used.

79 3 Technology Background, Part 2

It appears that the feds are going to lose this particular battle. The RSA algorithm is published, and anybody can implement it. People in and out of the US have done it, even in hardware. A Prague-based developer can simply link to the Inter- net, and download a set of programs that will allow them to integrate RSA into their product. So much for export restrictions.

interoperability Despite the excellence of public key cryptography, there are many obstacles to widespread deployment. For a full discussion, we refer the reader to the 7/93 Ferris E-Mail Analyzer. One area of particular concern is that interoperability between different public key products is still almost non-existent. RSA and many major organizations are trying to define further standards to resolve this. To summarize: in theory, X.400 has excellent security features. But they will be of limited value for perhaps the next five years. Until then, security will be poor.

3.7 Connecting To Customers & Trading Partners X.400 is useful to an organization not only as an internal backbone, but as a way to connect to the external world. There are several possibilities (figure 3.5): • When it is necessary to exchange messages with a number of trading partners, then it may be more appropriate to connect to a service provider using an X.400 connection. Such a connection is referred to as a PRMD- ADMD connection. • When connecting to a single correspondent organization, such as a trading partner, it may be useful to connect directly using X.400. This is referred to as a PRMD-PRMD connection.

Alternatives to X.400 Connections Organizations exchanged messages well before X.400 came along, and alternatives abound: • One can develop interfaces optimized to a particular application (as has been done for EDI traffic). • One can connect to a messaging service provider using its custom protocols. • One can use an Internet connection, using SMTP.

FIGURE 3.5 CONNECTING TO THE OUTSIDE WORLD WITH X.400

ABC Corp. DEF Corp.

PRMD ADMD ADMD PRMD

X.400 over X.25 (dialup in future?)

GHI Corp. (a) PRMD-ADMD connection

ABC Corp. DEF Corp.

PRMD PRMD

X.400 over X.25, TCP/IP, or dialup

(b) PRMD-PRMD connection

Usually, one connects to trading partners via an ADMD (a). Sometimes it makes sense to have a direct PRMD-PRMD connection (b).

• Some service providers allow organizations to exchange messages through their systems, using eg cc:Mail-, MS Mail-, or NetWare MHS-based protocols. These are all connectivity alternatives that compete with X.400 and which at times are a better solution. We'll look later at X.400's weaknesses. But for the moment, we focus on its strengths.

X.400 External Connectivity Benefits The advantages of X.400, as a way to connect with the external world, are: • Widespread Connectivity. Many ADMDs are interconnected via X.400. Thus, once connected to your ADMD, you can exchange messages not only with your ADMD's customers, but also with the customers of all ADMDs connected to your ADMD. Within the US, for example, it does not make much difference as far as connectivity is concerned whether you connect to Advantis, AT&T EasyLink

81 3 Technology Background, Part 2

Services, MCIMail, or SprintMail. There are, however, subtle differences, and not all connect to as many or the same international service providers. • Standardized. X.400, even if complex, is fairly standardized. You can use the same technology to connect to different service providers. • International Access. This is generally good. Some US-based service providers, such as Advantis and Sprint, provide access to 30 or 40 countries. • Expandable Functionality. Often, organizations connect to a service provider for a particular reason. With an X.400 connection, once the link is established, its use can be expanded since the underlying functionality is there. For example, a company based in Texas may initially need to exchange word processor files with two correspondents in Connecticut and Oregon. A few months later it realizes there is need to exchange messages with a new business partner in Taiwan. Another example is where X.400 is installed as a telex replacement between two law firms, one in the US, the other in Latvia. Soon it becomes apparent that if revisable word processor files are exchanged, the amount of retyping done on both sides will be enormously reduced. • Physical Network Independence. An X.400 connection does not necessarily dictate the type of the underlying physical network. Today it can be dialup, packet network, TCP/IP, or ISO connection.

PRMD-PRMD Connection Benefits A PRMD-ADMD connection is usually the best way to connect outside with X.400. But sometimes it's best to connect directly to trading partners: • Security. Two organizations connecting directly can have greater control over the handling of their messages than with an intervening service provider. • Cost Savings. If two organizations exchange enormous binary files very frequently—imagine two engineering organizations working together and exchanging multi-megabyte CAD/CAM files—then a direct connection may be cheaper. You pay only for intersite data communications, and avoid the additional "messaging charges."

PRMD-ADMD Connection Benefits The main arguments in favor of a PRMD-ADMD connection are: • Connectivity. You connect to a much larger universe of correspondents, immediately. • Security. Some organizations perceive a security exposure when third parties connect directly to their messaging system. An intermediary ADMD thus acts as a sort of fire wall.

• Debugging. Establishing an X.400 connection requires some level of initial testing. It is easier to test once with a service provider than with every potential connection partner. • Custom Connections. A service provider is usually better equipped to deal with correspondents' varying communication capabilities. For example, if some of the correspondents consist of small companies that will not install X.400, then the ADMD can make access simpler by offering proprietary connections. • Support. When a large number of correspondents are involved, the ADMD operator can provide necessary technical support, training, operational support, and so on to correspondents, reducing the load on the organization initiating the connection.

Making The Physical Connection At the time of publication, the normal method of connecting a PRMD to its ADMD is over X.25. Dialup connections, following the APS specification, are becoming available and as discussed elsewhere, will become very popular.

Internet As PRMD-PRMD Connection For PRMD-PRMD connections, a good alternative is to use the Internet as an connect mechanism. In such a case, TCP/IP replaces the lower three layers of the protocol stack (figure 3.1). This can be a lot cheaper, and simpler if you already have an Internet connection. Plus it doesn't require installing X.25, and the elements providing message integrity, such as session connection and checkpointing, are still available. On the other hand: • Both MTAs must have an Internet connection. • The Internet poses certain security risks, since one really doesn't know which route the messages are taking and who can eavesdrop. See the March 1993 Ferris E-Mail Analyzer for a further discussion of connecting to the Internet.

X.400 Connectivity Shortcut: Service Provider's X.400 Gateway There's also a very attractive compromise as far as installing X.400 goes. You use a messaging service provider's X.400 gateway (figure 3.6). It's a means of providing X.400 connectivity that's doesn't require much money or technical skill to get started. MCI's REMS service is the best known example, although many other service providers offer a similar capability.

83 3 Technology Background, Part 2

FIGURE 3.6 SERVICE PROVIDER RUNS X.400 GATEWAY

ABC Corp. e-mail service provider DEF Corp.

Non- 00X 4 X.400 X.400 X.400 PRMD Gateway MTA Networ PRMD MTA k

dialup connection

A very good way to get external connectivity started is to let an e-mail service provider run the X.400 gateway for you.

You connect to the service provider using some non-X.400 connection method. This could be MHS, SMTP, cc:Mail, or any other custom protocol used both by the customer and the service provider. The service provider converts the messages to and from X.400 and provides connectivity to the rest of the X.400 world. This approach is a very good first step towards X.400 connectivity: • It is usually much cheaper than installing an X.25 connection, at least until X.400 access becomes available over dialup. • The software required to implement it is usually much cheaper. • Standing fees are low. You mainly pay per-message charges. • Many computer staff understand the technology involved—asynchronous modems and dialup lines. The disadvantages are: • The service provider makes many decisions about address structure, conversion facilities, etc. • Users' X.400 addresses are generally unintuitive and unpleasantly complicated. • It is less flexible, in particular when the organization is internally X.400-based. • As traffic increases, it can become more expensive than generating the X.400 protocols in house.

3.8 Original Software Developers Don't assume that a given X.400 vendor has written all their software themselves. Vendors often purchase source code from a third party, and then perform some level of tailoring. The major OEMs concerned are: • Data Connection Limited. This company has an X.400 MTA, UA, and message store, and an X.500 DSA. It produces custom versions of its code for a small number of third parties, of which Lotus and Microsoft are the best known. • Enterprise Solutions. A number of vendors resell this firm's X.400 user agent software. • ISODE Consortium. This group offers an X.400 MTA and message store, and X.500 DSA. Many commercial, academic, governmental, and research groups fund the Consortium's work: Perhaps the most visible resellers are AT&T Global Information Services, Boldon James, Enterprise Solutions, Innosoft International, ISOCOR, LJL Enterprises, NET-TEL, Northern Telecom Secure Networks, and Software and Systems Engineering. • Marben. This firm offers an X.400 MTA and X.500 DSA. • Retix. A number of products contain this vendor's MTA code. Since Retix has cut back greatly on its messaging activities (and may indeed have extinguished them), most vendors no longer consider the company a viable supplier. • Unisys. The company offers X.500 code, its most notable customer being Lotus/SoftSwitch. There's also some public domain code. PP and QUIPU are the best-known examples, representing an X.400 MTA and X.500 DSA respectively. PP can also route SMTP messages. ISODE Consortium products are based on PP and QUIPU; NEXOR and Control Data Systems also use some of the code.

3.9 X.400 Backbone Alternatives You don't have to use X.400 as the only way of connecting different e-mail system. There are alternatives that are successful in many settings. Here we compare them to X.400, and assess when they're a better choice.

85 3 Technology Background, Part 2

SMTP/MIME and the Internet Simple Message Transfer Protocol or SMTP is a set of messaging protocols used widely in the Internet. It is described by a set of request for comments or RFCs. RFCs can be viewed as the equivalent of recommendations in the CCITT world. They are numbered consecutively as they come out. The message formats are described by RFC 822, and the protocols, ie, how nodes talk to each other, are described by RFC 821. It's interesting reading. SMTP messaging comes in several versions. The earliest and most popular version of SMTP was limited to ASCII text. Nevertheless, it is possible to transfer binary files. To do so, there are programs that convert a binary file to an ASCII file for transmission purposes. It looks like gibberish in transit, but the recipient has a matching decoding program that reads the "ASCII message", and reconverts it to a binary file. This works well for smallish files—say up to 64KB—but creates problems. Invoking the programs requires some techie skills. Originator and recipients must, of course, use compatible encode and decode programs. The most popular programs to do such encoding and decoding are called UUENCODE and UUDECODE, respectively. A newer version of SMTP addresses this problem, and lets binary files be included in a message. It is defined by RFC 1341, and is called Multi-Purpose Internet Mail Extensions or MIME. Pointers to binary files can also be carried instead of the files themselves. When you read the message, if such an attachment is detected, you are asked if you want to fetch it. If you answer Yes—and assuming you have the required file transfer software—the file gets fetched. MIME is starting to become popular. It requires an implementation of SMTP with the MIME extensions, as well as the associated file transfer protocols. There are additional extensions, such as Privacy Enhanced Mail or PEM. This provides public key cryptography services that are much the same as those defined in the 1988 X.400 spec. It's at an early state of development, although activity seems to be much further along the road than that of the X.400 community.

SMTP/MIME As Backbone SMTP uses TCP/IP protocols to move packets around, as does the Internet. Just as X.400 messages can be transmitted over different transport mechanisms (X.25, dialup, dedicated links, etc), so can SMTP messages. Think of the two end systems as connected through a pipe, with the transfer complexities largely transparent.

As we mentioned before, many organizations are gradually replacing their existing mainstream data communications network—notably ones based on SNA, DECnet, and SPX/IPX protocols—with a TCP/IP network. SMTP then becomes attractive as a backbone technology. Such internal TCP/IP networks are usually largely isolated from the Internet for security reasons—companies don't want hackers and fellow travelers being able to get in. Ultimately, however, some sort of Internet connection is normally established, at the least to let e-mail be transmitted. (figure 3.7).

Standards Definition Faster Than ISO The procedure of specifying standards in the Internet world requires that, before an RFC is declared an Internet standard protocol, there be at least three independent implementations, and that they interoperate. This straightforward process is in stark contrast with that of the CCITT, where everything is specified in great detail, and the ink on the dot of the last i has to dry before anything is considered for implementation. The RFC mechanism provides for much faster definition and implementation cycles, at least in the academic community. Things that do not work are discarded, usually early in the cycle.

SMTP/MIME Advantages As Backbone • Entry costs are lower than X.400. No dedicated X.25 lines are needed. In X.400's defense, however, note that dialup will shortly become widely available. • Internet e-mail addresses and connections are much more ubiquitous than X.400. An enormous number of organizations are already on the Internet. • Connecting to the Internet, while still often quite challenging, is getting a lot simpler. Dialup communications and friendlier setup software deserve most of the credit. • The Internet has far better connectivity: there's a much better chance that given someone's Internet address, that mail you send to them will get through rather than be returned. As previously noted, the Internet has a distributed directory known as the Domain Name System or DNS. This provides the basis for MTA routing Messages can traverse many different intermediary organizations. On the other hand, to get messages from sender to receiver over X.400, you had better either share the same ADMD, or use two different ADMDs that have been connected, or have a direct PRMD-PRMD connection. Due to petty squabbling about how to share the fees, ADMDs haven't implemented

87 3 Technology Background, Part 2

FIGURE 3.7 INTERNET MESSAGING CONNECTIVITY

Sender's System Recipient's System (Other Organization)

Corporate TCP/IP Internet Network

Recipient's System (Same Organization)

SMTP is an attractive messaging backbone for organizations using TCP/IP as their main data communications network.

routing in which 3 or more ADMDs are involved in transmission. Since many ADMD-ADMD pairs have not implemented connections, international X.400 mail fails frustratingly often. • Life's usually cheaper once you connect to the Internet, because the charges are not usage-sensitive. You send as much information as your data link's bandwidth will allow. Eventually, the authors guess that some sort of per-packet charges will have to be introduced, however. • SMTP addresses are simpler to remember and type in than those of X.400. • Important messaging experimentation is proceeding very quickly in the TCP/IP world. For example, the largest X.500 pilot—the Paradise project— is TCP/IP based. There is a lively messaging management spec, known as MADMAN, now gradually being integrated with X.400. The best network management console technology—notably HP's OpenView and SunNet Manager—comes from the TCP/IP world. There's a lot of work in the field of public key encryption. Although much of this is not in principle pro- SMTP and anti-X.400, the fact remains that most of the experimenters use SMTP/MIME and so this tends to benefit users before X.400. • The faster standards definition process means that new technology can be introduced quickly. For example, it appears that public key encryption will become widespread over SMTP long before it will with X.400. • Vendors' commercial interests interfere much less with the technology. Eg, as we've noted, the X.400 world has suffered markedly by the absurd re-

quirement that addresses include the ADMD name, and the inability of ADMDs to provide for multi-hop routings over more than two carriers. In general, it has to be said that many key X.400 vendors feel equivocally about interoperability, while vendors in the TCP/IP world see it as their way to fame and fortune.

SMTP/MIME Disadvantages As Backbone The main disadvantage of SMTP as a messaging backbone technology appears to be that backbone products vendors--Alisa Systems, Boston Software Works, CompLink, Digital, SoftSwitch, Worldtalk etc—are providing their integration services over X.400. They'll get around to doing the same over SMTP later, as a matter of secondary development priority. So, for the moment, X.400 backbones can offer better directory propagation, address mapping, and so on. A related point is that the main focus of the dominant client software vendors— especially Lotus and Microsoft—is to provide X.400-based communications, rather than SMTP-based communications. It appears that from the vendor side, most of the development resources are being directed at X.400. Messages going over the public Internet also have a number of problems: • The Internet is a fairly chaotic, decentralized environment. Many of the nodes are operated by entities such as research organizations on a volunteer basis, without a commitment to continuous operation. Generally, there are no guarantees that messages will get through the Internet within a given time, and messages are fairly often delayed by as much as five days. • Even worse, SMTP has no delivery notification mechanism. You can't tell when your message is stuck in some intermediary system, instead of having been delivered. • By design, the path a message will take through the Internet is not predictable. The Internet was originally designed to US Department of Defence specifications, to be survivable in a battlefield situation when individual nodes are hit. Thus, routing is dynamic. When a message leaves the corporate network, you can't tell where it will go. If the message is plain ASCII, anybody may be able to read it. A number of commercial Internet carriers such as Alternet and Performance Systems are starting to provide more reliable connections to the Internet, and they may provide some relief. As previously noted, there is also lively work on public key cryptography services, and these will also ultimately provide further relief. • Connecting your private network to the Internet may provide some level of exposure to intruding hackers, competitors, and so on. There are steps that

89 3 Technology Background, Part 2

can be taken to reduce the risk, but such measures often also make communication more difficult. Again, use of a commercial Internet carrier may provide some relief. On balance, there's a lot to be said for having an SMTP/MIME backbone instead of an X.400 one. It can be a lot cheaper, and functionality will often be superior. Organizations with a strong committment to the use of TCP/IP transports and applications (FTP, Telnet, NFS, etc.) should consider the option particularly seriously.

PC E-Mail Everywhere PC e-mail is spreading quickly. It's clearly the e-mail system of choice in most large organizations, although niche communities of Unix workstations usually go the SMTP/MIME route. Further, where an organization has large mainframe or minicomputer e-mail systems, mailboxes are typically undergoing a migration to PC email. Since PC e-mail systems now have clients for a variety of platforms—Windows, DOS, OS/2, Unix, Macintosh—the possibility arises that you might simply standardize on your PC package. Either don't connect to the other systems, which will speed the migration; or provide gateways to them. Either way, the solution to integrating different e-mail systems is basically to force the migration to a single PC package.

Advantages Of PC E-Mail Everywhere A number of large organizations are likely to go this way. The advantages are: • You only have to know a single technology. • The software has high functionality. • Interconnectivity between users is good. • Mail enabled applications have consistent APIs and messaging system access tools. • The software and hardware required is a commodity and subject to great price competition. • It's easy to find knowledgeable support staff and they don't need high salaries. (On the other hand, many organizations find that more of them are required to support a given number of mailboxes.) • Many of the most difficult integration problems disappear, or at least become much easier to handle, such as the need for address translation, or the synchronization of directory information.

Disadvantages Of PC E-Mail Everywhere • PC e-mail systems tend to have scalability problems as they exceed around 5,000 mailboxes. Mail delivery times become more unpredictable, and troubleshooting "lost" messages becomes harder. However, this is due to a series of factors, and whether X.400-based systems have an overall advantage in this regard is unclear. • Many organizations still need to connect other types of e-mail system. Legacy systems such as PROFS/OV and ALL-IN-1 will hang around for quite a while. SMTP/MIME e-mail is unlikely to disappear among Unix workstation users, even though there are Unix versions of some PC e- mail products like cc:Mail. Plus organizations acquire other organizations, and the new groups may well not use the same e-mail system as the merger partner. In every case, integration services must be provided. • A lot of support staff are required, which is very expensive. Many companies have one full time person (or equivalent in part-time hours) for every 400 PC e-mail mailboxes. • Connectivity must still be provided to the external world. Again, a gateway must be operated somewhere to serve the entire PC e-mail user population. • If several types of different PC messaging systems are being connected, one must make sure that the pairwise conversions (message format, address conversions, etc) are satisfactory.

Chapter 4

4. Directory Services

We now turn to a discussion of the main issues associated with directory services. First, we review what a directory is. Then we discuss several important directory-related issues that must be dealt with by messaging support staff: • Address lookup • User administration • Letting outsiders have access • Message routing. Address translation is closely associated with directories, but because the topic's a big one, we leave it to its own chapter. We mention briefly that there are two main ways backbone directories are implemented: using directory synchronization, and using X.500. These approaches are discussed in greater length in later chapters.

4.1 What's A Directory? As society becomes increasingly interconnected via various communication media—telephones, faxes, computer networks, the postal service, etc—the problem of finding information about the myriad things that are potentially accessible via these media acquires critical importance. This is especially the case for people, organizations, and applications that are interconnected via computer networks: • People need e-mail addresses in order to exchange messages and need to know how to obtain documents stored electronically.

93 4 Directory Services

• Workgroup applications need to know how to direct information to appropriate members of the group. • A browser application used to access network-accessible information resources needs the address of the resource. • Security programs that use public key cryptography need to find people's public cryptographic keys. • Various kinds of store and forward delivery systems need routing information. Today, this information is usually found in a rather laborious way. People copy email addresses from business cards or get them over the telephone; applications require manually constructed configuration files; network resource addresses are copied from magazine articles or bulletin board postings. They're effective but inefficient solutions to the problem. Directories provide a more elegant solution. The long-term vision is that someday most if not all information needed about the things accessible via these media will be available via a directory service that is ubiquitous and easy to use. All that will be required in order to interact with a person, organization, application, or information resource will be its name—or a reasonable approximation if the directory can be accessed in a way that supports browsing or searching. So much for the ideal of a ubiquitous global directory. Today's reality offers several types of computer-based directory:

System Directories These are the main system directories found in a computer system or network. Thus NetWare users, for example, use the bindery or NetWare Directory Services, LAN Manager users use the Domain Server, and Vines users use StreetTalk. These directories contain a lot of information about users, such as: • A user's login ID • Their password • Files they're allowed to access, and a definition of the type of access allowed (eg, read only, execute only, etc ) • Print queues they're allowed to access • Valid login times • Amount of hard disk allocated Minicomputer and mainframe directories contain much the same sort of information.

Messaging Directories These are very closely associated with an e-mail packages. They contain user-friendly names of users or mailboxes, and their e-mail addresses. This lets users specify recipients, while they're somewhat shielded from the obscurities of e-mail addresses. Messaging directories often contain a variety of auxiliary information, such as the person's department, telephone number, employee ID, and so on.

Employee Directory Many organizations maintain an employee directory, which contains information like name, telephone number, title, department, employee ID, date hired, salary, and so on. A lot of the information needs to be restricted (eg, salary). The directory is often maintained by the organization's human resources department. Physically, it's often little more than an indexed flat file stored on a mainframe or PC.

Special-Purpose Directories Beyond these three directories, there are a mass of special-purpose ones. Eg, manufacturing probably keeps a directory of suppliers; accounting keeps a list of customers and their credit limits, and so on. Many databases provide a directory as part of their function.

4.2 The Messaging Directory As we noted, messaging directories are closely associated with e-mail directories. Their initial purpose was to facilitate envelope addressing. Users give simple selection criteria, eg, "people whose last name is Brown" or "In the purchasing department"; they then select from a list of matches. Many organizations discovered that the e-mail directory was a good place to put other information, too, since users are frequently in their e-mail application. For example, the corporate phone book has often been merged with the e-mail directory. To facilitate directory expansion, many e-mail vendors have built in additional fields, and also let administrators define additional fields. Thus, a messaging directory often contains information such as a person's department, telephone number, and job title. If the information can't be put into a custom field, it's usually typed into a catch-all free-form field such as the Comment field in cc:Mail's directory.

95 4 Directory Services

What Information is Stored? From the user's standpoint, the most important information you're likely to find is: • User names, such as John Smith, John R. Smith, and Smith, John. • Additional identifying information, such as the user's title, location, employee ID, and telephone number. • The address used by the e-mail system: a string of characters that unambiguously identify the mailbox concerned. An e-mail address may be user-friendly, as in Smith, John, or it may be more computer-friendly, as in JSMITH/SFSALES/WREGION. • X.400 and Internet addresses by which the person may be known. • Over the next few years, a person's public key (see discussion of public key cryptography) will frequently be included. Other information that may well be present is: • An ID uniquely identifying the directory entry. • Routing information. For example, cc:Mail's directory includes the user's post office. Or Banyan's StreetTalk directory contains, for each user, the name of the user's local MTA. Routing information isn't necessarily present in a directory, although it's likely to appear more and more frequently. • Addresses and user-friendly names used by other e-mail systems to refer to a mailbox. For example, if an organization contains PROFS as well as cc:Mail, the directory entry for cc:Mail user john Smith might contain the name and address used by PROFS users, as in: JRSMITH and SFVM1CCMORSMITH.

The Important Issues If you're implementing an X.400 backbone, the main directory issues are: • Address translation. People usually want to deal with addresses in the format of their "home" e-mail system. Assuming a variety of different types of email system are connected to the backbone, this means that sender and recipient addresses may need to be translated when a message goes between two different types of e-mail system. • Directory synchronization. Your e-mail system probably contains many different directories. Within a given e-mail system, there may be just one directory (as is typical with mainframe e-mail systems), or there may be many (as is typical with PC e-mail systems). Since every user wants to be able to browse directory entries for most people throughout the organization, the normal approach used today is to copy entry information between the

directories concerned. This process is known as directory synchronization. • X.500. An alternate approach to directory synchronization is to let the directory itself worry about how to integrate separate directories, using X.500 technology. These are large issues, and we address them in the following chapters. Less significant issues, which we address in the remainder of this chapter, are: • Address lookup. Users need to be able to browse through lists of other users' names and associated information like department, nickname, and so on. This lets them determine someone's e-mail address. • User administration. New employees join the organization, people leave, and people change departments or locations. This means there's a somewhat clerical job of keeping the directory up-to-date. • External access. Users may need to browse directories of external organizations; and outsiders may need controlled access to the organization's directories. • MTA routing. Currently, routing information is often manually configured into MTAs. However, it seems likely that it will increasingly be placed in a directory, for on-demand lookup by MTAs.

4.3 Address Lookup

There are two ways users can look up directory information: • Using their application software • Using general-purpose directory access utilities

Lookup Tightly Integrated With Application Of the two options, this is usually far more convenient for users. Here, a user can browse and select directory entries within their application, and the application accesses the directory via an API. The best-known example is e-mail, although forms routing and group scheduling packages also make good illustrations. The application will expect name and address information to be in a particular format, and entries reflecting users or mailboxes in another mail system are likely to have been converted into this format (see chapter 6 on address translation).

97 4 Directory Services

General-Purpose Directory Query The other approach is where you use a general-purpose utility to access the directory. If you're lucky, this will involve use of an interactive, GUI-based interface. NEXOR's PC-DUA is an example (figure 4.1). You specify search criteria and can drill down into the directory until you find the entry you want. Then you cut-and-paste the address as needed. The cutting-and-pasting takes time; hence, it's better to use lookups that are tightly integrated with the application. If you're not so lucky, the lookup process is likely to involve something typically called query-by-mail. Here, you send a mail message to a special directory mailbox, and in the body of the message you type in simple keyword-based query commands. A directory lookup program receives the message, accesses the directory, fishes out the information, and returns it to you by mail (figure 4.2). This approach is quite common in backbones, notably those based on SoftSwitch's EMX. It's an inelegant

FIGURE 4.1 NEXOR'S PC-DUA isoom______

Browser

Position Type United Kingdom Organisations [

[Filter Organisation *Ltd

, , 014 4 •• letyMing-1

Boldon James Limited GID Ltd NEXOR Ltd OsiSoft Ltd Salford University Business Services Ltd

X.500 directories often have general-purpose browsers like this.

FIGURE 4.2 LOTUS/SOFTSWITCH'S QUERY-BY-MAIL

Soft•Switch Names Directory Query Report

Query Request ID: SFVM1GPW.JRSMITH SFVM1GPWARSMITH_0073 10/15/94 13:42

Proper name: Last name : Smith First name : John Middle initial : R Generation Initials : JRS

Title : Project Manager

Query-by-Mail lets a user query EMX' central directory. The user sends an interpersonal message to a directory mailbox, and the message contains a simple keyword phrase such as "FIND LASTNAME=Smith". A reply is generated similar to the one shown.

way of accessing a central directory. But the big advantage is that it's likely to work: all you need is e-mail connectivity to get to the central directory. This is unlike, say, the X.500 directory lookup we just saw, where much of the network will have to be running TCP/IP or ISO transport protocols.

4.4 User Administration New employees join the organization, people leave, and people change departments or locations. This means there's a somewhat clerical job of keeping the directory up-to-date. We now look at the main issues to consider, from the backbone's point of view.

Centralized vs. Distributed Administration The most import issue is to what extent you will choose to distribute administration. Many structures are possible, and large organizations often end up with a hybrid mix of centralized and distributed administration. We now elaborate. In some backbone environments, all directory administration is done centrally—by the human resources department, or by a central messaging support group, for example. Other organizations prefer to let directory administration take place within

99 4 Directory Services

each e-mail system connected to the backbone. Figure 4.3 illustrates one possibility. In country A, three independent e-mail systems (two cc:Mail, one PROFS/OV) connect to the backbone. One cc:Mail environment chooses to centralize its administration at a particular cc:Mail post office, while the other has administration done at every post office. PROFS/OV by its nature has centralized administration. Thus overall, country A has a mixture of centralized and distributed administration. From the standpoint of the backbone, it has distributed administration. Country B also has three different e-mail systems connecting to the backbone. However, all administration is done at a single location. The main master directory is directly updated, and change information is automatically copied to the directories in the systems attached to the backbone. Thus country B has centralized administration.

FIGURE 4.3CENTRALIZED VS DISTRIBUTED ADMINISTRATION 1.• ______

X.400 Backbone

Country A

cc:Mail cc:Mail (Centralized (Distributed Admin.) Admin.)

Master Directory

X.400 Backbone

Country B

PROFS/OV (Centralized Admin.)

On a global level, most organizations administer their messaging directories using a mixture of centralized and distributed approaches.

Finally, we should note that on a global basis, the organization has a distributed directory administration structure. A mechanism must be put in place to copy directory updates between the various countries.

Role of Human Resource Database As a general rule, centralized administration has the benefit of minimizing the coordination required among administrators. However, in a large organizations, the choice will be influenced by the structure of other administrative functions that play a role in directory administration. For example, if your company has a centralized human resources database maintained by a single HR organization, centralized administration and dissemination probably will make good sense. Military organizations are also likely to find a centralized directory administration architecture attractive.

Distributed Personnel & Network Management On the other hand, enterprises with personnel and network management responsibilities assigned to designated organizations will usually find distributed administration to be the natural approach. A distributed administration architecture may be also be attractive in large enterprises with geographically dispersed sites, each of which has its own human resources group, network operations, and other functions that bear on the directory service. Retail outlets hiring a lot of temporary employees are an example.

Autonomous Divisions with own HR For enterprises consisting of autonomous or loosely linked organizational units, each with its own HR responsibilities, hybrid directory administration architectures will probably be appropriate. A typical architecture would be centralized administration and dissemination within each organizational unit, with directory synchronization keeping the various units up-to-date with each other.

International Organizations Similarly, large countries usually operate autonomously. So it's usually best to let them do their administration independently, irrespective of the approach used within the countries themselves.

101 4 Directory Services

Product Support for Centralized Administration Some products and environments make it easy to have the mix of centralized and distributed administration you'd ideally like. You're most likely to have a lot of flexibility if you're using X.500, or if you're using integration technology from a single vendor like SoftSwitch. This way, the different directories will have a means of exchanging information. On the other hand, if you're not using X.500, and are attaching to your backbone using gateways from a series of different vendors, your options will be a lot more limited. You'll probably have to maintain the directories of the different e-mail systems independently, and then write code to copy directory information as necessary. Alternatively, you could write your own programs that let you maintain a central directory, and that copy changes to the e-mail systems attaching to the backbone. Writing this sort of code often gets tricky, and should be avoided if possible.

Administration-by-Mail Most administration will be done using interactive programs that directly update the directory concerned. However, it's sometimes possible to send a mail message containing keyword-based instructions to a directory administration mailbox. A special program reads the message and updates the directory accordingly. It all works in much the same way as Query-by-Mail discussed earlier. Clearly, this sort of maintenance is not for heads-down clerical operators. But it can be useful on an ad hoc basis, particularly for remote updates to a centralized directory.

Initial Directory Load Populating a directory with data like telephone, job title, and office numbers for tens of thousands of entries can be a significant undertaking. Support tools with well-designed user interfaces, especially ones which read in a database extract file, help get all that into the directory.

Other Database Connections It's often desirable to be able to interface with other databases. Eg, much of the user information may reside in one or more existing databases. With a little coding, it may be possible to populate the directory database from them. This can be a real time-saver.

4.5 External Access Users need to browse the directories of external organizations. From the standpoint of this report, the main purpose of these directories is to determine e-mail addresses—especially Internet and X.400 addresses—of a correspondent. Con- versely, outsiders need access to an organization's directories, to determine addresses of correspondents within the organization. Addresses aren't the only thing that require inter-organization directory inquiries. Looking ahead, other types of query will retrieve public keys and revocation lists (for authentication and encryption purposes), fax numbers, phone numbers, postal addresses, photographs, and so on. For the moment, very few organizations allow outsiders to have any electronic access whatsoever to their internal messaging directories. Just making the connection is difficult, because: • Often, the technologies used aren't standardized; a third party has to use the same products to access directory information. • Sometimes, an organization's central messaging directory has been created by custom programming. A program sucks in entries from the different e- mail systems in use, and consolidates everything in a central file. The same problem applies in this case: clearly an external organization will need to know the details of how that file works, and how to connect to it. Apart from these technical problems, people are worried about security issues. For example: • Competitors may "trawl" their directory to see what groups of people are growing rapidly, and hence make inferences about where business is going well, or about the nature of the organization's development efforts. • Life will be made much easier for recruiters trying to hire away their best staff. As a result, where external access to internal directories is allowed, it's usually done by query-by-mail. This is easily implemented, and has natural access controls.

Role of X.500 X.500 is specifically designed to provide a standard way that directory information can be shared between different computer systems. It defines a standard way of sending inquiry and update commands to a directory, and a standard way of replying to such commands. X.500 will clearly be the way that electronic directory access is provided between

103 4 Directory Services

independent organizations. Nevertheless, many organizations are holding off from deploying this, in part because the technology is unfamiliar and they don't want to be on the bleeding edge. With regard to security issues, access controls were introduced in the 1993 version of the standard. Most commercial implementations still reflect the 1988 X.500 specification.

Proprietary Access Control for X.500 Proprietary extensions exist today that do provide access controls. One example is that of the DSA from IS ODE Consortium, which is resold by such vendors as Enterprise Solutions and NEXOR (figure 4.4).

Access by Autonomous Divisions A less difficult case is where autonomous or semi-independent divisions of an organization want to access each others' directories. We've already noted that the common way of providing directory services is by synchronizing the directories of the different e-mail systems connected to the backbone. The general way of doing this is by consolidating entries in a central master file. We explain this in more detail in chapter 5, which covers directory synchronization. There are many cases where it's practical to make directory information available across independent organizations of this type. If they all use the same directory synchronization technology, there may well be an automatic way in which the

FIGURE 4.4 ISODE CONSORTIUM'S X.500 ACCESS CONTROLS

cce.sqTyp, .

None No accesses to the object allowed Detect A DUA can detect that the protected object exists Compare object A filter (eg test equals some value) may be applied to the object Read Contents may be read Add Contents may be added to, but not removed Write Contents may be modified in any way Remove Object may be removed or modified in any way

The types of access controls to X.500 entries that will soon be available are illustrated by these proprietary extensions in ISODE Consortium's DSA.

various master directories can swap information, either directly to one another, or by consolidating to a "master master directory." This is much like the scenario we discussed in figure 4.3 above. SoftSwitch EMX's directory synchronization can do this kind of multi-level consolidation, for example. If no packaged software tools are available, the swapping of information can still take place. It requires writing special consolidating code, however, and doing this is something of a pain.

4.6 MTA Routing As we've noted, MTAs are responsible for routing messages through an X.400 network. Very often, X.400 MTAs require that routing information be entered into a table "owned" by each MTA. As the MTA network grows, maintaining these tables becomes a major burden. One solution is to adopt a hub-and-spoke MTA architecture. Unfortunately, this results in an unreliable system. For example, most messages might arrive within half an hour, but perhaps one percent might take as long as five days to arrive; and .001 percent might disappear entirely. Because messaging systems are increasingly used to transfer time-sensitive information (eg, sending out orders to suppliers for just-in-time manufacturing), this uncertainty simply won't be acceptable. Where possible, MTAs should be allowed to connect directly to a recipient's MTA and transfer a message directly, without forcing the message to plod through intermediate MTAs. It turns out that for this to occur, routing information should be located in a directory, not in a special-purpose table. This is rare right now, but over the next five years it will become common.

We now elaborate on these rather concise assertions, and explain why

they're so. Routing Table Maintenance is a Major Scalabliity Obstacle Consider the simple network shown in figure 4.5. Here, three offices are connected. Each office has a single MTA serving users, and each MTA can connect directly to the other two MTAs. All things being equal, it's better to have direct communications between sender and recipient MTAs. It's certainly possible to do otherwise, however. For example, you could connect the New York MTA to the London one, and the London one to that in Rome. But then messages going between New York and Rome now have to go through two hops. This slows them down; it may slow them down a lot if the

105 4 Directory Services

FIGURE 4.5 SIMPLE MTA LAYOUT

G-john; S-smith; P-xyz; C-us G-sheila; S-skippers; P-xyz fruit; A-bt; C-gb G-sue; S-jones; P.xyz; C=us G-frank; S-trotman; P-xyz fruit; A-bt; C-gb

Giovanni; S-mocka; P=xyz fruiX A=omega 400; C.it G.flora; S-panelli; P-xyz fruit A-omaga 400; C-it

Three offices, each with two users, are directly connected. The MTAs link using TCP/IP, OSI, or dialup transports.

London MTA is very busy with other traffic. So assume we have the setup of 4.5. The MTAs consult special tables in order to route messages. Figure 4.6 shows what the New York MTA's routing table might look like. * represents a wildcard—ie, a match with any value. Each user has an entry, indicating to which adjacent MTA a message for them should be routed. A separate table specifies how to set up a link with each MTA, using a TCP/IP, OSI, or dialup address. If a user's local, no relaying is required, and the message is put in the recipient's mailbox.

FIGURE 4.6 NEW YORK MTA'S ROUTING TABLE immumm ______

OiR.Address tin 11

G=john; S=smith; P=xyz fruit; A=*; C=* Local: F:\mail\jsmith\ G=sue; S=jones; P=xyz fruit; A=*; C.* Local: G=sheila; S=skipper; P=xyz fruit; A=*; C=* F:\mail\sjones\ G=frank; S=trotman; P=xyz fruit; A=*; C=* London MTA G=giovanni; S=modica; P=xyz fruit; A=*; C=* London MTA Rome G=flora; S=panelli; P=xyz fruit; A=*; C=* MTA Rome MTA

Here we see what the routing table for the MTA in New York might look like. Maintaining routing tables like this is very laborious: whenever a user is added or deleted, or moves locations, all tables must be updated.

Bad Solution: Put Routing Information in Addresses One possible solution is to put routing information in the user's address, using 0 and OU attributes corresponding to MTAs, as in: G=flora; S=panelli; O=rome; P=xyz fruit; A=omega400; C=it Here, 0 and OU attributes are used. Now a single entry can give routing directions for a large number of users (figure 4.7). Life's now much easier for routing support staff: • Explicit user information need only be given for local users—their messages are simply deposited in their mailbox. • Adding or deleting a user only requires updating the table maintained by the local MTA. If a user moves from one department to another, so that their local MTA is now changed, the tables of only two MTAs need be changed. Thus, when you see weird and wonderful addresses, as in G=john; S=smith; OU2=ny acctg; OU1=new york; O=acme machinery; P=ami; A=attmail; C=us, there's a fair chance that the 0 and OU's correspond directly to MTAs, and that all this junk is being included to make routing table maintenance easier. Unfortunately, as we noted earlier, compromises of this sort are particularly dis- mal. Users have to put up with unnecessary complexity in their address. Typing in the address is a pain, and error-prone. It's impossible to guess someone's O/R address. Plus, when people move departments, their address changes. All correspondents now have to update their personal directories, or find that mail is being returned. It's possible to forward mail, but that's a pain for administrators to maintain. An-

FIGURE 4.7 0/R ADDRESSES CONTAINING ROUTING INFORMATION ins______

.:.:OiRActcitestu Dcostination MTA

G=john; S=smith; O=new york; P=xyz fruit; A=*; C=. Local: F:\mail\jsmith\ G=sue; S=jones; O=new york; P=xyz fruit; A=*; C=.* Local: FAmail\sjones\ G=*; S=*; 0.1ondon; P=xyz fruit; A=*; C=* London MTA G=*; S=*; O=rome; P=xyz fruit; A=*; C.* Rome MTA

Routing table maintenance is greatly simplified if O/R addresses contain routing information. But users suffer greatly from unnecessary complexity. They can also be affected when users move departments, or the network is reconfigured.

107 4 Directory Services

other problem with forwarding is that an address may now be counter-intuitive, as is the case of a sales rep who used to work in development and whose (forwarded) address is: G=john; S=smith; O=r&d; P=acme; A=attmail; C=us

Bad Solution: Routing Hubs Another bad-but-widespread idea is to use central routing hubs (figure 4.8 ). The concept is that most MTAs only have explicit routing information for their local users: namely, the location of their mailbox. Messages for all other users are sent to

FIGURE 4.8 TYPICAL ROUTING HUB HIERARCHY

30 mbs Toronto Dublin London 100 mbs

100 mbs 20 mbs Cam- Oslo bridge 60 mbs 100 dial-in mbs. Also customers & suppliers Stock 40 mbs Jeffer- 80 sonville holm mbs

Piscat- 800 mbs 800 Helsinki 60 away mb New mbs York Paris MCI 30 mbs Kansas Mail 200 Hamburg 100 mbs City mbs QUIK- 300 mbs COMM Also X.400 600 mbs of connectivity 400 mbs Topeka Brussels which 400 100 mbs are cc:Mail

30 mbs Atlanta

KEY: mbs = mailboxes 40 mbs Mexico City

A typical hub hierarchy. Two hubs communicate as peers. One spoke MTA also acts as a hub, to serve Dublin operations.

a central hub. That is, Wan MTA tries to route a message but can't find an entry for the recipient in its table, the default is to relay the message over to an adjacent hub. The central hub contains explicit information for all users. There's an entry for each user, indicating to what MTA messages for them should be sent. This approach goes a long way towards solving the MTA routing table administration problem. In figure 4.8, for example, only two tables must be updated when you add a user: • An entry must be added to the routing table for the user's local MTA, indicating that the user is local and where arriving messages should be placed. • An entry must be added to the central hub's routing table, indicating that messages for that user should be directed to their local MTA. As we have just noted, the second entry may not even be needed, if routing information is included in the user's address. For example, and again referring to figure 4.8, if the address contains information like O=san francisco, the hub's routing table need only indicate that messages matching G=*; S=*; O=san francisco; P=xyz fruit; A=*; C=* should be routed to San Francisco MTA. In this case, adding someone to San Francisco won't need any updating of the US Hub's routing table. In practice, larger networks end up with a hierarchy of hubs. Often, North America will be broken down into three to ten hubs. These may routed directly to each other, in which case the hubs are said to communicate on a peer-to-peer basis. Alternatively, they may connect by means of a further level of hub, where a sort of meta-hub has hubs hanging off its spokes. You often end up with a hybrid mix of hubs and meta-hubs, in which some hubs communicate as peers, others via higher order hubs. Figure 4.8 illustrates the sort of thing that evolves in practice. This particular example illustrates a fairly simple hub-and-spoke network, connecting around 3,000 mailboxes. In general, the more routing hubs you have, the more tables to you have to maintain. However, the effort is usually manageable. For every user status change, only a small number of tables need be updated. Furthermore, the MTAs that must be updated are all clearly defined elements of the network and it's not usually too hard to write a program that updates every hub involved.

109 4 Directory Services

Problems of Hub-and-Spoke Architectures Unfortunately, hubs become bottlenecks. If a hub stops or fails for any reason, all traffic going through it stops. If the hub is busy transferring a large file, other messages get delayed. To compound the problem, messages may have to plod through a series of intermediate MTAs, each of which slows delivery in an unpredictable way. Design of the MTA network is also very difficult. It requires careful attention to the design of the underlying physical network (see January 1994 Analyzer). And if the underlying network changes, the MTA-MTA transfer network may suddenly need to be re-configured if it's to remain efficient. It's also very hard to define flexible alternate routings, to allow for the failure of intermediate MTAs or data links.

Good Solution: Directory-Based Routing It's far better to let a directory store MTA routing information. To be more precise, when one defines a user in the directory, one also defines that user's local MTA in a directory, together with connectivity information like its TCP/IP, OSI, or dialup address. This information is then automatically made available to a wide number of MTAs throughout the messaging system: • If it's an X.500 directory, the information can be made available automatically. • Otherwise, some sort of directory synchronization or propagation process will do the job. Once routing information is stored in a directory, the number of hops required for a given transmission is drastically reduced. An MTA needing to transmit a message can simply look up a recipient in the directory, determine that recipient's local MTA, and then transfer it directly. Sometimes a direct connection isn't possible, but in any case this procedure allows the MTA-MTA hop count to be minimized.

Advantages of Direct Routing • Delivery is much faster and much more predictable. • Far more efficient use is made of the underlying physical network. Lower level software works out how to navigate an optimal path. • Network congestion and breaks are dealt with in a far superior way, since OSI and TCP/IP have the ability to automatically and dynamically work out alternate paths.

• To design an efficient messaging system, the support staff doesn't have to learn about how the physical network works. • The physical network can be altered without adversely affecting the messaging system. • There's less chance that a message will be lost in transmission. • If there's only one hop, it's easy for the user (and support staff) to monitor the progress of messages in transit. If a message is delayed, users themselves can take corrective action. • Many users feel direct transmission is more secure. In short, forcing messages to go through hub hierarchies is, all things being equal, a no-no.

Occasions When Relaying Makes Sense However, a certain level of multi-hop transmission can make sense: • To compensate for difficulties in administering routing information. As we've seen, this is the primary motivation for implementing hub-and- spoke hierarchies. You're most likely to have to adopt this course if your MTAs don't have directory-based routing. • To handle different protocols. The store and forward approach allows for conversion at other locations. For example, a site may need to use a particular transport technology (OSI, TCP/IP, or dialup); or a particular X.400 version; or interact with non-X.400 e-mail systems (and their transports). • To create a firewall. A single MTA, through which external messages enter or leave an organization, can be used to handle chargeback and access control. • To reduce line charges. If an expensive data link lies along the path, it can be cheaper to channel everything through a small number of MTAs, so that the MTAs can minimize the costs. For example, low priority messages to a particular country may be scheduled for transmission at particular times. • To optimize fanout. If a message is being sent to two remote MTAs that are close together, it is usually optimal to send the message to one of the MTAs (for both recipients), and let it pass a copy to the other MTA. • To access an intermediate MTA for special processing, notably distribution list expansion, message format conversion, and file format conversion. • To simplify addressing. Give your users an address that normally only contains S, G, and P attributes (no O's and OU's). Messaging arriving from the outside will have to go through a main MTA, which will then route them to specific locations.

111 4 Directory Services

We're grateful to ISODE Consortium's Steve Kille for these

observations. X.500 is Focus of Action

In the PC e-mail world, directory-based routing is a rarity. cc:Mail comes fairly close, but still each MTA must maintain its own table describing how to connect to adjacent MTAs. Banyan Intelligent Messaging is the only product in which full- fledged directory-based routing is implemented, and in which, as a result direct, connections between end MTAs are practical for large networks. In the X.400 world, most MTAs do their routing by means of routing tables owned by each MTA. The MTAs found in Lotus/SoftSwitch's LMS and Tandem's OSI/ MHS are typical examples. However, ISODE Consortium-based products are leading the pack as far as directory-based routing is concerned in the X.400 world. This isn't surprising, since ISODE's principal software architect Steve Kille has done much of the original RFC research and development work. The first implementation of this appears to be found in Control Data Systems' Mail*Hub. Here, Control Data's own MTA uses the ISODE X.500 directory. Release 2 of the ISODE Consortium code, released in mid-1994 to its licensees, contains an X.400 MTA which uses X.500-based routing. Consortium members such as Enterprise Solutions and NEXOR can be expected to offer directory-based routing before long. NEXOR's offering is likely to be particularly strong, since the company did much of the development involved. ISODE Consortium's approach is a proprietary one, and is cautiously described as experimental in nature. However, we strongly recommend that readers investigate further, because: • Directory-based routing is critical for scalability. • The technique can be used within an organization, although its proprietary nature precludes integration with external groups. • There's a good chance that something very similar will end up being incorporated into the X.400/X.500 standards.

ISODE Consortium Approach The basic algorithm is quite simple: • First, a PRMD defines a routing tree in its X.500 directory. This tree contains routing and address mapping information for all mailboxes in the organization.

FIGURE 4.9 X.500 ROUTING ENTRY FOR AN MTA

cn= acme-mta description= Acme's main MTA presentationAddress= u597”/TELEX+00737346+RFC1006+03+128.243.9.1 ITELEX+00728722+X.25(80)+02)00002100102999 ITELEX+00728722+X.25(80)+06+20433450210399 IDCC+826+d110000210021900014000 mTAName= US.CO.ACME transportCommunity= tc-intemet & tc-int-x25 & tc-cons

A typical X.500 entry containing MTA routing information. The presentation address gives various electronic addresses for the MTA, separated by a vertical bar. The transport community specifies what data communications technologies the given MTA supports, which is useful to check if a direct MTA-MTA association is possible.

• When an MTA receives a message, it fishes out a recipient's 0/R name, eg: G=john; S=smith; P=acme; A=attmail; C=us • It then converts this into an X.500-distinguished name, using a fairly natural mapping strategy. Smith's 0/R name might end up as: C=us@aDMDName= @pRMDName=acme@cn=john. smith • The MTA then connects to the PRMD's routing tree, and uses the X.500-distinguished name to fish out the recipient's local MTA, and how to connect to it. Figure 4.9 shows an example of the sort of information stored for a given MTA. As usual, various if's and but's end up making the actual algorithm quite a bit more complex, notably to allow for multi-hop relays and alternate routings. For further reading, we recommend Control Data Systems' Mail*Hub Administrator's Guide, and ISODE Consortium's ISODE Volume 4, Administrator's Guide, Messaging Handling Services.

113

Chapter 5

5. Directory Synchronization

From the e-mail standpoint, the main reason to have a directory is to let users track down someone's e-mail address. Users want to be able to browse a list of names that possibly provides selection criteria, such as where the person is located, or their department. E-Mail systems like cc:Mail, ALL-IN-1, and PROFS/OV, maintain their own directory, and each such directory will normally only know about users of the same e-mail software package. To make sure users can browse through names of everyone in the enterprise, including users of other packages, special action must be taken. This usually entails copying directory information between the different directories. This process is known as directory synchronization. It's by far the most common method used today to ensure different messaging systems have access to a shared directory. An alternative technology is that of X.500, where the directory itself knows how to make entries available at many locations. We discuss X.500 in a separate chapter.

5.1 Propagation vs. Synchronization For traditional e-mail systems like PROFS/OV and ALL-IN-1, displaying a list of users is pretty simple. All e-mail and administrative information is typically kept on a single computer, so displaying a directory list is just a matter of querying a centralized database. For distributed e-mail systems, notably those running on PCs, Macintoshes, and

115 5 Directory Synchronization

UNIX workstations, things aren't quite so simple. Special efforts are necessary to enable all users of a large cc:Mail or MS Mail system to browse a system- wide directory: information must be copied between many separate directories. This process—copying directory information between the different directories of the same e-mail system—is known as directory propagation. However, many large organizations have several different types of e-mail system. A typical reader of this report might have: • 10,000 PROFS/OV mailboxes • 4,000 ALL-IN-1 mailboxes • 4,000 cc:Mail mailboxes • 2,000 MS Mail mailboxes • 1,000 SMTP mailboxes (based on UNIX workstations) • 1,000 QuickMail mailboxes. Users of each of these systems can browse through names of other users of the same e-mail system. If they're a PROFS/OV user, this is trivial. If they're a cc:Mail or MS Mail user, they can see a consolidated address book for their e- mail system thanks to directory propagation. However, without special efforts, they won't be able to browse the names of users of other e-mail packages, because the storage and query mechanisms are all different. The process of moving around directory information between different e-mail packages so that everyone can see it is known as directory synchronization, or dir sync for short.

Name and Address Translation is Also Required To review the discussion so far, there are two main ways of copying information between directories: • Directory synchronization. This involves copying directory information between different e-mail systems. • Directory propagation. Here directory information is copied between the different directories in the same distributed e-mail system. One thing that makes directory synchronization intrinsically more difficult than directory propagation is that users want to see other users' e-mail names and addresses in the format to which they're accustomed. For example, consider a company which has a messaging system made up of cc:Mail, SMTP/Internet, Novell's GroupWise, and X.400 components. User John Smith's "home" system is Novell's GroupWise. There he's known as John Smith, and his e-

mail address is JSMITH/SFSALES/WREGION . However, cc:Mail users see him as Smith, John R. SMTP users see his name and address as JR Smith and [email protected], respectively. Thus, when performing directory synchronization, it's also important to translate names and addresses into suitable formats. This process is known, surprise surprise, as name or address translation. We discuss the topic in depth in chapter 6.

5.2 How Directory Synchronization Works

Two fundamental concepts of directory synchronization are: • The master directory. This is a single location which contains an entry for all mail users, irrespective of what e-mail system they normally use. • The synchronization process. This consists of a number of programs that consolidate and copy over information between directories.

The Master Directory

For every user, the master directory (figure 5.1) describes the different addresses which refer to the user, depending on what e-mail system is being used. It also typically defines the user-friendly name used by each e-mail system, the user's "home" system, and a canonical messaging address. There's also likely to be additional user identification information, such as the user's title, department, telephone number, and so on. In many cases, a master file is a corporate resource, and is not used merely as a working file for technical support. It's commonly the database of record for the human resources department, for example, and contains much non-e-mail information. Sometimes the master directory has a lesser but still important role, acting as the corporate telephone book. The master file is often located on a mainframe, but you can have it on any convenient platform. We've seen a number of cases where it's PC-based, controlled by a 4GL database such as Paradox.

The Synchronization Process The directory synchronization process is normally a series of different programs that have to be run in a particular order. In some cases, they might all be run from a single .BAT file. In other cases, careful scheduling of programs running on different systems would be required.

117 5 Directory Synchronization

FIGURE 5.1 TYPICAL MASTER DIRECTORY ENTRY Field

Home System Symmetry cc:Mail Friendly Name Smith, John R cc:Mail Address Smith, John R MS Mail Friendly Name John Smith MS Mail Address JRSMITH/SYMMGW/MSMNET PROFS/OV Friendly Name JRSMITH PROFS/OV Address SFVM1SYM(JRSMITH) QuickMail Friendly Name John Smith QuickMail Address John S SMTP/Internet Friendly Name JR Smith SMTP/Internet Address [email protected] Symmetry Friendly Name John Smith Symmetry Address JSMITH/SFSALES/WREGION X.400 Friendly Name John Smith X.400 Address G=john; S=smith; P=acme; A=mci; C=us Dept Widget Marketing Title Research Assistant Tel # 415 986 1414 Fax # 415 986 5994 Legal Name John R. Smith Soc Sec # 554-33-1234 Badge ACC-4321 Canonical Messaging Address G=john; S=smith; P=acme; A=mci; C=us Local MTA WM_MTA03

A master directory is a database in a single location that describes the different names and addresses associated with each user. Additional identifying information is likely to be included.

The components of a typical directory synchronization system for multiple directories are shown in figure 5.2. Vendors use a variety of terms for the different components—we've either adopted those that seem most descriptive or created our own. A directory interface unit or DIU is a software module that provides the direct interface to a directory that participates in the synchronization process. Its main function is to transfer directory information between a participating directory and the directory server. The directory server maintains a master directory for the integrated directory service. During a directory synchronization cycle, the directory server executes the following steps: • Directory information is received from each directory interface unit.

FIGURE 5.2 DIRECTORY SYNCHRONIZATION COMPONENTS

111111110 Master Directory Server Directory

Directory Directory Interface Interface Unit Unit

Directory Directory • • • 1 N

Directory information for each directory is sent by the corresponding directory interface unit to the directory server, which uses it to update the master directory. Either a summary of the combined changes or the whole updated master directory is then sent to each directory in the appropriate format.

• The new directory information is assessed to identify necessary changes to the master directory, and the changes are made. • Either the complete updated master directory, or a consolidated list of all changes to the participating directories that have been made since the previous synchronization cycle, are sent to each directory interface unit. The standard way of determining what recent changes have been made to a directory is by comparing the latest version with a copy of the directory prior to update. Such before-update copies are known as shadow files. A directory interface unit typically shares a computer with other software modules that are components of the messaging or the directory system. In some instances, however, the directory interface unit may require a dedicated computer.

119 5 Directory Synchronization

international and Cross-Division Synchronization Typically, an international organization, or one consisting of somewhat autonomous divisions, will have a multi-level synchronization process. Within a country, global region (eg, Europe), or division, the synchronization process will consolidate the directories in a master directory. The separate master directories must now be consolidated across divisions. This is done in two ways (figure 5.3): • By copying over changes directly to each other. This is known as peer-to-peer synchronization. • Into what you might call a "master master" directory. This is known as master-slave synchronization. A hybrid of the two approaches is also possible, and is especially likely with very large organizations. For example (figure 5.4), you might have three divisions, which exchange master information on a peer-to-peer basis. However, Division 3 has about 40,000 staff, spread across the US and several European countries. Each of Division 3's countries does its own directory synchronization, and has its own master directory. All the country master directories within Division 3 consolidate into Division 3's overall master directory, using master-slave synchronization.

FIGURE 5.3 INTERNATIONAL AND INTER-DIVISION SYNCHRONIZATION

Master "Master Directory Master" Directory N Z

Master • Master • Master • • • Master Directory Directory Directory Directory

Peer-to-peer propagation Master-slave propagation

Sometimes large organizational groups must synchronize their master directories. Master directories exchange information directly, or consolidate to a higher level master directory.

FIGURE 5.4 HYBRID MULTI-LEVEL SYNCHRONIZATION

Division 2 Master

Division Division 1 • 3 Master Master

France Germany Italy UK US Master Master Master Master Maste

Large organizations may need a mix of peer-to-peer and master-slave synchronization strategies.

Directory Propagation We said earlier that the synchronization of different directories of a particular e- mail system, normally a distributed system such as cc:Mail, MS Mail, or Novell's GroupWise, is called directory propagation. For example, cc:Mail's ADE does the job for cc:Mail environments, while Microsoft's Dir-Sync does it for MS Mail. Directory propagation has a lot in common with directory synchronization. The copying takes place in master-slave, peer-to-peer, and hybrid structures. Normally it's done using specially formatted messages. However, this report is only concerned with directory synchronization between different types of e-mail system. So we ignore directory propagation. For a detailed discussion and assessment of major PC e-mail directory propagation tools, check the March 94 Ferris E-Mail Analyzer.

121 5 Directory Synchronization

5.3 Product Solutions A growing number of vendors offer directory synchronization solutions. For the most part, these are messaging integration software vendors, whose purpose is to provide a suite of tools that help customers tie together different e-mail systems. Vendor products in this category include Alisamail, Boston Software Works' InterOFFICE, Digital's Directory Synchronization Utility, Lotus/SoftSwitch's LMS, and Worldtalk. There's also a stand-alone directory synchronization product, Hitachi's SynchWare. Since directory integration is a major headache for messaging support staff, the availability of good directory synchronization tools is an important criterion when choosing between different e-mail integration products.

Avoid Building Your Own Directory Synchronization Such packaged solutions have only become available recently, however. Conse- quently, many organizations have had to build their own cross-system directory synchronization software. This has required using the import and export utilities that are provided with the e-mail systems being connected. The coding job is one that can be taken on by most large organizations. But avoid the task if you can: • The process must be split up into a series of sub-processes, and these are run on different machines. The sub-processes must be carefully coordinated, and this is a delicate and error-prone matter. The reasons are mainly that subprocesses can take a long time to run, and can easily take longer than had originally been anticipated. • Providing for recovery when a sub-process fails for any reason is tricky. • The code must be maintained, as programming interface synchronization requirements change. • Name-and-address-mapping software can involve some tricky design and coding. • As a matter of economics, e-mail professionals are much more productive when they do things that require an understanding of their organization's business. They have better things to do than writing cross-industry systems software: this should be provided by third parties. In short: it's a bore.

Lotus/SoftSwitch's Directory Synchronization This is the main directory synchronization technology used by large organizations today, so now we take a look at it. We illustrate using Lotus/SoftSwitch's LMS integration software, although the synchronization works similarly with the company's older Central product.

How it Works There are two main components (figure 5.5): The directory synchronization server. This process controls a master directory. Lotus calls this a Names Directory, and it is stored in an Oracle database.

FIGURE 5.5 LOTUS/SOFTSWITCH LMS ARCHITECTURE

1 0 40 Optional link to X400 11111111 1111111111 another LMS Box ADMD Distribution Names Store Directory

X.25 Management Workstation PROFSIOV

Dir Sync UNIX Box Client X.400 MIA X 450 Gateway ,- Dir Sync SM P,'M It/ E Mainframe LU 6.2 Server Gateway Internet SN AD S Convertors Gateway TCP/IP SNAPI PROFS CV Server Gateway TCP/IP SM SNAPI TP1 Main LMS Box Dir Sync Client VM S mall Gateway SNA, TCP/IP or OSI link VAX SNAPI SNAPI SNAP] cc Mail cs MS Mail Gatewa Gatewa PC DOS PC DOS PC Gateway DOS PC

cc. Ma cc Mail !I System System MS mail A B System

Dir Dir Dir Sync

DOS PC DOS PC DOS PC

A central LMS box runs various processes, including a directory synchronization server. Remote machines run gateways and directory interface software.

123 5 Directory Synchronization

• Directory interface units, referred to as Dir Sync clients. These programs connect to other directories and allow them to submit synchronization information to the server, or to receive synchronization information from it. Information exchange between the server and interface units is done with specially formatted messages, addressed to the server or one of the interface units (figure 5.6). These messages have specially formatted fields to indicate that they contain directory synchronization information, along with version, time, addresses, and indicators about whether a particular entry is being added, modified, or deleted. All the information is normally included in the main message, so that the protocol can be processed through e-mail systems that don't support binary attachments. This standard message format, and the rules associated with its use, is known as the SoftSwitch Directory Synchronization Protocol or DS/P. It's published by Lotus/ SoftSwitch, which makes it relatively simple for customers or third parties to write code participating in directory synchronization.

Strengths • Numerous mainframe and minicomputer e-mail systems are supported. Directory synchronization is available for cc:Mail, DEC's Message Router, IBM's Enterprise Address Book for MVS, Microsoft Mail for PC Networks, Notes, PROFS and OV/VM, SYSM, VinesMail, and Wang OFFICE. Directory synchronization for Callup, EMC2, Memo, and OV/400 is scheduled for 1Q95. • Third party gateway developers, or customers, can participate in directory synchronization using DS/P. • LMS has a lot of directory management tools.

FIGURE 5.6 LOTUS/SOFTSWITCH SYNCHRONIZATION MESSAGE FORMAT

Pommand.

Modify Entry Update/add an entry owned by the client Delete Entry Delete an entry owned by the client Request Updates Get all master directory updates since specified time Delete All Entries Delete all entries owned by client Header Denotes beginning of DS/P message Trailer Denotes end of DS/P message

Lotus/SoftSwitch's directory synchronization works by sending special messages, with formats as summarized in this table.

• LMS supports a large number of entry attributes that are consistent with the attribute set suggested in the X.500 standard. • Strong rules-based technology is available that converts e-mail addresses and friendly names between the formats used by the various connected systems. • Peer-to-peer and master-slave higher level synchronizations, and hybrids, are supported. • The process verifies that synchronization was successful, and provides for recovery if it wasn't. • There's a migration path to X.500. Lotus/SoftSwitch plans to provide an X.500 DSA, and an export-to-X.500 utility, in 1995.

Weaknesses • There's no directory synchronization for NetWare MHS, Novell GroupWise, QuickMail, and Microsoft Mail for Macintosh Networks. • Directory synchronization for Gallup, Enterprise Address Book, PROFS, OV/400, SYSM, and Wang OFFICE requires you to run Lotus/SoftSwitch Central (which runs on a mainframe). • A dedicated gateway PC is required for each LAN e-mail system; however, the directory synchronization software can run on this platform. • LMS directory synchronization is relatively new There are few customer references that are beyond the pilot stage. • Directory synchronization can take a long time. Eg, it takes one customer 2.5 hours to download 100 updates a day from an e-mail system into the names directory. • There's no X.500 integration today. • It's only attractive if you use Lotus/SoftSwitch LMS or Central as messaging integration software.

Retix' DX Retix also published a synchronization protocol, the Directory Exchange or DX protocol. This operates in much the same way as Lotus/SoftSwitch's DS/P. This isn't surprising, since SoftSwitch was a major development partner for the DX specification. The protocol has been published, and is seen as a fairly open standard, more open than Lotus/SoftSwitch's DS/P. Many e-mail vendors have adopted DX. For example, the following vendors have stated they use DX, or plan to do so:

125 5 Directory Synchronization

• Retix, for dir sync between cc:Mail and MS Mail. • Amadeus Systems, for dir sync between cc:Mail, MS Mail, NetWare MHSbased systems, 3+Mail, Notes, SMTP, ALL-IN-I, and VMSMaiI. • Alisa Systems, for dir sync between cc:Mail, MS Mail, MS Mail/Mac, NetWare MHS, Da Vinci eMAIL, QuickMail, VMSMai1, ALL-IN-I, X.400, and SMTP. • DEC, for MAILbus dir sync between various environments, including cc:Mail, MS Mail, PROFS/OV, ALL-IN-I, SMTP, and X.400. • Linkage, for dir sync between PROFS/OV, OV/400, IMI's OfficePath, cc:Mail, and MS Mail. • Phoenix, for dir sync between MS Mail and Notes. • ZOOMIT, for dir sync between X.400, cc:Mail, MS Mail, ALL-IN- 1, PROFS/OV, and VinesMail. So DX is the closest thing we've got to an open standard for directory synchronization. It's a great pity that Retix has now become largely inactive in the messaging field; as a result, DX's future seems uncertain at best.

5.4 Implementation Issues We end this chapter with some pointers on the do's and don'ts of directory synchronization

Use Third Party Packages if You Can Use third party packages if they're available. Use them even if they provide only a partial solution. For example, if you have cc:Mail, PROFS/OV, ALL- IN-I, and BeyondMail, you might already have a solution for the first three. In this case, you'd only have to write add-on software integrating the BeyondMail environment.

Filtering & Security You may want to restrict names being propagated out of a given e-mail system; and for some names that you do propagate, you'll want to restrict who can have access to them. Some of the concerns are: • Directory limits. Some directories have a maximum numbers of entries, or they don't work well if they go beyond a certain size. • Unrestricted mail to senior management. Should all staff be able to send

mail to the president? And if this is okay, should his or her mailbox (rather than that of an assistant) be in any directories external to the organization? • Controlling junk mail. Many people already get 100 messages/day. Junk mail could increase this by a factor of ten. Permission lists and filters will likely be the basis for solving these issues. However, the tools and practices required are at an early stage of development. For the moment, expect to implement custom controls.

Verification Tools It's one thing to synchronize different directories. In addition, you need to be able to check that synchronization is successful, and that directories contain the information you think they do. If things get out of kilter, you must then bring the directories concerned into their proper state. Don't assume that all the verification tools are available. At this stage of the technology, there's a good chance you'll have to build some of your own, even if you are using a directory propagation product.

Role of X.500 X.500 is quite different from the sort of cross-platform directory synchronization we've been discussing. It's not a copy-things-over-between-directories technology. X.500 enables different directories to dynamically query each other—they form a distributed database. You'll have to decide how to mix and match directory synchronization and X.500. We believe that within an organization, directory synchronization will continue to be widely used through the end of the century, and X.500 will commonly be used to locate people outside the organization. Nevertheless, a growing number of people will adopt X.500, especially where an organization consists of highly autonomous divisions.

Synchronization Frequency Most organizations find it's sufficient to have a weekly enterprise-wide synchronization process. Often, the elapsed processing time, allowing for fault processing, makes it difficult to have more frequent synchronizations.

Multi-Tier Synchronization Sometimes it makes sense to have several levels of directory consolidation. Divi- sions of large multinationals often operate autonomously, and each division may

127 5 Directory Synchronization

want to perform its own cross-system synchronization. Thus, each division maintains its own master directory. These different master directories can then be further synchronized. This can be done in two ways. • All things being equal, we recommend doing a final, top-level consolidation on a single, "master master" directory. Lotus/SoftSwitch's DS and Retix DX products allow for such multi-tier synchronization. • Sometimes the master directories can update each other directly, without need for a master master directory.

Centralized Administration Some organizations find it natural to centralize e-mail name administration. In this case, it may make sense to have user add/changes/deletions performed on a master directory (or master-master directory, if multi-tier synchronization is being done). Then allow the synchronization process to propagate the names out to user directories.

Don't Confuse With Message Flow A quick observation. In principal, your backbone can consist of a mesh of MTAs. However, many backbones will have one or more central routing hubs at certain locations. Many people think that master directory siting has something to do with the MTA- MTA layout. In particular, they assume that a master directory needs to be at the same location as a central hub MTA. That's quite wrong: directory synchronization and MTA-MTA message flow topologies are completely independent. The only connection is that directory sychronization files are usually sent via e-mail.

6. Address Translation

As we saw in figure 5.1 on page 118, different e-mail systems have different ways of expressing someone's address. The profusion of formats is confusing for users, so in this chapter we explain the problems, and discuss how to shield users from unnecessary complexity.

6.1 Survey of Address Formats We begin with a quick look at how different products handle addresses and user-friendly names. The main intent is to indicate the variety of formats you may have to deal with.

BeyondMail, ON Technology's eMAIL, Notework ON Technology's eMAIL and Notework use NetWare MHS to move messages and files around, as can BeyondMail. All but the most recent versions of MHS use a name@workgroup naming convention, where both parts are limited to 8 characters with no punctuation except - (hyphen), $, and #. The user interfaces of BeyondMail, eMAIL and Notework generally reflect this structure. You either refer to people by an up-to-8-characters name, or, if necessary, you can append their workgroup name. More natural names are also possible, although in limited contexts. For example, BeyondMail lets you define free-form aliases of up to 100 characters, including spaces.

129 6 Address Translation

cc:Mail Addresses can be up to 126 characters, including spaces, commas, colons, and so on. They have the format last name, first name. You can insert titles or letters, but must be sure the comma is in the right place. Examples are: Smith, John Smith Jr., John Smith J.R., John Smith, John R. O'Donnelly, John Thus in cc:Mail, there's no difference between a user-friendly name, and an address. Depending on where you are in the product, addresses are displayed in a last name, first name format, or in a permuted first name last name format.

CompuServe Addresses for this public information service normally uses numbers, such as: 75300,3422 75600,535 100024,2471 We couldn't determine a precise definition of valid user-friendly names, but they appear to have a FIRST NAME LAST NAME format, where the first name can contain initials. Examples are: JOHN SMITH JOHN A SMITH For people you send mail to frequently, you can define aliases. These can be up to 24 characters in length, and could accommodate any characters we tried, including spaces, colons, and hyphens.

MCI Mail This public service uses a 3-4 numeric format, as in 377-3271 345-6789 Every account has a user-friendly name, such as: John Smith John R. Smith These don't have to be unique. We have not seen any MCI names greater than 26 characters, and they can contain spaces and periods. You can also define distribution lists. These must be between 2 and 20 characters in length, and contain spaces, numbers, and letters. Most special characters are rejected.

Microsoft Mail for PC Networks User-friendly names can be up to 30 characters, including spaces, commas, colons, and so on. Typical names are: John Smith John R. Smith Smith, John R Smith, John R., Jr Addresses have a three-part structure, with up to 10 characters in each. They contain routing information, and have the form NAME/POST OFFICE/NETWORK, as in JRSMITH/GRPWGW/MSMNET

PROFS/OV There are three types of address you can use: • A name of someone who uses the same mainframe as you do. This has up to 8 characters, eg, JRSMITH. In PROFS/OV jargon, this is known as their userid. • A name of someone who uses a different computer. Then, you type the computer name followed by the userid in parentheses, such as NYCVMSYS(JRSMITH). Both parts are limited to 8 characters. This two- part 8 by 8 address format is also known as DGN.DEN format, which lovers of the boring will be excited to know stands for Distribution Group Name.Distribution Element Name and is pronounced "diggin dot den." • A nickname. If you don't want to use a userid or system_name(userid), you can use an alias which must also be limited to 8 characters. For example, you might use JONSMITH as nickname for NYCVMSYS(JRSMITH). Valid characters are A through Z (no lower case), 0 through 9, $, #, @, +, - (hyphen), : (colon), and _ (underscore). PROFS/OV also has distribution lists, and these have a similar not-greater- than8-characters syntax. You can also put more user-friendly names in a directory. PROFS/OV tries to use these aliases, although user are still usually forced to use the restrictive 8.8 convention.

QuickMail The leading Macintosh e-mail package has three parts to its addresses, as follows: first name last_namegMESSAGE STORE

131 6 Address Translation

The first name field is required. The last name field is optional. The length of both combined must not exceed 30 characters. Both fields can contain almost any ASCII character except I (vertical bar) and ! (exclamation mark). Users select from a concatenation of the two fields, as in: David Ferris Cemil Betanov The message store field has a more restrictive syntax and for example spaces are not allowed. Message stores are specified for users outside your local message store, as in: David Ferris @ CORP_HQ Cemil Betanov @ COMPLINKR&D

SMTP/Intemet The standard format is [email protected], as in: [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] There's a lot of flexibility in the organization side, but readers will mainly be concerned with a [email protected] format.

X.400 We discussed the structure of X.400 addresses in chapter 2. A typical example is: G=john; S=smith; P=acme; A=mci; C=us

6.2 Basic Translation Concepts

E-Mail addresses appear in many elements of a message, most notably in the originator and recipient elements. A big challenge, as far as an X.400 backbone is concerned, is that users prefer to see addresses and friendly names consistent with what they usually see. A PROFS user wants to see PROFS addresses, a Microsoft Mail user wants to see Microsoft Mail addresses, and so on. Now consider a more extended example. A company has a messaging system made up of cc:Mail, MS Mail, PROFS/OV, QuickMail, SMTP/Internet, Novell's GroupWise, and X.400 components. Figure 6.1 shows the different ways in which

FIGURE 6.1 NAME AND ADDRESS FORMATS VARY AMONG E-MAIL SYSTEMS

yFstert Ow,

cc:Mail Smith, John R Smith, John R MS Mail John Smith JRSMITH/SYMMGW/MSMNET PROFS/OV JRSMITH SFVM1SYM(JRSMITH) QuickMail John Smith John S SMTP/Internet JR Smith [email protected] Symmetry John Smith JSMITH/SFSALESNVREGION X.400 John Smith G=john; S=smith; P=acme; A=mci; C=us

A person can be referred to in a variety of different ways, depending on which email system the sender uses. Typically, users browse "friendly" names and are shielded from addresses, which are unambiguous references to a mailbox for the email system concerned.

user Smith might be addressed by colleagues, depending on their e-mail system of preference. Smith's "home" system is GroupWise. There he's known as John Smith, and his email address—which shows up here and there—is JSMITH/SFSALES/VVREGION. However, cc:Mail users see him as Smith, John R (note in cc:Mail the friendly name is also the address). SMTP users see his name and address as JR Smith and [email protected], respectively. Clearly, some machinery has to be put in place if the various different directories are to show such flexibility in displaying names and addresses. In the jargon, the names and addresses must be translated into a format suitable for the directories into which the information is being copied. The term mapping is used synonymously with translation.

Naming Conventions Also Demand Translations Note that even within a given e-mail system, there can still be great differences of format. For example, John Smith's SMTP address could easily be any of the following: [email protected] [email protected] [email protected] Thus: • Names and addresses need to be converted between the formats used by different e-mail systems.

133 6 Address Translation

• They also have to be converted into a form consistent with the particular naming conventions the user group has adopted.

Inflexibility of Older Systems Modern e-mail systems allow much greater address formatting flexibility. Consider a PROFS/OV address, such as: SFVM1(JRSMITH) All the information has to fit into two strings, of eight characters each. Life gets to be wild fun when you try to send mail to someone who's given you their X.400 or Internet address. A cc:Mail address, on the other hand, can have up to 126 characters, and is mostly free-format. This means that in a cc:Mail TO: field, you can type in almost any type of e-mail address, including: Smith, John John Smith SFVM1(JRSMITH)@PROFS_GATEWAY X400: G=john; S=smith; p=acme; A=telemail; C=us Thus, from a cc:Mail client, you can address almost anything, even if it becomes tedious at times. We wilt see later that the restrictiveness of systems like PROFS/ OV ends up causing unpleasant problems, because you often can't type in a recipient's address, and arriving mail may have addresses which don't fit into the required address structure. In such cases, work-arounds known as autoregistration and inline addressing are used.

Benefits of Name and Address Translation Name and address mapping is important, because: • It makes the messaging system appear a lot more friendly. No messing around with strange addresses! • Some older e-mail systems, notably PROFS/OV, only let you type in an 8 by 8 mail address. The software won't let you enter a longish PC or Internet e-mail address, so entering an equivalent expression is a big help. • It increases the use of e-mail, as now more users can easily be reached with e-mail. It creates a uniform user community, regardless of the actual platforms involved. • It also allows the integration of, and easy correspondence with, an organization's external correspondents.

Three Key Translation Requirements In summary, there are three key criteria related to address translation which should, ideally, be satisfied: • Consistent directory lookups. In each e-mail system, the name of every user in the e-mail system's address lists should appear in a consistent format that is independent of their home e-mail system. For example, every user in an MS Mail address list, whether an MS Mail user or not, might appear in a Last name, First name format. • Consistent message headers. In the header of a received message, the sender and all recipients should be displayed in a consistent format that is independent of their home e-mail system. Eg, if only names but not addresses are displayed for local users, only names are displayed for users of other e-mail systems as well. • Reply To All should work. Ie, when a reply message is created and the option to send a copy to all recipients of the original message is selected, the resulting mail should be correctly addressed.

Now Address Translation Works Given that users normally want to see addresses in the format used by their main email package, the variety of address formats means that something somewhere has to convert addresses from one format to the other. There are two main ways this is done: • Table-based mapping. • Rule-based mapping This in turn falls into two categories: administrator-selectable rules, and administrator-defined rules. Usually, you end up using a combination of both methods. We now look at these translation methods in more detail.

6.3 Table-Based Translation The most common method of translating address formats is where the administrator explicitly defines all correspondences. Sometimes this is done by filling in a formatted screen—figure 6.2 illustrates how to define the name pairs for Microsoft's MS Mail Gateway To MCI Mail. Another approach, more suitable for bulk definition, is to prepare and ASCII file containing the list of pairs. This is then read in by the gateway.

135 6 Address Translation

FIGURE 6.2 TABLE-BASED TRANSLATION WITH AN MS MAIUMCI MAIL GATEWAY

Create fax ma-user Paper 11116 Telex in alias for f axaddress, Enter to accept. Esc to abut

This administration screen from Microsoft's MS Mail/MCI Mail gateway shows how associations between MS Mail and MCI Mail addresses are established.

6.4 Rules-Based Translation Today, most X.400 gateways offer address translation services via a table-based approach. However, a new, more powerful, technique known as rules-based address translation is quickly catching on. Here predefined rules are used to convert address types from one to another. In other words, the rules specify an automatic way of taking an address in one format, and converting it to another format. Unlike table-based translation, you don't have to go in and hard-code each of the translations.

Example: Mapping X.400 Addresses to cc:Mail Addresses Take as an example the X.400 address: S=john; G=smith; P=acme; A=mci; C=us and consider how it could be converted to a cc:Mail address. These are of the form: last_name, first_name The natural translation rule is that the given name and surname of an X.400 address should be mapped onto the first_name and last name parts of the cc:Mail address. The first letter of each name should be capitalized, while other letters

should be lower case. The translation thus results in the following cc:Mail address: Smith, John

Example: Mapping cc:Mail Addresses to X.400 Addresses Let us now look at the other direction, ie, given a cc:Mail address, how can rules convert it into an X.400 address? Suppose the cc:Mail addresses are all in the form: Smith, John One possibility is: • G is set to the lower case version of first name • S is set to the lower case version of last name • P, A, and C are set to the constants "acme", "mci", and "us" respectively. In this case, the X.400 address for Smith, John would be: G=john; S=smith; P=acme; A=mci; C=us

Example: Mapping X.400 Addresses to SMTP/Internet Addresses Now suppose an X.400 message arrives at an X.400 backbone's gateway, and must be converted into an SMTP format. An appropriate translation rule might be as follows: • Concatenate the given name and the first letter of the surname • Make it all lower case • Then add the constant string "@acme.com". This would translate John Smith's X.400 address into: [email protected] On the other hand, perhaps the SMTP naming convention is such that an address like: [email protected] is more natural to users. In this case, the rule would be: • Concatenate the first letter of the given name, "2, and the surname • Make it all lower case • Then add the constant string "@acme.com". So there's a great variety of possible rules that can be used to convert addresses in one format to those in another format.

137 6 Address Translation

Example: DDAs Used To Generate X.400 Addresses We discussed DDAs or domain defined attributes in chapter 2. This is another method of taking a non-X.400 address and converting it into an X.400 address. For example, the cc:Mail address Smith, John can be represented as P=acme; A=mci; C=us; DDA.ccMail=Smith, John and the PROFS/OV address SFVMI (JRSMITH) as P=acme; A=mci; C=us; DDA.PROFS=SFVM1(JRSMITH) Here, the X.400 address generation algorithm is: • 13, A, and C are set to the constants "acme", "mci", and "us" respectively. • There is one DDA field. The type is "ccMail" or "PROFS", depending on which mail system is involved. The value is the address in cc:Mail or PROFS/OV.

Administrator-Selectable Rules Rules-based translation is most commonly done using a set of rules supplied by the X.400 gateway or backbone vendor. The administrator selects which of these he or she wants to use, as shown in figure 6.3

Administrator-Defined Rules Hopefully, you'll have a good selection of predefined address translation rules to choose from.

FIGURE 6.3 RETIX' ADMINISTRATOR-SELECTABLE RULES

Algorithm Male iinple

Given Surname Harry Truman Surname Given Truman Harry Surname—Given Truman—Harry Surname, Given Truman, Harry Surname—Initials Truman—HS Surname.lnitials Truman. HS Given Initials Surname Harry S Truman Given Initials Surname Generation Harry S Truman III

These rules are among those supplied with Retix' cc:Mail-to-X.400 gateway. They define various ways in which X.400 addresses may be converted to cc:Mail addresses.

Even if you do, you may find that the rules available don't quite fit the needs of your internal naming conventions. In this case, some vendors let administrators define their own rules (figure 6.4). Special scripting languages are used. These are dead simple to learn and use if you're the sort of person who spends most of their time writing compilers and line command processors—after all, it's just a matter of parsing a moderately complex expression. Disadvantaged readers lacking the appropriate background should expect hours of fun learning how to define and debug their own rules.

6.5 How Rules Are Applied You should be now have an idea of what a transformation rule looks like. The idea is that each rule defines a function of the form: If the address matches pattern A, then create an address with pattern A' which may be paraphrased as: If pattern_A, then pattern A' The general method of defining rule-based translations from e-mail system X to e- mail system Y is to define a set of rules like those of figure 6.5. The rules may be an arbitrary mix of administrator-selected and administrator-defined ones. This, however, only does half the job. Another set of rules must be specified which convert Y-type addresses into their X-type equivalents.

FIGURE 6.4 RETIX' ADMINISTRATOR-DEFINED RULES 111 ______

sliOjc!!e:sourqe.. C=us;A=telemail; P=acme; O=sales; @or@p=acme&g 8ts=@;%g %s diane shore S=shore; G=diane @or@s=@&(%c%a%p%o);%@.%s C=us;A=telemail; P=acme; O=sales; acme sales staff.shore S=shore; G=diane @or@dda(ccmail)=@;°/0*!(.+) (.+) C=us; A=telemail; P=acme; O=sales; smithers at (.+)!\2!dda{ccmail} dda(ccmail)=doug smithers at po1

@or©dda(rfc-822)=@;c/01(.*)$a$(.*) C=us; A=telemail; P=acme; O=sales; wally dowe@acme 1\ 1@\2!dda(rfc-822) dda(rfc-822)=wally dowe(a)acme

Administrator-defined rules are extremely useful, and Retix is one of the leaders in this field. The rules are often tricky to code and debug.

139 6 Address Translation

To recap: there are two tools to define address translation between a non- X.400 email system and an X.400 system: • Table-based translations, where you list out specific corresponding address pairs. • Rules-based translations, where you define automatic methods of converting an address in one format into an address in the other format. As we noted earlier, not all X.400 gateways support rules-based translation, although most have table-based translation. When both techniques are available, you can define the translation with a mixture of the two.

Centralized Translation Required Today, address translation rules and tables are usually owned and controlled by a specific gateway. This results in a number of problems: • The rules and tables need to be managed with gateway-specific tools. If you have lots of different gateways, that probably means knowing many different management tools. • If you're using table-based translation, then adding users or changing user addresses means making changes at all the different gateways. • Terminal emulation into the gateways may not be available. You'll probably need this to do rule and table maintenance. The solution is clearly to centralize the translation mechanisms. Lotus/SoftSwitch and Worldtalk are taking a leading role in this field. The general approach is to define a central directory of e-mail addresses. For each user, this directory contains the various addresses by which they are known in different e-mail systems. It may also contain the different friendly names by which they are known.

FIGURE 6.5 A TRANSLATION RULES SET

If pattem_1, then pattern_t If pattem_2, then pattern_2' If pattem_3, then pattern_3' If pattern_4, then pattern_4' If pattern_5, then pattern_5'

If pattern_n, then pattern_n'

To define an address translation from e-mail system X to e-mail system Y, you specify a series of rules. The first rule that matches the given system X address is then executed to produce its equivalent in system Y.

Each entry in the directory has a canonical messaging address by which a mailbox can be uniquely referred. In the case of Lotus/SoftSwitch, this is either an 8- by-8 SNADS address, or an X.400 O/R address. In the case of Worldtalk, it's an X.400 O/R address. The rest of the entry (figure 6.6) consists of the other addresses by which the mailbox may be known in connected e-mail systems, and it may also contain the various friendly names for each e-mail system. Thus for example, suppose Acme Corportion has an X.400 backbone with 5 attached non-X.400 systems: PROFS, cc:Mail, MS Mail, Novell's GroupWise, QuickMail, and SMTP. The address directory would have entries along the lines of figure 6.6. The equivalences may be explicitly enumerated, as is done with table-based translation; or they may be generated automatically using the sort of rules we've just discussed. Clearly, it's natural to use this directory for directory synchronization purposes. In X.500 directories, it's natural to include this information in a person's main entry.

FIGURE 6.6 ADDRESS TRANSLATION DIRECTORY ••••••1 ______

Home System Symmetry Canonical Messaging G=john; S=smith; P=acme; A=mci; C=us Address cc:Mail Friendly Smith, John R Name cc:Mail Address Smith, John R MS Mail Friendly Name John Smith MS Mail Address JRSMITH/SYMMGW/MSMNET PROFS/OV Friendly Name JRSMITH P ROFS/OV Address SFVM1SYM(JRSMITH) QuickMail Friendly Name John Smith QuickMail Address John S SMTP/Internet Friendly JR Smith Name SMTP/Internet [email protected] Address Symmetry John Smith Friendly Name Symmetry JSMITH/SFSALES/WREGION Address X.400 Friendly John Smith Name X.400 Address G=john; S=smith; P=acme; A=mci; C=us

A central address translation directory defines all the different addresses by which a mailbox may be known. Here we see a typical directory entry.

141 6 Address Translation

6.6 Autoregistration Suppose a message comes in from the outside, probably via the public X.400 network or the Internet. Often, there will be no pre-established entry for the sender in the address translation directory. This is a problem for e-mail systems with inflexible address structures, notably SNADS-based ones with their 8- by 8- addresses. The FROM: field can't handle the sender's X.400 or Internet address, so the recipient can't reply to the message. One common solution is known as autoregistration. When a message from a previously unknown sender is received, the sender's reply address is entered into the address translation directory. Then a rule-based translation of that address is used to create a corresponding name and unique address for each connected e-mail system. This allows the recipient to reply to the message using the name and address pair created by the autoregistration process. To illustrate: suppose an X.400 message comes in to a PROFS/OV user. The message is from G=john; S=smith; P=acme; A=mci; C=us Autoregistration would then typically create a PROFS/OV name and address pair like JSMITH and X400GATE(JSMITH) On the other hand, if an external user with the address G=janet; S=smith; P=widget manufacturing; A=telemail; C=us now sends a message, the basic autoregistration algorithm will probably generate the same SNADS name and address. When duplicates occur, therefore, the algorithm produces similar-but-different versions, such as JSMITH2 and X400GATE(JSMITH2)

6.7 Inline Addressing We've just seen how incoming mail can create major headaches for systems with very limited address spaces. A related problem occurs for outgoing mail: ® Suppose someone gives a PROFS/OV user their X.400 or Internet address.

How can the PROFS/OV user send them a message? • Suppose a PROFS/OV user wants to send mail to a fax address? If an address translation directory entry has already been defined, the answer is to use the 8- by 8- address synonym for the recipient's address. But suppose the recipient has not previously been registered in the address translation directory? This is often the case when someone hands you their business card, and invites you to send them mail. One possibility is that the user contacts the e-mail administrator, and asks them to create an entry in the address translation directory, so that an 8- by 8- synonym is created. But this takes time and is a big pain. A more attractive option for lazy but important people is to ask the prospective recipient to send a message first to the would-be sender. This can then force autoregistration. But this is an aburdity. Plus, you then have to suffer the problems associated with autoregistration, notably that of proliferating directory entries. Another solution is to use inline addressing, also called wild or open addressing. Here the user enters recipient addresses in the message text, using a simple keyword-based grammar. Typically what happens is: • One set of special keywords brackets the address text. • Then TO, CC, and BCC keywords define the main clauses. • Sub-clauses contain keywords followed by values. The keywords are things like LASTNAME=, PERSONALNAME=, ATTENTION=, H 0 MEMAILNAME = , FAXNUMl3 ER= . Figure 6.7 illustrates, showing the way inline addressing work with Lotus/ SoftSwitch Central and LMS (ex-EMX). Note that Lotus/SoftSwitch uses open addressing to refer to this feature.

6.8 Translation Problems We now turn to a discussion of the most common problems people have with table- and rules-based address translation. You should pay particular attention to these factors when testing the backbone before general deployment.

143 6 Address Translation

FIGURE 6.7 LOTUS/SOFTSWITCH INLINE ADDRESSING

Hi John,* Very good seeing you again yesterday, hope to see you again soon. Best regards, Frank

SSW: TO LASTNAME = Smith FIRSTNAME = John FAX = 1 415 555 1212 CC: PERSONALNAME=John Smith FIND=Y BCC PERSONALNAME='Jim 0"Hara", TLX=3362001 SSW:

Wine addressing lets users type in X.400, Internet, and fax addresses in the body of an interpersonal message. This example is from Lotus/SoftSwitch; the FIND command indicates a directory lookup should take place.

General

No Administrator-Selectable Translation Rules You may find there are no translation rules available. Some gateways lack them, and only offer table-based translation, which is much more laborious to maintain. Some gateways even lack table-based translation.

Table-Based Translation Very Laborious to Maintain Maintaining the hard-coded pairs is a big hassle and probably won't be done properly.

External Mail Not Delivered Plenty of mail arriving from external mailboxes (usually X.400 or Internet traffic) won't be delivered or will have incomprehensible sender names. The problem arises due to the unpredictable formats. Some translations won't have been defined correctly and gateways get confused. See the later section on multi-hop name translation for a more detailed discussion.

Sloppy Naming Conventions The name and address translation job will be much simpler if each different e-mail

environment uses an internally consistent naming convention. If they don't, do your utmost to get such conventions in place. Consistent naming conventions let you use rules-based translation. Without this, you'll be stuck with maintaining hard-coded translation tables. This is a large administrative overhead. More importantly, users will pay dearly in terms of undelivered mail and addressing frustration. Unexpected incoming mail will have a much higher incidence of being returned.

Administrator-Selectable Translation Rules Inadequate The predefined rules available may not suffice. You may have particular naming conventions that aren't properly processed by any of the possible choices. In this case, if you're lucky, there will be a flexible utility to define your own mappings, what we referred to as administrator-definable rules. These are a natural solution, but they're hard to learn, implement, and maintain.

Duplicate Names What happens if there are two people called John Smith within the organization? This is bound to happen if you're in a larger organization. One solution is to use tie breakers. For example, one could use the GQ(generational qualifier) field in the X.400 address: G=john; S=smith; GQ=iii P=acme; A=mci; C=us and to pick a rule-based translation which incorporates the GQ, such as: Smith, John III There are a number of problems with this solution. The main issue is that it's both unintuitive and error-prone. People, expecting an intuitive address, may end up sending their message to the wrong person. So if you have two users with the addresses: Smith, John and Smith, John III, it is likely that the former will receive some of the messages intended for the latter. If you need tiebreakers, it's best to ask users what they would like to have as tiebreaker. A nickname or user-selected abbreviation is often better than a rule- generated tiebreaker. Therefore rule-based translations are often combined with the table lookup method—you use lookups when the rules don't generate the mappings you want.

145 6 Address Translation

When operating a messaging system, one thing you absolutely want to ensure is that one user does not get another user's e-mail by mistake. It really shakes users' trust in the system.

Non-Unique Translations It's possible to implement translation algorithms which map two different mailboxes to the same address. For example, cc:Mail users Smith, Jay and Smith, John could both be mapped to [email protected]. This means that someone can receive someone else's mail.

MTA Routing Confused by DDAs It's easy to translate a non-X.400 address into X.400 format using DDAs. How- ever, MTAs often get confused by DDAs, because they generally route on some combination of G, S, OU, and 0 attributes. So if you can, avoid DDAs.

Multi-Hop Name Translation When mail has to go through several intermediate systems, and several associated translations, expect addressing problems. Mappings get confused, especially when the mailboxes at either end haven't communicated before. For example, suppose Fred Jones, a CompuServe user, wants to send mail to a PROFS/OV John Smith at Acme (figure 6.8). Smith uses MS Mail for AppleTalk Networks, and his Internet address is [email protected]. Since Jones is a CompuServe user, he addresses his message the way CompuServe requires for an Internet connection: IN'1ERNET:[email protected] The mail goes through CompuServe's network, and into the Internet where Jones' CompuServe address (75300,3400) is put into Internet format. It arrives at Acme's gateway, where the Internet version of my Compuserve address is mapped into the SNADS 8.8 canonical address. The message is then transferred to MS Mail for the Macintosh, where the SNADS version of the Internet version of my CompuServe address is converted into a format suitable for MS Mail for AppleTalk Networks. Get all that? Guess what: will Smith know who the mail is from? Chances are, he sees Jones' address as something like GTVVY_E9.00041089 ... or something equally unrecognizable. And there's a fair chance that the process isn't reversible, ie, if Smith tries to reply, the reply will be bounced back to him as undeliverable.

FIGURE 6.8 MULTI-GATEWAY ADDRESS TRANSFORMATION

Gateway Gateway SNADS CompuServe Internet Backbon

Fred Jones From: Fred Jones 75300,3400 Gateway

MS Mail for AppleTalk

From GTVW_E9 00041089 John Smith

Unrecognizable address translations are common when several gateways must be traversed.

Solutions are gradually evolving to deal with this issue. They typically involve directories maintaining a canonical X.400 0/R name, as well as equivalent formats for e-mail systems frequented by the user. But for the next few years, expect dynamic multi-hop name mapping to be a nagging irritant.

Co-Recipient Address Translation The handling of co-recipients is tricky. Suppose John Smith sends a message to Fred Jones and Eugene Lee (figure 6.9). Fred Jones is a cc:Mail user, Eugene Lee is an SMTP user. Ideally, Jones should receive a message that indicates two recipients, Jones and Lee. But what format should Lee's address be in? Should it be displayed as a cc:Mail address? Or should it be Lee's "real" address, [email protected]? Jones may not be familiar with the SMTP format. The person configuring address translation may have several options: The translation process makes up a cc:Mail address for Lee, such as Lee, Eugene, so Jones sees a cc:Mail name for both himself and Lee.

147 6 Address Translation

FIGURE 6.9 CO-RECIPIENT ADDRESS TRANSLATION

To: Jones, Fred Fred Jones Lee, Eugene-or [email protected] From: Smith, John cc:Mail

John Smit h To: [email protected] Eugen [email protected] Jones, e Lee Fred From: [email protected] SMTP

It's often unclear whether to show co-recipients' addresses in their "home" format, or in the recipient's format.

All things being equal, this is the best approach. • The translation process puts Lee's SMTP address into the message seen by Jones. If it's too long to be displayed in the space provided by cc:Mail, the address is placed at the beginning or at the end of the message text. This approach is often used where there's no address translation directory or autoregistration. • When Jones receives the message, Lee's address is omitted. Jones sees his own address as the only recipient. This option can make sense if a message has a larger number of co-recipients, where the list will have to be inserted in the message text itself. With each co-recipient address taking two lines, you can end up with a ten line message followed by 500 lines of address information!

Autoregistration and Inline Addressing We now turn to problems that are of particular interest—or should we say pain?— to people using autoregistration and inline addressing, such as PROFS/OV and SNADS-based system users.

Cryptic Autoregistration Names and Addresses Often, the algorithms used to autoregister originator names and addresses result in expressions that have little suggestive value to the message recipient, such as GTWY_E9.00041089

If the message is itself ambiguous, the recipient may be unsure who sent it. Table Entries Proliferate People who send a message only once will have an entry created for them. This means that the directories can get very large. The answer is, of course, to purge the directories every so often, discarding addresses that have been inactive for, say, six months. But what if seven months later, someone wants to reply or send a message to the sender? If the entry has been deleted, the system will not recognize the address, and mail will be returned. Even worse, suppose John Smith of Acme was autoregistered, and given the PROFS/OV address X400GATE(JSMITH). His entry is later purged, and following this Janet Smith of Widget Manufacturing sends in a message and is duly autoregistered. She might be assigned the same address as John Smith had earlier. Thus, a reply to John Smith's message might go off to Janet Smith—obviously, this is completely unacceptable. We are not aware of any good solutions to this problem. Many people turn autoregistration off; but this then forces users to deal with the nastiness of inline addressing.

Multiple Addresses for Same Person Sometimes people sending mail get autoregistered several times. For example, someone might send you a message once through TELEMAIL and then once via ATTMAJI. Two different entries will be created. Thus PROFS/OV users will see two different senders, such as one at X400GATE(JSMITH), and one at X400GATE(JSMITH2). In fact, they're the same person. You get same problem if someone sends you a message from two different mail systems. For example, if they send you a message from the Internet, and then one via the public X.400 network.

Inline Addressing Easy to Get Wrong You have to get the syntax right when entering inline addressing instructions. It's easy to get something wrong, and have the mail returned.

Inline Addressing Creates Confusing Messages Also, suppose PROFS/OV users sends a message to two recipients defined by inline addressing. One is another PROFS/OV user, the second is a cc:Mail user.

149 6 Address Translation

Both recipients are likely to see the inline text in the body of their message, which as far as they are concerned, is simply confusing clutter.

One-Off Addressing Unwieldy Generally, expect PROFS/OV and SNADS-based users to have problems with one-off addressing to fax numbers, and X.400 and Internet addresses. The various options open to them are all unwieldy.

7. File Transfer & Conversion

Messaging systems are commonly used to transfer files. It turns out that a number of important issues are involved when transferring files by e-mail. In this chapter, we first describe a useful file processing tool that is often used with PC e-mail systems, the viewer. It's used to view files that have been transfered. Then we explain how X.400 file transfer works. We then turn to one of the main problems with e-mail file transfer: that it can be hard to tell the name and creating application of a received file. We then discuss the various methods of converting file formats. This is done either in the workstation by the sender or, more likely, the receiver. However, it's also possible to have conversion take place automatically in the backbone itself.

7.1 Viewers First a quick summary of what a viewer is. A viewer is a piece of software that looks at a file and works out what format it's in. This is much more reliable than the simple association of extensions with applications types, as is common in the DOS and Windows world. A viewer can normally determine additional information, such as the software version, and the type of computer and OS used to create the file. Viewers are best at looking at word processing documents, although they often support major spread sheet, database, and graphics formats. Having determined a file's type, a viewer then displays it on the screen (figure 7.1). If the necessary text fonts aren't available on your machine, the viewer uses

151 7 File Transfer

FIGURE 7.1 USING A VIEWER

Russell Wilson Andrea O'Leary Fourth Quarter Marketing Strategy Bill Plante

Outside/In displays a compressed Microsoft Word document.

fonts that are close to the intended ones. Typically, you can do things like: • Zoom in and out • View graphics, and do basic manipulations such as rotation and sizing • Print the image • Copy portions to the clipboard, for transfer to other applications • Search for text • Launch the application that created the file, assuming the software is available Outside/In, from Systems Compatibility Corporation, is the market leader in this field. Other products with a viewer include Symantec's Norton Desktop, Keyword Office Technology's KEYview, and Mastersoft's Word for Word Windows Edition. Most PC e-mail packages include a viewer. This is very convenient, since when someone mails you a file, you can double-click on it, and the viewer comes into action. Often the viewer is a subset of Outside/In, as with BeyondMail, ON Technology's eMAIL, Microsoft Mail, and GroupWise. Some non-e-mail applications packages contain viewers, such as the word processor WordPerfect.

7.2 How File Transfer Works Before a recipient can use a viewer to inspect a file contained in a message, the message containing the file must be transmitted. We now look at how this happens. Figure 7.2 displays the message formats used by typical e-mail environments and X.400. In both cases, attachments can usually be carried along with a message. The attachments can be of any type: word processor files, spreadsheet files, CAD drawings, and so on.

FIGURE 7.2 HOW FILE ATTACHMENTS ARE HANDLED: PC E-MAIL VS. X.400

0010010101010101000100 0010010001000101011001 0101010101001010100101 0100100101011011111010

0010010101010101000100 0010010001000101011001 0101010101001010100101 0100100101011011111010 To: Jim Jones@accounting To: Jim Jones @accounting From: JPeengineering From: JP @engineering

Dear Jim, ASCII body part I attached our most recent Dear JP, business plan as well as the process charts. I attached our most recent business plan as well as JP the process charts. Jim busplan.wp —...... plan.tif --...... „ binary file body part 0010010101010101000100 0010010001000101011001 0101010101001010100101 (a) 0100100101011011111010 Message model for binary file body part most LAN based e-mail systems. 0010010101010101000100 0010010001000101011001 0101010101001010100101 0100100101011011111010 •

(b) Message model for X.400.

153 PC E-Mail messages, unlike X.400 messages, contain the names of attached files. 7 File Transfer

PC E-Mail File Transfer Is Messy With PC e-mail products, if the recipient uses the same product, his or her view of the message is identical. Regardless of the actual transmission mechanism, the user receives one message, with the indication of attachments. The names of the attachments are carried over. Usually the user can guess the application that created the file, by looking at the filename extension. This often works reasonably well. But suppose you receive a file with a .DOC extension. Presumably this is a word processing document. Nev- ertheless it can be hard to determine what word processing application created the file, let alone the platform (eg, PC or Macintosh) and version concerned. Another example is where you receive a file with a name like STATSFOR JIM. Is it a spreadsheet file, a word processing file, or what? And if you know the application, what version is it, and what platform was it created on? If the format of one of the attachments is obscure, then the sender may have to include information about what the file type or creating application is. Another popular option is to use a viewer.

X.400 File Transfer Is Messier Thus, PC e-mail file transfer is often messy. It's worse with X.400. A message consists of a header and one or more body parts. The first body part can be a simple ASCII message to explain the nature of the attachments, but does not need to be so. Furthermore, X.400 does not carry file names or file types, unless the user makes a specific effort to include this information into, say, the subject line or within an interpersonal message. Thus, in the X.400 environment, one can receive a message with absolutely no indication of the type of its file attachments or even the name of the file. Many X.400 systems provide crude workarounds. A common approach is to include in the message a separate message that specifies the name and characteristics of the file. This ends up being rather cumbersome for users. For example, suppose someone uses cc:Mail to send a textual message with an attached file to a MS Mail user. After traversing a couple of gateways on the X.400 backbone, the message may contain three separate attachments: one containing the textual message, one containing the attachment, and one specifying the name of the file! Once a file has arrived, hopefully along with its name, there still remains the inconvenience of determining what application created it. The situation's now identical to that of PC e-mail; if the extension's obscure, you need to use a viewer to work out what to do.

In summary: X.400 messages allow several files, each possibly of different type, to be included in a message. Each file is included in a separate body part. The basic interpersonal message is also considered a body part. When a file is transferred, there are only crude facilities to determine its attributes.

Body Part IA5Text/ASCII Each body part is assigned a body part type. While X.400 defines several body part types, only two are actually used. The first is the body part type IA5Text that indicates that the body part contains only non-extended ASCII text. This is a least common denominator: every implementation can deal with it. The second type of body part—basically non-ASCII files—are known as type 14 body parts in 1984 implementations, and as type 15 body parts in 1988 implementations.

Body Part Type 14 In 1984 terminology, a non-IA5Text file is said to have a bilaterally defined body part type. The term has become a catch-all. Any non-ASCII body part gets the type 14 label. Note that with type 14 body parts, no file details are included, such as the file name and extension, whether the file is a TIFF file or a WordPerfect file, or the name and version of the application that created the file. Thus as we noted above, when you receive a 1984 X.400 message that contains a file, it can be hard to know what to do with it.

Body Part Type 15 The body part 14 deficiency was partially addressed by the 1988 recommendations. These define another body part type, known as body part type 15. This basically refers to a binary file that has an associated field defining the format of the file. When a new file type comes along (eg, a new version of a word processing package), you simply add a new value representing that file type. The trouble with this approach is that everybody has to know which definitions are in use. Somebody must maintain a list of assigned types to be used in body part type 15, and provide the list to whoever requests it. At the time of this writing, nobody has volunteered to perform this task, and there is no registration authority. So right now, using body part 15 really only makes sense if you control both the sending and receiving ends, and are prepared to assign your own file type values.

155 7 File Transfer

File Transfer Body Part While writing the 1992 recommendations, the study group extended the body part 15 mechanism, to allow for a file transfer body part. This mechanism specifically provides for computer files that are transferred through messaging systems. This can be used to specify: • File attributes: creation date, size, pathname, access control, etc • Creating application and version • The operating system used to create the file • The type of compression used, if any. Unfortunately, no standard definitions are available. Eg, there are no standard values which indicate that a file was created by Microsoft Word on a Macintosh, version 5.1. This problem's being worked on by an EMA committee known as the Message Attachment Working Group. The information required will likely be the application used, version number, and OS under which the application ran. Optional recommended data will probably include the file size, and a string (eg THIS IS AUTOCAD v3.1) which will be displayed if the launching application gets confused. The spec's now fairly solid, and the plan is to publish it in early 1995. Sometime in 1996—the estimated date keeps getting deferred—we'll probably see products that implement it. So the end's in sight for androgynous files.

7.3 Preserving File Attributes Across X.400 Gateways Thus, deficiencies in X.400 itself make it hard to know what to do with arriving files. However, additional problems arise when files pass through a gateway as they go to and from an X.400 backbone.

From Non-X.400 to X.400 The challenge here is to convert a non-X.400 message containing one or more attachments, so that the associated file names and characteristics aren't lost. Since X.400 does not carry this information by default, where it is put depends on the implementer of the gateway. Figure 7.3 displays one possibility. As we noted, this example is at the user-friendly end of the options: you might well end up with a series of separate messages, and in some cases all file attribute information will simply be discarded.

FIGURE 7.3 PRESERVING ATTACHMENT PROPERTIES ACROSS GATEWAYS

To: Jim Jones@accounting From: JP@engineering • ASCII body part Control section: File 3 busplan.wp Type WordPerfect Inserted Cr Date 01/12/94 control Length 5097 section File 4 pIan.tiff Type TIFF Cr Date 01/14/94 Length : 38992 End • ASCII body part

Dear Jim, I attached our most recent business plan as well as the process charts.

binary file body part 0010010101010101000100 0010010001000101011001 0101010101001010100101 0100100101011011111010

The properties of a file can be inserted into an X.400 message by adding a text body part.

Whatever's done, the results are messy and confusing, and the message that was originally sent is now distorted. Things may get even worse if the attachment is first converted into X.400 (say by being put on the backbone), and then converted back into some non-X.400 format (say that of the recipient).

Tunneling A special case arises when the originator and recipient are both users of the same non-X.400 mail system, connected through X.400. With a small extra gateway

157 7 File Transfer

feature, life can be made a lot more pleasant for users. The gateway converting from non-X.400 into X.400 creates an X.400 message along the lines of figure 7.3 above. The same gateway can be designed to recognize the first part of a similar arriving X.400 message, and reconstruct the message as it was before going into X.400. This technique is known as tunneling. It's easy to preserve all non-X.400 message properties in this way, so that the recipient is completely unaware of any in-transit conversions.

From X.400 to Non-X.400 Suppose now a message is originated by an X.400 user, rather than by a user of a non-X.400 system. The originator may know that the X.400 transmission system loses the file names and types, and therefore may put related information into the message. Or he/she may not. Thus, an X.400-to-non-X.400 gateway cannot assume the existence of file attribute information. So when the conversion from X.400 to non-X.400 occurs, the gateway has to assign internally the generated filenames, like Received File 3.

7.4 Large Message Transfer Problems

There are several problems relating to large file transfers that you should be

aware of. Message Too Large For The System Some messaging systems have limitations on the size of message they can handle. For example, ADMDs often limit messages to two megabytes. If you expect your message to be delivered as a telex message, a maximum limit of 50,000 characters is more likely. If one of the components of your network has a maximum message length, it's worth checking what happens when a message exceeds the maximum size. A variety of things can happen. The message may: • Simply disappear • Be divided into two messages • Be canceled and a nondelivery notification sent back • Be canceled and returned

System Breakdowns Large files will tend to stress test a messaging system, and can cause breakdowns at many places. For example, transient storage in an MTA may be too small, or MTAMTA data links may be too slow. Periodically, send a file that's of abnormal size for your environment, and see what happens. Keep sending larger files until the system runs into difficulties, and then take corrective action so that the problems are handled gracefully, rather than causing the system to lock up. Since users are sending larger and larger files all the time, you also need to monitor average message sizes and the size of the largest file transfers. Doing so will enable you to project future systems use, and increase bandwidth before users start having problems.

Service Provider Charges When messages get longer, the cost associated with transmitting them increases, sometimes in unexpected ways. When sending messages over a service provider, this is most pronounced. You probably don't mind paying 50 cents to send a 1,500 character note to a correspondent. But once you've included drawings and so on into the document, it can quickly grow to 1.5 MB. ADMDs charge less for longer messages on a per-character basis. But a 1.5 MB file transfer is still likely to cost $30 to $75. The question becomes: It is better to send it as a message, or put it on a diskette, and send it via overnight courier? A further issue arises. Ideally, users would be charged for the cost of sending large files. They can then make a rational tradeoff between cost, and sending a message of given size and priority. The trouble is, few tools are available to implement user chargeback. In most environments, users can't easily find out what they will be charged. Clearly, the problem is most acute when a large file has to be sent over a public service provider, when substantial real costs are incurred.

Everyone Gets Delayed Large file transfers usually delay everyone else. For example, suppose that two MTAs in your network can exchange only one message at a time. One of them is a low capacity MTA, serving a small branch office. It is connected to your central MTAs using a dialup link. At installation time, analysis of likely traffic showed that a 9600 baud modem was sufficient. Then some new application starts routinely sending 1.5 MB files.

159 7 File Transfer

Every time these files go over the slow line, all other messages will have to wait until the transfer has been completed. Since each transfer will take about half an hour, other users will be confronted with an unacceptable degradation of service.

7.5 Desktop File Conversion We've focused in this chapter mainly on the problems of determining the name and type of arriving files. However, it often isn't enough to determine the creating application, especially when the creating application (together with enough supporting hardware) isn't available. In these cases, it's often necessary for the recipient to convert the file into a format his or her software can read.

Possible Locations of File Conversion File conversion can occur in several places (figure 7.4): • In the sender's or recipient's desktop • In one of the gateways that connect the sender's or recipient's environment to the backbone • In the backbone itself

FIGURE 7.4 PLACES WHERE FILE CONVERSION CAN OCCUR

cc:Mail/ User Messagin X.400 MTA g System Gatewa A

X.400 Backbone

cc:Mail/ User Messaging X.400 MTA System B Gateway

File attachments can be converted at three places during message transfer: at the workstation, in a gateway, or in the backbone itself.

We refer to the first type as desktop-based conversion, and refer to the second and third options as backbone-based conversion. At present most file conversions occur in the sender's or recipient's desktop. The sender or recipient manually controls the process, using conversion utilities. These utilities fall in three categories:

Stand-Alone General-Purpose Conversion Packages These are very similar to viewers, except they go further. They first delve into a file, and work out what software produced it. Some conversion packages, such as Keyword's KEYview, then display the file. Finally, they produce a new version of the file, in a format more easily digested by the recipient. Keyword is the big vendor in this field. Their conversion software runs on many different computers, from IBM mainframes though minis, and more recently PCs. Keyword offers a wide variety of source-to-target combinations. DataViz' MacLinkPlus is the dominant product in the Macintosh world, although Keyword also has an offering. Mastersoft's Word for Word is another important converter, and versions of its translators are used in many third party software packages from companies like Microsoft, Lotus, and IBM. Finally, we should note that although Outside/In focuses on viewing (no pun intended), the product now includes several format converters.

Built-in General-Purpose Conversion Packages Many applications include conversion software, accessed as file-open and file- save options. Microsoft applications are particularly well-endowed in this regard. Application vendors typically call upon third parties such as Mastersoft and Keyword to produce the translators.

High End Graphics Conversion Packages Fine details are important for people doing advanced graphics—technical drawings, high quality artwork, and so on. The tools used include Adobe Illustrator, AutoCAD, DTP software like PageMaker and QuarkXPress, and specialized graphics workstations. They need good translation of things like lines, Bezier curves, splines, and gradient fills. For example, consider some of the special characteristics of lines: Ends can be squared, rounded, or tapered.

161 7 File Transfer

• Two lines may meet smoothly, or they may cut off abruptly at the point of contact, creating a corner with a notch. • The style of dashed lines varies. • Arrowhead styles vary, too. General-purpose translators such as those from DataViz, Keyword, Mastersoft, and Systems Compatibility ignore these niceties, or map them into a crude lowest common denominator. It's possible to find very specialized high end graphics converters to address these issues. One of the better known is Cadmover from Kandu Software. This supports common formats like EPS, Adobe Illustrator's EPS subset, CGM, as well as more specialized ones like DXS, and IGES.

7.6 Backbone File Conversion Many readers will consider putting the conversion process in gateways or in the backbone. In-transit file conversion has two immediately apparent benefits: • Users don't have to bother with converting file formats. The process is transparent. • Support is much reduced. In the right circumstances converters do not need to be available at each user's desktop. Also, technically unsophisticated users do not need to be supported through such conversions.

Strategic Advantages of Backbone Conversion For some organizations, in-transit conversion can also provide a significant business advantage. Such cases have certain characteristics in common: • A large central library of documents is in place. • This is made available to employees and business partners. Users can browse through the library, and download items of interest. • Conversion tools provide for format differences. For example, an aircraft manufacturer might put all its technical drawings up on some system. Subcontractors can then browse for documents, either interactively or, if need be, by some sort of query-by-mail. Appropriate documents can be downloaded by mail. Another example is that of a stock brokerage. Its research reports—including lots of special graphics—might be made available on-line. Investors can browse among them, downloading items of interest. Because the type and configuration of recipi-

ents' machines is unpredictable, converters are used to put the information in the right format.

How Backbone-Based Conversion Works A directory maintains information about the preferred file formats of recipients. In-transit files are automatically inspected to determine their type, and a converter program is executed to change into a format suitable for the recipient. A growing number of gateways and backbone packages support such conversion. Typically the gateway or backbone vendor lets you specify what converter packages you want to use. Keyword is by far the largest supplier of converter software.

What the Snags Are The disadvantages of in-transit conversion are: • It can be difficult to maintain the information on user preferences. Most of the time a user might want a standard conversion to take place; but occasions when the default transformation doesn't work will cause confusion and frustration, and will eat up a lot of support staff time. • MIPS on a backbone are often expensive—eg, SoftSwitch Central runs on a mainframe—and conversion takes a lot of cycles. • Backbone components are often heavily used already, so conversion will require significant upgrades of equipment. Fax converters are an exception, because they are usually off-loaded to a dedicated PC. Around 1O%-20% of large organizations do in-transit conversion, while the rest feel the disadvantages outweigh the benefits. Suitable environments appear to be ones where you're connecting separate mini or mainframe OA environments, when you're creating a multi-format library of diverse basic textual documents, or when users are migrating from mini or mainframe technology to more modern platforms.

Two important Suggestions If you do in-transit conversion, remember it usually makes sense to send the original, unconverted file along, too—it gives the recipient more flexibility. You may also want to limit the number of conversions available, since this allows for more rigorous testing, and it's easier to manage users' expectations about what they can expect.

163 7 File Transfer

7.7 Main Conversion Problems Conversion software has its limits, whether run at a desktop, or in the backbone. Here we describe the main areas to watch out for.

Unknown File Format As we noted before, the basic annoyance is that when a file arrives, you can't usually tell what application created it. It may have no extension; and even if it does, a .DOC extension doesn't tell you what word processor created the file. Even when you know the application, you need to know the version and computer type. Today's workaround is to invoke a viewer, which looks inside the file and comes up with the information. A proper solution should finally arrive when the work of the EMA's Message Attachment Working Group comes to fruition.

Fonts Not Available The recipient's machine may not have the fonts required. The better conversion packages look at what's available, and try to choose a similar font. Nevertheless, this frequently introduces differences in formatting: for example, what used to be a single page can now flow over into two pages. The ideal solution is to ensure both sender and recipient have the same fonts, preferably from the same manufacturer. As a practical matter, however, often it's too much bother to install new fonts. Also, the recipient may not know which fonts were used by the sender.

More Complex Documents Most conversion packages handle basic text quite well (figure 7.5). However, expect problems with more complex documents that include things like columns, footnotes, graphics, hidden text, OLE objects, tables of contents, and so on.

Basic Graphics Images come in an incredible variety of formats, depending on the application program you're using. Figure 7.6 illustrates many of the common ones. They're the sort of thing you generate with Adobe Illustrator, paint programs, screen dumps, and so on.

FIGURE 7.5 PRESERVED TEXT CHARACTERISTICS

Character Attributes Margins Bold Left Underline Right Subscript Indent Superscript Italics Line Spacing Shadow Single All caps Double Small caps Triple Font size Tabs Justification Left TabRight Left Center Tab Right Decimal Tab Center Full Other Hard Page Break

Most conversion packages handle basic text well. You can expect these features to be preserved through translation. Specific source/target converters may handle more sophisticated formatting, but take nothing for granted.

Advanced Graphics As noted earlier, people doing advanced graphics will find that most converters ignore the fine details of lines, Bezier curves, splines, gradient fills, and so on.

Spread Sheet Macros Many conversion packages translate common spread sheet formats. However, macro logic is likely to be ignored. Only hard numbers and simple cell formulae will come across.

Crossing Platforms Many translators get confused when you cross platforms; for example, when you go between any two of the following: • DOS/Windows • Macintosh • UNIX workstation • VAX • IBM mainframe

165 7 File Transfer

FIGURE 7.6 COMMON GRAPHICS FORMATS 1000::F

Vector Formats Vector Formats CGM Computer Graphics Metafile CGM Computer Graphics Metafile SDW AmiDraw Graphics WMF Windows Metafile WMF Windows Metafile WPG WordPerfect Graphics WPG WordPerfect Graphics

Raster Formats Raster Formats BMP Windows & OS/2 PM Bitmap BMP Windows & OS/2 PM Bitmap EPS Encapsulated PostScript EPS Encapsulated PostScript G3ID CCITT G3-ID Encoding GIF Graphics Interchange GIF Graphics Interchange MAC Macintosh Paint MAC Macintosh Paint PCX PC Paintbrush PCX PC Paintbrush PICT Mac Picture Graphics PICT Mac Picture Graphics TIFF Tagged Image File SDW AmiDraw Graphics WPG WordPerfect Graphics TIFF Tagged Image File WMF Windows Metafile WPG WordPerfect Graphics

Keyword's KEYview converts a wide variety of basic graphic formats, shown here. However, a given source/target converter may not support the particular combinations needed.

In these cases, many translators only provide basic text translation (figure 7.5). This is probably fine for most mini and mainframe documents, but PC, Mac, and UNIX workstation users are often disappointed to receive something with no graphics, poor font translation, and distorted layouts.

Out of Date Converters When a new version of a major application package appears, it's typically around three to six months until converters for the new features become available. If you're unlucky, the new features will never be supported, as is likely if the product is dying and has little market share.

Features Not Translatable Sometimes a feature isn't supported in the target format. For example, WordPerfect allows triple underlining, while Microsoft Word doesn't. So at best, a translator will choose some reasonable substitute: in this example, it would probably substitute Word's double underlining.

OLE Files Sending OLE files creates endless amusement for the sadistically inclined: • Viewers and converters often get confused and you end up with empty holes where embedded structures should be. • The receiving machine usually won't have the different applications needed. • Most users don't know what OLE is yet and get confused even if their machine has the applications needed.

167

Chapter 8

8. X.400 Gateway Services

In this chapter, we discuss many of the things that are done at the point of connection between a non-X.400 system and the X.400 backbone. In other words, we discuss what the connecting gateway does. We dwell only briefly on address translation, file transfer and conversion, and directory synchronization, because these issues warrant chapters to themselves, and have already been discussed at length.

Main Gateway Functions The main tasks of an X.400 gateway are, in rough order of importance (figure 8.1):

FIGURE 8.1 MAIN MESSAGE ELEMENTS PROCESSED BY A GATEWAY

Sender Recipient List Each recipient's address Responsibility indicator associated with each recipient Whether a positive delivery should be acknowledged to the sender Priority Message ID Trace information Contents Main message (often an interpersonal message) File attachments

An e-mail message consists of a number of components. When evaluating an X.400 gateway, the ones shown should be the main focus of testing.

169 8 Gateway Services

• Interpersonal Message Conversion. Today, the main reason for operating a gateway is typically to convert the core message—often an interpersonal message—being sent. • Address Translation. E-Mail addresses appear in many elements of a message, most notably in the originator and recipient elements. The big challenge as far as gateways are concerned is that users often prefer to see addresses conformant with their own environment. A PROFS user wants to see only PROFS addresses, a Microsoft Mail user wants to see only Microsoft Mail addresses, and so on. Thus, addresses need to be converted from one format to the other. • File Transfer. The main question here is whether information about a file—such as its name, the type of application that created it, and its clickable icon—is preserved through the gateway. • File Conversion. The recipient of a file must have the hardware and software needed to read the file. In this case, the format can be converted into one suitable for the recipient. • Tunneling. If the sender and recipient of a message use the same e-mail software, it's possible to preserve the message perfectly intact, even though it's passing through the backbone gateway. This technique— packing everything into a binary file and then unpacking it upon transfer into the recipient's e-mail system—is known as tunneling. • Directory Synchronization. Directory information on both sides of the gateway may need to be passed to the other side, in order to keep directories on both sides up to date. This means that the gateway needs to integrate the directory synchronization processes of the two systems connected by the gateway. • Notification Processing. Delivery/nondelivery and receipt/nonreceipt notifications must be transferred across the gateway. • Message Tracking. Some e-mail systems provide the ability to query the system about the status of sent messages. Although such services are in their infancy, it won't be long before messaging tracking will have to be able to peer through gateways. • Security. A gateway can restrict the passage of certain types passing through it. • Auxiliary Element Conversion. This catch-all concept refers to the translation of other, more obscure message elements, such as the priority or importance. • Special Character Handling. Certain characters—the percent sign, the @ sign, the exclamation mark, the double quotes sign, and the underscore— cannot appear in X.400 messages. They therefore require special processing.

Some Services Can Be Provided Elsewhere The above list of gateway services is pretty all-encompassing. All X.400 gateways provide for conversion of interpersonal message elements, and most provide some level of address conversion and notification processing. A small but growing number offer directory synchronization, tunneling, file conversion, and security services. None offer messaging tracking. We should also note that some of these services can be performed elsewhere. For example, file conversion can take place at the sender and recipient workstations, or in the backbone itself Security filters can be inserted in the backbone as well as in gateways. And directory synchronization could be done quite independently of gateways.

Gateways Must Be Customizable Another importanant thing to note is that there are no one-size-fits-all solutions. It helps when gateway designers make as many options as possible configurable, so their products can be customized. We now discuss gateway services in more detail. Due to their complexity, we've separated the sections on address translation, file transfer and conversion, and directory synchronization into their own chapters, and they have already been discussed.

8.1 Main Interpersonal Message Conversion Problems For many people, e-mail means sending someone else a textual message—ie, for them it means interpersonal messaging or IPM. After that, people think of using email to move files around, which you might call interpersonal file transfer. Most readers will be aware that such informal person-to-person messaging is becoming a smaller proportion of the traffic in a messaging system. Other forms of message are proliferating. For example, structured forms and EDI messages, under the control of mail enabled applications, will flourish. By 1999, we guess that perhaps one message in 100 will be an interpersonal message; and perhaps one-hundredth of one percent of the total number of bytes transferred will be interpersonal messages. Nevertheless, it is very important to scrutinize the interpersonal messaging aspect of a gateway. For example, consider a PROFS user and a cc:Mail user who need to communicate via their X.400 backbone. A PROFS message has various special characters and is written in IBM's own character code, EBCDIC. A gateway connecting PROFS to the X.400 backbone must first convert the message and its

171 8 Gateway Services

header into an X.400 message, which is in ASCII. The message and its header is then converted into cc:Mail format by the X.400-to-cc:Mail gateway. The main things that go wrong

are: International Character Sets If you're international, you want messages to contain the special characters found in various non-English languages. They're frequently removed. Addresses themselves usually have to be in straight ASCII, so forget umlauts, acutes, etc.

Multiple Text Body Parts Most non-X.400 mail products have a single main text message and possibly one or more attached files. In X.400, there are multiple body parts, each of which can be of any allowable type. Thus, an X.400 gateway has to decide how to convert incoming multiple body part messages into a main-message-plus-attachments format. The way it chooses to do things can cause problems. For example, some X.400 gateways include information about attached files (name, size, etc) in a separate text body part. Users often prefer this information to be available in the message body rather than in an attached file that must be opened for viewing. Another example is where an Internet message goes through X.400 before arriving at a non-X.400 end mail system. The Internet has a mail routing body part separate from the message body part, but the two can end up being strung together (figure 8.2).

Special Characters, Embedded Figures, OLE Objects Any special character properties such as underlining, bolding, flashing, and colors will be removed. Any enclosed figures will be discarded. Regarding OLE objects: don't even think about it.

Fonts & Text Layout Even the blandest of text messages will have their appearance altered. The main things that cause this are: ® The message was prepared using a particular screen font; when it arrives at the recipient, it's viewed with another screen font. The message was prepared using a certain font size; when it arrives, it's viewed with another font size.

FIGURE 8.2 MULTIPLE BODY PART HANDLING immon ______

Sender: jjonesgqmail3.bigcorp.org Received: from bigcorp.org by dub-img-l.compuserve.com (5.67/5.930129sam) id AA09644; Wed, 27 Oct 93 16:04:45 -0400 Received: from qmail3.aero.org by bigcorp.org with SMTP (5 65c/6.0.GT) id AA03506 for [email protected]; Wed, 27 Oct 1993 13:04:32 -0700 Posted-Date: 27 Oct 93 13:09:37 U Message-Id: <[email protected]> Date: 27 Oct 93 13:09:37 U From: "Jim Jones" Subject: X.400GW paper update-part I To: 75300.3422gcompuserve.com

Subject: Time:12:56 PM OFFICE MEMO X.400GW paper Date:10/27/94 david -

Will get you the outline in 3 days .... Jim.

Incoming X.400 messages with multiple body parts may be crammed into a single message. A similar thing often happens with SMTP messages. Here, an Internet message has had its routing information inserted ahead of the interpersonal message. This means wading through gobbledygook before you can read the text.

• Tabs may have been expanded to spaces; or the interpretation of what distance a tab corresponds to is different at each end. • The systems have different places at which automatic word wrap takes place. • A gateway automatically inserts new line instructions at predefined locations. For most interpersonal messaging, these alterations are an annoyance, but ones that users can usually tolerate.

8.2 Address Translation See chapter 6 for a detailed discussion.

8.3 File Transfer and Conversion See chapter 7 for a detailed discussion.

173 8 Gateway Services

8.4 Tunneling Suppose a major corporation has two messaging systems from the same vendor, one in New York, and the other in Sydney, Australia. The corporation needs to connect the two systems, but a direct data link is too expensive. A good solution is to connect both systems to local public service providers. Since these providers are interconnected via X.400, there will be messaging connectivity between the two sites. The big problem with this approach is that the messaging content can be affected. For example, Janet, a user in New York, creates a message in rich text format (figure 8.3). Then she sends a message to Jim, a user in Sydney. The gateway in New York converts the message into ASCII, losing features such as underlines, bolded characters, colored text, icons, and an enclosed figure. At the receiving end, the gateway converts the message back from X.400 into the local format, but the message looks very different. What can be done about this? The answer is tunneling, also known as encapsulation. This is where the message, with all its special goodies, is crammed into a single binary file. It's then sent to its destination. As it passes through intervening gateways, the file isn't changed. When it arrives, matching software is required to unwrap the arriving file. In this way, things like underling, bolding, and figures arrive intact. Clearly, matching wrapping and unwrapping software is necessary on both sides. It

FIGURE 8.3 LIFE WITHOUT TUNNELING

To: Janet From: Jim To: Janet We 4U demur the From: Jim new awl enscreze development when We will discuss the you come on new engineering Friday. development schedule po not forget to when you come on bring a copy of the Friday. Do not forget to business plan. bring a copy of the Directions to office: business plan. Directions to _I L._ office: Norliwn Blvd.

Da pew. 1 Jerk:holt*

What Janet sent What Jim received

Non-trivial formatting is lost during conversion to and from X.400.

must have been supplied by the same vendor, because the internal format of the wrapped binary file is proprietary. As far as the X.400 backbone is concerned, the wrapped message is just another binary file. A number of vendors provide tunneling. Perhaps the most go-ahead is Novell, with its GroupWise product line. Microsoft gateways use tunneling a lot, too. cc:Mail provides a utility to wrap and unwrap messages, which allows developers to integrate their transport mechanisms transparently into cc:Mail networks.

8.5 Directory Synchronization A directory synchronization mechanism looks up the directories of the different mail systems, and maintains a central directory with all variations of all addresses. It then distributes subsets of the central directory to the mail systems, so that every user thinks every other user is on his/her own mail system. In an environment with Microsoft Mail and cc:Mail, all cc:Mail users would think that the Microsoft Mail users are cc:Mail users, and vice versa. This is a complex subject, and was discussed in chapter 5.

8.6 Notification Processing In the X.400 world, there are two classes of notifications: • Delivery or nondelivery notification indicate that a message was delivered or not delivered, respectively. • Receipt notifications or nonreceipt notifications indicate that the recipient read the message or did not read the message. Often, a gateway does not support either type of notification. That's clearly a significant problem and you need to check for this. If there is notification support, however, you need to check how it's working.

X.400 to Non-X.400 Processing First, suppose an X.400 user sends a message to a cc:Mail user, and requests delivery notification. The X.400 user, of course, does not need to be even aware that the message is going into a cc:Mail environment. The message is deposited into the cc:Mail user's mailbox, and a receipt notification is generated when it's read. The cc:Mail receipt notification comes back to the gateway, and must now be

175 8 Gateway Services

converted into an X.400 delivery notification. But this is not simple. In order to generate a well-formatted X.400 delivery notification, the gateway needs information present in the original X.400 message. Thus, there is an implied requirement that the gateway hold on to the original message, or at least to parts thereof. This makes the design of a gateway much more of a challenge: • It becomes necessary to be more careful about the necessary storage capacity on the gateway, since more information about messages is being stored in the gateway. • Security issues become more important, since now the information stored in the gateway can be compromised. • It becomes necessary to determine whether it is acceptable to lose information if a disk drive crashes. It may become a requirement to have redundant disc drives, together with suitable recovery software.

Non-X.400 to X.400 Processing Now let's look at what happens when a message is sent in the reverse direction. A cc:Mail user sends a message to an X.400 user. The message goes through the gateway and is received by the X.400 user. A delivery notification is then generated, and received by the gateway. Life is now easier for the gateway, because X.400 typically carries along a lot of information, including that needed to generate the notification for the cc:Mail user. The gateway generates the appropriate notification and sends it to the original sender. On the other hand, information can be lost. For example, X.400 delivery notifications have a file called Supplementary Information. This can carry information like the time it took to send a fax. There is no place to put this in a cc:Mail notification.

Transfers Over a Backbone Thus notifications over a backbone—where one non-X.400 system connects to another non-X.400 system, using X.400 as the interim format—are very likely to run into trouble, because at least one round of X.400 to non-X.400 connections are required.

8.7 Message Tracking In today's e-mail systems, the ability to query the system to determine the location and status of sent messages is not usually available. So when a message doesn't arrive on time, it's usually impossible to tell where it is. Or if you send an expenses statement to your boss, there's no easy way of telling whether the message has yet been forwarded to accounting. The lack of message tracking facilities is annoying, but with today's messaging systems, it's something most people can put up with. However, as mail-enabled and workflow applications become widespread, good tracking will become a requirement. To get a good feel for the sort of thing that's possible, we recommend a look at Novell's GroupWise (figure 8.4). A critical underpinning of message tracking is that each message can be uniquely identified. We won't go into the gory details of how this is done in X.400, but it's one of the things X.400 does particularly well. Every message receives an identifier that is attached to it at origination time. These are strings like: 1132FB1A29318035 Once attached, an indentifier stays with the message for the rest of its lifetime. Message identification mechanisms are also used in the non-X.400 world. How-

FIGURE 8.4MESSAGE TRACKING WITH GROUPWISE limmomm. ______

File Edit Dols Window Help Mail Envelope Information

Subject: Cross Platform Minutes -Reply Creation Date: April 14.1993 (Wednesday) 8-35 son From: Steve Vawdrey

Created By: WPCDEVTOFFICEistevev

Recipients Action Date & Time Post Office WPCDEV1.OFFICE Delivered Wednesday, April 14,1993 Paul (Paul Smart) Opened Wednesday. April 14. 1993 Replied Wednesday, April 1 4, 1993 Deleted Wednesday. April 14. 1993 Domain.Post Office Delivered Route WPCDEVI.OFF1DE Wednesday, April 14, 1993 WPCD EV1OFFICE

Files Size Date & Time MESSAGE 143 04/14/93 08:35am

Options Auto Delete: No Expiration Date: None Notify Recipients: Yes Priority: Normal

Novell's GroupWise has the strongest message tracking tools available today.

177 8 Gateway Services

ever, the problem for organizations building an X.400 backbone is: How are X.400 and non-X.400 message identifiers mapped to each other? In particular, while a typical non-X.400 message identifier is easy to map into an X.400 message identifier, the reverse is not simple. It almost invariably requires the gateway to maintain a mapping table. Further, such a table must be managed—at the least, operations staff must be able to query it, to determine what the mappings are. Recently, the EMA has been doing some good work to define message tracking between different systems. It will be some time until this becomes commercially deployed, and we refer the reader to chapter 11 for further discussion of this initiative.

8.8 Gateway Security

A good time to enforce security in many gateways is when addresses are converted, since addresses can easily be associated with access privileges. Generally, security in this context means determining who can pass messages through the gateway. An X.400 gateway is often a point where one organization's system touches another's. Thus, they are a useful way of enforcing: • Access to external services. In particular, the use of service providers to send e-mail and faxes can be limited. • Access from intrusion. You can restrict the ability to transfer messages to certain sender and recipient addresses. • Protection from junk mail. Messages from particular originators can be blocked from crossing the gateway. Registration to specifically allow or block messages from certain originators does not need a compete O/R address. For example, a particular gateway might allow messages only from originators whose X.400 addresses contain the attributes C=us; P=acme; O=sales This would allow users within the sales division of Acme Corporation to send messages through the gateway, regardless of which ADMD they used, since no ADMD was specified in the required attributes. Some vendors, such as Worldtalk and Lotus/SoftSwitch have tools to enforce security in this way. Generally, the technique is based on letting messages through the gateway if an O/R address matches a directory entry, or matches an administrator-defined pattern.

The main problems are: • A determined and technically knowledgeable intruder can fairly easily impersonate another originator. • It may rule out rules-based address translations, since some gateways require a full 0/R address in the directory in order to forward a message. Nevertheless, the technique is still useful, especially if the goal is cost control.

8.9 Auxiliary Element Conversion A message consists of a series of components. The main elements of course are the originator, the recipients, and the message body (the actual information that needs to be transmitted). Some are more obscure. For example, in an X.400 message, there is an element called authorizing users. This is rarely used. It is intended to be used when a person writes a letter or memo, has it authorized by another person, and then sends the message to the recipient. Now suppose that in a particular X.400 environment, authorizing users is used routinely, and that a message containing the element has to be sent to a Microsoft Mail user in another organization. The trouble is, Microsoft Mail does not support such an element. Several courses of action are possible. The gateway can: • Insert text indicating the presence of the element at the beginning of the converted message text. Eg, "This message was authorized by Jim Jones." This is likely to insert so much text at the beginning of the message that the recipient can be annoyed. You know the feeling if you receive an Internet message in a non-SMTP system, with a mass of routing elements inserted at its beginning. • Omit the element in the MS Mail message. In this case, the recipient will not be aware of the presence of the element. This may be acceptable in some organizations, but a show stopper in others. It prevents organizations from using many useful X.400 elements. • Put in text indicating the presence of the element at the end of the converted message. This can be a good compromise. But if there are a large number of such elements in an X.400 message, you can end up with very long messages. A recent trend we've spotted: Some gateways, such as the StarNine Technology's AOCE/SMTP gateway, let you choose where non-translating message elements

179 8 Gateway Services

should be put. In the StarNine case, you can specify, as a gateway-wide default, whether SMTP routing information should be discarded, or inserted at the front of a message, or at its end.

8.10 Special Character Handling Certain things are funny about X.400. They have deep-rooted technical reasons, but explaining them to non-specialists is like pulling teeth. They are perhaps best put as axioms. Anyway, none of the characters % ! " can occur in X.400 addresses, not even in DDAs. There are some other such characters, but these are the most important ones. Left and right parentheses can appear, but only in special prescribed ways. There's a standard way of handling these special characters, described in figure 8.5. These characters are important, because they often occur in non-X.400 addresses. They can occur in message headers, as well as in the main message body. The @ is often seen in cc:Mail, Internet, and NetWare MHS addresses. The ! occurs in every UUNET address, another non-X.400 messaging network running on top of the Internet.

DDA Handling The biggest cause of confusion is when non-X.400 addresses are mapped into DDAs. Figure 8.5's character mapping is applied, with some not-very-intuitive results. For example, you'd expect an X.400/SMTP gateway to map the address [email protected]

FIGURE 8.5 SPECIAL CHARACTER MAPPINGS IN DDAs

1.tatiielii.

0/0 per cent (p) ampersand (a) exclamation mark (b) asterisk (q) underscore (u) left parenthesis (I) right parenthesis (r) other (nnn)

nnn is a three character octal code representing an ASCII character.

into something like [email protected] Instead, you'll get something like DDA.internet=jsmith(a)acme.com Now, you can see the reason for the left and right parentheses in X.400 messages. They act as escape characters, to indicate that a transformation is needed. There- fore a real right parenthesis is converted to (r)

Currency Watch out for how currency characters—eg $, 0, and .6—are converted, too. Many gateways get confused by them.

8.11 Main Stand-alone Gateway Selection Criteria We now present the major things to consider when assessing an X.400 gateway used to connect to the backbone. Many of the points were discussed in depth earlier in this chapter, or in the chapters on address translation, file transfer and conversion, and directory synchronization, and in those cases we are fairly concise.

Address Translations Wherever possible, users should be able to look at mail addresses in the format of their end mail system—especially for correspondence within their organization. To do this, you should be able to use rules-based and table-based mappings. Pref- erably, you should be able to use both administrator-selectable and administrator- defined rules.

One-Off Addressing Check how easy it is to type in an X.400 address. For example, if a user has recently met someone and been given their X.400 address, the user should be able to mail them something by entering the X.400 address. The process should be simple.

Single Space ADMDs In chapter 2, we saw that sometimes one doesn't want to refer to an ADMD, and in this case you want to be able to set the ADMD value to a single space.

181 8 Gateway Services

Check how single space ADMDs are handled. Client software as well as gateway software will often ignore a single space, causing a parsing error. The invisibility of a space also creates problems.

Cost Figure in hidden costs like gateway and MTA software, computers to run the software, LAN and X.25 cards, modems, and communications links. In some cases, cost will rule out some of the possibilities.

Feasibility Some fine gateways simply won't work well in a particular customer environment, for reasons that are never clear. They may never get working, despite a week's work on site by a vendor system engineer. Or maybe messages get corrupted. Or maybe the gateway goes down unpredictably. The more a gateway has been tested for interoperability with other systems, the better.

File Transfer Check how well file attributes are being preserved when files are sent. The most important things are that users should be able to run the application that uses the file, and that the file name should be preserved. In the latter connection, check what happens to relatively flexible file names such as those of UNIX, VMS, and Macintosh systems, when they must be converted into a DOS 8.3 format.

Delivery Notification Gateways differ in how they define message delivery. In principle, X.400 delivery occurs when the message is successfully delivered to the recipient's message store. However, some X.400 gateways send a delivery notification when they receive an X.400 message and pass it to the end mail system, even though there are still several ways delivery to the final message store could fail. Also, when delivery fails, the failure notification should identify the message in question. This is not always the case. At a minimum, the failure notice should include the addressee, subject, date, and a unique identifier added by the X.400 gateway. The latter information is gibberish to users, but it can help troubleshooting. If at all possible, the failed message itself, together with attachments, should also be returned.

Boundary Conditions X.400 has a lot of high boundary conditions. For example, you can have large numbers of file attachments or of message recipients, and addresses can be made up of very long strings. Most end mail systems have tighter constraints. So what happens when an arriving message exceeds the end mail system's boundaries? Eg, if the sender's X.400 address is long, does it get chopped to the first 31 characters? Or are long text messages turned into attachments? Expect problems, and check how the gateway handles them.

Tunneling

Check if tunneling is supported between users of the same mail system. International Character Sets If you're an international organization, you'll want messages to contain the special characters found in various non-English languages. Addresses themselves usually have to be in straight ASCII, so forget umlauts, acutes, etc.

Multiple Text Body Parts Check how the X.400 gateway is converting incoming multiple body part messages into the main-message-plus-attachments format required by most e-mail systems. The way it chooses to do things can cause problems.

Performance Many gateways require a DOS machine to run in, and typically they can process around 500 to 1,000 messages per hour. Initially, a DOS-based gateway may be fast enough. However, if the traffic increases, you may need to move to a more powerful platform. Gateway vendors are beginning to offer more flexibility in this regard. Some gateways • Are being implemented on RISC processors • Can run concurrent sessions under a multi-tasking OS such as OS/2, UNIX, or Windows NT • Allow load sharing between separate gateway PCs

183 8 Gateway Services

File Size Limits X.400 gateways have limits on the size of message that they will successfully handle, typically in the range of a few megabytes. Since many users see e-mail as an alternative to file transfer using traditional methods (disks, FTP, etc), this may result in user dissatisfaction. The other side of the coin is that some gateways allow the administrator to set a size limit. You may need to do this, since large files can hog the mail system, and often stop other transmissions while they're being processed. Whatever the case, the limits should be determined for each gateway, and users advised accordingly.

Directory Synchronization Today, most PC e-mail products can coordinate addresses among different groups of users of the same system. That is, they can do internal directory synchronization. However, check the directory synchronization tools available when you're connecting end mail systems via an X.400 backbone. Packaged solutions are beginning to become available, from such vendors as Lotus/SoftSwitch and Worldtalk. Nevertheless, there's a good chance you'll have to implement some directory synchronization yourself.

Vendor Technical Support One problem with X.400 gateways is that they involve a wide variety of different concepts, from low-level data communications protocols such as X.25, TCP, and TP4, to high level ones like ADMDs, address mapping and chargeback mechanisms. We've yet to see a support person who didn't find some aspects new and confusing. Hence, it's important to have telephone access to vendor support staff. You want them to understand the gateway, what's involved in installation, and the nature of your environment. Unfortunately, with some vendors you end up talking to people who know less than you do.

integrated Administration Some gateways—notably those of Microsoft Mail and Novell's GroupWise—are tightly integrated with the end e-mail system's administration utilities. This makes for easier administration, less learning, and nice extra features. This is particularly attractive for autonomous groups of users who control their connection to the X.400 backbone.

Ease Of Installation As we remarked, there's a lot to learn when installing X.400. So the easier the installation process, the better. Gateways with integrated administration have a natural advantage in this regard.

Extensibility Most gateways lack a lot of useful features they'll presumably have in a couple of years. Things like user chargeback, or sending alerts to support staff, are often lacking. You may also have special needs that will never be accommodated by a product sold to many companies. In both cases, it's helpful if a gateway has some sort of user exit so you can write your own code.

Vendor Development Skills & Future Vision You want the gateway vendor to be good at enhancing their product. It should be able to keep up with: • Features of the end mail system. For example, when cc:Mail offered tunneling, cc:Mail-to-X.400 gateway vendors needed to support this. Another example is that X.400 has a rich set of delivery notifications; if an end mail system has its notifications improved, the gateway vendor should quickly develop corresponding support. • Evolving X.400 and X.500 standards, and other industry trends such as in-transit document conversion and virus checking. Vendors should also understand where the technology's going and be abreast of new developments, or they'll be at a significant development disadvantage. Assessing vendors in this regard is somewhat subjective, but nevertheless it's worth doing with them directly and with references. In our judgment, some vendors are markedly superior to their competition in this regard.

Commitment Finally, you will probably want to consider the risks that the vendor will go out of business, or drop the gateway line. Dangers lurk everywhere. Some better vendors are small firms living off investment capital, or at least not making money on their X.400 gateways. Some big firms like DEC could easily drop their X.400 products since their lives don't depend on it.

185 Chapter 9

9. External X.400 Connectivity

In this chapter, we discuss the details of how to connect directly to a trading partner, and how to connect indirectly via a public X.400 service. We noted earlier that X.400 is used in two ways: • As a means of connecting in-house messaging systems • As a means of connecting to external messaging systems In the latter case, we also noted that it's quite possible to create a direct X.400 connection between two organizations. For example, a major government department might put in a direct X.400 connection between itself and one of its major contractors. This is known as a PRMD to PRMD connection. However, when connecting to another organization's e-mail system, the normal thing is to connect to the public X.400 network via a public X.400 carrier or ADMD. This lets you: • Connect to other organizations' messaging systems. • Use special services, notably to send faxes, telexes, or cables. • Preserve the security of your in-house system. If you don't want people to connect directly into your systems, they can connect through your ADMD. The public X.400 network is made up of a series of different-but-connected public X.400 carriers, such as AT&T, British Telecom (in Great Britain), GE Information Services, MCI, Sprint, ArCom (in Switzerland), Telekom (in Germany), and so on. Provided your correspondents are similarly connected to the world-wide public network, you can then exchange messages.

187 9 External Connectivity

9.1 On-site Requirements To install an X.400 connection to the outside—whether directly to a trading partner or to an ADMD—requires putting in special hardware and software on your premises. Figure 9.1 shows a common scenario. Here a LAN e-mail system such as cc:Mail, MS Mail, or QuickMail stores all its messages on a file server. A gateway in a separate PC or Macintosh then converts between the proprietary format and X.400 format. Messages in X.400 format are also kept on the file server. An MTA runs in a second dedicated PC or Mac, and exchanges messages with the outside via X.25. A common variant is to have the MTA and gateway run in the same machine, under a multitasking OS such as SCO UNIX. Figure 9.2 shows how today's most popular backbone—mainframe-based Lotus/ SoftSwitch Central—usually connects to the external X.400 world. Lotus/SoftSwitch's X.400 gateway runs in a separate 386 PC attached to the mainframe. It converts between Lotus/SoftSwitch's internal message format and the X.400 format, and exchanges messages with the outside. An X.400 MTA is built

FIGURE 9.1 TYPICAL X.400 EXTERNAL CONNECTION immem______

File Message Server Store

User

User Synchronous Modem Permanent X.400 X.400 X.25 Gateway MTA Connection

A typical X.400 external connection. An MTA runs in a DOS box which is attached to a LAN. Separately, a gateway converts between non-X.400 and X.400 e-mail protocols into X.400.

FIGURE 9.2 CONNECTING A BACKBONE TO THE PUBLIC X.400 NETWORK

PROFS

Synchronous Soft Modem Soft Switch Permanent cc:Mail Switch X.400 X.25 Centra Gatewa Connection

Mainframe 386 PC

QuickMail

Here's how Lotus/SoftSwitch Central usually connects to X.400.

into the gateway machine, and this uses X.25 to connect to the ADMD. Physically, the X.25 service provides a wire from itself into the customer's premises. This wire connects to the X.400 gateway machine through a synchronous modem.

General Requirements Thus, to connect an e-mail system to the external X.400 network, you need: • A gateway converting any non-X.400 e-mail into X.400 • An MTA These two processes often run in different, dedicated PCs. As we noted, it's quite common to have them both running in a single PC running a multitasking OS. It's also possible to have them running in a multi-tasking environment along with other programs. For example, NetWare Global MHS lets you have gateway software and the MTA running in a single NetWare file server. To make the physical connection, you normally connect the MTA to X.25 using a synchronous modem. X.25 then acts as the link to your ADMD or trading partner. Depending on the MTA software you're using, it may also be possible to make the connection with:

189 9 External Connectivity

• Dialup connections and ordinary asynchronous modems • A TCP/IP connection (probably over the Internet)

X.400 Backbone Requirements Connecting an X.400 backbone to the outside X.400 world is simpler. You don't need a gateway, because everything's already in X.400. You simply have an MTA process, which connects outside via X.25; or more rarely, dialup or TCP/IP. Typically, the MTA runs in a dedicated PC, although as we've noted it could easily run in machines running another process. However, for the purposes of the rest of this chapter, we assume it runs in its own machine, and we refer to the MTA machine as the system/gateway box. If you're not using a dedicated machine, just drop the points that are no longer relevant.

9.2 Direct Connections To Trading Partners We now focus on direct links to trading partners using X.400. As we noted, there are three options: • The use of packet networks on both sides • Dialup connections • Connection over the Internet

Addressing We indicated in chapter 4 that X.400 addresses are ADMD-centric, and that each address has an ADMD name in it. But what happens where you're connecting directly, where there is no ADMD involved? You cannot simply omit the ADMD name attribute, since then the address is not valid, and X.400 software is likely to reject such messages. You have two choices: • Set the value of ADMD to a single space, or an X. As noted before, when using A=" ", verify that all systems, gateways, etc, involved can deal with it well. Use this approach if you are sure that the messages generated will never reach a public network, and be sure to test well before distributing addresses to your users. • You can use the name of an existing ADMD, even though the messages never go through that ADMD. This is likely to be a good choice if your system connects directly to a trading partner and also to an ADMD.

Making The Physical Connection Expect to use X.25 if both systems are already connected to X.25 networks, or if you have a lot of time- and security-critical traffic. For low traffic volumes, it is unlikely you will be able to justify setting up X.25 connections on both sides. For dialup connections, both systems should ideally use the APS protocol. Since this is only just becoming available, many MTAs don't support dialup connections, and those that do often offer a proprietary implementation. In the latter case, you'll need the MTA software at both ends to come from the same vendor. If you're using APS, be sure to check both systems are conversing properly. Finally, if you're using an Internet connection, be sure that adequate security procedures are in place.

Direct Connection Advantages • A direct connection can be cheaper than going through a public X.400 carrier. This is particularly likely if: 1) Two sites frequently exchange very large messages, or 2) Instead of going over an X.25 network, you use an Internet connection (figure 9.3). • A direct connection can be better from the security standpoint. You use voice channels rather than going through a service provider's comm room equipped with monitors, etc. Nevertheless, both are vulnerable to a determined intruder.

Direct Connection Disadvantages • If you are connecting to a large number of partners, it will be a hassle for your personnel to set up all the connections, perform interoperability tests when needed, and maintain connectivity to a large number of partners. You

FIGURE 9.3 TYPICAL ADMD MESSAGE TRANSFER COSTS

M*Asage: alas >;• • • •-..• • • ••••• ••• ••••• • >• ••• Cost.•

1st 500 characters $.50 2nd 500 characters add .10 1,001-10,000 chars. add .10/1000 chars > 10,000 characters add .05/1000 chars

MCI's message transfer charges as of November, 1994. Large messages going over an ADMD typically cost $20-$50/MB. Plus you may incur X.25 packet charges.

191 9 External Connectivity

are probably better off handing over that responsibility to a service provider equipped to deal with these issues. Then your personnel have only one connection to worry about, the one to your service provider. • You do not have the handholding provided by a service provider. This requires a higher level of expertise by your staff and that of your trading partner. • Security may be an issue if you are transiting over the Internet. The messages might be going through a competitor's system, and picking off interesting messages is trivial with a protocol analyzer.

9.3 Connecting To An ADMD

If you decide to use an ADMD, you must first figure out how to connect to it. Currently, you must do this via X.25. This is a relatively expensive technology, plus it's also somewhat specialized. Most computer professionals—including most messaging professionals—are unfamiliar with it. However, it should soon be possible to connect to ADMDs using conventional asynchronous dialup modems, using the APS protocol (chapter 3). Because of the cheapness and simplicity of asynchronous dial-up technology, together with the fact that so many computer people are familiar with it, this development should greatly encourage X.400 use. There is a third way to connect two X.400 networks: using the Internet. This approach is most important when connecting one's own X.400 network directly to that of a trading partner. However, at some point in the future, ADMDs may themselves offer connections over the Internet. It's not hard for them to do. Thus, as a practical matter today, there are usually two steps in setting up mail communications with the outside: • Select an ADMD • Select an X.25 carrier to connect you with the ADMD As we'll see, it often makes sense to buy the two services—X.25 and X.400— from the same company.

ADMD Selection Criteria In the US, there are many public X.400 services to chose from. In other countries, your options are more limited. If you don't know who they are or how to contact

them, ask the vendor of your in-house X.400 software (eg, an X.400 gateway you are considering buying). We now look at the main things which differentiate the various ADMDs. Even if you don't have a choice of carriers, it's worth thinking about these things, since being aware of them makes it easier to plan for unexpected pitfalls.

Correspondents' ADMDs The ADMDs used by your correspondents is important in the selection of ADMD: • If most of your potential correspondents use a particular ADMD, consider using the same one. • If you don't want to or can't use the same one, then you must make sure that your ADMD choice connects to the ones used by your correspondents. Many X.400 networks are now connected with each other, especially in the US (figure 9.4). The reliability of connections is good and getting better. However, as we have suggested, it's usually better to try to use the same ADMD as your correspondents. For example: • ADMDs may have different maximum message lengths. Messages going over the limit may end up in a special queue which has to be browsed by an operator. The operator might look at this only once every day or two.

FIGURE 9.4 US ADMD CONNECTIVITY

Ad- AT&T Bell MCI * Compu- Easy EMB- GEIS Graph- Info- MCI Pacific S p r i n t vantis South Serve Link ARC net net Bell Advantis 91 9V V V V V 1 1 1 I 1 :V AT&TT :::.,::::::::::::: V V i V V 1 V V V V V Bell South V V ::::::::: V V V MCI * V V V A V V V 1 V V CompuServe V V A V A A V V . EasyLink 1 V V V V :::::::::::::::::::: V V V I V 1 V / EMBARC V V A ,,, mii:::i i: i V V 1 GEIS V V I i :::.:::1;.:I:::::: V V V 1 Graphnet 1 1 Infonet V V V V v 1 ::::::::::::::: 9or V MCI V V V V 1 V 1 V V Pacific Bell V V V V V V 9 V Sprint V V V V V V V V V V 1

In the US, many ADMDs are directly connected. Source: EMA, 3/94 ∗ Formerly BT Tymnet. An A means the connection is announced.

193 9 External Connectivity

• When something goes wrong, there's a longer train of events to analyze, even though your ADMD will handle it all. • Sometimes a gateway between two ADMDs will stop working. This is a quality-of-service issue. ADMDs are rather reluctant to come forward when it comes to admitting this is possible. Since all correspondents, present and future, are unlikely to use the same ADMD, you do need to check that your prospective ADMD connects to the other ADMDs. Since ADMD-ADMD links are being added all the time, ask your prospective ADMD for its latest connectivity chart.

International Connectivity ADMDs have not yet worked out how to provide for multi-hop routing, where more than 2 of them are involved in message transmission. No technical problems are involved, it's simply that the firms concerned are squabbling about revenue sharing. This absurd situation reflects poor commercial judgment, but nevertheless it's a fact of life. As figure 9.4 above indicates, the US has good inter-ADMD connectivity. And indeed, many US ADMDs have connections with the main ADMDs in other countries. Obviously, provided the sender and recipient ADMDs are connected, messages will get through. However, many ADMDs outside the US have very limited connections to ADMDs in other non-US countries. This means that a lot of international traffic not going through a US ADMD probably won't get through. It's most regrettable, and in fact is an excellent reason to use the Internet in preference to the world- wide X.400 network. Thus you should be especially careful to check for connectivity with and among your international correspondents. Ifyou have operations in many countries, there's a good chance that people connected to one ADMD cannot get through to corespondents connected to another ADMD. Note that a few US based providers, notably Advantis, AT&T EasyLink, and Sprint, provide ADMD service in many countries. Companies concerned about international connectivity often sign up with one of them: it's better than the alternatives, but connectivity is still not as good as it ought to be. An ADMD doesn't have to have actual X.400 operations in these countries (figure 9.5). All it needs is: • An X.25 presence in the foreign country. • An MTA able to handle users with several country codes, e.g. C=us and

FIGURE 9.5 VIRTUAL MULTI-COUNTRY ADMD

ADMD'S MTA X.25 (C=us and Private network C=uk) MTA (C=uk)

Private MTA (C=us) Great Britain United States

To operate in different countries, an ADMD just needs X.25 connectivity from the different countries to its central location.

C=uk if it wants to handle American and British customers. It doesn't matter what country the MTA is located in. All that counts is that a local X.25 port can be used to connect to it. This approach can be attractive for organizations with users in several countries. A single vendor results in a number of benefits such as consistent billing, better troubleshooting, and lower prices.

Non-X.400 Services Provided By ADMD The types of non-X.400 services needed by an organization are an important consideration. For example: • An organization may need access to non-X.400 messaging services, such as telex, fax, or postal delivery. ADMD services in these areas vary. • Certain providers have EDI services, which may be useful if you're into EDI. • Suppose an organization needs a number of dialup users external to the organization to exchange messages with the organization's users. Suppose also that, for security reasons, the organization does not want these users to dial into its own systems. In this case, it may make sense to select an X.400 provider that also operates a user-friendly dialup service. External users use the provider's dialup service to communicate with the organization's users.

195 9 External Connectivity

Costs The main direct cost elements are: • X.25 access costs, both fixed monthly charges (leased line, port) and volume-dependent packet charges. • X.400 message fees. • The cost of non-X.400 services (telex, fax, EDI, etc) accessed through an X.400 interface. • Fixed monthly service charges. • Initial setup charges for the X.25 circuit and the ADMD connection. The costs of running tests should also be included. • Special services, like customized billing and MTA management (see Ancillary Services below). In some cases, hidden costs not directly related to X.400 may be substantial. We don't have a watch-out-for-this checklist, but examples are: • An X.400 provider with good prices may not be able to provide you with a connection point close to your site. The cost of a dedicated line halfway across the country to connect in may make that provider more expensive than others. • A service provider may require that you go through several weeks of exhaustive testing before it will let you connect to its production system. This translates to personnel costs, plus the cost of the leased line during testing. • Remember that the time your personnel spend administering the connection is also a cost factor. Note that there are interesting opportunities for negotiating with an ADMD. If you can generate more than 1,000 outbound X.400 messages per month, many carriers will offer large discounts. Some companies we spoke to told us they were getting 80% discounts, because their ADMD expected greatly expanded traffic in the future. Not surprisingly, many carriers' contracts require that you don't disclose the terms with anyone else. Conclusion: when it comes to tariffs, brush up your negotiating skills.

Installation Support You will likely need a good amount of handholding during the setup phase and first few weeks of service, encompassing: • Initial X.25 and X.400 connection and setup. • X.400 interoperability tests. These should ensure your system performs adequately (ie, is really X.400-conformant), and verify your configuration settings.

• End-to-end tests with your in-house non-X.400 systems, such as cc:Mail or PROFS/OV.

Post-Installation Support You need to consider the support you get after installation. On the surface, all service providers provide similar support. They will take a call and investigate a problem. They will trace a message for you, even if they have handed the message to the recipient's ADMD. It's worth checking on the quality of support that will be provided. Some of the questions to ask are: • Will I immediately get an operator who is specialized in X.400 ? • Will an X.400-specialized operator be available at all times (7 x 24 x 365)? • Does the service provider have an infrastructure to quickly troubleshoot both network (X.25 and dialup) and X.400 problems (session cannot be established, protocol violation, etc)? In the case of an ADMD in another time zone, such as in another country, you should also ask: • Will I get—during business hours in my time zone—the same level of support that the service provider gives during business hours in its time zone?

Education It may be necessary to educate your trading partners on the benefits of messaging, and give them the confidence they can implement it. For example, major retailers have hundreds of suppliers, most of whom have no external e- mail communications. Many don't even have an in-house messaging system. To successfully implement X.400, some user organizations have organized a telemarketing team that contacts suppliers by letter or phone, and explains the benefits. If you don't want to provide the telemarketing staff yourself, some ADMDs, such as MCI and Advantis, can provide them for you.

Technical Support for Trading Partners Sometimes a trading partner finds it hard to get support from its in-house IS group. Also, if the trading partner is a small organization, its in-house IS skills may be very rudimentary. In either case, you may have to provide installation, maintenance, and training support. Sometimes your ADMD can help.

197 9 External Connectivity

Billing To help chargeback to user departments, you may need your invoice in a particular format. For example, you may want it on floppy disk, or as an e-mail message containing a spreadsheet, or on paper but with totals sorted by end user. Some service providers are more accommodating than others in this area. Billing options are particularly weak when you have to go through an ADMD's own gateways, eg, X.400 to telex. Consider this last case. The billing record is typically generated by the telex delivery system. In many cases, the telex delivery system was built long before X.400 came along, so it can't capture the originator's X.400 address, needed for billing. Therefore, the service provider needs to consolidate the billing record generated by the telex system and the billing record generated by the MTA (containing the X.400 details). This consolidation is often hard to do. Hit is not well organized, you get either a telex bill with no originator information, or a bill with no telex details. So ask for invoice samples, and ask about the formats and levels of detail that can be provided. Some providers will provide additional details for an extra charge.

Ancillary Services Sometimes X.400 carriers offer ancillary services. For example: • They may offer alternative delivery mechanisms if your MTA is down for an extended length of time. You should consider this if you are running a PC based MTA with no configured spare available at all times. • To ensure your MTA is working properly, the ADMD may send it periodic messages and then track the corresponding delivery notifications. If they do this, they may know when your MTA is down before you do. So it's worth finding out about such extra services, and what they cost.

9.4 Selecting An X.25 Carrier We start with a quick X.25 backgrounder.

X.25 Primer X.25 or packet networks let two computer systems transfer data between each other. Connections are set up only when necessary, and last only as long as required. In

other words, X.25 provides on-demand connectivity between two computers. Normally, the computers are geographically separated, so X.25 is a way of providing WAN connectivity. It's used for many purposes, only one of which is to carry X.400 traffic. Telephone companies are the main providers of X.25 networks, and they've linked their networks to form a world-wide X.25 network, in much the same way as they've linked their phone systems to form a world-wide telephone network. Thus with X.25, you can connect two different computers, even though each computer connects to a different X.25 service. Systems connect to each other by indicating the DTE number they want to connect to. A DTE number is similar to a phone number, and contains up to 14 digits.

Points of Presence X.25 network operators provide points-of-presence or POPs, which are places where users can connect into the network. A large network operator may have POPs in hundreds of cities in many countries. To connect to an X.25 network, you need a dedicated telephone line from your computer system to your selected X.25 network provider's POP. It is easy to see that this can be cheaper if your provider has a POP in the same town. And now for the final twist. Even though on-demand connections are made to other computers, the actual connection from your computer to the carrier's POP is a dedicated one. It's permanently available. It can be used at any time for connections between your various systems (whether messaging or otherwise), and external systems. In other words, the line is shared between many different applications, and connections to your X.400 ADMD will just be a part of the overall mix.

X.25 Advantages Thus, use of a public X.25 network to connect two geographically separated computers is an attractive alternative to putting in a dedicated link between them, or running your own X.25 network: • It's usually cheaper, since the resources within the network are shared with other customers of the network. • You don't have to maintain the network. As a result, some carriers, such as Sprint and AT&T, have built large international networks.

199 9 External Connectivity

Use With X.400 So how does X.400 fit in with X.25? As far as the X.25 network is concerned, it doesn't care about the meaning of data being transferred over it. When you use X.25 to send a message from your system to an ADMD, the following occurs: • An MTA on your premises links to its X.25 network (figure 9.6). • It "dials up" the ADMD's MTA, using its DTE number. • If the receiving MTA is on a different X.25 network, connections are set up between the different X.25 networks so as to create an end-to-end link between the sending and receiving MTA's. • The MTAs transfer the message. • When transmission is complete, the link is closed, increasing the bandwidth available to others.

Costs On the cost side of an X.25 connection, there are three main components: • Installation fees, which may include the cost of installing the leased line into the X.25 carrier's POP, and the cost of special modems known as CSU/ DSUs. • Fixed monthly fees, such as port charges, and leased line charges from your premises to your network provider's POP.

FIGURE 9.6 X.25 PROVIDES ON-DEMAND LINKS

One Provider's X.400 System Your (Packet X.400 System Leased

/ Line Network) Leased Other line Provider's connection X.400 always These System present connections present only during message transfer

X.25 is used to connect computers at different locations. It's shared with many other organizations, so often works out cheaper than an in-house network.

• Usage fees, sometimes called packet charges. These depend on how much traffic you passed over the circuit. The fees vary from country to country, but in the US, companies typically pay between $500 and $3,000 per month for an X.25 service if it's brought in specifically to support X.400. These fees are significant. They can kill a project unless either there is a lot of traffic, or unless the link is perceived by management as of central importance to its business. (But note the immediately following Tips on Reducing Packet Charges). Cost justification is much easier if an X.25 connection is already in place. In this case, ADMD connectivity is seen as an add-on, and messaging use takes only a proportional share of the monthly fees.

Tips on Reducing Packet Charges • You'll be charged a monthly fee for the dedicated X.25 line connecting to an ADMD. This can be a few hundred dollars a month, and may make access for a smaller installation unfeasible. For a large account, the service provider may be willing to absorb such cost. • Generally, packet networks apply a monthly port charge as well as per packet charges. If you establish a connection to a service provider to gain access to its X.400 network, you can often get such charges waived. • Suppose you set up a packet network connection for X.400 connectivity, and later use the same circuit for other, non-X.400, connectivity. It's good to clarify in advance how much you will be charged, and whether the service provider will limit packet charges to the non-X.400 traffic. • You may already have access to another provider's X.25 network. In this case, find out if your X.25 network and your potential X.400 provider's X.25 network are connected. If so, you may be able to use the existing connection, resulting in significant savings. • As they become available, dialup connections to ADMDs using the APS standard will lower many organization's connection and usage costs substantially.

Selection Considerations

We now turn to some pointers regarding which X.25 network to use. When To Get X.25 From Your ADMD Above, we said that most X.400 service providers offer an X.25 network service, but you can actually choose separate X.25 and X.400 services.

201 9 External Connectivity

However, it usually makes good sense to use the X.25 service offered by the ADMD you select, because: • The carrier will give you financial incentives to do so. For example, they may waive the X.25 packet charges or offset some of the X.25 port charges against your X.400 invoice. • You have one less entity in the loop. If something goes wrong, only one company troubleshoots both the X.25 and X.400 services. • At setup time, you have less coordination to do. One provider coordinates the leased line installation, X.25 service setup, and X.400 connectivity.

When To Have Different X.25 and X.400 Carriers The times when it makes sense to have different X.25 and X.400 carriers are: • You already have a connection to another X.25 provider from the site where your X.400 system is located, ie, you are already paying for the most significant cost, the dedicated line from your site to the carrier's POP. • You already connect to an X.400 service provider, but need to connect to a second one, perhaps for redundancy reasons. If one ADMD fails, you route message traffic over the other. In either case, one important consideration is that two different carriers are involved, with all the attendant difficulties of determining where problems lie. When something goes wrong, someone has to be able to definitively assert whether the problem is an X.400 problem or an X.25 one. This requires substantial further expertise in your staff.

9.5 Installation Planning We now discuss the major installation tasks, summarized in figure 9.7. You have to make sure that you plan these well, including time frames, because: • Some steps simply take time. For example, if you need the phone company to install a dedicated line for X.25 access, it will take 30-90 days. This is the case even if your X.25 provider orders the line on your behalf. No sense planning X.400 tests for next week, if the line is not in for another six weeks. • Users get impatient when glitches occur after introduction of service. You should in particular plan for thorough testing and a sufficient pilot test period. You also should manage expectations about which service will be available when. • If the leased line becomes available a long time before you are ready for

FIGURE 9.7 ADMD CONNECTIVITY INSTALLATION STEPS

Plan the installation steps & schedule Order line and equipment Configure system/gateway box or software Test X.25/Dialup/TCP-IP link Initi al X.400 tests Tes t PRMD-ADMD interoperability Configure MTA directory Stress testing Train help desk and operations Pilot Support trading partners as necessary Train users Cutover (not a step as such) Post-production support

Once you've chosen your ADMD and the connectivity products, these are the main ins tallation steps.

X.400 tests, you are paying for the line for no good reason. If the leased line is not available when you are ready to start testing, you are delaying the whole process.

Hardware & Software Checklist First, check you have all the equipment you need. We assume you'll be using X.25 rather than dialup or TCP/IP. Hardware includes: • Computer equipment needed to operate the system/gateway box, including required LAN network interface cards. • A synchronous interface card in the system/gateway box. • A synchronous modem which sits in-between the synchronous interface card and the X.25 line. • Cabling to connect the system/gateway to your in-house systems, most likely via a LAN. Software items include: • All software supplied or required by your X.400 vendor, such as MTA, gateway, and management software. • Device drivers. In particular, you need drivers for the X.25 interface card and the LAN network interface card.

203 9 External Connectivity

• Diagnostic software, to check out the LAN and X.25 connections, and analyze the status of system/gateway vendor supplied software. There may also be environmental items: • An uninterruptible power supply, to survive power outages in a graceful manner and with minimum damage. • Space. If you need your system to be in a special-purpose computer room, make sure that you have the space allocated, with X.25 and dialup lines terminated close to the X.400 system.

• Racks for the equipment. Use

A Step-By-Step Approach

There are many gotchas that take a long time to iron out, in particular if you are unfamiliar with the environment. If you are using a PC-based system, you need to make sure that you don't run into subtle incompatibilities of equipment or software supplied by different manufacturers. You need to verify that you have the necessary device driver versions. In particular, instead of configuring everything all at once, you should configure and test each component using a step-by-step approach. The main components to test like this are: • Operating system • LAN connectivity • Communication links, modems, and X.25 lines • Messaging software configuration • Basic messaging software • Gateways (one by one) • Full messaging software, under heavy load and high throughput • Additional applications, eg, billing If you configure incrementally—strictly step-by-step—problem resolution will be much easier when things go wrong. Also, if you have to call a vendor's help line, it will be much easier to describe the problem, since the step-by-step approach simplifies problem description. It's often helpful if your system vendor pre-configures and pre-tests the hardware and software for you.

9.6 Major Installation Steps We now describe the installation steps of figure 9.7 above in more detail, and provide advice on major do's and don'ts.

Order Line & Equipment You need to figure ahead of time what you need to operate the system. Some items have long approval or delivery times, so it is important to plan ahead to make sure it is all ordered and available when you need them. Consider: • Hardware. Computers, and computer extensions such as additional memory, modems, X.25 interface cards, etc. Also order all cables, connectors, and patching equipment. • Software. Your X.400 vendor may assume that you have some off-the-shelf software, such as a particular operating system, or remote troubleshooting software, or drivers that come with a particular X.25 board. Find out exactly what you need. • Communication links. You may need X.25 lines, telephone lines for modem and fax card connections, and LAN connections. A dedicated line may take 30 to 90 days to install. • Environmental factors. If you keep your communications equipment in a special datacomm center, reserve space for the new equipment so you know where to install it when it comes in. If you need to order an uninterruptible power supply or special racks to hold your equipment, make sure it is all ready before you start testing.

If you skip any of this, you may have to interrupt or postpone your tests

later on. Configure System/Gateway Box or Software First, you need to put all the necessary boards into the system/gateway box. Then, make sure that the operating system works well, and has all the necessary drivers configured. If the system is on a LAN, make sure you connect well to the LAN, with access to all the servers.

Test X.25/Dialup/TCP-IP Link Once your system/gateway box is properly configured, you set up and test data communications links to your ADMD or trading partner. When you install the X.25 card and drivers, before going out to the network, you may want to run some "back-to-back" tests, ie, interconnect two systems next to

205 9 External Connectivity

each other with X.25 cards and get them to talk to each other without an intervening network, assuming the necessary hardware and diagnostic software is in place. Then connect to X.25 addresses across the network. Your X.25 provider should be able to provide test numbers to connect to. Follow a similar course of action for dialup and TCP/IP connections. Such testing will tell you whether basic connectivity is working, without the added complexity of X.400 protocols. To verify basic connectivity, you may need special tools, such as line monitors or programs to connect as a terminal across an X.25 network. Vendors can often provide assistance in this area. Sometimes, monitoring or trace tools are built into the software, and vendors can tell you how to activate them and inte rpret the results. In some cases, such tools allow you to collect troubleshooting information for later analysis. The vendor's technical support personnel can then use this to solve initial connectivity problems.

Initial X.400 Tests On ce you know that your X.25 (or TCP/IP or dialup) connectivity is working well, you can try establishing X.400 connectivity. We suggest testing and debugging as follows: • First, send a simple message, even if to a wrong address. You just want to see the message being accepted by the other system. • Then send a message to a valid address. • Then test that you are receiving notifications. • Then try to send a single message to two or three addresses. Do the steps one by one so you can easily pinpoint a problem when it occurs. Sending the first few successful messages will probably take longer than you think. It's especially tricky if messages must go through gateways, and address translations must be negotiated.

Test PRMD-ADMD Interoperability When messages are being exchanged successfully with your ADMD, you need to go through interoperability tests with the ADMD. These tests have two purposes: • To ensure your software conforms with the X.400 recommendations • To verify your system setups If you use a popular package, such as one from Lotus/SoftSwitch or DEC, your ADMD may have already tested the software for conformance with another cus-

tomer. In this case, the tests may be abbreviated, and the primary purpose shifts to the verification of your setup. The ADMD will assign you a contact person and probably a time to start the tests. Generally, before starting, the ADMD will send you a description of the tests they want to perform. The length and complexity of the tests varies from carrier to carrier. Some ADMDs are content when a few messages can be exchanged, others want to run numerous tests, each verifying a particular feature. The duration of these tests can be anywhere from two days to two weeks, although the process is not a full-time occupation.

Configure MTA Directory You have to configure the receiving MTA so that it knows how to route messages arriving from the ADMD. In certain circumstances, the task can be fairly trivial. For example: • You might have a fully populated master directory (see chapter 5), and the MTA which connects to the ADMD may be able to use this. • The receiving MTA may simply route all messages to a central routing hub. However, these circumstances don't usually apply. And even if they did, most organizations want to have a complete definition of all valid users at the receiving MTA, so it can reject invalid messages or ones conflicting with security constraints. As a practical matter, what you often have to do today is: • Define X.400 addresses for all employees. • Define routing for all employees. Frequently, this means defining the gateway queue in which messages for a given recipient should be placed. In the ideal world, all this would not be terribly time-consuming. The information would already be in a directory, and the receiving MTA could use the directory to determine whether the recipient address is valid, and where to send the message to. However, directory-based routing is not yet common, as we have noted separately. Thus, configuring the MTA directory can be a big issue for larger organizations, since it is not feasible to enter 20,000 users manually. Two techniques can be used: • You can write programs to load data from an external database, such as a human resources database, or a payroll file. • Hopefully, you can use rules-based address translation to generate X.400 addresses from the native addresses of non-X.400 users.

207 9 External Connectivity

If these won't work for you, you're stuck with a major job of manually populating the MTA's dirctory. This, by itself, may render your game plan unfeasible, so be sure to address it at a early planning stage. Note also that if you are generating data from several sources, such as PROFS and cc:Mail, plan to handle • Duplicates, if users are registered on two systems • Collisions that occur when two users have the same name

Stress Testing Once the connection is working, you should do more exhaustive testing. This includes working with users to test with typical messages they expect to send. Look carefully at exception conditions; see the next section, entitled Stress Testing, in this chapter for the main things to check.

Train Help Desk & Operations Before connection date, your support staff should be thoroughly familiar with the software as well as with troubleshooting procedures. The main thing to educate them on are: • How to use the tools that come with the X.400 part of your messaging system, and how to interpret the connecting MTA's logs. • How to trace messages within your in-house messaging network. • How to contact the ADMD by telephone and e-mail, and what information to give the ADMD when contact is established. • Performance requirements—notably, how quickly messages and notifications should be delivered—and escalation procedures. Staff should understand that when they contact an ADMD, they should be prepared to provide: • Your site's connectivity information, including X.25 addresses, X.400 MTA IDs and passwords. • If the problem is related to a particular message, message information, such as message ID, date and time, sender's X.400 address, and recipient's X.400 address. • Other information your service provider may require. You'll also need to train staff on how to differentiate between X.25 problems (eg, cannot connect to the MTA) and X.400 problems (eg, bad recipient address). This is par t icularly important if your X.400 provider is different from your X.25 provider.

Pilot Some organizations formalize the users' involvement by performing a pilotproject, or beta test. Whatever the name, the concept relies on getting initial users involved. These are people who tend to do unusual things and who are interested in providing feedback. They understand that things may go wrong during a beta test. Typically, the pilot is accompanied by many related activities, such as making sure that directories work OK and are getting populated correctly, that maintenance routines (directory synchronizations, message store backups, periodic outdated message purges, etc.) are being performed correctly, and so on. It's important to get the help desk working smoothly, and publicize its phone number in advance of the system becoming fully operational.

Support Trading Partners As Necessary As we noted in the section describing ADMD selection considerations, you may need to educate trading partners on messaging benefits, and give them help as necessary to implement connectivity.

Cutover & User Training After the beta test is completed, the system is said to be in production. The step from a beta test to a production system is called cutover. Around or shortly after cutover, distribute information to users on how to use the connection. Things to include are: • How users can address correspondents from their own e-mail system. • How correspondents can send messages to your users. Tell your users what their own X.400 addresses are. • How your users can call an operator to find out how to send a message to a particular correspondent, to report a message-related problem, register a correspondent's address, or update their own registration. • What notifications mean. In users' home e-mail systems, they typically mean the user has opened a message. For messages exiting to the outside world, a return receipt may merely mean that the message has been put into the recipient's message store or that it has been delivered to a fax machine. The recipient may not even be aware that there is a message waiting for him or her. You also need to determine how to disseminate information on how to use external X.400 connectivity. The following methods are often useful: • Distribute printed pamphlets, newsletters, etc. Try to keep them simple and

209 9 External Connectivity

to the point. Put them in a format that allows users to keep some information handy for later reference—this can reduce the demands on help desk operators a lot. • Organize classes. One- to two-hour hands-on classes are probably best. Stay away from long classes. • If applicable, you may want to send e-mail messages to advise users of new capabilities. However, stay away from this if your users already suffer from email overload.

• Distribute definitive electronic or printed manuals for your power

users. Post-Production Support Users who do not participate in the beta test start using the system when it is in production. It is not unusual to sign them up gradually in order to minimize inconvenience should something go wrong. It is important to remember the following for a production system: • Schedule periodic housekeeping tasks, such as backups and directory synchronizations, to run in the early hours of the morning. • Make sure your help desk is operational, and that everybody knows its phone number. • If appropriate, publish pamphlets, manuals, etc, to ensure that users can use the system efficiently and to its full extent. If appropriate, you can distribute these as e-mail messages. When X.400 transmission problems occur after cutover, your ADMD is the main point of contact for external troubleshooting. This is so even if you suspect that the problem lies elsewhere, probably in a connected ADMD or in an end PRMD. For example, suppose your ADMD is MCI. You sent a message to an ATTmail user, and you have a question about the message. You should call MCI even though you think the problem was caused by ATTmail. MCI will do the necessary investi- gation and get back with the results. Be aware that the amount of X.400 technical expertise varies a lot among providers. A knowledgeable support person that understands the technology is worth a lot and is not common.

Reminder: Vendor Support As we discussed earlier, many ADMDs offer installation services. If this is your first X.400 connection, you may want take up the offer.

Typically, a member of the vendor's staff installs the first connection and performs initial testing. This may include testing from non-X.400 mail systems (eg, cc:Mail or PROFS/OV). As we noted, some ADMDs can also help educate trad i ng partners on how to contact you via X.400. Sometimes they can also pro v ide technical help to less sophisticated partners.

9.7 Stress Testing He r e, we present the main things that go wrong. Test for them particularly carefully. Some of the points were also discussed in the chapter on X.400 gateways, but we repeat them here for the sake of clarity. Readers planning an exhaustive battery of tests may want to get a copy of Message Handling Systems Interoperability Tests, published by the US National Institute of Standards and Technology (see bibliography).

Ad d ress Transparency Check that wherever possible, users can look at mail addresses in the format of the ir end mail system.

On e -Off Addressing Check how easily users can send mail to someone outside the organization who isn't already defined in some sort of mapping table or algorithm. The issue here is: How easy is it to type in an X.400 address? Verify the addressing alternatives: using a form, entering the address into the TO: line, and using inline addressing.

Single Space ADMDs As we discussed, there are moves to make X.400 addresses carrier-neutral, notably by allowing the ADMD to be a single space, or an X. Also, the Internet pilot X.400 project uses a single space as ADMD value. If you're connecting directly to a trading partner, single space ADMDs can cause a problem and should be checked. Client software as well as the gateway software will often ignore a single space character, causing a parsing error. The invisibility of the space also creates problems: there are various workarounds, but they tend to be unwieldy. If you're getting single space problems, the answer is probably to make the ADMD equal to X.

211 9 External Connectivity

Delivery Notifications In principle, X.400 delivery occurs when the message is successfully delivered to the recipient's message store. However, some X.400 gateways send a delivery notification when they receive an X.400 message and pass it to a non-X.400 end mail system, even though there are still several ways delivery to the final message store could fail. For example, if an X.400/fax gateway generates a delivery notification when it passes the message to the fax delivery unit, it has no assurance that the phone number is correct or that the fax machine has sufficient paper to receive the message. So you should: • Check the delivery notification messages sent back in response to incoming mail, where the recipient is on one of your non-X.400 systems. It may be seriously misleading. • Check the delivery notification messages received by users of your non- X.400 systems when they send mail into the public X.400 network. Also, note that when delivery fails, the failure notification should identify the message in question. This is not always the case. At a minimum, the failure notice should include the addressee, subject, date, and a unique identifier added by the X.400 gateway. For user convenience, the failed message itself should also be returned, preferably with attachments. ADMDs don't charge for messages that have not been delivered. Hence they don't typically return attachments, which can easily be in the megabyte range. Right or wrong, you can see their point. So it's advisable for users to keep a copy of all messages they send to the world outside.

Boundary Conditions X.400 has a lot of high boundary conditions. For example, you can have large numbers of file attachments or of message recipients, and addresses can be made up of very long strings. Most non-X.400 e-mail systems have tighter constraints. So you need to check what happens when an arriving message exceeds the end mail system's boundaries. For example: • A user may routinely send messages to a very large number of recipients. • A user may include a large number of attachments into his or her messages. • If an incoming message has a long X.400 address, and it's then passed to a non-X.400 end messaging system, does the sender's address get chopped to the first n characters, where n is, say, 31?

• Are long text messages turned into attachments? This can be inconvenient for users. Amazingly, some providers consider anything above 10,000 characters long!

Tunneling Normally, special goodies of a non-X.400 mail system—things like text color attributes, attachment names and icons, etc—are lost when they go through an X.400 gateway. However, some X.400 gateways will allow messages to be passed with no loss of fidelity, provided you have the same X.400 gateway and the same mail system at both ends. As noted elsewhere, this is known as tunneling or encapsulation. A growing number of X.400 gateways offer this feature, including those of MS Mail/PC and Novell GroupWise. You may have users who are corresponding with people using the same non-X.400 e-mail package, and who expect perfect pres ervation of the messages. In this case, you'll need to check whether tunneling is taking place.

International Character Sets If you're international, you'll want messages to contain the special characters found in various non-English languages. Addresses themselves usually have to be in straight ASCII, so forget umlauts, acutes, etc.

Multiple Text/Body Parts X.400 allows multiple body parts. If incoming X.400 messages are distributed to users of a non-X.400 system connected to your backbone, problems can arise because most non-X.400 mail products have a single main text message and possibly one or more attached files. Thus, your X.400 gateways have to decide how to convert incoming multiple body part messages into a main-message-plus-attachments format. The way they choose to do things can cause problems. For example, some X.400 gateways include information about attached files (name, size, etc) in a separate text body part. Users often prefer this information to be available in the message body rather than in an attached file that must be opened for viewing. Another example is where an Internet message goes through X.400 before arriving at a non-X.400 end mail system. The Internet has a mail routing body part separate from the message body part, but the two can end up being strung together.

213 9 External Connectivity

Per formance Initially, a DOS-based MTA may be fast enough to connect you to the ADMD. These can typically handle around 500 to 1,000 messages per hour. As traffic increases, you may need to move to a more powerful platform. Run tests to determine the maximum capacity of your MTA and link.

Large File Attachments Check what happens to large files being sent to or received from the public X.400 network. Many ADMDs limit you to 2MB files.

9.8 Virtual PRMDs Finally, we describe a very simple way of connecting non-X.400 systems into the public X.400 network, that also has very low up-front costs. We call this approach a virtual PRMD, for reasons that will be apparent shortly. MCI's REMS (stands for Remote Electronic Mail Systems) service is the best known example, although other ADMDs such as CompuServe, GEIS, Mercury, and Sprint offer similar services. What happens is that your non-X.400 system, say cc:Mail, connects to a messaging service provider using its normal MTA-MTA dialup (figure 9.8). That's very simple for the people supporting the non-X.400 system, and involves little cost. In some cases, you also install some special MTA software provided by the messaging service. The service provider then has a similar MTA that receives the message, and puts it in storage. Then a gateway between X.400 and the non-X.400 system converts the message, and an X.400 MTA then connects to the world-wide X.400 network. In other words, what's happening is that the messaging service is providing X.400 connectivity for you on its own premises. To the outside, your messaging system appears to be a PRMD. If you're a user of the non-X.400 messaging system, you can now send and receive X.400 messages. Your X.400 address won't be as simple as it could be; it'll probably be something like: G=john; S=smith; A=mci; C=us; DDA:EMS=acme; DDA:MBX1=Smith, John @ SFPO

Since this is rather unwieldy, the service provider will often provide an alias, reducing the address to something like:

G=john; S=smith; A=mci;

C=us Pricing One of the big strengths of the virtual PRMD is that it has low up-front costs. We illustrate with the charges associated with MCI's REMS service: • There's an annual fee of $100 for every non-X.400 system connected. • There's a $10 annual fee for every X.400 address for which you need a more user-friendly alias. • Apart from that, you pay only per-message charges. In the US, these are likely to be around 75,$ for a 2,500 byte message, and $30-$50 for a 1MB message. We now look at the advantages and disadvantages of using a virtual PRMD compared to installing your own PRMD.

Advantages • It's easy to understand what's happening. Almost no specialized X.400 and data communications skills are required.

FIGURE 9.8 VIRTUAL PRMDS 10 1

Your Network eg cc:Mail Messaging Carrier, eg MCI Mail

Message Store Dialup Line World- Non-X.400 X.400 X.400 Wide Messaging MI MTA Gateway MTA X.400 System Asynch Asynch Network Modem Modem Non-X.400 Messaging System MTA

A virtual PRMD is where a messaging service provides X.400 connectivity on its own premises. Almost no special skills are required, and the up-front costs are minimal.

215 9 External Connectivity

• Installation is very simple. It's only necessary to understand how to configure a dialup session with your normal (non-X.400) MTA. The service provider gives additional handholding as necessary • Day-to-day maintenance is simple. No special skills are required. • The up-front incremental costs are minimal. At worst, they are the cost of a dialup modem, PC to act as MTA, the cost of a new dialup line, the cost of any special MTA software, plus a small sign-up fee per user.

Dis advantages • Users may be stuck with unwieldy X.400 addresses. • You have minimal control over how the X.400 gateway converts between your non-X.400 system and X.400. • While virtual PRMDs work pretty well for interpersonal messages and interpersonal file transfer, mail enabled applications requiring precise formats will get confused. Eg, don't try transmitting EDI messages this way. • There can be scalability problems. Maintaining aliases for 100 users is one thing. Maintaining them for 10,000, with an average of 40-50 changes per day, is another.

Summary Virtual PRMDs are very attractive in certain circumstances: • When the capital costs of putting in your own X.400 PRMD are too high • When you don't have the required X.400 and data communications skills • When you plan to put in your own PRMD, and need X.400 connectivity on an interim basis • When you only have a limited amount of X.400 traffic

10. Messaging Support Tasks

In this chapter, we present a checklist of tasks involved in supporting a messaging sys tem. The intention is that this can be a practical tool for managers, helping th e m identify all the major things that need to be addressed. We also suggest the type of person—from messaging professionals to clerical staff—that can handle each task. The tasks are broken down into two categories: messaging management tasks, and other support tasks.

What's Messaging Management? Central help desk staff need to ensure the messaging network is working properly. Messaging network management—also known as messaging management—is the disciplines and technologies involved in making this happen. More specifically, central help desk staff must ensure: • Availability. The mail system should up and running when needed. • Serviceability. When things go wrong, it should be easy to provide a fix. • Reliability. When you send something, it shouldn't be mislaid. • Performance. Mail should be transferred between end points on time. • Common manageability. It should be possible to manage the mail system, even though it's made up of different products from a variety of vendors. The basic entities mail management deals with are: • User e-mail accounts

217 10 Messaging Support Tasks

• User programs (when mail enabled) • Messages, message stores, and bulletin boards • MTAs, their queues, and MTA-MTA connections • Gateways and their queues • Directory servers and distribution lists • Service providers

10.1 Basic Concepts & Facilities First, a quick review of some basic messaging management concepts. You need to be familiar with these in order to understand many of the support tasks we describe later in the chapter.

Management Monitor & Alerts There ought to be a program somewhere that constantly monitors the network. It typically displays a graphical map of the system (figure 10.1), together with status information. For example, components that are operating satisfactorily might be in green; seriously failing components in flashing red; components that have been turned off in yellow. Often, you can drill down into underlying layers. The idea here is that to get more details about a component, you double-click on it. You may well then be able to double-click or drill down further, gradually increasing the specificity ofwhat you see. When the monitor senses that something's gone wrong, it generates a warning or alert. The warning will be recorded in a log file, which can later be inspected. Alerts are normally prioritized, ranging from low to high levels of urgency. More urgent alerts are sent directly to support staff: they may be displayed on a screen along with a warning sound, and/or sent by e-mail, and/or sent to a beeper.

Service Guarantees Within a PC e-mail system, people typically expect five to 10 minute delivery times. If the message has to go to some very remote office, such as from San Francisco to Singapore, all within the same e-mail system, this might be extended to 15 minutes. If you're using dialup links everywhere, these times can be a lot longer, and delivery within an hour is often acceptable. 4-hour delivery times, however, would

FIGURE 10.1 TYPICAL NETWORK MAP

:10 Window

. 44000Wei • ***0044 .42424,

ikiet Ath*i.fg.

. NO:FP.*:' .

MAN

A central management monitor displays a map of the messaging system. The status of individual components is indicated, typically by their color. For more details, you can drill down by double clicking on an icon.

rarely be acceptable today. If the message has to go between different e-mail systems—such as when an MS Mail user sends a message to a PROFS/OV user—longer delivery times are acceptable. Typically, end-to-end delivery across different mail systems, all within the same organization, takes between 30 and 60 minutes—figure less if sender and recipient are at the same location.

Structure of Guarantees Most organizations provide a formal service guarantee to users. This is a big help in clarifying what support people are supposed to deliver, and whether or not they're living up to expectations.

219 10 Messaging Support Tasks

We interviewed a number of people about their service guarantees, and here are some illustrative comments: • "We guarantee that 95% of the time, mail will get between our HP Desk and PROFS environments, including transit through the SoftSwitch backbone, in five minutes. Most users think about 15 to 20 minutes is acceptable in 90% to 95% of cases." • "We offer a 30 minute end-to-end guarantee in our cc:Mail system." • "Delivery varie s, depending on the mail system. Within All-In-1, it should be less than 30 minutes, and within PROFS it should be within 10 minutes. Mail gets through within one or two minutes 90% of the time." • "We haven't established any delivery guarantees for our cc:Mail system. Normally it takes about 10 to 15 minutes if several hops are required." • "Most customers say something like: 85% of the mail within 15 minutes worldwide, across different environments; and 100% within 35 minutes." • "We use dialup links a lot, and our goal for world-wide delivery is 60 minutes. We don't have any guarantees." The most common service guarantee structure is X% of messages will be delivered in time Y Sometimes companies also add constraints relating to the maximum size of message that can be delivered, and to the priority of the message being sent. In backbone environments, where different messaging systems are being connected, and where many of them are distributed e-mail systems, it's extremely rare (the authors have never seen one) to receive a guarantee that all messages will get through in a specific time. It's unwise to make such a commitment, because a large file going through the system can easily disrupt everything. Plus, the way distributed e-mail systems (such as cc:Mail, MS Mail, SMTP/MIME, or an X.400 system) are built, many things can cause unpredictable delays.

Structure of Future Guarantees Tomorrow's service guarantees will need to be much more tightly defined than those of today. In part, users will demand faster delivery times. This is relatively easy to provide, in the sense that most messages are speeded up by throwing more powerful hardware and faster data communications links at the system.

A larger problem is that today's service guarantees have a caveat. They say that X% of messages will arrive within time Y. Such guarantees are generally satisfactory for interpersonal messaging. If the occa- sional message takes longer to get through, it rarely creates real problems. For example, most Internet messages get through pretty quickly, probably within 20 minutes or so. But around 1 in 100 takes between 3 and 6 days, typically because some router along the message path wasn't turned on. It's an annoyance, but not usually a disaster. But what about the (100-X)% of messages that don't get through in a timely way? Many mail enabled applications will not accept a chance of even 1 in 10,000 that a message goes into never-never land. Consider, for example, a manufacturing line sending just-in-time orders to suppliers; or a stock quote system in an investment banking firm. So users will need hard guarantees relating to all messages. But on the other hand, e-mail systems will continue to be subject to unpredictable delays, such as when a component fails, or when the system is swamped by massive files. We think service guarantees will evolve along the lines of the following compromise: X% of messages will be delivered in time Y; and where a message fails to get through in time, the sender will be notified of such failure within time Z and will receive a copy of the message they attempted to send. Again, embellishments relating to message fees, size, priority, method of user notification, and so on can be expected. Substantial improvements in messaging technology will be required if such service guarantees are to be satisfied. The system will have to promptly detect that something has gone wrong; and then attempt to fix the problem automatically, while alerting operators of a misfunction.

Statistics & Log Analysis Messaging system components generate statistics on things like how many messages they've handled, how many came from a particular destination, how many could not be processed, and so on. These are basically just a series of counters. Messaging systems also maintain a series of different log files, notably those controlled by each MTA, gateway, message store, and management monitor. A log entry typically includes highly codified information in addition to a time stamp, an indicator of who made the entry, and a descriptive message in English such as "received message 82993-2 from MTA HQ05."

221 10 Messaging Support Tasks

Inspecting these logs yields extremely valuable management information. For example, they can be used to: • Spot trends, such as growing congestion on a specific MTA-MTA link, or the approaching need to upgrade a CPU • Trace the various steps taken by a particular message • Provide summary operating information, such as the number of messages handled, average size, average delivery times, failing components, and so on • Generate performance level reports • Generate chargeback reports

Troubleshooting Tools

Several things are particularly useful for detecting and fixing operational

problems: Problem Message Queues When a system component—especially MTAs, gateways, and message stores— have difficulty forwarding a message, their normal course is to return it to the sender. If this is not possible, the message is normally placed in a special queue which we shall call a problem message queue. An administrator can later inspect such messages manually, and take appropriate action.

Probes A very useful fault detection technique is to have the management monitor automatically send out test e-mail messages into the network. These probes are received by special mailboxes, and an automatic reply to the sender is generated. If a probe isn't returned in a timely way, that's good reason to suspect a connectivity break, and the monitor can generate a suitable alert.

Loop Detection Messages can float around in circles in the system, passed forever from MTA to MTA. This can happen, for example, if routing tables have been wrongly configured. Normally, each message contains a hop counter, which is increased every time it's passed from an MTA to another MTA. When an MTA reads of message that has exceeded the maximum hop count, the message is returned or placed in a problem message queue, and an alert is generated.

Physical Network Problems Problems arise if the underlying data communications network is itself having problems. Large organizations normally have a team of people already in place to support and troubleshoot this when it occurs. Ideally, physical network problems should be capable of generating alerts to the management monitor.

Thresholds An extremely powerful management technique is to define thresholds. Here, the administrator defines specific criteria like "Message store X is at least Y% full". Special monitoring software constantly checks the system to see whether the thresholds have been satisfied; when they have, an alert of specified severity is generated. For example, one needs to be able to specify that urgent alerts should be generated when: • An MTA or message store stops functioning • An MTA-MTA link stops or cannot be established • A message takes longer than X minutes to arrive • A queue contains more than X messages • A queue contains messages older than X minutes • A queue is full • A file over X megabytes is being transmitted • A probe is not returned in a timely way • The underlying physical network has serious problems One would also like to be able to specify that a low level alert should be generated when: • A message store becomes more than Y% full • A queue contains more than Y messages • A queue contains messages older than Y minutes • A looping message is detected • A message is placed in a problem message queue • The underlying physical network is suffering from low levels of congestion

223 10 Messaging Support Tasks

10.2 Major Support Tasks

We turn now to discuss the most time consuming support tasks of an e-mail

system. Support Tasks Vary Greatly First, an important observation: the main support tasks vary a lot, depending on the nature of your messaging environment. For example: • Certain systems, such as all-SMTP, all-PROFS/OV, and all-Banyan environments will need little time on directory synchronization and routing, completely unlike a system with a series of different mini, mainframe and PC e-mail systems. • Static systems—where you're doing minimal maintenance because the system is being gradually phased out—require comparatively little support. As a result, the remaining tasks, such as user adds/moves/changes/ deletes, take a higher proportion of total support time. • Some organizations invest a lot into enhancements for their e-mail systems, such as special bulletin boards, or special multi-message deletion utilities. • Message store reorganization is a big hassle for PC e-mail systems. • Good user training significantly reduces the demand for help desk services. • Moves and changes are simple with centralized systems such as PROFS/ OV, much harder for PC e-mail systems. It typically takes 5 to 10 minutes to add/change/move/delete a PROFS/OV user, but between 15 and 30 minutes to add/change/move/delete a PC e-mail user. • E-Mail may be the first application requiring a network. In this case, installing the application may take a lot of time, since a variety of other products such as network cards and software must also be installed and integrated.

Size of Support Staff: Planning Guidelines We now present some guidelines about the number of people needed to provide support for your messaging environment. Support includes such diverse tasks as adding new users, maintaining distribution lists, reading the trade press, attending key vendor presentations, training how to use file conversion utilities, developing special system support utilities, and so on. Ie, the whole ball of wax. In the calculations, we use the concept of a full time equivalent support person, or

Fl E. Here, one person working half time on e-mail support, plus three working quarter-time, make 1.25 FTE's of support. The size of head count varies enormously. Very roughly, expect: • One FTE of support for every 400 to 800 PC e-mail mailboxes. • One FTE of support for every 2000 mainframe or mini e-mail mailboxes. • One FTE can support 3,000 to 5,000 mailboxes in a static (probably a dying mainframe- or mini-based) e-mail environment. Note for PC e-mail, some organizations have a ratio of around 1 P IE for every 1000 or 1500 mailboxes. This typically means that support staff are severely overworked as well as unable to provide a proper level of service. Systems based on Banyan Intelligent Messaging and HP OpenMail are notable exceptions to the PC e-mail guidelines, mainly because the maintenance of their transports is much simpler. For these products, a ratio of 1FTE for between 2,000 and 4,000 mailboxes is realistic.

Top Ten Support Tasks Figure 10.2 lists the support tasks that typically take a lot of time. We've ordered them by the proportion they take of the overall support effort. Be cautious about the second column. For the reasons just discussed, the share of total support for a given task in a particular environment can easily be outside the range of the fig u re given, and indeed some items may take next to no time at all.

Add/Change/Move/Delete Accounts This encompasses registering new users, changing the status of their account (and possibly moving mailboxes and address lists when they change departments), and deleting users. For PC e-mail systems, this is a particularly demanding chore. The tasks include: • Determining which MTA the user's account should be associated with • Entering user names and addresses in the directory, and various distribution lists • Configuring address translation tables or mappings where different e- mail products are connected • Defining constraints like the amount of space and number of messages the user is allowed to have

225 10 Messaging Support Tasks

FIGURE 10.2 TOP TEN TIME-CONSUMING SUPPORT TASKS

1 Add/change/move/delete accounts 15%-25% 2 Programming & utilities development 10%-25% 3 Ad hoc application usage questions 10%-20% 4 Help user with returned/disappeared mail 5%-20% 5 Installation/major upgrades 5%-10% 6 Training 5%-10% 7 Troubleshoot workstation environment 2%-20% 8 Resolve invalid directory lookups 2%-10% 9 Help with file conversion 2%-5% 10 Reinstate forgotten passwords 2%-3%

Registering users, and adjusting their account status, is by far the largest support task. Dealing with returned or "disappeared" messages is also a major time consumer. Be cautious about the third column: figures can easily differ for a given environment.

The work will expand further when public key cryptography becomes popular, because managing user certificates is time-consuming.

Programming & Utilities Development It makes a lot of sense to build tools to de-skill as many of the support tasks as possible, so that clerical administrators can do the work, or so that they can be handled automatically. For example, user moves and changes are naturally amenable to this treatment, especially because they can consume a lot of support time. A utility can update the appropriate directories, moves message stores, update distribution lists, and so on. Another example is a utility which automatically synchronizes the different directories; a good chunk of the code will need to check for failed synchronizations, and appropriate recovery.

Ad Hoc Applications Support Users have general questions about the use of the various generic e-mail applications: how to compose a message, view an arriving file, send mail to an X.400 or Internet address, and so on. Weird, hard-to-fix bugs also fall in this category, such as bulletin board messages that can't be read until the workstation is rebooted.

Returned/Disappeared Messages Messages can be returned for a variety of reasons. For example, the address mapping may not be working properly when two different systems are being connected. Or someone may have moved locations. Mail can also "disappear." Users call in to say that mail they sent hasn't arrived yet, and want to know what's happened. This can be caused by such things as fault y addresses, or halted MTAs or gateways, or large file transmissions slowing everyone down; it's particularly prevalent for distributed systems such as PC, X.40 0, and SMTP e-mail. Ofte n, faulty messages are dumped into a special problem-message mailbox controlled by an MTA or gateway. If an operator doesn't periodically inspect this mailbox, the message is effectively lost. These problems may afflict only one message in a thousand, but determining what's happened and fixing the situation is time demanding and often skill-intensive.

Installation/Major Upgrades Installing e-mail software—including ancilliary software like fax and file viewers, and file conversion software—can be time-consuming. The work isn't terribly hard, but it involves a lot of steps. Plus additional hardware may be required for the workstation.

Training Users need to be given formal (if short) classes on their e-mail software. Some users also need direct hand-holding when first using it. The training probably needs to be accompanied by some soft of reference documentation. When public key cryptography becomes popular, users will need a lot of training on the concepts and procedures involved.

Troubleshoot Workstation Environments Often, users call in to say that e-mail isn't working, when actually, the problem lies elsewhere. For example, perhaps the workstation hard disk or network card has got problems, or the disk is full. Solving their problem means troubleshooting the general workstation environment.

Invalid Directory Lookups Sometimes users can't find a recipient's address in their directory, or the directory gives them an address that's invalid.

227 10 Messaging Support Tasks

This often happens in organizations which have a number of different e-mail systems connected, and in which a directory synchronization process runs periodically. Information about new users or moved users takes a while be disseminated—often synchronization runs weekly— and until that's happened, correspondents have difficulties. Other things also create lookup problems. For example, sometimes synchronization processes fail, and the recovery efforts can take time. Or some users deliberately keep their addresses out of the directory, for privacy reasons.

File Viewing & Conversion Users often need help when receiving files that their software can't read, or reads imperfectly. Likewise, they need help working out how to send files to other people in the recipient's preferred format.

Forgotten Passwords In environments where users only rarely use e-mail, forgotten passwords can be a problem. Resetting the password is a simple clerical task, but PC e-mail systems often require use of the main e-mail support person's password—thus dragging that person to the process.

FIGURE 10.3 TYPICAL SUPPORT TASK MIX

Training 5% Forgotten Passwords 2% Programming 10%

Installation 5%

Other 40% Retumed/Lost Messages 5%

Ad Hoc Application Questions 10%

Troubleshoot Workstation 3%

File Transfer 2% Invalid Directory Lookups 3%

Moves and Changes 15%

Messaging systems consisting of several different products connected via a backbone often have a support task mix like this.

10.3 Message Management Task Checklist We said earlier that messaging management is what a central help desk does to ensure a properly working messaging system. Many commentators like to define messaging management further, in terms which apply to classical network management. Network management is what NetView and OpenView operators do—they support low level communications hardware and software, like routers, modems and data communications links. Network management is a rather specialized, technical discipline.

IFIP Messaging Management Definition The IFIP working group on electronic mail management is typical of this base- the-definition-on-classical-network-management approach. It defines messaging management as: • Configuration Management. Activities which control the system configuration (eg routing tables, software, and parameters), and the provision or removal of new capabilities. Configuration management also includes engineering support, which is the process used to determine the optimal system, based on performance data, resource utilization, and system requirements. • Fault Management. Functions that enable an e-mail manager or application to detect, isolate, and correct faulty components and service. • Performance Management. Functions that evaluate, report, and optimize and report the operational behaviour of the e-mail system components and user service. • Security Management. Functions used to achieve e-mail and e-mail system component authentication, accountability, confidentiality, integrity, and access control. • Accounting Management. Functions used to measure service usage and provide billing information. The problem with this configuration/fault/performance/security/accounting approach is that it doesn't give an intuitive feel for what the important support issues are, how they interrelate, and how support people are involved. It's also hard to tell whether everything's been accounted for.

229 10 Messaging Support Tasks

EMA Messaging Management Committee Definition A better approach, we think, has been adopted by the EMA's Messaging Manage- ment Committee. This divides messaging management into five main categories: • Operational Management. Finding outages and fixing them before users notice, and doing routing maintenance to keep the system healthy. Topics here are dynamic monitoring; data collection for fault analysis, reporting, and forecasting; information query to outside messaging systems; message tracing, and user agent fault management (eg, too many messages in message store). • Configuration Management. Managing the addition or subtraction of components in the messaging system, their software versions, and interconnections. Topics are discovering and depicting the messaging components (usually on a drill-down graphical display), starting and stopping things, routing configuration, routing changes, setting time of day (notably for daylight savings time), and moving users. • Administration Management. Managing users, distribution lists, and generating billing, accounting, and chargeback information. • Security Management. This encompasses restricting access to services, and detecting attempted security breaches. • Network Management. Keeping the underlying data communications network healthy. It's not discussed in detail by the EMA group, since other technologies already address the issue.

Our Approach: Base on Messaging Tasks We take a slightly different approach, based directly on messaging concepts rather than ones drawn from general network management. We develop a comprehensive list of messaging support tasks, and clump them together as best we can.

Types of Staff Required We also describe the sort of support staff required for each task: • Clerical people use repetitive utilities. They have a general understanding of the e-mail system, but have no indepth technical skills. • Information Center consultants—IC consultants—have more technical skill. Their main work is to help with questions for a variety of applications, of which e-mail is one. They typically have a business orientation rather than a technology orientation. They have light, general-purpose

technical skills: for example, they can install PC software and negotiate config.sys and autoexec.bat files. • Messaging professionals are specialized technologists. They know the details of how the messaging system works, and are responsible for tasks such as its design, performance tuning, and training programmers how to use messaging APIs. • Data communications staff. These people know about data communications links, configuring network addresses, modems, routers, and so on. In short, they are responsible for providing and maintaining the data transport over which a messaging system operates. Their help is important in a small number of tasks, such as configuring X.25 connectivity to an ADMD, or advising on the layout of MTA-MTA associations (so their topology doesn't conflict with that of the underlying data network). • Users. Some messaging system support tasks can be done by the users themselves, possibly with the assistance of a support professional. For example, more technical users can install workstation software, and configure dialin scripts for travelling workstations. Another example is where client software provides management utilities, such as Novell's GroupWise and its message tracking. • Other. Sometimes other people get involved. For example, audits must often be done by disinterested third parties. We look later at the management tools available today, and evolving standards.

Basic User Support Figure 10.4. First of all, a single point of user contact is provided. This is typically by means of a telephone number at a central help desk. This first line of support is normally a clerical person, who routes the questions to other support staff as appropriate. In addition, basic user support handles the installation of user interface software on user workstations, and general-purpose questions about the use of messaging software.

User Adds, Moves, Changes, Deletes Figure 10.5. This encompasses adding new users, changing their status (eg assigning a new password), moving an account location (eg, user changes department), and account deletion when the employee leaves.

231 10 Messaging Support Tasks

FIGURE 10.4 BASIC USER SUPPORT TASKS

Provide single point of user contact

Client Software Installation Install required add! hardware Install & configure user interface for e-mail software, file viewers & converters, fax gateway, bulletin boards, directory interface, special-purpose rules, public key cryptography Help configure dialin scripts for remote users 9 Apply software upgrades ,/ 9

Ad Hoc Usage Questions Gen eral help with interpersonal messaging, interpersonal file transfer, bulletin boards, addressing, file viewing, file conversion, rules, eg, autofiling, public key cryptography, chargeback

A lot of different tasks are involved. Defining address translation is particularly tricky, and often accounts for undelivered message problems. Maintaining distribution list entries is also an error-prone chore. Moves are particularly challenging for PC e-mail, since message stores and address books must be copied over. This work can be enormously simplified if easy-to-use utilities are developed for support staff. In this case, almost all of the work should be do-able by clerical staff. Note that a user's e-mail registration generally coincides with the user's registration as a system or LAN user, and may well be associated with changes adminis- tered by the human resources department. You don't want redundant processing, so often the administrator who performs system sign-up also performs the e-mail registration; and sometimes the whole thing is done by a human resources administrator.

Message Stores & BBS Figure 10.6. We cluster bulletin boards along with message stores, since the former is usually implemented as a special type of message. Most of the administration of bulletin boards is done by registered users.

FIGURE 10.5 U SER ADD, CHANGE, MOVE, DELETE TASKS

User Adds Put user name in directory 9 Put user address in directory 9 Put entries into appropriate distribution lists 9 Assign password 9 Configure routing 9 Configure address translation if necessary 9 Assign message store space 9 Configure constraints, notably on # msgs in store, message store space, message size, maximum chargeback 9 Define access privileges, eg, for message store, bulletin boards, directory, distribution lists, external messaging systems 9 Assign public & private keys 9 Escrow digital keys if necessary 9 Generate certificate 9

User Changes Adjust distribution list entries 9 Password forgotten so assign new one 9 Adjust access privileges, eg, for message store, bulletin boards, directory, distribution lists, external messaging systems 9 Adjust constraints, notably on # msgs in store, message store space, message size, maximum chargeback 9 Alter message store space allocation 9 Config autoreply or autoforwarding 9 Configure message forwarding, autoanswer, hold for delivery 9 Assign public & private key for new role 9 Escrow digital keys if necessary 9 Generate certificate 9 Update revocation list if necessary 9 Restore lost keys if applicable 9

User Moves Put user name in directory at new location 9 Put user address in directory at new location 9 Adjust distribution list entries 9 Assign password 9 Reconfigure routing 9 Reconfigure address translation if necessary 9 Assign message store space 9 Define access privileges eg for message store, bulletin boards, directory, distribution lists, external messaging systems 9 Define constraints, notably on # msgs in store, message store space, message size, maximum chargeback 9

233 10 Messaging Support Tasks

Move users private directories Move user's i messages i Configure message forwarding, autoanswer, hold for delivery 9 V Delete name and address from old directory 9 Delete old message store entries 9 Assign public & private key for new role 9 Escrow digital keys if necessary 9 Generate certificate 9 Update revocation list if necessary 9

Account Deletion Disable login 9 Forward messages to replacement 9 Update public key revocation list 9 Archive message store 9 Remove user name from directory 9 Remove user address from directory 9 Remove from all distribution lists 9 Reconfigure routing tables if necessary 9 Reconfigure address translation if necessary 9 Remove message store space allocation 9 Configure message forwarding, autoanswer, hold for delivery 9 9

Directory & Distribution Lists Figure 10.7. Much of the work here is the day-to-day maintenance of directory entries, so a lot of it has already been described in the section on Adds/Changes/ Moves/Deletes. A lot of work must often be put in developing software that provides for entry propagation within a given PC env iro nment, as well as directory synchronization between different systems attached to the backbone. Then the propagation and synchronization utilities must be run periodically. We also single out a special type of entry, the distribution list. Note that: • Often special-interest distributi on lists will be maintained by designated users. • Since distribution lists can easil y become very large, the costs of using them needs to be monitored and managed.

Transport & Gateways Figure 10.8. The transport consists of the network of MTAs—those on the backbone plus ones in proprietary connected systems such as cc:Mail's Router. Data communications skills are often needed: • To ensure MTA-MTA links make reasonably efficient use of the underlying data network. • To configure network addresses, if technologies such as TCP/IP, X.25, or LU 6.2 are being used. Dialup or server-server connections are much simpler and can be handled by e-mail professionals. Gateways plug the different e-mail systems together. Much of the day-to-day maintenance should be included in the Add/Changes/Moves/Deletes tasks, notably

FIGURE 10.6 MESSAGE STORE & BBS SUPPORT TASKS

c= Who:Doe~TheVlftaiak<::

IC: MOO Prot......

Message Store Install & configure message store Start, stop, suspend message store Apply software upgrades Create & delete folders Move & delete messages 9 Propagate message folders Reorganize message stores Purge old messages Backup/archive Restore lost messages Configure automatic rules processing Maintain access controls 9 9

Bulletin Boards Install software 9 9 Regi ster bbs administrators 9 Create & delete bulletin boards 9 Propagate bulletin boards 9 Reorganize bulletin boards 9 Purge old bulletin board messages 9 Sta r t, stop, suspend service ,/ 9 Apply software upgrades Backup/archive 9 Restore lost messages 9 Configure automatic rules processing 9 ,/ 9 Maintain access controls

235 10 Messaging Support Tasks

FIGURE 10.7 DIRECTORY & DISTRIBUTION LIST SUPPORT TASKS

Directory Support Install and configure software .1 Start, stop, suspend directory 1 i Ap ply software upgrades 1 i Maintain entries, notably user names, addresses, distribution lists, and identifying auxilliary information such as department, telephone number 9 i Backup/archive 9 Purge old autoregistered addresses 9 Custom field definition 9 9 9 Maintain access controls 9 ./ Develop propagation utilities 9 Develop synchronization utilities 9 Propagate directories 9 9 Synchronize directories 9 9 9 Reorganize directories 9 Distribution Lists Define new distribution lists 9 9 ./ Register DL administrators 9 Maintain entries 9 1 Delete distribution lists 9 9 J Develop cost tracking reports 9 i Monitor usage costs & notify users 9 Check for circular references 9 Maintain access controls 9

the maintenance of address translation table entries and access controls. It's worth noting that one of the greatest sources of lost and returned messages is faulty address translation,

External Connectivity Figure 10.9. Connections to the Int ernet and public X.400 networks must be installed and maintained. The former will require particular attention to security, to provide protection again st viruses, hackers, nosey competitors, and so on. Periodically, autoregistered addresses will pro bably h ave to be purged. Users have difficulties determining the correct addresses of external parties, and with entering Internet and X.40 0 addresses correctly. They may have to indulge in such nastiness as inlin e addres sing .

FIGURE 10.8 TRANSPORT & GATEWAY SUPPORT TASKS

Transport Install MTAs Configure/maintain MTA-MTA associations Configure/maintain MTA routing Configure/maintain association filters, eg, destination address, message size, priority, 9 time of day etc Start, stop, suspend MTA Start, stop, suspend MTA queues Backup/archive MTA logs ./ Reset MTA logs ./ Apply software upgrades

Gateways Learn technologies on both sides 9 Install gateway Install automatic conversion tools if needed Configure/maintain static parameters, notably interpersonal message co nve rsion, file attribute conversion, special character conversion, delivery notification conversion, receipt notification conversion, tunneling 9 Configure/maintain address translation rules and tables 9 Configure access controls eg to fax, SMTP gateways 9 Purge old autoregistered addresses 9 Start, stop, suspend gateway Start, stop, suspend gateway queues Backup/archive gateway logs 9 Reset gateway logs 9 Fax gateway: route incoming faxes 9 Apply software upgrades Develop and maintain custom gateways if needed Develop and maintain custom directory synchronization if needed Write chargeback utilities if needed

9 Initially, directory inquiries from staff as well as those from outside are likely to come by phone, e-mail, or fax. As X.500 becomes popular, people outside the organization will be able to query an internal directory with no human intervention. Corresponding access controls will have to be defined, to protect against competitors seeking marketing intelligence, headhunters trawling for prospective goods, and so on.

237 10 Messaging Support Tasks

FIGURE 10.9 EXTERNAL CONNECTIVITY SUPPORT TASKS

External X.400 Connectivity Retain consultants as needed 9 Plan installation steps and schedule 9 Select ADMD Order line and equipment Install line ,/ 9 Install connecting MTA Test X.25/Dialup/TCP-IP link Initial X.400 tests ,/ 9 Test PRMD-ADMD connectivity Configure MTA directory Write message trace integration utility 9 Write chargeback system integration utility 9 Stress testing 9 Develop and maintain user training, documentation Train help desk and operations Run pilot ,/ 9 Support trading partners as necessary 9 9 Train users Define information to be given to service provider for chargeback, message trace queries/troubleshooting 9 Contact service providers, for chargeback, message trace queries/troubleshooting 9 Start, stop, suspend MTA Start, stop, suspend MTA queues Maintain address translations Advise users on correct addressing 9 Check problem message queues Configure in- and outbound access controls ,/ Periodically purge autoregistered addresses Internet Connectivity Retain consultants as needed 9 Plan installation steps and schedule 9 Select Internet carrier if applicable Order line and equipment Install line 9 9 Install connecting router Configure/maintain connecting router Test connectivity to carrier Initial SMTP/MIME tests Write chargeback system integration utility 9 Stress testing 9 Develop and maintain user training, documentation ,/ 9 Train help desk and operations Run pilot Support trading partners as necessary 9 9 Train users ,/ 9

Provide point of contact with Internet carrier 9 Configure in- and outbound access controls 9 9 9 Start, stop, suspend router 9 9 Maintain address translations 9 9 9 Advise users on correct addressing 9 Check undeliverable queues 9 Periodically purge autoregistered addresses 9 9 Directories Handle telephone, fax, e-mail directory inquiries from outside

9 Handle telephone, fax, e-mail inquiries about external directories from inside sta ff

9 Install and configure automatic external access Maintain controls on outsiders for access to internal directory

Fault Management Figure 10.10. These are the tasks re quired to ensure that when operations go wrong, they can be detected and co rrecte d in a timely way. If possible, faults should be detected and fixed before users become aware of them. In addition to describing the tasks involved, two classes of common problem warrant particular attention: • Returned messages. These are of ten caused by incorrect addressing, such as when an X.400 address is type d inco rrect ly, or wher e a user has moved and directory synchronization has not y et upda ted local directories. Many other causes are also possible, such as full disks, failed M TAs, and unavailable MTA-MTA links. • Delayed/lost messages. When a message takes an abnormally long time to be delivered, users often call up th e help desk. Messages can be delayed by many factors, such a s faile d MTA s, lar ge files passing through the system over dialup lines, and so on.

Primary Diagnostic Methods Diagnosing the cause of an alert m ay be simple, or it may require considerable detective work. The main things to do are to: • Obviously, read any error inform ation provide d by the s ystem. • Check message queues in MTAs and gateways.

239 10 Messaging Support Tasks

FIGURE 10.10 FAULT MANAGEMENT TASKS

General Fault Management Select and install monitoring tools Write alert generation software as required Define alerts Configure means of alert distribution Configure automatic reconfiguration Monitor the system Diagnose cause of alerts Take corrective action if applicable Plan for fau lt tolerance, eg, alternate routing, alternate delivery method (post, fax etc) 9 Provide for fault tolerance, eg alternate routing, alternate delivery method (post, fax etc) Restore MTA, message store, gateway logs Maintain trouble ticket system Liaison with connected external messaging system, eg, ADMD, PRMD, Internet carrier Liaison with third party data link providers eg, X.25, dialup links, Internet carrier Install automatic alert & diagnostic process to connected external systems 9 Returned Messages Diagnose cause of problem and take corrective action if necessary Update address translations Provide user education 9 Recover message body or file attachments if not returned 9 9 9 Liaison with service provider

Delayed/Lost Messages Diagnose cause of problem and take corrective action if necessary Provide proofs of delivery ,/ 9 Recover messages delayed in transit Message store restore Liaison with service provider 9 9 Generate message trace request 9 Interpret message trace request reply 9 Provide user education 9

• In particular, check problem message queues. • Check the logs kept by MTAs, gateways, and message stores. • Check the central alert log maintained by the system monitor. • Using the logs, trace the path a message has taken. Lost messages can

often be retrieved from an MTA or gateway queue along the message's likely path. • Where a message has been transferred to an ADMD, contact the ADMD and ask them to conduct a search. This is done either by telephoning the ADMD, or by sending a specially formatted request-to-track message. Likewise, taking corrective action may be simple, or may require ingenuity. In the future, tools will often be available which allow support staff to define what corrective action should be taken when certain problems arise, such as to bypass an MTA if it fails.

Performance & Capacity Management Figure 10.11. Here we're concerned with ensuring messages get through quickly enough. The emphasis is on detecting deteriorating service, and taking corrective action, before users become aware of what's happening.

Security Figure 10.12. There are two main clusters of tasks here: • Access Controls. You need to limit access to the messaging system, and programs which use the messaging system. • Public key cryptography. This technology will become widespread over the next five to ten years. It provides a ser ies of benefits, notably encryption, the ability to be sure that person X send a message rather than someone else masquerading as X; and the ability to be sure that a message wasn't changed prior to being received. For a more detailed description, see the June 1994 Ferris E-Mail Analyzer. We've listed many of the points b efore, but repeat them here since they naturally cluster together.

Suggestions for Operational Security Operational security relates to whether your messaging systems can be compromised through actions of your operations staff. Messaging systems should be designed so that damage from both intentional and unintentional actions is minimized. You may want to adopt the following precautions: • Control access rights to directories where messages reside.

241 10 Messaging Support Tasks

FIGURE 10.11 PERFORMANCE & CAPACITY MANAGEMENT TASKS

Select & install performance monitoring tools eg probe monitors Develop custom performance monitoring software as necessary Define quality of service criteria Develop performance reports Define performance warning alerts Define regular system snapshot dumps Monitor and analyze alert logs for performance problems Generate periodic performance reports 9 Study performance reports to discern deteriorating service 9 Liaison with users, notably for information on service deterioration, future application demands 9 Restore MTA, message store, gateway logs reports/logs relating to quality of service, warning alerts, resource utilization, trouble tickets Develop performance simulation software 9 Plan & implement corrective action, notably hardware and data link upgrades, split message stores, reconfigure MTA-MTA routing, MTA routing logic 9 9 Manage queues, including priority adjustments within queues, new queue definition, concurrent processing, filter configuration 9 9 Contingency planning for performance interference eg by heavy traffic, poor lines, equipment disruptions 9 9

• Although X.400 messages are binary encoded, most systems come with parsers that allow an educated technical person to inspect such messages. Limit access to such tools. • Limit access to all management programs, eg, those managing disks, user adds, directory synchronization etc. • Some systems have an operator to which messages with bad addresses are sent. The idea is that they may be able to inspect the message to route it to the intended recipient. In X.400, such an operator is called an alternate recipient. You may want to limit your operators to seeing only the header fields, including subject.

FIGURE 10.12 ACCESS CONTROL & PUBLIC KEY CRYPTOGRAPHY TASKS

Maintain Access Controls For: Message size 9 File transfers Messages in message store Bulletin boards Directory fields Distribution lists 1 MTA access by another MTA Message transmission by an MTA Message transmission by a gateway Message transmission to ADMD/Internet Inbound messages arriving from ADMD/Internet Chargeback maximums Virus introduction Management software Public Key Cryptography Assign public & private keys 9 Escrow keys if necessary 9 Generate certificates 9 Maintain revocation list 9 Restore lost keys if applicable 9

• Most datacomm rooms have monitors to see what is happening on a data line. This can provide a security risk, even for X.400 messages, since ASCII text is still readable, even within a binary envelope. • The operator interface should verify operator actions to the extent possible, and prompt the operator for confirmation before performing actions that could be damaging. A graphical user interface helps reduce both the operator's learning curve and error potential. Some of these requirements, of course, conflict with the efficient operation of a system. For example, the operator may be able to determine the correct recipient of a misaddressed message only by looking at its content. Or, during a crisis, an operator may need to use parsers for troubleshooting purposes. There are no onesize-fits-all rules.

Message Access Controls Beyond Your Premises Messages received and sent by your organization may be subject to security breaches while in other systems. For example, you can't be sure your ADMD enforces the

243 10 Messaging Support Tasks

same security levels as those you apply internally. What if an operator within the ADMD can read the message? For this reason, the preferable method of providing security when dealing with the outside world is by encrypting message bodies, rather than requiring that MTAs along the path of a message be secure.

Chargeback Figure 10.13. Most organizations do not charge their users (or the users' departments) for messaging services. When chargeback does take place, it is generally just a flat monthly. fee. Sometimes, notably with PR.OFS/OV, the charge can also depend on how long the user is logged on. This situation will probably have to change, partly to ensure messaging services provided by third parties are readily available, and partly to encourage user to make efficient use of the system (eg send large files overnight rather than at peak times).

Chargeback System Development Methodology To put in a more economic chargeback system: • First, you make sure that individual subsystems, notably MTAs, message stores, and gateways, can write accounting records in an arbitrary format. • Then specify a corporate-wide master accounting record format. Ideally this should be in a format that can be generated on any platform, ie, it should be in ASCII.

FIGURE 10.13 CHARGEBACK TASKS 11111 ______

.. :or, . .. C ...... g.

Write/maintain chargeback utilities which encompass use of backbone, attached e-mail systems, directory, distribution lists, bulletin boards, fax, telex, and external messaging Audit bills from service providers Query service providers and negotiate as necessary 9 Generate and distribute chargeback reports 9 Answer user queries, renegotiate 9

• Write accounting format translators from accounting records written by individual components to the master accounting record format. • When you acquire new systems, you ask your vendors if they are willing to match your master accounting record format. There are some tricky issues involved, such as identifying an individual message as it threads its way between different messaging systems, and ensuring that individual translators should be insensitive to the addition of new fields in the master accounting record. Service providers charge by the message. Invoices are often on paper, but the trend is to provide them on a diskette or as an e-mail message. Check: • They contain information your billing system needs. For example, they should contain sufficient information to attribute a message to a particular sender within your organization. • The data should be in a format you can easily feed into your in- house accounting system. Note that one of the big problems with X.400 accounting is that many accounting systems are based on fixed length records. Who ever said COBOL was dead? X.400 field lengths can vary enormously. For example, an address can be anything between 30 and 1,400 bytes, and a message ID ranges from 15 to 120 bytes. Th us, using fixed length records either leads to a lot of wasted space, or the accounting system occasionally chokes on a long record.

Inventory Management Figure 10.14. It's tempting to view inventory management as a bureaucratic, administrative function. But actually, the information is important for day-to-day system management. In order to be able to troubleshoot problems on the fly, you need detailed information about what hardware and software is installed. When we say detailed, we mean it: the term covers things like product number, internal asset ID number, purchase date, the nat ure of guarantees and service contracts, maintenance history, and person and telephone number to call at the vendor when the component fails.

Housekeeping Figure 10.15. Some tasks—eg, backups, disk space reclamation, log deletion— need to be performed periodically. O ften they can be highly automated, using

245 10 Messaging Support Tasks

FIGURE 10.14 INVENTORY MANAGEMENT TASKS

Manage list of all h/w and s/w Ensure licensing terms satisfied Manage equipment leases Purchase hfw and s/w Test and install software upgrades Test and install hardware upgrades Maintain vendor support agreements Maintain hot spares as needed Inventory audits Provide access to vendor bbs 9

things like mainframe .REXX scripts or PC .BAT files. Technical support staff get involved mainly when things go wrong. Many of these items have already been listed, we list them again to point out that they belong to this special group. Note also that a very wide variety of reports are likely to be needed. We've listed some of the most important.

10.4 Checklist of Additional Support Tasks The crux of messaging management is that it keeps the system working smoothly. Hence the need for: • A database describing the environment • Automatic warnings when things go wrong, or start to go wrong • Diagnostic tools • The ability to reconfigure the system on the fly • Centralized help desk support A number of support tasks don't fall in the category of messaging management. We now review the most important of these.

Training & Consulting Figure 10.16. Training requires a lot of effort. And if it's ignored, the cost in terms of user frustration and wasted time, and unnecessary support calls, is much higher.

FIGURE 10.15 HOUSEKEEPING TASKS

Directories Directory propagation Directory synchronization Message store folder propagation Bulletin board propagation

Backup/Archive Directories 9 Message stores 9 Bulletin boards 9 MTA, gateway, alert logs 9

Reorganize Directories 9 Message stores 9 Bulletin boards 9

Purge Old messages 9 Old bulletin board messages 9 Autoregistered addresses

System Resets MTA, gateway, message log, management monitor log reset/archive Set system clocks 9 System clocks synchronization 9 Empty wastebaskets 9

Downtime Management Plan and schedule downtime 9 ,/ 9 Distribute downtime warnings 9 Shut down system components 9 Restart system components 9

Generate Reports User chargeback reports 9 Quality of Service reports 9 General system statistics 9 Trouble ticket summary 9 Performance trends and analysis 9 Security breach reports 9 Downtime reports 9

Programmers must be advised on the use of the messaging system, and in particular the APIs that allow access. As public key cryptography is deployed, much consulting will be required on its use and impact on business processes.

247 10 Messaging Support Tasks

FIGURE 10.16 TRAINING AND CONSULTING TASKS

Training Develop training on interpersonal messaging and file transfer, file viewing and conversion, public key cryptography, policies and procedures Develop training for clerical and technical help desk staff Train trainers ,/ 9 Promote classes Give classes 9 When necessary, give 1-on-1 help Maintain class curriculum

Mail Enabled Apps Development Advise on APIs, DDE access, forms routing tools 9 Write mail-enabled add-ins for Windows packages 9 Write and implement rules 9 Advise on performance 9 Configure APIs 9 Train on API use 9 Assist with debugging as needed 9

Public Key Cryptography Advise on altered business processes Security audits

Management Utility De velo pme nt Figure 10.17. A major task is to write an d maintain code that helps the rest of the messaging management effort. Like training, you ignore this at your peril. By investing in such software develop ment, you enable people with less skill to take over a lot of support tasks. Th at cuts down on salary costs, plus the system is less error-prone. A very wide variety of tools can be deve loped. Here we highlight some of the most common. A number of the listed items have already been described, grouped along with related tasks.

Policies & Procedures Figure 10.18. A large number of policy and procedural issues need to be thought through, documented, and communicated to staff. Some are quite tricky, as with

FIGURE 10.17 MANAGEMENT UTILITY DEVELOPMENT TASKS

User Accounts Account registration utility User moves and changes utilities Automatic distribution list updates User chargeback system Automatic user notifications when quotas exceeded Automatic user notifications for messaging system, eg, planned downtime, server full

Propagation & Synchronization Directory propagation 9 Directory synchronization 9 Configure MS folder propagation 9 Configure bulletin board propagation 9

General Management Quality of Service reporting 9 Downtime reporting 9 Security breach reporting 9 Integrate service provider billing reports with chargeback system 9 Automated message trace requests to service provider 9

Exec Scripts Backup/archiving of directories, message stores, bulletin boards, MTA logs, gateway logs, alert logs 9 Reorganization of directories, message stores, bulletin boards 9 Purging of old messages, old bulletin board messages, and autoregistered addresses 9 System resets 9 Shut down messaging system 9 Restart messaging system 9

Other Implement directory query by mail, administration by mail, other by-mail utilities 9 Write custom gateways as needed 9 Write custom directory synchronization as needed 9 Integrate public key cryptography with generic packages, eg, e-mail, forms routing 9 Integrate different public key cryptography approaches 9

249 10 Messaging Support Tasks

FIGURE 10.18 POLICY & PROCEDURE TASKS

Otiaii ThaVotkri.

General Name and alias conventions Address conventions Role in performance evaluation Appropriate use policy (IPM contents, cc'ing, bcc'ing, priorities, personal use, ownership of contents, privacy, etc) Quality of Service goals Msg store backup, archive, purge Bulletin board backup, archive, purge Scheduled downtime

Directory Directory propagation and 9 synchronization External access to 9 internal directory Distribution list usage 9 V Who administers distribution lists 9 9 Bulletin board propagation 9 Message and directory chargeback 9

Security Who manages system security 9 Privacy policy 9 Security breaches 9 What should be encrypted Security audits Public key cryptography audit procedures Suitable contents for messages to outside

Other Policy-Related Tasks Document policies 9 Promote/communicate to staff 9 Audit where necessary 9

naming and address conventions, interpersonal message privacy, and backup. We list some of the main policy issues that may need to be considered.

Technology Planning & Staff Management Figure 10.19. Finally, it's important to keep abreast of messaging technologies and plan how the system should evolve over the next five-to-ten years. The general management of support staff also has a number of tasks associated with it.

FIGURE 10.19 T ECHNOLOGY PLANNING AND STAFF MANAGEMENT TASKS

Technology Planning Evaluate new products ./ Evaluate new versions of installed products I Keep current with key products, vendors, technologies Project future applications mix Plan and project future system architecture

Staff Management General management 9 Hire support staff 9 Hire and m anage consultants 9 Train support staff 9 9 Organize support rotas 9 9 Periodic evaluations and reviews 9 V

251

Chapter 11

11. Messaging Management

In this chapter, we begin with a technical primer on network management standards. This refers to the tools and disciplines used by central support staff to keep a network (any network, not just a messaging one) up and running. We give particular attention to the dominant protocol, SNMP, and its associated MIBs. Then we look at what's being done to define standards in the special field of messaging management. These standards are aimed at helping the central help desk staff monitor and maintain the specifics of a messaging system. We then look at a variety of important, illustrative mail management tools. All of them are proprietary in nature, since messaging management standards are in their infancy. We then comment on the key management developments that can be expected over the next few years. Finally, because of the importance of timely message delivery, we describe the top ten performance bottlenecks, and what can be done about them.

11.1 A Management Standards Primer We start with an explanation of network management standards. Network management is what people at a central help desk do to keep a large computer network running. Often, the tools they use are proprietary to a given vendor. However, standards-based tools can significantly improve the quality of support provided, because a single set of tools can be used to manage the network,

253 11 Messaging Management

even though many different products are involved. First, we present an abstract model of how network management works. Remember, this applies to any type of management, not just management of a messaging system. Then we explain the dominant standard, SNMP. Then we briefly look at CMIP, and summarize the state of the art.

Network Management Model The architecture of a standards-based network management system is as follows (figure 11.1):

FIGURE 11.1 NETWORK MANAGEMENT ARCHITECTURE

Host Computer

Managed MIB Process

anagement Agent LOG

• Management Protocol Management via Interpiocess Device/Process Application Using Communications Proxy or E-Mail Agent Different • Sometimes Management Management File Technology Application Host Computer Management Station/ Console Managed MIB Process

Management Agent LOG

Host Computer

Managed Devices and Processes

A management application talks to managed devices and processes using interprocess communications, e-mail, or file redirection.

• A management station or console is what operators look at. It provides a system interface for central network support staff. • The programs used by central support staff are known as management applications. They gather information from, and control, devices and processes in the network. Management applications run in a management console. • A management agent is a piece of software that runs along with the device or process being managed. It connects the managed device or process to a management application, which in turn interacts with the operator via a management console. • Management agents maintain a database reflecting the status of the managed device or process. This is known as a management information base, or MIB. A MIB is itself a model of the device or process it represents. • Management agents also keep a log of things that have happened to the device they manage. This is usually just a list of ASCII records. • Information and commands going between management applications and agents are put into a standard format, or protocol. The best known management protocols are SNMP and. CMIP. Transfer takes place by interprocess communications, or by e-mail messages. • Sometimes a management agent hasn't been designed to converse with a management application, in which case the latter probably uses file redirection to access a remote log or MIB. • Devices that are managed using a different technology are connected by means of a program called a proxy agent. This is a gateway between different management technologies. One management station can control many agents, and manage many devices and processes. Similarly, several management stations can manage a given agent, although, of course, this may create problems if not done carefully. For example, an MTA located in Los Angeles could be managed by a station in New York during East Coast business hours, from Hong Kong during Far East business hours, and from London the rest of the time.

Why Management is Often Proprietary Ideally, it would be possible to buy management applications and management agents from different manufacturers. For example, you might have MTAs from a variety of different manufacturers, which is likely to mean they have different management agents and applications.

255 11 Messaging Management

You'd ideally like to be able to use a single management application tool to manage all the different MTAs and their agents. The main problem with separating applications from agents is the following: The application displays information about the managed device. It's not hard to see that, say, a managed modern will need to have different information displayed than a managed MTA. Even two MTAs from different manufacturers may need to h ave different information displayed. Thus a general-purpose management application needs to be able to display device-specific data. It should also be extensible to display data for new and different devices. This can be done with SNMP technology, and we'll see below how.

SNMP Management SNMP, or Simple Network Management Protocol, was developed in the Internet world, initially as an interim measure, to be used until the more sophisticated CMIP was ready. The architecture and terminology of SNMP is similar to that of figure 11.1 above, with the notable exception that the management application/agent protocol runs over interprocess communications. In particular, it runs over a TCP/IP transport. There's no use of e-mail or file redirection.

The Protocols SNMP protocols provide three types of operation: • Get allows a management application to ask a management agent for the value of a particular variable (eg, the number of messages transmitted or number of errors encountered). • Set allows the management application to tell the agent to set a particular value for a certain variable (eg, the number of messages in a queue which, when exceeded, generates an alarm). • Trap is a signal from the management agent to the management application. It's typically some sort of alarm. Everything is designed to keep things simple: • No commands containing verbs (such as: reboot system) are sent to the management agent. Instead, a variable indicating the command to be executed is defined in the managed device's MIB. For example, a variable called reboot system might be defined in a managed device or process's MIB. If reboot system is set to 1, the managed device

knows to reboot. Thus, the reboot action is accomplished by sending a set command indicating that the reboot system variable is to be set to 1. When the MIB is duly updated, the managed device or process reboots and then sets the variable to 0. • Protocols are passed over an IP (as in TCP/IP) connection. They are dispatched over the network with almost no checking that they've been received. The intention is both to impose minimal overhead on a network, and to increase the chance that management messages get through in a failing network.

Reasons for Popularity SNMP quickly caught on because: • It is simple to implement. • Device (routers, etc) manufacturers could get source code for agent software that they then could integrate directly into their product, typically at no or little cost. • A device manufacturer does not have to worry about implementing a management application. The agent can be managed by a number of third party products, such as HP's OpenView Node Manager and Sun's SunNet Manager.

• At the time it came out, it was the only management standard

available. SNMP Versions SNMP comes in two versions: The specs for version 1 were released in 1990 and 19 9 1 in RFCs 1155, 1212, 1157, 1213. The specs for version 2 were released in 19 9 3, in RFCs 1441 through 1452. This version is often referred to as SNMPv2. SNMPv2 is based on the experience gathered with version 1. While backward co m patibility was a goal, it was not completely met. But vendors supplying SNMPv2compatible devices can easily make them talk both dialects. Some of the differences between SNMPvl and SNMPv2 are: • Under SNMPvl, it is hard and wasteful to get devices and management stations to exchange large amount of data. SNMPv2 has primitives to make that simple. • SNMPv2 contains many security enhancements, including encryption, authentication, parties, tokens, and time windows. • SNMPv2 improves the manager-to-manager communication, allowing the setup of networks with hierarchical management. • SNMPv2 makes it easier to run SNMP over non-TCP/IP networks, such as SPX/IPX (used by Novell NetWare) and OSI environments.

257 11 Messaging Management

Plus there are a large number of other smaller improvements. Nevertheless, SNMPv2 has been slower to catch on than SNMPvl. Most vendors currently implementing SNMP are using v1.

Ge neral-Purpose Management Application Environments Thus, management applications use the SNMP protocol to converse with management agents. There are many different devices to be managed, and hence there are potentially many different management applications. For example, one to manage a router, one to manage your ethernet cards, one to manage your token ring hubs, one to manage your 3270 controllers, one to manage your MTAs, and so on. The trouble is, all these programs have to be used by help desk staff. It gets confusing to learn them all, since they all work in different ways. Plus, help desk staff will never get familiar with the more rarely used parts of a given management application. So it's strongly desirable to give management applications a consistent look and feel. This can be done using a general-purpose management applications environment. Hewlett-Packard's OpenView Node Manager is the leading example in the SNMP world, followed some way behind by Sun's SunNet Manager. In the SNA world, the aging and clumsy NetView predominates. OpenView Node Manager and SunNet Manager provide the entry interface for ma nagement applications, akin to the top layers of a menu hierarchy. They define a standard style for applications, including pull-down menus, GUI icons, and so on. OpenView Node Manager runs on Unix workstations and PCs running Windows, and hundreds of vendors have written management applications to work within it.

Vendor Enhancements SNMP has a number of shortcomings, and as a result, vendors frequently add proprietary goodies. For example, most implementations currently in use are SNMPvl, with no security to speak of. Some vendor-specific enhancements have included: • Requiring that critical operations be done using a tool other than SNMP, eg, Telnet, dialup login, or a proprietary management protocol. In such cases, the MIB may be written to be allow only get operations (see MADMAN below). • Restricting the agents to accept commands, in particular set commands, only from pre-configured addresses. • For critical operations, such as shut down everything, requiring commands in

a particular order, or requiring that some apparently unrelated parameters be first set to particular values. An impostor would presumably not know the combination.

CMIP CMIP, or Common Management Information Protocol, is the ISO/CCITT standard for network management. It's a lot more sophisticated than SNMP. The data structures are more complex, there's much more intelligence in the network, good security, and so on. CMIP was originally intended to run over an ISO transport, although it can also run over a TCP/IP network. We will not describe CMIP in further detail. As a practical matter, it has not caught on, and for better or for worse the technology has been supplanted by SNMP.

Summary • SNMP and CMIP are standard general-purpose tools used to build monitoring and control systems for network components. • They don't define specific management facilities (and in particular, message management facilities) any more than a programming language defines a specific applications program. Vendors build their message management products on top of SNMP and CMIP. • CMIP is a lot more sophisticated than SNMP. • SNMP is very widely implemented and is very popular. • Despite SNMP's ever-more-visible shortcomings, CMIP has almost no market penetration and is not picking up steam.

11.2 Messaging Management Standards We now examine the main attempts to define standard messaging management. Here we get much more specific about what the managed devices and processes are. The main objects of interest are: • User e-mail accounts • User programs (when mail-enabled) • Messages, message stores, and bulletin boards • MTAs, their queues, and MTA-MTA connections

259 11 Messaging Management

• Gateways and their queues • Directory servers and distribution lists • Service providers

MADMAN's MTA, DSA, and MS MIBs In January 1994, a number of people interested in both X.400 and Internet technologies published three SNMP MIBs which could be used to monitor a messaging system: • A network services monitoring MIB, defined by the Internet standard RFC 1565. This is a general set of functions needed for monitoring many applications, not just messaging applications. • An MTA monitoring MIB, defined by RFC 1566. • An X.500 DSA monitoring MIB, defined by RFC 1567. The team that developed the specs adopted the intriguing acronym MADMAN, which stands for Mail and Directory Management Working Group.

Network Services Monitoring MIB The goal here is to monitor applications that provide network services, of which MTAs and DSAs are examples. The MIB lets you do things like measure system loads, detect broken connectivity, isolate system failures, and locate congestion. No security assumptions are made, so access is only in read-only mode. There's no ability to control the managed system, nor to let the managed system generate alerts. The MIB contains a series of counters for every network application running on the system, and summary information about each active connection (figure 11.2). It's very much an infrastructure MIB, mainly used to build other, more application-specific MIBs. The functions on offer are deliberately minimal, and designed to be needed by a wide variety of specific network applications.

MTA Monitoring MIB This monitors X.400 MTAs, and MTA components within gateways. Along wi th the network services MIB, it provides a series of counters describing an MT A's current status (figure 11.3). MTAs are often clustered into groups, eg, where several work off the same outbound message queue. For each group, much the same information is stored about

FIGURE 11.2 MADMAN'S NETWORK SERVICES MIB ctiveAsg

Name Name or IP address of remote system Application name used in X.500 directory Protocol used for communication Software version Application type (UA-initiator, US-responder, Time when application was last initialized peer-initiator, peer-responder) Operating status (up, down, halted, congested, Time the association started or restarting) Time when entered current operating state # current inbound associations # of current outbound associations Total # inbound associations since initialization Total # outbound associations since initialization Time o f last inbound association Time of last outbound association Total # of rejected inbound associations since last initialization Total # of rejected outbound associations since last initialization

This M IB lets you see summary information about a network application, as well as current connections the application has.

its current status. The "group" concept tries to allow for the fact that different MTA vendors may structure their products differently. For some vendors, the group and an MTA will be equivalent.

X.500 DSA Monitoring MIB This monitors an X.500 DSA. A DSA, or directory system agent, is software that controls an X.500 directory, and which can respond to directory requests either by accessing its local directory, or by interacting with other DSAs and their directories. This MIB provides (figure 11.4): • Summary statistics about a DSA's accesses, operations, and errors • Summary statistics on a DSA's current entries and cache performance • For each of an administrator-specified number of peer DSAs, summary information about how the managed DSA has interacted with the peer DSA

Host Resources MI This MIB, defined in RFC 1514 in September 1993, provides for management of the computers that provide network services. It's designed to be independent of the operating system and the network services. It was not designed by the MADMAN people, but is a nice complement to the work.

261 11 Messaging Management

FIGURE 11.3 MADMAN'S MTA MIB

iron rmetton

Name of the group # messages received since initialization # messages rejected since initialization # messages currently stored in the MTA # messages currently stored in group's queue # message transmitted since initialization # message transmitted since initialization Total # KBs of messages received since initialization Total # KBs of messages received since initializa- Total # KB of messages currently stored in the MTA tion Total # KBs of messages sent since initialization Total # KB of messages currently stored in group's Total # of recipients of all messages received since queue initialization Total # of recipients of all messages currently Total # of recipients of all messages currently stored in group's queue stored in the MTA Total # KBs of messages sent since initialization Total # of recipients of all messages sent Total # of recipients of all messages received by since initialization group since initialization Total # of recipients of all messages sent Time since oldest message in queue was placed since initialization there # current connections to the group, where group is responder # current connections to the group, where group is initiator Total # connections to the group since initialization, where group was responder Total # connections to the group since initialization, where group was initiator Time since last inbound association Time since last outbound association Total # rejected inbound associations since initialization Total # rejected outbound associations since initialization Reason for last rejected inbound association

The MTA MIB mostly provides counters for a managed MTA or group of MTAs. It's used with the network services MIB.

Unlike the MADMAN MIBs, it's read/write; ie, many of the managed objects can be assigned values as well as monitored. A very large number of things can be managed. For example: • The system date and time • Place where the OS boots from • Types of storage available, and size of each type • How storage is being used, covering disk partitions, file systems, RAM, virtual memory swap space, and so on • Device-specific information relating to printers, video cards, modems, mice, tape drives, and so on

FIGURE 11.4 MADMAN'S X.500 DSA MIB

din •Entriest:i< actr

# anonymous connections from DUAs # master entries since startup # entries for which copies are maintained in the # unauthenticated connections since startup DSA # cached entries # authenticated connections using simple # entries serviced from cache since startup authentication since startup # operations serviced from local shadow # authenticated connections using strong entries since startup authentication since startup # atte mpted connections rejected due to wrong authentication

rain X.500 name of the peer DSA Time this entry was created # operations forwarded from DUAs or other Time of last attempt to connect to this DSA DSAs since startup Time of last successful connection to this DSA # read operations since startup # failed connection attempts since last successful # compare operations since startup connection # add-entry operations since startup # DSA failures since creation of this entry # remove-entry operations since startup # DSA successes since creation of this entry # modify-entry operations since startup # of modifyRDN operations since startup # of list op erations since startup # of search operations since startup # of operations forwarded to this DSA # of one-level-search operations since startup which failed security requirements # of whole-tree-search operations since startup # of operations that failed due to errors . . Outgoing

# of referrals returned since startup # of operations forwarded to other DSAs since startup

The DSA MIB provides summary statistics on accesses, operations, errors, DSA entries, cache performance, and interaction with peer DSAs.

• When the file system was last backed up • The manufacturer, version, and name of running applications • The parameters passed to a running application when it was initially booted • CPU utilization Thus, for the purposes of the MADMAN group, this MIB is useful for configuring and getting information about the machines that are running MTA and DSA processes.

263 11 Messaging Management

Message Store MIB MADMAN hopes to write an X.400 message store MIB, and work is expected to start in 1995. However, no substantial work has been done on this, and no projected publication date for a corresponding RFC is available.

MADMAN Assessment • The MADMAN specs are useful and are rightly getting a lot of attention from vendors. Many products will appear in 1995 and 1996 which support it, and extensions thereof. • The functions supported in the MTA MIB apply to proprietary MTAs as well. So, for example, a MADMAN MTA MIB could be supported by the MTAs used by cc:Mail and Microsoft Mail. • By design, the scope is extremely limited. As they stand, the MADMAN MIBs don't provide a lot of important functions relating to MTAs and directories. Eg, you can't get information on what's happened to specific messages, or who's made directory inquiries, and you can't update MTA routing tables. As a glance at the top ten messaging support tasks (figure 10.2, page 226) indicates, the MADMAN MIBs help with perhaps 1% of messaging management functions. • Thus, while use of MADMAN-based MTA management tools will become common, they will be used in conjunction with proprietary approaches for the foreseeable future. • There's little current industry interest in the DSA MIB, which is a pity. • There's little current industry awareness of the host resources MIB, which is a pity.

Infonet Software's MADMAN Implementation In October, 1994, Infonet Software Solutions became an early vendor to support a MADMAN MIB. (The credit for the first implementation goes to ISODE Consortium.) Infonet offers a range of X.400 and X.500 messaging products. Their Messenger 400 Management Control Center is administrative software running on Unix workstations under Motif. It provides three functions: • XMaint, a program which allows you to configure messaging components such as MTAs, gateways, directory services, and users. • An MTA traffic monitor. This periodically polls a MADMAN MIB. • An alarm handler. This receives and processes alarms generated by system components.

Thus, more specifically, what Infonet Software has done is to implement a management agent in their MTA, and this agent maintains a MADMAN MIB. They have also built a management application which can query the MIB, and this runs within the Management Control Center. Figure 11.5 illustrates how one can request MIB data: the data is clearly from the MADMAN MTA MIB of figure 11.3 above. Figure 11.6 illustrates the graphical display of MIB data. The implementation is not as "pure" as it might be. The Management Control Center accesses the MIB using its own mechanism, rather than using SNMP. Also, there's currently no ability to define thresholds and alerts based on MDA MAN information. Infonet Software sees its work as the beginning of an extended development process. With regard to MADMAN, it plans to provide: r Support for SNMP

FIGURE 11.5 BROWSING A MADMAN MIB

File

Poll interval: 5 minutes Poll Immediately

Gro up: Attribute: TOTAL MTA local Transmitted Messages Received Volume (bytes) Transmitted Volume (bytes) Received recipients Transmitted recipients Failed deliveries

Monitor...

Infonet Software is an early vendor to implement a MADMAN MIB.

265 11 Messaging Management

46255

delta Value cl

0 AlIII t t tttetilistile (byte$)

FIGURE 11.6 PLOTTING MADMAN MIB HISTORY Infonet Software's management application can display MADMAN-based trends.

• Support for the DSA monitoring MIB • A GUT network map, where alerts show in different colors and the user can drill down to get more d etails • More sophisticated threshold-setting and alerts • Support for MADMAN extensions as they evolve, probably through work done by the EMA's Messaging Management Committee

EMA's Messaging Management Committee The Messaging Management Committee had its first meeting in early 1994. It's an informal group of vendors and users, meeting under the auspices of the EMA. Its charter is to define or reference messaging standards that work for a wide variety of different messaging systems, whether proprietary or standard, and whether mainframe-, mini-, or micro-based. In 1994, Microsoft launched a similar effort, called the Messaging Management Council, intended to get key vendors together. Shortly thereafter, the Microsoft- based group folded itself into the EMA group, becoming its technical sub- committee.

The committee has an emphatically pragmatic orientation. It meets frequently, and hopes to have its work translate into real products from 1996 onwards. It is drawing heavily on the work of the MADMAN group, and to a lesser extent on that of IFIP and ISO/ITU people. Many major vendors are fully involved, such as Digital, Hewlett-Packard, Lotus, Microsoft, Novell, and Tandem. There are two main efforts: • One group is producing a user requirements definition. • Another, the technical sub-committee, is defining standards which provide for the re quirem ents defined by the first group.

User Requirements Definition This is a detailed list of management tasks, together with some characterization of the tools needed. First published in May 1994, the tasks are divided into: • Operational management. Dynamic monitoring; data collection for fault analysis, reporting, and forecasting; information query to a foreign domain; message tracing; and user fault management. • Configuration. Discovering and depicting the messaging components; starting and stopping; routing configuration; routing changes; daylight savings time; and moving users. • Administration. Subscriber management; distribution list management; billing and accounting. • Security administration. Access to services; user security services. • Lower-level network management. See the last chapter for a more detailed discussion. The document also prioritizes the urgency of providing support, providing guidance to the technical sub-committee as it develops its specs.

Technical Sub-Committee There are two sides to this: • MTA and limited gateway monitoring. In 1Q95 it is planned to release a definition of an SNMP MIB. This will build upon the MADMAN MTA MIB and define small extensions to it. Additionally, the sub-committee hopes to define a mechanism to enable management application/agent conversations to take place by e-mail as well as SNMP. The e-mail protocol will work in much the same way as directory synchronization protocols, discussed earlier. This approach will greatly enhance connectivity. In addition, the MADMAN MTA MIB will be further polished with regard to its abilities to represent non-X.400 MTAs.

267 11 Messaging Management

• Message tracking. Standards will be defined which provide for locating a message, determining the path taken by it, and so on. To a much lesser extent, the work will also provide for user chargeback. It's envisaged to work as follows: MTA management agents store information into logs. The agents don't have a lot of intelligence, and are not initially expected to generate alerts. A management application traces a message by making requests like "Get me information about message 1132FB1A29318035" to a series of MTA agents.

Assessment • This is important work. The committee has good vendor support, strong momentum, and realistic, high value goals. The effort is likely to succeed, with commercial implementations appearing in 1996. • As we noted in the last chapter, tracking lost or delayed messages is one of the top ten support tasks. Hence the message tracking extensions should be of particularly high value. • The initial work will help with roughly 5% to 20% of management tasks. • The heterogenous nature of the standards is important. In particular, it will mean that a single tool can locate and track a mislaid message, even though it's traversed several different messaging systems. • As the spec evolves, it will be important to add more intelligence to the agents. To make efficient use of the network, it will be important that a management application can supply thresholds, which when satisfied will asynchronously generate and transmit alerts back to the management application. • Other nice enhancements would be to provide control rather than just monitoring; and manage other things beyond MTAs (and routing within gateways).

ISO/ITU X.400 Management The International Standards Organization and Telecommunication Standardiza- tion Sector of the International Telecommunication Union is defining a very extensive set of CMIP-based management facilities for an X.400 messaging system. This encompasses, in rough order of priority: • User chargeback and sharing of revenues between connected ADMDs (also known as settlements) • MTAs

• User agents • Message stores • Security • Configuration management • Fault management • Performance management • Gateways (they call them access units) There's a separate group working on X.500 management, which we shall not discuss. The messaging work here is far more sophisticated than the Internet- and EMAbased work. Very rich models of managed objects are being built, as opposed to simple tables. The definitions are much more rigorous. Plus, you can control the messaging system as well as monitor it: eg, the main commands are get, replace, add, remove, create, and delete. The group anticipates likely publication dates as follows: • Chargeback and MTA, probably late 1995 • User agent, configuration management, message store: probably 1997 • Fault management, performance management, security: probably 1998 • Access units: after 1998 It's a long-term project; the most mature parts relate to chargeback and settlements, and MTA management. All in all, the work is impressive, well thought through, and makes for interesting reading. It may well be a major force in educating the industry on messaging management issues. Unfortunately, it's hard to see the efforts translate into widely implemented standards over the next five to ten years: • The work is hard to digest. It is very comprehensive and requires understanding a lot about other ISO standards. It's much more effort than working through IETF RFCs. • Few people are involved. Meetings often have literally a handful of people, and the number is shrinking. • No major vendors like Digital, IBM, Lotus/SoftSwitch, Microsoft, and Novell participate. It's heavily influenced by ADMDs, and as observed earlier, such vendors are not driving the messaging marketplace. • The work is proceeding slowly. Limited work has been done on fault, security, and gateway management. The work on configuration management, performance management, user agents, and message stores, while often very

269 11 Messaging Management

insightful and valuable, still has a long way to go until it's ready for publication. We suspect that the projected publication dates are optimistic, with the exception of those for chargeback and MTAs.

IFIP E-Mail Management The International Federation of Information Processing Societies, IFIP for short, is a research-oriented group that helps bring active standards-setting processes into being. Since 1983 it has had a group working on e-mail management. The group developed a draft document describing messaging requirements. Then it collected MIBs from Bull, CDC, Hewlett-Packard, Infonet Software Solutions, ISO/ITU, Mitre, SoftSwitch, and Tandem, with a view to developing an all-encompassing, cross-technology IVIIB. The group then realized that its work had a strong overlap with that of the IETF and ISO/ITU. At that point it decided to propose to the ISO/ITU that the latter's work should apply to proprietary messaging systems, in addition to X.400- based ones. This was accepted by the ISO/ITU, and from mid-1994, a lot of the IFIP group's energy has been diverted into assisting the EMA's messaging management activities. A brief aside. The authors would like to thank Sue Lebeck, chairperson of the IFIP e-mail management working group, and also Tandem's main messaging and electronic commerce guru. She helped us understand the various messaging management standards-setting bodies, and the nature of the work being done.

EMA's Inter-MTA Message Trace In 1994, the EMA's Interoperability Committee defined a simple but useful way that e-mail messages can be used to request message traces, and to furnish trace information. The work is now being integrated into that of the EMA Messaging Management Committee's Technical Sub-Committee. It should also be useful for readers who want to implement home-grown message tracing. The idea is that ADMDs and PRMDs: • Set up a mailbox whose address is S= messagetrace • Provide automatic or manual generation of the trace information • Reply within 4 hours of receiving the trace request, during normal business hours

Trace Message Request Format Address the trace request as follows: • Set S to messagetrace. • C and A are set to recipient's country and ADMD. • P, 0, OU's, and DDAs are optional, used as needed to define the receiving organization or messaging system. The subject is set to Message Trace. The body of the message contains a definition of the message to be traced. It contains MPDUID: followed by the originator's message ID. Optionally, it may also contain: • Originator O/R Address: followed by the originator's O/R address. • Recipient O/R Address: followed by the originator's O/R address. • Date: followed by the date the message being traced was submitted to the MTA. • GMT: followed by the time the message being traced was submitted to the MTA. For example, the message body might be: MPDUID: 51803161403991/2565791CSTEAM Originator O/R Address: G=john; S=smith; P=acme; A=mci; C=us Recipient O/R Address: G=sue; S=jones; P=bigcorp; A=attmail; C=us Date: 16-APR-1993 GMT: 15:31

Trace Message Reply Format The following information should be returned in the message body: • MPDUID: followed by the message ID • Date: followed by the date the message being traced was submitted to the MTA • GMT: followed by the time the message being traced was submitted to the MTA. In addition, the following types of delivery information should be provided: • Message not delivered, and reason • Message delivered • Message transferred/relayed to another domain

271 11 Messaging Management

• Message still in queue to be delivered and reason The format of the delivery information was not defined.

DMTF, Document Management For completeness, we should note that industry efforts are under way to define general management for intelligent workstations (by the Desktop Management Task Force or DM11,), and to define document management standards. These activities have little current connection with the messaging management initiatives we've just discussed, although more collaboration can be expected in the future, especially as Microsoft integrates its "universal mail client" into Windows.

11.3 Some Important Mail Management Products We now look at some important management products, to illustrate what sort of tools are available, and what the major trends are.

Probe Monitors One way to get a sense of mail system performance is by sending out small test messages—known as probes. A central poller program dispenses the probes, and sends them either to remote mailboxes, or to special mail network components like gateways or MTAs. You also install reflector software provided by the monitor's vendor, and this is placed in the machines that are sent a probe. When a probe arrives at a component being tested, it's then bounced back to the poller by reflector software, along with information like the mail system name, version, arrival time, and so on. Finally, a monitor program oversees the process. If a probe doesn't return, or if it takes a long time to get back, the monitor knows there are problems and generates an alert. Probes are automatically sent at administrator-defined intervals. Administrators also define reply times and corresponding levels of urgency. Figure 11.7 illustrates a main monitor screen. For example: • A reply within 20 minutes might be deemed normal. • A reply after 20 minutes but not after 30 minutes might be deemed dubious, worthy of attention, but not yet critical. • A reply after 30 minutes might be deemed a failure and needing immediate corrective action.

FIGURE 11.7 MAILCHECK'S MAIN MONITOR SCREEN

MailCheck File Display Mailbox Alerts Help .1.. „km:M.•..."4.1:4**:-W...

• MR4St . . .

7 • • •• OK Berkele Office OK Chicago Office X Port Frederick Office h. OK San Francisco Office ve Santa Teresa Office

The main function of a probe monitor is to indicate whether message connections are working.

There are two main probe-based monitors to be aware of Lotus/SoftSwitch's Mail Monitor, and Baranof Software's MailCheck. Both are suitable for enterprise networks made up of different types of mail systems.

How Probes Are Used If a probe doesn't return in time, several things can happen: • The monitor may send out an alert, by mail or pager. • There may be a graphical diagram of the mail network, in which components change color corresponding to their state. • Event logs (figure 11.8) will also have exception entries tagged in some way. Event logs also are valuable for spotting trends. Typically this means noticing that response times are gradually getting longer, so you can take action before users notice anything. Various tools are provided by the monitor to dig out the information, and you can also export data to external tools like a spreadsheet, database, or graphics package.

273 11 Messaging Management

Types Of Probe In the normal scheme of things, a probe should be returned by reflector software. This yields the most information, and the most reliable information. Sometimes reflector software is not available to test a mail system. If the system to be tested supports auto-forwarding, probes can be sent to a dummy mailbox that has been created just for the monitor's use. Auto-forwarding is then configured so that arriving probes are sent back to the poller. This situation yields less useful management information than by means of reflectors, and it may not test all of the path through to the destination. If neither of the preceding are possible, the poller can send out a probe with a deliberately invalid mailbox address. At some point, the probe should be returned as undeliverable. This approach is the least attractive, due to: • False echoes. Here a mail system along the path of the message recognizes that the address is invalid, and returns the probe. The monitor mistakenly assumes the end mail system has returned the probe. • Gateway security. Often gateways maintain internal address tables. When the probe arrives with the invalid address, the gateway returns it. In short, the

FIGURE 11.8 EVENT LOG FROM LOTUS/SOFTSWITCH'S MAIL MONITOR somin______

Agent Minns t, Actions elect Agent Help CENTRAL PROBE INFORMATION 05/05/92 10:43:32

LITErfAl IL1111 Et ?Ft DDEF.; cifitEd Dant OvonJun "runnuut Ab !undo', - 1r."rypg flare TIM& Twit, Titta R 10:44:02 10:44:02

COMPLE TEL ?RODE; Ear.tta E:unt TilhEt Dutripl tn ti -11171 Et El UP verdue OS/04/92 09:24:26 88/04/92 10:09:54 00:4S:28 05/04/92. 00:23338. 05/04/92 439:09:16— 00:45:58 Werdue . 05/04/92 07:21:43 05- /04/92 08:24:04 01i00 i21 imedout . . oepdUe 05/04/92 08:28'7:12 OS/04/92 07:26:04 0159:52 imedoot OS/04/92 05:28:42 06/04/92 06:32:03 01:03:21 05/04/92 06:04:26 01:38:S2- iMednof - 05/04/92 04:25:34 . uerdoe 05/04/92 03:23:31 05/04/92 03:55:31 00:33:00 . . 00:23.7.41- ez4o. rw.iiC 05/04/92 02:23:45 05 /04/92 02:47:26 05. /04/92 01:28:22 00:05-:11 OS/04/92 01:23:11 - eesponive 05/04/92 12:21:15 05/04/92 12:25:11 00:01 :36

Char.,

Here we see the main event log screen in Lotus/SoftSwitch's Mail Monitor. This can be queried in various ways to gather performance management information.

probe never gets a chance to be returned by the mail system it was intended to test.

X.400's Built-In Probe Support X.400 has the concept of a probe, and has built-in reflectors. When an MTA recognizes a specially formated X.400 probe message, it generates a normal delivery or non-delivery notification. However, commercial products make little, if any, use of this feature.

Strengths • Probe monitors are easy to understand, install, and use. • They give a good overall indication of how quickly mail is being delivered. • Using history logs, you can spot trends and plan for future system upgrades before users are aware of any bottlenecks. • You can also determine when system peak times are (although other methods are better).

Weaknesses • Probe monitors only give a rough measure of overall mail system performance. They only take periodic samples, and they only measure delivery times of the probes themselves. So some messages can still be seriously delayed, while the probe monitor shows everything to be normal. • Operation can be expensive if you're checking connections to external systems. Service providers charge the same for probes as for normal messages. We now make some quick observations on the two main probe monitors available today.

Baranof Software's MailCheck

Strengths • Has the best selection of e-mail reflectors for non-legacy systems. Reflectors are available for cc:Mail, Notes, MS Mail/PC, MS Mail/Appletalk, SMTP, UUCP, BeyondMail, Da Vinci eMAIL, GroupWise, Notework, other NetWare MHS systems, AT&T Mail, MCI Mail, UUNET. • Low entry cost. The pricing varies on the number of message stores. It

275 11 Messaging Management

typically works out to about $3.00 per user. Plus you'll probably want a dedicated PC to act as the monitor. • Simple to understand, learn, and use. • Easy to install. • Flexible configuration of alerts. It's easy to specify when alerts of a particular type should be generated, and whether they should be delivered by e-mail, pager or other means. • Hierarchical groups and multiple views allow each operator to have a customized view of the network. • A series of useful reports analyzing system history are included, such as outage and response time reports. These can be customized to some extent.

Weaknesses • No drill-down network map available for message direction troubleshooting • No reflectors available for older mail systems including PROFS/OV, All- In1, or Wang Office • Limited traffic statistics available, such as average number of messages per hour, average message size, and so on • No ability to analyze MTA logs

Mail Monitor by Lotus/SoftSwitch

Strengths: • Well-designed, rich set of functions. • Good reflector support for legacy e-mail systems. • An easy add-on for existing users of SoftSwitch Central or LMS. • Draws a map of the mail network indicating its status. You can drill down to underlying components. • Has a Windows API—a set of SoftSwitch-defined DDE primitives—which make it relatively easy to build custom reporting and analysis tools.

Weaknesses: • If you don't have LMS or Central, you're out of luck (you'd need to install LMS or Central, which would be an unacceptable cost for a probe monitor). • Relatively high entry costs of $25,000 for LMS-based systems, or $40,000 for Central-based systems. In other words, if you're already a Lotus/

SoftSwitch LMS customer with 10,000 mailboxes, figure $2.50 per mailbox, or $4 per mailbox if you're a Central customer. • Designed for enterprise backbone support, so installation and maintenance assumes familiarity with more complex concepts such as LU 6.2, SDLC, DGN.DENs, TCP/IP, etc. • Few reflectors are available for PC and Mac e-mail systems; so you can't reliably probe deeply into them.

Log Monitors As we've seen, probes are a very useful way of getting a rough picture of what's happening in an e-mail system. A complementary approach analyzes the system logs generated by MTAs. Every time an MTA does something to do with sending a message, it appends a description to its log file. Typical log entries give general information on: in- transit messages (how large one was, when it was sent, who it was sent to, etc); messages that couldn't be delivered; poll attempts; and broken transmissions. This is extremely valuable management information. The trouble is, it's difficult to read logs. Also, the various logs in an messaging system aren't coordinated, so you have to look at them one at a time, and work out for yourself how the data in one log relates to that of another. What you really want is the centralized ability to process log information. Most of these products are proprietary, ie, they only work with a given messaging system. Two good examples are Lotus' cc:Mail View, and Automated Business Solutions' Gateway Manager. These both work with cc:Mail. Infonet Software Solutions' Management Control Center also contains a log monitor, as discussed previously in connection with MADMAN.

Strengths • Message log information is rendered easy to read, and is very valuable for fault management and capacity planning purposes. • Unlike probe monitors, the data gathered is the actual data, not an estimate. Delivery times are actual message delivery times. • Error alerts give specific information about what caused the error.

Weaknesses • Unlike probe monitors, they're currently limited to a given e-mail system.

277 11 Messaging Management

• Processing times are sometimes excessively slow. Each message generates about 1KB of log information, and 10,000 users typically generate around 4GB of management data per month. Some reports requiring consolidation of all this information take too long to run.

Lotus' cc:Mail View This product, initially released in December 1994, monitors MTA-MTA connections, dialin user connections, message queues, message stores, and directory propagations. The information is displayed on graphical maps (figure 11.9), and you can drill down to get detailed information (figure 11.10). The system automatically gathers a lot of the information it needs (a process commonly known as autodiscovery), which is a big aid to defining and maintaining maps. You can set simple thresholds. For example, the ones you can define for MTAMTA connections are: • The error transmission rate exceeds X% • A connection attempt failed • A LAN call lasted more than X minutes • A telecom call lasted more than X minutes • A router failed to send more than X% of its messages Actions can be defined for each of these. Icons can be displayed in different colors on the map, the program can beep, an alert box can pop up, special objects can pop up on the map, and warning messages can be sent to specific staff by e- mail or pager. Many charts and reports are provided, and it's easy to generate a wide variety of custom reports.

How It Works A special mail management mailbox is created somewhere in the cc:Mail network. This acts as a central receptacle for mail management information: • Whenever a directory propagation takes place, information on how it took place and whether the propagation was successful is sent in. • Periodically (at administrator-specifiable times), each MTA mails in summary information about the various connections it has made recently to other MTAs. Ie, it sends in its connection log, and then resets the log to empty. • Whenever an MTA mails its connection log in to the central mailbox, the information is accompanied by summary information about message stores

FIGURE 11.9 CC:MAIL VIEW'S NETWORK MAP

-0-MN.OVONDEVOtEfitiV=TE2 LrM

•. .4?)6.--%;44;** :

---

Administrators can define a series of maps. Much of the information is automatically provided by cc:Mail View.

local to the MTA and their queues. On arriving at the central mailbox, the messages are read into a user-friendly database package (initially this is Lotus Approach). This database is then monitored and information is duly presented to the system manager. Enhancements envisioned by Lotus include: • The ability to drill down through a hierarchy of maps. This is important for large systems with many different components. Right now, a map can't take you to another map. • The ability to define a much wider variety of thresholds. • SNMP support, so standard SNMP-based monitors such as Hewlett- Packard's OpenView Node Manager can see the information. • Support for other databases, notably Sybase and Oracle.

279 11 Messaging Management

FIGURE 11.10 DRILLING DOWN FOR MESSAGE STORE DETAILS WITH CC:MAIL VIEW

.4:4WAttf>vr. • VN:?445:*, 'IiireatliNREWJAZAPEL6413N1

......

Pjfice

lumber of enbiiesm the Frae Space Table

. att lumber' el% Local%mailboxes in use:

...... r}tifisx it

Summary information about connections can be obtained by drilling down into map icons.

• Integration with Lotus' upcoming LCS.

Strengths • Gives a lot of valuable information • Gives timely alerts for a lot of problems • Good connectivity, since management information is returned to cc:Mail View by e-mail • The custom report and chart generation facilities are very

useful Weaknesses • With the exception of directory propagation messages, no message-specific information is available. So, eg, you can't track a lost message, or bill back to individual users based on usage. • It's only a monitoring tool. You use other tools to control the system, and

these are not integrated with cc:Mail View. • It doesn't present a real-time picture. Eg, if MTA logs are sent in every half hour, it might take that time (plus the time to deliver the information to the central mail management mailbox) to determine that something's gone wrong. • It's a new product, and as such will gain a lot from initial enhancements. We particularly look forward to multi-level map hierarchies, and more sophisticated threshold-setting.

ABS' Gateway Manager Automated Business Solutions' Gateway Manager is a suite of products which lets you do things like: • Receive alerts whenever cc:Mail MTAs experience any sort of error, such as: MTA halted, MTA-MTA link broken, message store not available, or dial-in voice call • Track what happened to a message: how it went through the network, how long it took, and so on • User chargeback • Determine what your dialup links are costing Alerts typically arrive about a minute after their triggering event. A wide variety of reports are provided, including system-wide message delivery times, MTA activity (useful to determine bottlenecks and load balancing), message store outages, peak traffic periods, MTA-MTA transmission speeds, and the amount of traffic passing between different message stores. The pricing is by MTA, and on a typical network you'll end up paying around $5 per mailbox.

How It Works Gateway Manager monitors each MTA log, using file redirection (eg, it connects its F: drive to a remote directory containing an MTA's log file, and reads that log file). If an MTA stops working for any reason, or connectivity is lost, the monitor senses the lack of activity and generates an alert. Reporting takes place by consolidating all the different log files into a central Paradox database, and processing using conventional database techniques.

281 11 Messaging Management

Strengths • It gives you a very up-to-date picture of network operations. Alerts are generated quickly. • You can track what's happened to specific messages: how long it took, the route it took through the network, and so on. • The product has a very wide variety of mail management tools. It's been seasoned by extensive use by many large organizations.

Weaknesses • The monitor needs to be able to connect its F: drive to remote file servers which contain MTA logs. So, for example, it can't work through MTA- MTA dialup or X.25 links. • Gateway Manager provides a good selection of reports, but there's no custom report generation capability. • It can't display information via a network map, which can be drilled into for further details.

11.4 Key Future Developments We now present some thoughts on how mail management will evolve over the next five years.

Limited Cross-System Management Today, each messaging system must be managed using its own set of tools. For example, if you're connecting PROFS/OV, cc:Mail, MS Mail, and SMTP messaging systems over an X.400 backbone, you need at least five sets of tools, four for the four systems being connected, and at least one for the backbone. If you're using X.400 backbone products from different vendors, you'll probably need as many sets of tools as you have suppliers. For the next five years, don't expect this to change. Most messaging management will be proprietary, with the following exceptions: • The work being done by the EMA's Messaging Management Committee will result in limited common management, notably MTA monitoring and message tracking. • Where an environment sticks to X.400 user agents, with X.400 and X.500 tying everything together, with all products from a single vendor, common management is possible.

• Where a common transport replaces that of non-X.400 messaging systems. Here we are particularly thinking of Hewlett-Packard's OpenMail, where an SNMP- or X.400-based transport moves messages prepared by cc:Mail and MS Mail clients.

Better Intra-System Utility Integration Today, most individual messaging systems make you use a variety of different tools that work in different ways. For example, cc:Mail has one program to administer the directory and directory propagation, another to reorganize message stores, another to configure each MTA, and another to monitor MTAs. This makes it harder to learn the environment, since the different tools typically have different looks and feel. There is thus growing momentum to consolidate managements tools within a messaging system. For example, Novell GroupWise has an administration program in which most configuration is done, including user adds/changes/moves/ deletes, directories administration, and gateway administration. Likewise, most management of Lotus/SoftSwitch's LMS X.400 backbone is done using a single management tool, EMM.

Standard MIBs With Proprietary Extensions Many vendors will move to storing management information in SNMP-style MIBs. However, much of the information they store will not be standard in nature. To use the information, you'll have to use special utilities and these will normally be provided by the vendor.

Growing Use of SNMP Remember, use of an SNMP-style MIB doesn't necessarily imply you use the SNMP protocol to let a management application access MIB information. As we saw, we are at early stages of migration to standardized SNMP-style MIBs, and many early implementations use proprietary mechanisms to access MIB information. Infonet Software's Messaging Control Center is one example.

283 11 Messaging Management

Use of General-Purpose Management Application Environments Nevertheless, support for SNMP will become widespread. This will facilitate the use of general-purpose management application environments from third parties, notably Hewlett-Packard's OpenView Node Manager and Sun's SunNet Manager. These provide a common set of tools which can be used to monitor and control SNMP MIBs. This is much easier on help desk staff, since they don't have to learn a lot of different management applications, one for each vendor's managed device or software. They can be a lot more effective when handling unpredictable user problems.

Control and Configuration With Proprietary Applications However, it's hard to see products like OpenView Node Manager and SunNet Manager being widely used for control and configuration purposes, because of the lack of security. Proprietary applications will continue to be used for this.

Proprietary Applications Under OpenView Node Manager In due course, a number of vendors can be expected to rewrite their management control utilities so that they run in a general-purpose management applications environment. OpenView Node Manager is the primary and most attractive candidate, due to its widespread deployment. IBM's NetView is another possibility. But the crudeness of the user interface, plus the fact that the product is seen as a dying mainframe- and SNA- oriented technology, will deter vendors from making it a priority.

Use of Applications-Oriented Management Environments We've noted at several places that it's attractive to have a general-purpose management applications environment, within which different management applications—for modems, routers, 3270 gateways, MTAs, etc—can operate. This gives them a common look and feel, and makes help desk staff a lot more productive because the learning requirement is much less. The dominant player in this field, Hewlett-Packard, argues that its OpenView Node Manager is really best suited to the management of low-level network communications devices, like wiring hubs, routers, modems, network cards, telecommunications links, and so on. The company believes that applications, including e-mail

and messaging, require a different sort of operator interface, and to meet this need it offers its Open View OperationsCenter. The idea of an applications-level general-purpose management application environment (get that for a mouthful!) is a very interesting idea, and very plausible. There's a good chance that the concept will become popular. So we now present a summary of OperationsCenter and how it works.

HP's OperationsCenter OperationsCenter is designed for two main types of users: • Operators, who lack much detailed knowledge of the application being managed. They basically do housekeeping and unskilled support tasks. • Administrators, who can make major configuration changes. Each user is presented with options tailored to their particular roles and access privileges. They are only presented with notifications, programs, and so on relevant to the application being managed, and to the operator's responsibilities. Thresholds, alerts, and drill-down network maps can be defined. Users are presented with four main windows (figure 11.11): • Managed nodes. This displays a general drill-down map of the objects being managed. • Message groups. This provides a way of accessing notifications by their type. Eg, the operator can inspect all warnings about slow message queues, or congested message stores, and so on. • Application desktop. This displays the main management applications available to the user. Examples might be "Backup message stores" or "Run directory synchronization." • Message browser. This allows the operator to browse through management notifications and alerts. OperationsCenter uses services provided by OpenView Node Manager. It runs on a Unix workstation under Motif, and managed nodes use remote procedure calls to send alerts to the server. The product doesn't require the central management application to constantly poll remote devices. This generates too much overhead traffic in larger networks. In- stead, OperationsCenter uses intelligent agents, which check for thresholds being passed and then, if appropriate, send a notification back to the central console.

285 11 Messaging Management

Most Management Will Remain Proprietary A wide variety of tasks are involved in supporting a messaging system. They were discussed in detail in the preceding chapter, and include such things as adding/changing/moving/deleting accounts, developing management utilities, handling ad hoc user application questions, advising on how to get returned mail through, tracking down lost or delayed messages, installing software, training, troubleshooting workstation software and hardware, resolving incorrect directory lookups, and so on. The standards-based work currently in process (with the exception of that of the ISO/ITU) is very limited in scope. Its main value will be in tracking lost or delayed messages, and in generating timely alerts for certain important types of network congestion. However, the majority of messaging support tasks, and indeed the majority of messaging management support tasks (ie, those performed by central help desk staff), will not be much affected by the standards work. Long term, no doubt the scope of messaging management standards will be greatly extended. But for the next five years, don't expect them to bring about a revolution in messaging management. Look rather for valuable incremental improvements.

FIGURE 11.11 HP'S OPERATIONSCENTER

HP believes that applications such as messaging require a much more structured interface for help desk operators.

11.5 Top Ten Performance Bottlenecks, & Solutions Because of the importance of delayed/lost message handling, we end the chapter with a discussion of the main things that cause messages to delayed, and what can be done about them.

Large File Transfers The average mail message today—just the textual part—is around 1KB. Some- times people send file attachments. Normally these are quite short; of the order of 10 to 20KB, bringing the average up to around 2.5KB. As people move round more and more attachments, the average size is growing rapidly, however. Problems arise when someone sends a 2MB or 20MB or 200MB file. The e-mail system looks like a snake gobbling something larger than itself: a great bulge sweeps through the system—or tries to. A number of problems arise, but here we focus on the fact that WAN links get swamped. A typical WAN internetwork link operates at 56 kbit/sec. This is shared with other network applications, not just e-mail. A 3MB message being transferred over it will take around 1,000 seconds-17 minutes—to get transferred between two MTAs over the link, and that's if there's little other traffic over the link. So in practice, a 3MB transfer will often take 30 to 50 minutes to go over a given WAN link. This means the sending user doesn't see their message arriving quickly, especially if it has to traverse several WAN hops. However, the real problem is that most MTAs only handle one transfer at a time. So while a big transfer is going on, other users' messages pile up in the MTA's outbound queue, waiting to be sent. The situation is actually worse than this, because: • If there's a glitch in the transfer, many MTAs will re-establish the connection, and restart the transmission from scratch! What's needed is the ability to continue the transmission where it left off. • Delays are obviously longer with dialup lines running at 2.4 or 9.6 kbit/sec. A 3 MB file typically takes between 50 and 90 minutes to traverse a 9.6 kbit/sec link. To conclude: large files take a long time to pass though an e-mail system, and as they do, they hold many other messages up.

287 11 Messaging Management

Solutions • Set up multiple MTA processes, all working against the same outgoing queue. Configure different channels, corresponding to fast and slow lanes. Urgent messages with high priority under 250KB might go on one channel; urgent messages over 250KB on another; other messages over 250KB might automatically be sent on a low priority channel overnight. • Put in faster WAN links. At the very least, 2.4 kbit/sec modems should be upgraded to 9.6 kbit/sec ones (or faster). • Warn users about the problems of large file transfers, and ask them to send large files with low priority whenever they can. If you can, configure your MTAs so that low priority traffic goes overnight. • Educate users to send large files only to people who really need them. Often it's enough to put a file in a shared location, notify people it's there, and then let them copy the file with utilities like DOS' COPY, TCP/IP's FTP or ISO's FTAM. These utilities also have the benefit of not clogging up MTA sessions. • Some MTAs and gateways let you define limits on the size of attachments. Some mail administrators turn back anything over 500KB, for example. Not an optimum strategy for harmonious user relations, however. • Encourage users to compress files before sending them. Most PC files will be cut in half with no loss of information. Using algorithms like JPEG and MPEG, video and graphic images can be reduced to as little as 1% to 2% of their size. • Put in faster MTAs. Often a 486 machine can pump through twice the load of a 286.

Message Store Congested/Full Disk storage along the transfer path can run out of space. If you're unlucky, this means the MTA along the transfer path, or the receiving message store, hangs. In which case, all messages trying to get through the failed component are blocked, until the problem is diagnosed and corrected. By Murphy's Law, you can bet this happens on Friday evening, so that either you're paged over the weekend, or all mail is held up till around noon Monday. Problems can also arise if the storage is on a file server, and if the allocated storage is on its way to being full. In this case, the MTA trying to save messages has to spend a lot of time allocating space. This may cause a sending MTA to time out, assuming something's wrong.

Solutions • Make sure there's enough hard disk. Today, 3MB per user is probably enough for message stores. Busy routing hubs typically have between 200MB and 400MB of storage, although at any given time they'll probably use less than 50MB. In any case, you'll want to monitor the space used and increase it if necessary. • Reorganize the message store periodically, to reduce fragmentation. • Have a policy on how long before messages will be purged or archived. • Where you can, use a disk compression product like Stacker to double available storage.

DOS MTA Stops Working MTAs running on DOS machines are prone to stop functioning for a variety of reasons. For example: • The network detects damaged packets, and sends a warning message to the MTA PC. Unfortunately, this is displayed on a DOS command line, and the warning waits for an acknowledgment typed in at the keyboard. Until this is entered, all further processing stops. • Another program running periodically in the same machine as the MTA, such as a gateway or backup process, fails because there isn't enough RAM or disk space for it to run. When these things happen, all messages going through the MTA get backed up and are severely delayed or returned to the sender. Roughly speaking, you can expect a PC-based MTA to fail for some unpredictable reason every two to four months.

Solutions • Use Unix-, Windows NT-, or OS/2-based MTAs that have more sophisticated error-handling. • Key sites should have redundant MTAs, with call-hunting for dialup links. • Make the system (MTA and associated message stores) self-restarting in case of a power failure, and test this thoroughly. A number of products are available. • Minimize the number of hops a message must traverse. • Install MTA monitoring software, which will generate an alert if the MTA goes down.

289 11 Messaging Management

• Write your own program to poll one or more MTAs, and which generates alerts if no reply is received.

Message Flow Inconsistent With Traffic Flows You need to analyze the flow of communications between people, and if possible, design the network so that messages are sent with the minimal number of hops. For example, suppose San Francisco is the Western region HQ, and due to the way user addressing is implemented you need to have routing hubs. It probably makes sense to have a routing hub in San Francisco, with satellite MTAs hanging off this as spokes. If the regional HQ later moves to Los Angeles, the hub should probably be moved along with it.

Solutions • Do periodic user surveys asking them about how they use messaging services. • A systems analyst type of person—who's sensitive to the applications mix running over the messaging system—should participate in system design.

Message Flow Inconsistent With Physical Network The problem here is that to get to their destination, messages may traverse a convoluted path over the underlying LAN and WAN links.

Conflicts With WAN Design For example, suppose offices in Los Angeles, Oakland, San Francisco, and San Jose, are being connected. Suppose further that the Oakland office has a lot of email expertise. It may well seem natural to put a routing hub there. Unfortunately, this could be a disaster. Suppose the physical network is as shown in figure 11.12. If someone sends a 2MB file from Los Angeles to San Francisco: • The Los Angeles MTA transfers the file to the Oakland hub. The data packets first go to San Francisco, over the fast T1 link (1.544 mbits/sec). Then they are squeezed through the 56 kbit/sec link, taking 5 to 10 minutes if there's no competing traffic. • Once at the Oakland hub, the routing hub forwards the file to San Francisco. The file then retraces its path through the 56 kbit/sec line. So in this scenario, all traffic going between San Francisco, San Jose, and Los

FIGURE 11.12 MESSAGE FLOW CONFLICT WITH WAN

56kbit/s San Francisco Link Oakland LAN LAN T1 Link

T1 Link SanJose LAN Los Angeles LAN

Message flow is very inefficient if the underlying physical network is as shown here, and a routing hub is placed in Oakland. All inter-office traffic is forced over the slowest link, the 56 kbit/sec one from San Francisco to Oakland.

Angeles has to be sent twice over the 56kbit/sec link. This is clearly absurd, because the 56kbit/sec link is easily swamped, and will frequently cause unnecessarily long delays in message delivery. Besides, the physical network is being used very inefficiently. It's unnecessary to move everything over the San Francisco-Oakland link. When you're aware of the underlying physical network, it becomes apparent that it would in fact have been far better to place the routing hub in San Francisco.

Conflicts With Local LAN The problem of message flows that are inconsistent with the underlying physical network is most commonly noticed where slow (56kbit/sec and below) WAN links are involved. But it can easily happen within a campus or building LAN, too. Consider figure 11.13. The MTA transfers mail between message stores on different floors, and each floor has its own LAN segment. Each segment connects to a backbone via a bridge. The problem is that all inter-floor mail has to go over Floor 3's LAN. Plus, the MTA places its intransit messages on File Server 3. Now suppose it's a 20-floor building; Floor 3's LAN is swamped with mail packets, and the file server is del- uged with mail I/O. It makes far more sense to put the MTA on the backbone, together with an associated file server to provide working storage.

291 11 Messaging Management

Solutions • Ideally, MTAs should be able to route directly to other MTAs, without being forced to go through routing hubs; and lower level system software should be responsible for working out how best to transmit data packets between sending and receiving MTAs. • Message flow should be designed with the physical network in mind. So when designing the message flow, form a project team. You need to have three skills represented: knowledge of the e-mail system, data communications expertise, and systems analysis (to understand who sends what to whom).

MTA Accessing Message Store Over WAN As figure 11.13 illustrates, you only need a single MTA to move mail between message stores, provided everything's connected over a seamless internetwork.

FIGURE 11.13 MESSAGE FLOW CONFLICT WITH LAN

Floor 3's File MS Server

Floor 3's LAN

Floor 2's File MS Server

Floor 2's LAN Floor 1's

Building Backbone File MS Server

Floor 1's LAN

Here, all inter-floor messages have to pass through the third floor's LAN and transient message store on the file server. It would be much better to place the MTA and its storage on the building's backbone.

This often work fine, provided the message stores are connected via a high speed LAN. However, an MTA might be accessing remote message stores, through a slow speed (56 kbit/sec or less) link. Here, performance suffers, because the MTA generates a lot of I/O between itself and the message store it's accessing.

Solution • You should normally have an MTA at both ends of a WAN link.

Congested Routing Hubs As we've observed, systems software limitations often make it necessary to connect different offices using a hub-and-spoke arrangement. Then the hubs themselves are a bottleneck. Everything has to go through them, and anything that clogs up a hub—such as a large file—can affect very large numbers of users. If MTAs communicate directly to each other, the impact of clogging like this is much more localized. What's more, the larger a messaging network, the worse the problem gets, because a multi-level hierarchy of routing hubs evolves. This means that many messages must go through a series of interim MTAs, and each MTA means new delays. Local messages may take just five minutes to arrive, while others might take an hour to hop through the full hierarchy.

Solutions • Where practical, let MTAs talk directly to each other. Ie, avoid using routing hubs. • Minimize the number of routing hubs. • Make a routing hub hierarchy as flat as possible, so that messages go through a minimum of hops. • Have multiple MTAs processes associated with a routing hub, so that a single queue can have many concurrent transfers. • Don't have users local to a routing hub, so that all storage is transient. If users share the hub's message store, they might fill it with saved messages. Then there's nowhere to store incoming messages, and transmission stops.

293 11 Messaging Management

Dial-in Users With Slow Lines Laptop dial-in traffic can tie up an MTA for quite a while, especially because many laptops use built-in 2400 baud modems.

Solution • Put in multiple MTAs at busy locations, and provide call hunting between the different phone numbers.

Gateway Thruput Gateways that connect an e-mail system to a different type of e-mail system can be a bottleneck. They typically run on DOS machines, and process around 500 to 800 3KB messages per hour. Plus, since they're single-tasking machines, while a message is being sent one way, ones coming in from the other direction have to wait. One place where you're likely to need high gateway transfer speeds are at the point of connection to the in-house backbone. Heavily used Internet and X.400 gateways can also run into the problem.

Solutions • Run the gateway in a faster machine. • Have multiple connections to the backbone. For example, run two copies of a gateway connecting to the backbone, and have them both work off the same to-be-processed queues. • Don't run the gateway on the same machine as an MTA.

Too Many Users On A File Server Having more than 100 to 150 users based on a PC file server is usually a bad idea. • The larger the number and size of messages stored, the longer it takes to run maintenance programs. While these are running, no local users can send or receive mail. For example, a file server for 140 cc:Mail users, containing some 250MB of storage and 200 messages per user, takes two or three hours to be processed by the CHKSTAT/RECLAIM utility. On the other hand, limiting each server to 50 users keeps processing time to 30 minutes. • Chances are, the file server will get too busy. It's being bombarded with polls from workstations, checking to see if new mail has arrived. Plus, the file server is simply acting as an unintelligent remote disk, and almost all pro-

cessing must take place on separate machines. This means the file server is busy transferring files to and from network workstations. It all adds up to a lot of work.

Solutions • You probably won't want to have more than 100 reasonably active mail users on most PC file servers. • Put in faster file servers. • Use monitoring tools to track delivery times for a given message store. As the number of users increases, you can project the lengthening delivery times and take action before users start complaining. • Investigate client/server solutions, such as HP's OpenMail and SoftArc's FirstClass. Here, the message store has real processing capabilities, reducing the burden on workstations and reducing spurious network traffic.

295

Chapter 12

12. X.400 User Agents

A user agent, or UA, is a computer program that allows a human being to send and receive messages. For example, when you send a message using cc:Mail, the program you run on your computer (figure 12.1) is a user agent. In the strict X.400 definition, a user agent can also be a program that allows a program to send and receive messages—in other words, an API is a user agent. We, however, will focus here on the term's sense as a program that people use. When a non-X.400 messaging system connects to an X.400 backbone, you could, therefore, argue that the user interface amounts to an X.400 user agent. After all, it lets you send and receive X.400 messages. However, the term X.400 user agent usually refers to a user agent that has been designed to connect directly to an X.400 e-mail system, without any interim gateways. Today, most users don't use X.400 UAs. They use products like cc:Mail, PROFS/ OV, and so on. This situation—ie, X.400 UAs being relatively rare—is unlikely to change for the foreseeable future, even though many organizations are implementing X.400 backbones. Nevertheless, X.400 UAs do have a lot going for them. In this chapter, we take a closer look at them, and their pros and cons.

12.1 X.400 UA Products X.400 user agents are offered by a number of firms, some of the leading players being Alprange (now owned by Enterprise Solutions), Boldon James, Control Data Systems, Enterprise Solutions, Infonet Software Solutions, ISOCOR, MaXware, and NEXOR.

297 12 X.400 User Agents

FIGURE 12.1 CC:MAIL USER AGENT

...titobt.-

" . . 0.0*.OV4:'131.ftt:A0104:.0 0.00.

The program you use to send or receive messages is known as a user agent. Here's cc:Mail's user agent for Windows.

A number of X.400 vendors resell UAs developed by a third party. For example, AT&T/NCR, Bull, Control Data Systems, Digital Equipment, Infonet Software, and Tandem resell UAs from Enterprise Solutions.

Market Penetration It's hard to get accurate figures on market shares and product revenues, because many of the companies concerned are privately held, and/or secretive about their figures, and/or given to exaggeration. Nevertheless, we can make a number of observations. X.400 UAs have very small market share compared to proprietary UAs. Based on surveys by Ferris Networks (see for example the September 1993 Ferris E- Mail Analyzer, discussing market shares and purchasing plans), they appear to represent less than 2% of current shipments by number of units and revenues, and less than 1% of all installed seats.

The main competitors for X.400 UAs are proprietary products such as cc:Mail, GroupWise, Microsoft Mail, and QuickMail. Both of the market leaders, cc:Mail and Microsoft Mail, have far greater market shares than all X.400 UAs combined. Each product appears to be generating annual revenues of about $100 to $150 million for their vendors, although it must be recognized that a certain proportion of this should be allocated to revenues from the proprietary transports also provided by the vendors. On the other hand, developers of the main X.400 UAs, such as Boldon James, Enterprise Solutions, and ISOCOR, appear to be generating something between $500,000 and $4 million in annual revenues for the UA business.

User Functionality X.400 UAs look very much like non-X.400 UAs, and have pretty much the same features. Many people are hard put to tell the difference between the two. You can: • Prepare, send, and receive interpersonal messages • Use distribution lists • Run spelling checkers over a message • Browse user-friendly directories • Send and receive files • View arriving files and so on. Versions run under Windows and DOS on PCs, and on Macintoshes and Unix workstations, and in other environments, too. Figure 12.2 and 12.3 illustrate some screens from a typical product, Enterprise Solutions' X.400 UA for Windows.

Special X.400 UA Features The X.400 model includes a number of features that non-X.400 UAs usually lack, notably: • Expiry Time. This message element indicates when its contents become invalid. Useful, for example, when sending out special discount offers. • Obsoleted Messages. Originators can specify one or more messages that are to be replaced by the current messages. Useful, for example, when distributing price lists. • Related Messages. Originators can specify what messages are related to the message they're sending. What related means is not defined.

299 12 X.400 User Agents

FIGURE 12.2 X.400 USER AGENT FOR WINDOWS

S . . : File edit Messages Folders eontiguration Window ljelp

1,1

4:‹ - ,Cf;..:+X+XiV • wwa Outtray ...... • •"•• •• 0 YVastebin ESL acquires Comware in France Karl Klessig 089394 16:15 3 To Temp ESL partnershlis with hIS1- CaLANdar iKa l KlessIg 06939316:05 2 Cc Products C ant Based ESL parinershji with SCC - Ottside-In !Karl Klessig 08939314:07 2 Cc UA ESLoartnershp vitth JetForm (Karl Klessig 06939313:35 2 Cc Nandows ESL parinershlii with Boston Software :Karl Kieseig 08939311:14 2 Cc MotIf ESL parinershii with Keyword :Karl Klessig 08/03/93 013.35 2 Cc Macirtosh ESL partnership with RSA Security iKarlKlesMg 08102/93 21:44 2 C c DOS ESL parinershin for DAS :Karl Klessig 08929310:57 5 Cs Unix Overview of X.400 Public-Key Sectirty :Richard Shkley :081029310:36 2 Bcc Character DUA BBS Overview of X.400 51988) Message Store :David Webb :08/02/93 101 2 2 To Server Based Overview of XAPIA Robert Boucher :08/01/93 1203 3 Cc -C3MTA (2) - Overview of X.500 Tree Structures 'Peter Littlefield 107128/33 22:23 2 Cc CJDSA - Overview of X.500 Browsng & Searching ;Eno RosenquIst '•07/299314:29 3 Bcc C2Actrin Overview of Macintosh UA & DUA Marry Relf :07/299313:14 3 To Acid Ons (3-2) Overview of WV UA & DUA :Tony Petd :071289312:03 3 To IMSI Avelablit of MTA & DSA Platforms :Steve Marvel :07,289310:40 3 Cs CaLANdar SCC Viewer owar . Akkkk../47. Jeff orm Boston ESL Acquires Acquires Alprange Communications Software RSA Keyword Acquisition seen as Instrumental in worldwide expansion and continued Sales North America (1-1) explosive growth of X400/X.500 messaging market Europe U.K. n June 14th, at the European Electronic Messaging Association conference in tockholm, France Enterprise Solutions made the major announcement of its acquisition of prange, an Germany Scandinavia independent software company specializing in communications technology d OSI Netherlands software products. Alprarge has successfitliy integrated OSI and EDI products Spain o provide effective business solutions to corporate and government users and IT Italy l() Eselesum 4 • aLPRAIME.411F

sa: 7.4r-

X.400 UAs look very much like non-X.400 UAs. Here we see a typical screen in Enterprise Solution's UA for Windows.

• Reply Time. This lets a user specify by what time a reply is expected. • Importance. This message element allows the sender to indicate how important—high, normal, low—the message is. Don't confuse this with the concept of priority, which relates to how quickly the message should be delivered. • Confidentiality. This message element allows the sender to indicate how sensitive a message is. Three values are defined: personal, private, and company confidential. • User Authorizations. A message can have a list of authorizing users associated with it. The idea is that someone can write a memo or letter, have it authorized by someone else, and then send it to the recipient.

On the other hand, it should be noted that many X.400 UAs don't implement most of these goodies. Even if one of them is supported, users must be careful that the recipient has a UA which also supports the feature.

Technical Summary An X.400 UA, as we discussed in chapter 4, normally connects to an X.400 message store. It does so using P7 protocols, which run over ISO, TCP/IP, or dialup APS transports. X.400 UAs can also talk directly to an MTA, using the P3 protocol again running over ISO, TCP/IP, or APS transports, but such connections are rare.

FIGURE 12.3 X.500 BROWSER WITH X.400 USER AGENT

- i" '''' ''' ' Nmax:Naamligas- Elle Edit Messagin ''' ...... , ... ; ;; ... ; ....

The World Andrew J Mellon 2 Irene J Lalleche g +VD Inner:at C Howard Staveley g James R Cordy 2 +CV Internet Celia ft Andersen Janice Glasgow 2 .42 North Atlantic 2 chis waiway John P Jorgensen Tree g Colin R Banger 2 11 Judy Russell II Leif Haglund g Mary • ? Europe David A Dove g David L Mccollam g += AT - Aka Lamb Michael A Jenkins Austria 2 David Fleet Michael Levison 2 +EN AU - g Michelle Eggleston g Australia +El BE - 2 David RappapedS) Hamden Seeker Belgium 4E3 BR ? David T Barnard g Randy E Elks g - Brazi Donald A Jardine g Dorothea BlostearY ft Robert D Tennant «El CH - Switzerland Robert 6 Crawford +Itil CZ - Czech Re +!!! DE Fiona J Mckay - Germany += DK - Denmark Gory K Pestle, (S) sk Robin W Dawes 2 g Glenn H Macewen Roger A Browse 2 Henk Melia Sandra A Pryal 2 > tan A Macleod Sandra crock. • EE - Estonia Mina ...... r3-1

W s =

- • -•••i•••'-.-,- '...... WOMINUMP::*

X.400 UAs normally use an X.500 directory. This can browse the world-wide X.500 directory, as well as in-house users.

301 12 X.400 User Agents

Some products use redirection to place messages in and pick messages up from a file server directory, which acts as an inbound or outbound MTA queue. This is a proprietary extension to the X.400 model, however.

12.2 X.400 UA Strengths At first glance, X.400 UAs look very much like non-X.400 UAs, except that they allow the user to see some special X.400 message elements in more detail. Here we spell out the main differences.

User Perspective There are some really big advantages of using X.400 UAs, especially if you have a green field site and can put them everywhere. The advantages mostly derive from the standard nature of X.400.

Distributed, World-Wide Directory The X.500 distributed directory naturally goes along with X.400 (not surprising, since it was designed to do so). Users can browse a directory that encompasses the whole world, not merely other people within their organization. Also, X.500 names are similar in feel to X.400 0/R names.

Multiplatform Support With proprietary messaging systems, you need the vendor concerned to support all your different platforms. Otherwise, you need to install different packages, and gateway between them. Because X.400 is a standard, you don't rely on a single vendor to provide support for all your different platforms. You choose the workstation software you like best for a given environment.

Connectivity With Arbitrary Third Parties Users can use their normal addressing format to send messages to a world- wide community. Most e-mail users who are connected to the outside world in some way can be contacted via their X.400 address. Note that X.400 UAs typically have machinery to make it easier to enter X.400

addresses. Typically, you enter them via formatted templates, and these aren't always available with non-X.400 UAs. There's usually support for more user- friendly aliases, too. On the other hand, remember that limited inter-ADMD interoperability means that connectivity to external third parties is inferior to that of the Internet (see International Connectivity, in chapter 9 section 3.)

Flexible File Transfer X.400 UAs let you transfer an unlimited number of binary files, of arbitrary size. Some non-X.400 UAs, notably SMTP-based ones, can't handle attachments, and you have to go through an inconvenient process of encoding them into text and inserting them into a message body. Plus the encoded length is likely to have to be short, say up to 50KB. Then the recipient has to go through an equally gruesome decoding process. Many proprietary UAs let you transfer multiple files, but provide a limit to the number that can be carried in a given message. cc:Mail, for example, limits you to 20. This may seem a lot, but it's not hard to envisage mail-enabled applications needing many more attachments.

Reduced Feature Mapping Problems There are fewer differences between a message sent by an X.400 UA, and the message that's finally delivered to a user of a different e-mail system: • If the recipient is an X.400 user, no feature mappings will be needed. • If the recipient uses a non-X.400 UA, fewer gateways are probably required. Typically just one gateway will be involved. On the other hand, if the sender were using a non-X.400 UA and was corresponding with the user of a different non-X.400 UA, typically two gateways will be involved: one to convert the message from the sender's format into a canonical format such as X.400, and another to convert into the format of the recipient.

Advanced Messaging Features As we noted, X.400 includes a number of features that non-X.400 UAs usually lack. The most significant of these are: expiry time, obsoleted messages, related messages, reply time, importance, confidentiality, and user authorization. But don't assume a given UA package implements them.

303 12 X.400 User Agents

Handling Files of Indeterminate Format As discussed in chapter 7, the work of the EMA's Message Attachment Working Group will result in a standard way of preserving information about files being transferred. This will make it much easier to deal with arriving files of undetermined format. The impact should be felt first, and most usefully, by users of X.400 UAs.

Faster Access to Public Key Cryptography Organizations making extensive use of X.500 are in a significantly better position to adopt public key cryptography, since X.500 is a key underpinning of the technology. We think this is important, because public key cryptography will significantly affect the way many organizations do business.

No Difference Between LAN and Remote Versions We said that X.400 UAs use the P7 protocol to communicate with a message store. They use this whether or not the message store is connected over a LAN, WAN, or dialup link (or over any other form of data communications link). This means that there is almost no difference in the code required for a remote UA, with the result that: • There is almost no added complexity for a user. • It's almost trivial for an X.400 UA vendor to keep its remote and LAN software in synch. This is quite unlike most current PC e-mail systems, where LAN and remote UAs are generally completely separate products.

Support Perspective

Wide Choice of Transport, Message Store, and Directory Suppliers You can choose your MTAs, message stores, and DSAs from a wide range of vendors, who compete on price and functionality. The choice of message stores is particularly important, since an important barrier to PC e-mail scalability is the difficulty many products have in supporting more than about 100 accounts on a single message store. This translates into significant management headaches. With X.400 environments, the choice of message stores means one can essentially build message stores of arbitrary size, supporting an arbitrary number of users.

Message stores can be readily put on Unix machines with a wide range of cost and horsepower, and it won't be long until they can operate on a similarly scalable range of Windows NT-based multiprocessor PCs.

Choice of Other UA Suppliers You can easily plug other UAs in. Eg, suppose you've got your DOS and Windows UAs from one supplier, but prefer the special features of a Macintosh UA from another supplier. You can mix and match vendors more or less as you want, choosing on functionality and price.

Less Dependence on Product/Vendor Survivability If the UA vendor goes out of business or drops its commitment to its products, there are always competitors you can turn to.

Directory Management Much Simpler Directory propagation within proprietary distributed messaging systems requires time-consuming, careful attention, and it's an error-prone process. Directory synchronization—where the directory information in different messaging systems is shared—is even more problematic. With X.500, the integration of directories at different locations is automatically provided. Managing the distributed directory information and ensuring everyone's up-to-date is much simpler.

Competition Between Vendors The competition between vendors is a strong stimulus for them to improve functionality (eg, keep their Windows client up-to-date, tightly integrate X.500 lookup, add public key cryptography, and support special X.400 features like expiry time and obsoleted messages. ) It also helps to keep the prices of software down.

Greatly Simplified Management With OS! and TCP/IP Most large organizations are slowly migrating to the use of a common data communications technology. For example, an organization that uses SNA, DECNet, SPX/IPX, AppleTalk, TCP/ IP, and NetBEUI has to understand and—worse yet—integrate six different technologies. Life is much better for everyone, and cheaper, if a single technology is used.

305 12 X.400 User Agents

Some people have chosen to go the route of ISO transports. More commonly, they are going in the TCP/IP direction. X.400 and X.500 UAs offer a lot to organizations who have TCP/IP or ISO transports everywhere (down to the desktop), or who are well on their way to doing so. All products are expressly designed to work with one or both of these protocols. Installation is simpler, and messaging system components can be managed using standard technologies such as Telnet and Hewlett-Packard's Network Node Manager.

Single Management Technology You can have X.400 and X.500 products from a number ofvendors, and they share the same technology. Much of the management is common.

No File Redirection Overhead X.400 and X.500 UAs make far more efficient use of network bandwidth, because they don't use file redirection. They use layer 4 protocols instead.

12.3 X.400 UA Weaknesses

Small Market Share Issues The small market share of X.400 UAs translates into a number of disadvantages.

Vendor Financial Stability Some X.400 UA vendors are are not yet profitable, and are living off investment capital. ISOCOR is an example that comes to mind. Such vendors would, with some justification, assert that this is a natural part of their plans. Nevertheless, companies that are profitable are intrinsically more stable, and less likely to be subject to unpredictable and major changes in their product plans.

Few Tightly Integrated Applications Proprietary UAs often have tightly integrated applications which use the messaging system. X.400 UAs are much less likely to have them, perhaps because of the limited development resources available to the vendors.

By a tightly integrated application, we mean that the application: • Has the same look and feel. • Uses many of the same utilities as the messaging system. For example, it has the same directory lookup and address selection technique, and the same print commands. • Is managed with the same set of tools. The benefit of a tightly integrated application, as opposed to simply an application that uses the messaging system, is that there's less learning effort for users, and that users are hence more likely to take advantage of the additional functions. For example: • cc:Mail has a built-in bulletin board system. This is a very useful way of sharing information. • Microsoft Mail and GroupWise have a tightly integrated group scheduling system. • QuickMail and GroupWise have tightly integrated forms definition and forms routing software. • Many products have file and fax viewers, and spelling checkers, with varying levels of integration with the messaging system. On the other hand, it should be recognized that in certain cases, the additional complexity of tightly integrated applications has disadvantages. GroupWise illustrates the point: it's a very rich environment, but the necessity to face everything confuses many users.

Keeping Up-to-Date Because X.400 UA vendors have fewer development resources than larger proprietary vendors, they sometimes find it hard to keep their products up-to-date. For example, Windows UAs must now have such facilities as hierarchical folders, drag and drop between message elements, standard tool bars, customizable tool bars, rules processing, OLE support, support for Simple and Extended MAPI, and a wide variety of user-selected fonts.

Limited Support by Third Party Products Support staff working for vendors of third party products are more likely to know how to resolve integration problems with the leading proprietary UAs, since any given X.400 UA has a very small market share. Areas which could be a problem include forms routing packages, bulletin boards, file viewers, fax servers and viewing software, and group scheduling packages.

307 12 X.400 User Agents

Documentation User and technical documentation is generally somewhat unpolished. For example, it's often photocopied and quick-bound, covers topics briefly, focuses on the main user functions while ignoring more specialized cases, and has limited indexing.

X.400 Model Inadequacies There are also a number of areas where the X.400 model is clearly lagging behind the times. Often, X.400 UA vendors do proprietary things to make amends, eg, they provide a local hierarchical message store which is owned by each user, to augment the main flat message store. Or they implement rich text in an interpersonal message, where the standard requires ASCII.

Flat, Read-Only Message Store The model has a flat message store, that corresponds to an inbox. Today's users expect to be able to access and manage a shared hierarchical message store. They want to be able to insert messages in the store.

Limited Message Store Intelligence More and more intelligence is being built into proprietary message stores, and some of these are important to customers. In particular, the ability to: • Automatically replicate information between message stores. • Index, in real time, a wide variety of stored objects (not just ASCII messages). • Retrieve stored objects using a rich variety of selection criteria. • Control access to message store objects. • Retract messages that have been submitted for tranmission. Some proprietary UAs, such as GroupWise, offer this.

None of these features are supported by the X.400 UA

model. Interpersonal Messages Only in ASCII An X.400 interpersonal message is simple, unformatted text. The tendency in proprietary UAs is to allow ever-richer text. For example, people want to be able to use different fonts, a word processor of choice, and to drag-and-drop objects such as a bar chart or Lotus spreadsheet into the message.

File Attributes Lost During Transfer Some proprietary UAs, especially Macintosh-based ones, preserve file attributes during file transfer. This means it's much easier to work out how to process a file someone sends you. Most X.400 UAs do little in this field. The best they do today is to preserve the file name, and use Windows' ability to associate an extension with an application. As noted in the chapter on file transfer and conversion, this approach has severe limitations.

X.400 Address Complexity We have discussed elsewhere how many X.400 addresses are unnecessarily complicated, with a proliferation of O's and OU's. Messaging support staff can do much to alleviate some of the pain by adopting a simple address convention, and by making extensive of user-friendly aliasing to hide X.400 addresses. Nevertheless, users are still likely to be confronted, from time to time, with moderately long-winded expressions, for example in FROM: fields, and expanded distribution lists. Proprietary products, especially cc:Mail, do a much better job of presenting simple and intuitive addresses all the time.

Support Issues

More Technical Expertise Required Today, many of the products require a comparatively high level of technical sophistication on the part of support staff. Several areas stand out. Often: • Staff must digest data communications concepts associated with TCP/IP and ISO transports, such as RFC 1006, X.121 DTE addresses, NSAPs and TSAPs, and PAD parameters. • Configuration files with precise syntaxes must be defined or maintained, in lieu of more user-friendly GUI interfaces. • Documentation appears to have been written by engineers for their peers, rather than for people of lesser technical background.

Different UA and Transport Vendors The ability to purchase MTAs, DSAs, and messages stores from vendors other than the vendors of the UAs has major benefits.

309 12 X.400 User Agents

However, it does have a disadvantage compared to proprietary UAs, where the vendor usually also provides the transport, directory, and message store. When the UA and infrastructure vendors are different: • Different, unintegrated support tools are used, increasing the learning effort for support staff. • More sophistication is required to handle integration problems.

Proprietary Enhancements Dilute Standards Benefits Some vendors make up for features missing in the X.400 UA model by adding functionality. A common example is where a UA vendor preserves file names by placing them in an ASCII body part accompanying the file being sent. In general, this means one needs a UA from the same vendor to receive the message—it knows how to reasssign the file name and shield the user from unnecessary complexity. Some UA vendors also add a local message store that is hierarchical in nature; in this case, UAs from the same vendor must be used to access the message store. Some vendors allow rich text in an interpersonal message, in which case it must be received by a UA from the same vendor. Extensions like these can be of great value. However, they dilute some of the core benefits of using a standards-based product: • Interoperability. To read a message prepared by someone else, a UA from the same vendor must probably be used. • Vendor Independence. If a vendor goes out of business, it may be difficult to plug in another X.400 UA. In general, the more special features added, the more you're dealing with a proprietary product, and the more attractive packages such as cc:Mail and Microsoft Mail become.

12.4 Who Uses X.400 UAs? There are thus many good reasons to adopt X.400 UAs, and many good reasons not to do so. Most organizations, rightly or wrongly, are greatly influenced by the large market share of the leading proprietary packages. They thus decide against using X.400 UAs, even though they may plan to use an X.400 backbone to connect everything. Nevertheless, a growing number of major organizations are using X.400 UAs, and

have deployed or have commited to deploy a large number of seats. They appear to fall in one or more of the following categories:

TCP/1P and Standards-Based Orientation This is a common type of adopter. It is characterized by the use of TCP/IP as the standard internal data communications transport, in order to have a higher- function, more maintainable, and cheaper network. They are in the later stages of migration away from traditional mainframe- and mini-based systems. Around 90% of workstations are PCs, which run both DOS and Windows; the rest are a mix of Macintoshes and Unix workstations. This group likes X.400 because they can pick and choose products from a variety of vendors, based on function and price. They normally run MTAs, DSAs, and message stores under Unix, on scalable machines of their choice. In the future, many are considering migrating the MTAs, DSAs, and message store to scalable Windows NT-based platforms.

Greenfield Sites Many X.400 UA users are new to e-mail and messaging. They only started with the technology from around 1991 onwards. Conversely, organizations that started with e-mail before about 1985 are comparatively unlikely to be interested in X.400 UAs. They started with products like PROFS or All-In-1, and are much more likely to be going in the direction of proprietary products based on intelligent workstations.

Organizations Satisfying GOSIPs Some user organizations are government departments or contractors, with a pre- disposition to follow a formal government direction to adopt OSI standards.

X.500-Struck Some users are strongly attracted by X.500, notably the simplicity of directory management, and the ability to participate in the global directory.

311 12 X.400 User Agents

12.5 Future X.400 UA Market Share For what it's worth, we end with speculation on how X.400 UAs will do in the future. One is struck by the fact that many X.400 UA customers are typical early adopters of successful technologies. They are technically self-confident, and are prepared to try out things if they think it can materially improve the way they do business. They have a TCP/IP and standards-based orientation, described above, and they may also satisfy some of the other characterizations. On balance, we guess that: • More and more organizations will find X.400 UAs attractive. • Nevertheless, other approaches will predominate. • By the year 2000, between 5% and 20% of all UAs sold will be X.400 UAs. The rest will be proprietary, or SMTP/MIME- based. • By the year 2000, two vendors will have X.400 UA revenues with a present value of between $20 and $60 million. In other words, proprietary and SMTP/MIME technology will be stiff competition for X.400 UAs, but organizations adopting them won't be stuck in a technical cul-de-sac.

13. API Access

A user agent is one way of getting at a messaging system. The other way is via an API, or application program interface. A messaging API lets a program access the messaging system, whereas a user agent lets a human being access it. More specifically, a messaging API usually provides a set of subroutine calls which let the programmer: • Insert a message into the messaging system • Remove or receive a message from the system • Get addressing information Three types of program use a messaging API (figure 13.1): • Programs that provide a user interface to the mail system • Application programs, such as a database application which processes and responds to queries received by mail • Other messaging systems, in which case the program using the API is a gateway Thus a messaging API allows the programmer to send and receive messages, and access the messaging system directory, without the need to know the details of the underlying messaging system. Furthermore, the programmer doesn't need to be a messaging specialist. A programmer who does not know X.400 internals can still inject or extract X.400 messages. He or she does not need to be familiar with X.400 message encoding formats, routing details, timing or communications issues.

313 13 API Access

FIGURE 13.1 USE OF MESSAGING APIS

Mail System A Mail System B

A messaging API lets a user, application program, or gateway access the messaging network.

Programmatic vs. File-Based APIs Older messaging APIs often use specially formatted files as the means of communication between an e-mail system and a program which is accessing it. We call these file-based APIs. The best-known examples are cc:Mail's import/Export, MS Mail's FFAPI, and Lotus/SoftSwitch' Application Toolkit. More modern APIs use conventional subroutine calls, and for this reason we called them programmatic APIs. CMC, MAPI, and VIM are the best known of these. Programmatic APIs are usually faster and more reliable than file-based APIs.

Overview of Popular APIs Figure 13.2 summarizes the major messaging APIs. Some of them are likely to be used only by systems software developers, such as MAPI, VIM, and the X.API's calls to X.400. Today, many user organizations have built utilities with APIs like cc:Mail's Import/Export, and MS Mail's FFAPI. CMC, or Common Messaging Calls, is likely to be widely implemented. DDE calls are likely to become popular, although they suffer from some of the problems of file- based APIs. Lotus/SoftSwitch's APIs have been used by some user organizations to create mail-enabled applications, although in the future their use will mainly be by systems software vendors.

FIGURE 13.2 MAJOR MESSAGING APIS

ca .

Lotus Import/Export cc:Mail VIM cc:Mail, Notes, NetWare MHS; in theory other e-mail systems Microsoft FFAPI MS Mail MAPI Many; any e-mail system for which a service provider is defined Simple MAPI MS Mail Novell SMF-64, -70, -71 NetWare MHS Lotus/SoftSwitch SNAPI Lotus/SoftSwitch Central, EMX/LMS Application Toolkit Lotus/SoftSwitch Central, EMX/LMS X.APIA XOM Any X.400 system XMS Any X.400 system XDS Any X.400 system XMT Any X.400 system XMA Any X.400 system CMC Any e-mail system Various DDE Various e-mail systems

Few readers will need to code to the X.API's X.400 calls, or to MAPI and VIM. They're too complex.

We now turn to a closer look at the most important APIs. Readers seeking further analysis of major APIs may want to review the April and May 1994 Ferris E-Mail Analyzer for a more in-depth analysis of MAPI, VIM, the X.APIs, and their strengths and weaknesses.

13.1 File-Based APIs Figure 13.3 displays the file based API model. These work along the following lines: The API provider—typically the provider of the underlying messaging system—provides: • A definition of the structure of files used to put information into the messaging system (import files), and a definition of the structure of files containing information that has been extracted from the messaging system (export files). • A program to extract messages from the messaging system, and put them into an export file. This is generally known as an export program. • A program which takes message information in an import file, and puts this into the messaging system. This is generally known as an import program.

315 13 API Access

FIGURE 13.3 FILE-BASED APIS

User application User application formats the message Provided removes the User message from API User Program in API file format and by User Program puts it into import export directory and processes it directory t Message is in Defined Message is in Import format by API format Export Directory defined by Vendor defined by Directory API publisher API publisher 1 Import utility Export utility extracts takes messages from Provided messages from Import by API messaging system Export import directory, Utility Utility injects them into Vendor and puts them into messaging system export directory

Messaging System

With file-based APIs, communication with the messaging system takes place with cumbersome formatted files.

Sometimes—as with NetWare MHS's API—the API provider also defines the directory structure in which the import and export files are placed. Thus: • To inject a message into the messaging system, you write a program that converts the message from your private format into the format required by the API. • Periodically, you run the import program to inject messages into the messaging system. • Periodically, you run the export program which extracts messages from the messaging system. • You write a program to which parses the export file, and extracts message and directory information. Figure 13.4 illustrates the process. As we shall see, in the case of NetWare MHS' API, the procedure is varied slightly.

FIGURE 13.4 CC:MAIL IMPORT/EXPORT CALLS

A call to cc:Mail's Import program has the following basic structure: IMPORT post office name post office_password post office_path import file name &_path

A call to cc:Mail's Export program has the following basic structure: EXPORT mailbox name mailbox_password post office_path export file name &_path

A sample cc:Mail Export call from C is: rtn=spawnlp(P WAIT, "EXPORT.EXE", "EXPORT", argv[11, argv[2], "M:\\CCDATA", filearg, "NAME/1", "HEADINGS/ALL", NULL)

Normally, import or export calls are made at the DOS command line or in a batch file. It's also possible to run them from a program.

The NetWare MHS API Novell's NetWare MHS is a PC LAN-based messaging transport. It includes a non-X.400 MTA and a message store structure that resides in file servers. NetWare MRS is independent of the client programs, and there's quite a large group of third party products that use NetWare MHS to move messages about. ON Technology's eMAIL is the best known. Don't confuse NetWare MHS with the X.400 MHS. The API uses a file-based approach. Hence, its name—SMF—which stands for Standard Message Format. You use this to inject messages into NetWare MHS, or extract messages from NetWare MHS, or to maintain addresses and distribution lists. There are three SMF versions to be aware of • SMF-64 allows for one recipient and one attachment per input file. The address of the recipient is limited to an 8-by-8 string. • SMF-70 allows for 64 recipients per file and 64 attachments. Recipient addresses are still limited to 8-by-8 strings. • SMF-71 is the current version. It allows for an unlimited number of recipients and for 64 attachments. Recipient addresses can be strings of up to 253 characters. It also supports mailing lists. So, when you're looking at connecting different software together with NetWare MHS, it's important to check that everything supports the same SMF version.

How It Works The SMF API is something of a deviant in the file-based API world. It has a special

317 13 API Access

file server directory structure, containing user mail directories, gateway directories, special address book files, and so on. All this structure is defined as part of the API. To inject a message into NetWare MHS, you place a file in SMF format into a special directory. Likewise, to pick up arriving messages you move them from a special directory. No explicit call to an import or export program is required, because every few seconds NetWare MHS scans and automatically processes the special directories. Thus, to inject a message into NetWare MHS, you create an ASCII file, with a header and a text portion (figure 13.5). Human-readable keywords define most of the message elements. The header is terminated with a blank line, ie, a line containing only the carriage return and line feed characters. The following text is completely free-form. The file is then put in one of NetWare MHS's special directories, at which point the messaging system takes over.

CMC, MAPI as Alternatives to SMF In mid-1994, Novell introduced support for two important new APIs to NetWare MHS: CMC and MAPI. These should be a lot more attractive to corporate developers than SMF, because as programmatic APIs they're faster and more reliable, and arriving messages are easier to parse. Corporate developers should look particularly closely at CMC as a way of accessing NetWare MHS. It's much easier to use than MAPI, plus once your staff knows it, CMC can be used to access many different messaging systems.

FIGURE 13.5 MESSAGE IN NETWARE MHS SMF-71 FORMAT 1111______

SMF-71 Send-to: DorisgBigCorp Sender: Jim@Accounting Date-posted: 5-Feb-94 7:11:15 Attachment: BUSPLAN.WB1 Attachment-name: BUSINESS PLAN MHS-Id: 10950ae211afe109 Subject: Business Plan for 1994 Doris,

Attached is the business plan as you

requested Jim

As this example of an SMF file shows, import/export files are easy to read, if tedious to parse.

cc:Mail's Import/Export cc:Mail has two APIs: Import/Export, and the newer VIM. The former is a file- based API, the latter a programmatic one. Here, we discuss Import/Export. Import/Export's main purpose is to allow you to inject messages into the cc:Mail system, or extract them; or inject directory information, or extract it. There are also a number of very useful ancillary functions, such as those providing for fax images, bulletin boards, and full user moves. Import/Export is very useful as an access method to cc:Mail: but it's gradually being replaced by CMC, VIM, and MAPI. Note however that as of April 1995 Lotus' commitment to VIM is unclear—the development plans for v2.0 have been put on hold. Import/Export is actually two programs: the import program, and the export program. You inject messages by creating a structured file that's similar in appearance to an SMF file. Then you call the import program, and provide the file name as a parameter. To extract messages, you run the export program, which creates a file with the information you requested. This also has a similar structure to an SMF file (figure 13.6). Typically, you then write a program to process the output file. Import/Export allows access to LAN-based messages and to those on a remote (dialin) workstation. The calls run under DOS and OS/2; those for a remote workstation run under DOS.

Microsoft's FFAPI FFAPI stands for File Format API. Its purpose is to let you get message and direc-

FIGURE 13.6MESSAGE IN CC:MAIL IMPORT/EXPORT FORMAT 1.•• ______

Message: From: Jim Jones at Accounting Date: 2/5/94 7:11AM To: Doris Day at BigCorp Subject: Business Plan for 1994 Contents: Doris,

Attached is the business plan as you requested

Jim File item: BUSPLAN.WB1 2/4/94 11:12AM

Import/Export file formats are very similar to those of Novell's SMF

319 13 API Access

tory information in and out of MS Mail, and it works in much the same way as cc:Mail's Import/Export. Figure 13.7 shows a sample export file. As with cc:Mail's Import/Export, to inject information you first create a specially formated ASCII file. You then run various Put programs which take the input file as a parameter. To extract information, you run Get programs, which create a similarly formatted export file. The calls allow access to LAN-based mail files and to those on a remote (dialin) workstation. Get and Put programs run under DOS and OS/2; the versions for a remote workstation run under DOS.

13.2 Programmatic APIs The main function of programmatic messaging APIs is, like their file-based colleagues, to get message and directory information in and out of the system. With programmatic APIs, you do this using a library of subroutines. To access the messaging system, a programmer simply makes an ordinary subroutine call, passing parameters as required. The subroutines are then linked to a library supplied by the API vendor at compile time, making for seamless integration. Figure 13.8 depicts typical program logic used to extract a message.

FIGURE 13.7 MESSAGE IN MICROSOFT FFAPI FORMAT IMIIIIIII______

Version:3.00 TO:CSI:NETNET/NETPO/DAY.DORIS FROM:CSI:NETWORK/BIGCORP/JSTAR DATE:1994-03-17 TIME:15:25 SUBJECT:Business Plan for 1994 PRIORITY: XATTACH:H:\FFAPIFIL\D81D4008 BUSPLAN.WB1 TEXT:68 Doris,

Attached is the business plan as you requested

Jim

FFAPI file formats are also much the same as those of SMF and cc:Mail's Import/ Export.

FIGURE 13.8 PROGRAMMATIC API LOGIC

Initialize environment Establish session with server Open messr container

Get unread+mail count *Unread mesa es exhausted? no yes

Get summary of next message in container Close message container Close server connection Get message header Terminate One by one, get all recipients One by one, get summaries of note, attachments, etc. One by one, get note, attachments, etc. Close lessage Mark message as read

Delete message from container

Programmatic APIs allow a high level of runtime control over message system access.

Programmatic API Strengths The main problems with file-based APIs, as compared to programmatic APIs, are: • They're too slow for most interactive access to the messaging system. • At run time, they require initiation of a separate DOS process. The DOS process can fail for many reasons (eg, insufficient space available), and only very limited error information can be returned to the calling application. Thus, file-based APIs are less reliable. • The programming required to interpret an export file is difficult to write, and error-prone. • The method of injecting or extracting information (via intermediate files with a predefined format) is cumbersome compared to a subroutine call.

321 13 API Access

• Programmers understand a subroutine call, whereas the concept of using intermediate files is an alien one. • You have to maintain a cluster of executables that are separate from the application code.

File-Based API Strengths On the other hand, the main advantages of file-based APIs are: • They're in widespread use, and often are the only choice available. Eg, if you have a MS Mail remote client, you'll have to use FFAPI. • Since they've been around for some time, they often have access to useful features. Eg, cc:Mail's Import/Export provides for fax images, bulletin boards, and full user moves. • Much of the programming can be done using batch files. Unlike many programmatic APIs, you're not forced to program in C. • Troubleshooting can be easier with file format APIs. When something goes wrong, just looking at the files tells a lot; plus, injecting test messages is much simpler. • Programmers don't have to understand how to assign properties to a formal data structure.

Programmatic APIs Generally Superior So all things being equal, programmatic APIs are preferable to file-based APIs, and most of the API action is in the programmatic API field. For example, Microsoft started with FFAPI, but now also supports MAPI and CMC; Lotus started with cc:Mail Import/Export, and now also supports VIM. We now turn to look at a number of programmatic APIs. We start with one of the simplest, CMC. Then we turn to VIM, which is rather more complex. Then we look at MAPI, which is still more sophisticated. We then turn to the X.APIA's X.400 APIs. Finally we look at various higher level (ie, easier to use but with less control) APIs.

CMC or Common Messaging Callo The Common Messaging Calls, or CMC as they are more often known, is another program-based API. Unlike the others, it is defined by the X.APIA, together with X/OPEN), a standards-setting group in which users and vendors participate. We discussed the XAPIA's activities in chapter 3.

CMC defines a basic set of calls to inject and extract messages and files, and access address information. A user interface is also built in, so that at program execute time the user can browse address books, and define messages and attachments on the fly. Figure 13.9 lists the CMC calls. CMC is intended to define a useful common denominator across a wide variety of messaging systems. Any e-mail system, no matter how crude, should be able to support a CMC front end. The first CMC implementation worked with MS Mail. It's catching on quickly, and in January 1995 support was available or soon to be available with AT&T Mail, cc:Mail, Excellenet, HP OpenMail, MCI Mail, NetWare MHS, Notes, and PROFS/OV.

Simple Send Although CMC calls are fairly easily understood, it turns out that programming is tedious and quickly becomes a chore. The problem is that there are so many different elements to a message (recipients, cc:'d people, attachments, etc) and so many different types of return codes. It also turns out that a large class of mail-enabled applications only need to be able to send a file to a mailbox. For example, if you're in a word processing package, and want to send a copy of the file you're working on. Or if you've filled in an expense requisition, and need to send it off to accounting.

FIGURE 13.9 CMC CALLS

Sending Messages cmc_send Send a mail message cmc_send_documents String-based function to send mail

Receiving Messages cmc_act Perform an action (typically deletion) on a message on cmc_list List summary information about messages meeting specified cmc_read criteria Read and return a specified message

Looking Up Names cmc_Iook-up Looks up addressing information

Administration cmc_free cmc_Iogoff Free memory allocated by the messaging service cmclogon Terminate a session with the messaging service cmc_query_configurat Establish a session with the messaging service ion Determine information about the installed CMC service

CMC has 10 calls to a messaging system.

323 13 API Access

The code to send a message and/or file attachments can be relatively straightforward. Thus CMC provides the cmc send documents command (figure 13.10). All its parameters are simple strings, whereas the other CMC calls involve more complex structures. The message to be sent can be composed explicitly by the calling program, or a user interface can be invoked to let the user define it on the fly. For obvious reasons, commands of this type are known as Simple Send commands.

Future Outlook What's the future outlook for CMC? Mainly, you can expect it to get a lot more sophisticated. The X.APIA plans to turn CMC into a fully functional messaging API. In particular, it will get a hierarchical message store, distribution lists, private address books, and access to more directory information. In this regard, Microsoft and Lotus have contributed MAPI and VIM as a basis for ideas. CMC v2.0, when it appears, will probably end up being an attractive alternative to MAPI.

VIM We now turn to look at VIM, which stands for Vendor Independent Messaging. VIM lets a program: • Compose and send messages • Receive, read, store, and file messages • Manage address books At the programmer's option, users can be presented with dialog boxes to provide for dynamic address book browsing and address specification, and dynamic message and attachment definition (figure 13.11). Although it is intended to be a widely implemented and vendor-independent API, in fact VIM is closely associated with Lotus. Today, the only systems which have a VIM API are cc:Mail, Notes, and NetWare MHS. The other founding members of the VIM Consortium have since dropped their plans to provide a VIM API.

FIGURE 13.10 CMC SIMPLE SEND Imm.

cmc_send_documents(recipient_addresses, subject, text_note, flags, attached_file_paths, attached_file_titles, other_parameters)

CMC includes a call to send a message, optionally with attachments.

More Sophisticated Than CMC VIM is a lot more sophisticated than CMC. The main distinguishing features are: • With CMC, you can only browse a single message container: the inbox. With VIM, many different message containers can be browsed. Each container only contains messages, however. There's no folder hierarchy in the v1.0 specification, although this is planned for v2.0. • With CMC, you can only retrieve an e-mail address associated with a name. With VIM, you can access other address book fields, such as someone's telephone number or their department. • CMC has a single address book. VIM allows for many. • Address books can be flat or hierarchical. An entry could be a mailing list, for example. In general, there's far more control over processing details than with CMC. For example, there are calls to forward mail, and to count the number of messages satisfying particular criteria.

FIGURE 13.11 VIM USER DIALOG BOXES

Address MeSsage Address (Howell, Rebecca TO: Bryan Dunn TO: Amp Randall at SiIvet-P0 • •

,select From Clavill, Cliff tte; Dunn, Bryan ,, Howell, Rebecca Malone, Jeffrey ki Malone, Slim Peterson, Storm cc:Mail Simple Messaging Interlace Subject Silver.P0 Feedback on your document B,eceipt Memo (8) Ruler Priority 'Urgent Carmen, Your latest document looks great?

, Ks 7-Tommui

Most mail APIs let the user define message content and addressing at run time. Here we see two of the dialog boxes provided by cc:Mail's VIM.

325 13 API Access

Like the CMC developers, Lotus recognized that a large class of mail-enabled applications can get by perfectly well with Simple Send commands, taking only string parameters, and possibly allowing interaction with the user. Figure 13.12 illustrates an Excel macro using a VIM Simple Send command.

VIM v2.0 A new, richer version of VIM, v2.0, was in development during 1994, and Lotus expected to ship the first implementation in early 1995. The major changes were to be support for a hierarchical message store, and support for CMC v1.0 (which will replace VIM's SMI calls.) Other goodies include an enhanced address book interface, and improved filtering. However, as of April 1995, it appears Lotus has decided to drop its development plans for VIM. The API was unduly buggy, and had received little industry support.

Microsoft's MAPI We now turn to Microsoft's MAPI, which stands for Messaging Application Pro- gram Interface. This is a generalized set of messaging APIs that can be used to access a wide variety of e-mail systems, including MS Mail.

Simple vs Extended MAPI Several things are loosely referred to as MAPI: • Simple MAPI, occasionally known as MAPI v0. This became available with MS Mail for PC Networks v3.0 in September 1992. It's an elementary set of messaging APIs, almost identical to CMC. • Extended MAPI, sometimes known as MAPI rol. This is a very full- featured set of e-mail calls. Simple MAPI is a very small subset.

FIGURE 13.12 A VIM SIMPLE SEND maimaissemoma ______

CALL("SMI.DLL", "SMISendDocumentg", "JJCCCJ", 0, "c:\budget.xlarc:\demo.doc", "budget.xls;demo.doc", ";", 0)

An Excel macro used to send two files. The first reference to files specifies where they are to be found; the second indicates the names to be associated with them upon arrival.

• Microsoft's messaging architecture, which defines a series of services running in a Windows environment, and which provides a client API and user interface as well as low-level drivers. MAPI—in the sense of the full-blown messaging API----has been available in beta form since December 1993. Full distribution is expected sometime in 1995. Readers will be able to get it in three ways: • Included in all versions of Windows from Windows 95 release onwards. Availability is expected in the first half of 1995. • As part of the new client/server version of Microsoft Mail for PC Networks, Microsoft Exchange. There's no announced release date for this product, but sometime in 1995 seems likely. • As part of the Microsoft Developer's Network, a CD-ROM subscription service.

MAP! Services MAPI is similar in its scope to VIM, although it generally provides a higher level of control. The main things a program can do are: 1) manage a hierarchical message store; 2) manage hierarchical address books; and 3) send and receive messages. MAPI also has a user interface. This can optionally be invoked by several APIs, and allows the user to compose and address messages at run time. MAPI itself is a complex environment, and learning it is a significant challenge. It contains a large number of calls, most of which may be clustered together as shown in figure 13.13.

Most Corporate Developers Will Use Only The CMC Subset Most readers will not need to program to these calls. However, MAPI includes the CMC calls, and also the Simple MAPI calls (which are being phased out in favor of CMC). When computer professionals in large organizations write to MAPI, they'll likely use the CMC subset.

Service Provider Interfaces A major strength of MAPI is that it presents a very general messaging model. This allows it to be used as the API for many different systems. Along with the APIs we've just discussed, Microsoft has also defined a standard set of drivers interfaces, collectively known as a service provider interface. By writing appropriate drivers, a messaging vendor can make MAPI act as a front end to their system.

327 13 API Access

FIGURE 13.13 MAIN MAPI CALLS

Property Management GetPropList, SaveChanges Open Message Store Entry, SetRetrieveFolder Folders GetHierarchyTable, CreateFolder Messages GetRecipientTable, DeleteAttach Address Books Open Entry, CreateOneOff Address Book Containers GetContentsTable, CreateEntry CMC cmc_send, cmclookup Simple MAPI MAPIReadMail, MAPIAddress

MAPI contains a large number of calls, falling into eight main categories.

Many vendors will develop MAPI service providers, because it will mean that applications which make MAPI calls—such as fax software, bulletin board systems, and forms routing packages—will work with their products. The following vendors are writing MAPI service providers: • AT&T and CompuServe: for their respective public services • Banyan: for Banyan Intelligent Messaging • Digital: for DEC MailWorks • HP: for its OpenMail X.400 servers • ISOCOR for X.400 and X.500 systems; for PROFS/OV, and for SMTP/ MIME • Lotus: future plans for cc:Mail and Notes • Microsoft: for Microsoft Exchange's transport, directory, and message store; and for PROFS/OV • Novell: for NetWare Directory Services and NetWare Global MHS • Unipalm: for SMTP/MIME

X.400 Implications Thus, MAPI will be widely used as an X.400 API. For example, HP, ISOCOR, and Microsoft have written MAPI drivers to their respective X.400-based transports. Lotus has also said that in due course (don't hold your breath), they will provide a MAPI driver for their LCS X.400 transport. By 1996, there will be few X.400 systems that don't have a well tried- and-tested MAPI interface. Since many systems software vendors are writing products built upon MAPI, this in turn means that X.400 backbones will work with a wide variety of applications packages.

X.APIA's X.400/X.500 APIs The X.APIA was originally created to define a set of APIs to an X.400 system. Later on, it came to act as an impartial forum for the development of other vendor-independent APIs such as CMC.

Its X.400 APIs are as follows:

Object Management API: XOM

XOM is a series of function calls which create, alter, and delete things like e-mail messages, directory entries, distribution lists, return receipts, and EDI messages. The spec is a little confusing at first, because one's accustomed to APIs with names and parameters that describe the type of object they're processing. The XOM APIs, however, are extremely general, and are used to manage a very wide range of things. It's much the same idea as MAPI's property management APIs. XOM calls are used in conjunction with the other X.APIs. For example: • The XDS API lets you request a directory entry. You then use XOM to change specific directory information such as someone's telephone number. • The XMS API lets you retrieve a message from a message store. You'd use XOM to make a copy and then alter some components like a distribution list or file attachments. In addition, XOM does the dirty work of converting a data structure into a protocol—that is, the formatted record that's sent over a network; and the equally dirty work of converting a protocol into an easily interpreted data structure.

Message Store API:XMS XMS lets a program access and administer a simple message store. You can: • Pick up arriving messages • Send a message or probe • Read and delete messages in a message store • Access inbound and outbound message logs You process the components of a message using XOM APIs. One interesting feature is that operations can take place synchronously or asynchronously. In the former, all application processing waits until the API call returns. With asynchronous processing, you set a maximum_number of outstanding operationsvariable, and then later check for completed API calls.

329 13 API Access

Directory Services API: XDS XDS lets a program access an X.500 directory to make queries and updates (figure 13.14). Strictly speaking, XDS doesn't require X.500 and could in fact be used to access another type of directory, such as a mainframe-based VSAM file. Like XMS, many operations can execute asynchronously as well as synchronously. This is clearly a requirement when you're dealing with a distributed X.500 directory, where some queries will take 30 seconds or more to resolve. As before, programmers use the XOM APIs for detailed tweaking of directory information.

Message Transfer API: XMT XMT—also known as the X.400 Gateway API—is designed for people building gateways between X.400 and non-X.400 environments. It lets a program connect directly to an X.400 MTA, and: • Pick up any messages, probes, or notifications destined for the non- X.400 environment • Submit messages which came from the non-X.400 environment to the X.400 MTA, once they've been put in X.400 format using XOM • Submit probes or notifications to the X.400 MTA So XMT provides for a small part of the work in writing a gateway. The bulk of the

FIGURE 13.14 THE X.APIA'S DIRECTORY ACCESS API 1.. ______

Search * Find entries of interest in a portion of the directory tree Read * Query information in a directory entry by name Receive Result Retrieve the result of an asynchronously executed function Abandon Abandon the result of a pending, asynchronous operation Compare * Compare an entry with a supplied value List * List the immediate subordinates of a directory entry Add Entry * Add a leaf entry to the directory information tree Modify Entry * Change a directory entry Modify RDN * Change the Relative Distinguished Name of a leaf entry Remove Entry * Remove a leaf entry from the directory information tree Initialize Initialize the API and allocate resources Shutdown Shutdown the API and release resources Bind Start a directory session Unbind Close a directory session Version Negotiate features of the API Ob. Mgmt. APIs XOM is used for fine-detail processing of directory entries

* means the function can execute asynchronously

The XDS API corresponds directly to X.500's underlying protocols.

development effort must go into converting message protocols or formats, converting address formats, and in the thankless but intricate task of mapping the facilities of the two mail services. Normally, XOM is used to create, read, and delete X.400 messages, while an API for the non-X.400 system (eg, cc:Mail's Import/Export) is used to process non-X.400 messages.

Message Access API: XMA XMA is similar to XMT, in that it connects directly to an MTA, and can accept messages from the MTA as well as submit messages to it for transfer. The main difference is that normally it only picks up messages for a single mailbox, and sends messages on behalf of that mailbox. It's really just for an e-mail client program that's constantly on-line to the MTA. XMA is unlikely to be of interest to many readers.

X.API Strengths • They provide a full set of APIs for X.400 environments. • They define a rich set of data structures, close to object oriented programming. • The APIs correspond closely to their respective underlying protocols (eg, XMS corresponds to P3 and P7). So they're a good way for systems software developers writing X.400 code to implement the protocols. • The documentation includes useful programming examples. • There's provision for both synchronous and asynchronous processing.

X.API Weaknesses • You need good C programmers to use the APIs. Preferably they should know C++, the object-oriented version of C. People unfamiliar with object-oriented programming will have to master many new concepts. • Very few people write to the APIs (the notable exceptions being people writing gateways between X.400 and non-X.400 systems). So hiring experience will be expensive and a challenge. • It's tough to get trained. The documentation is hard to understand; it's mainly for people who already understand what the APIs do and how they work. • Due to the very fine level of control possible, and the fact you've got to do it in C, programming is extremely time-consuming. • The message store API is limited, because the underlying X.400 message store model is limited. Things that stand out are 1) it consists of a single

331 13 API Access

folder containing messages; 2) that folder can't contain other folders; and 3) you can't store messages unless they've been sent to you.

Relevance to Corporate Developers • The X.APIs are well-designed, and offer a high level of control over a purely X.400/X.500 e-mail environment. • They are mainly of interest to people writing X.400/X.500 systems software. In particular, using the X.APIs is much preferable to coding and decoding X.400/X.500 protocols directly. • They're hard to learn, and code using them is expensive to write and maintain. • Very few corporate users will need to be familiar with the X.APIs.

13.3 API Alternatives APIs such as CMC, VIM, and MAPI are difficult to write to. In general, mail enabling will take place with much higher level interfaces. Here we present the most important of these.

DDE More and more messaging vendors are providing the ability to call the messaging system using Windows DDE calls. DDE is a standard way that two windows programs can exchange data. It's mainly suitable for applications that provide DDE functions in their scripting or macro languages, like Excel or Ami Pro. Figure 13.15 illustrates DDE calls in an Excel spread sheet, allowing access to BeyondMail. DDE use is mostly limited to "quick-and-dirty" programs, or to prototyping. Learn- ing to use the macros is tricky for most users, but can be mastered by reasonably competent programmers in a few hours. Reliability—and sometimes speed—problems usually prevent them from being used in production applications.

Forms Routing and Workflow Packages These let you design forms and their processing logic using a 4GL-like environment. Examples are JetForm'sJetForm, Novell's Informs, Delrina's FormFlow, and Banyan's BeyondMail in the PC arena, and IBM's ECFORMS and Verimation's Memo/Forms (figure 13.16) in the mainframe world. Typical features include: a form drawing package; moderately complex edit and validation criteria, which may include database lookups; calculated fields; field-

sensitive help and error messages; a 4GL-style language to define complex routing logic; and digital signatures. Forms-based mail messages—rather than free-form e-mail messages—make enormous sense, because programs can easily read them and determine their meaning. For this reason, expect heavy use of this type of tool for mail enabling.

DBMS Extensions Database development environments are beginning to have mail-enabling primitives built in. Oracle's an innovator in this field. Its PL/SQL language is used to define database transactions, and the SEND function (figure 13.17) allows a message to be sent to a user or another program. For example, if someone's budget is exceeded, the database can automatically fire off an e-mail notification, together with an ex- planatory message. Microsoft's SQL Server is another early player, and also has some built-in mail enabling. Today, don't look for much more than a Simple Send capability. But in the future, expect more and more mail-enabling functionality to creep into 4GL programming environments. The calls should be far easier to program than things like MAPI, although the granularity of control won't be as fine.

FIGURE 13.15 MAIL ENABLING WITH DDE CALLS

MACROLXLM

CHANNEL- INITIATECBMAILW,"MAILa - -TERMINATE r CHANNEL) -

DDE calls to BeyondMail in an Excel spread sheet.

333 13 API Access

13.4 Which API Should You Select? Your choice of API is likely to be determined by the hardware, OS, and messaging system you're using. For example, if you're running MS Mail for PC Networks on a DOS machine, your only option will probably be Microsoft's FFAPI.

However, if you do have a choice, here are our guidelines on what to

choose. Avoid APIs If You Can Our first advice on which API to choose is: avoid using any API i fyou can. Use higher-level access mechanisms instead, such as those we discussed above. This will simplify application development and maintenance. For example, if you're writing a forms-routing application, chances are the development package (such as JetForm) will handle messaging system access for you.

Is A Simple Send Enough? If so, restrict API use to it. Programmer learning, and program development and maintenance will be much simpler.

FIGURE 13.16 MAIL ENABLING WITH FORMS ROUTING PACKAGES

Options Formsail Functions Misc(Z) HELP 89-02-23 17.55.48 Formatted MEMO Destination =.> MEMO Title ..) Trauel Request Page 1I 11 Line 1 Col li 751

Travel request form.

Mame : MICHAEL FRAWLEY Department : GPR Phone : 201-123-4567 Purpose of treuel : business Going ta : Hamburg Going by : Plane Plane, Train, Bus, Ship Nuance needed : 12000 Dollars

ACCEPTED, PLEASE PRESS F3 TO GET APPROVAL

Enter FI.HELP F2.Directory F3=Send MEMO F4=Hardcopy F5=Seue MEMO F6=Dist List F7=Backward F8=Foruard F9.0elete F12.Return

Forms routing packages usually have a built-in scripting language, which provides an easy way of sending and receiving mail messages.

Check Required Functionality Check if the API has the functionality you need. File-based APIs have benefitted from more extensive market pummelling than programmatic APIs, so they often have some important bells and whistles. For example, cc:Mail's Import/Export has nice user-move functions, which VIM doesn't.

Programmatic Rather Than File-Based APIs For the reasons discussed earlier, programmatic APIs are, all things being equal, preferable to file-based APIs.

Try to use CMC If you must use a programmatic API, try to use CMC. This is easier to learn than VIM and MAPI. Also, the same calls can be used to access many different mail systems, so programmer education costs are reduced.

CMC Doesn't Imply Portability Don't expect your programs to be portable, simply because you're using CMC. Many other factors are far more important in determining whether software can be moved between environments.

Avoid MAP! Avoid doing MAPI programming yourself, because it's very tough to learn. All things being equal, the only people who should make the effort are: • Systems software developers, writing things like gateways, group scheduling packages, and messaging management utilities. • Corporate developers building high-budget production applications that need a rich messaging environment (hierarchical message store, hierarchical directory, etc), and that can't find higher-level mail enabling tools that will do the job.

FIGURE 13.17 ORACLE'S BUILT-IN SEND COMMAND

procedure send(sender_name_string, recipient_name_string, cc names_string, bcc_names_string, subject string, reply_to_string, body_text_string)

Oracle's database transaction language includes the ability to fire off an e-mail message.

335 13 API Access

Check inhouse Programming Skills Check what programming skills you have in-house. If you don't have C programmers, a number of programmatic APIs won't be applicable. Visual Basic is now supported by some APIs.

Avoid the X.APIs The X.400 APIs defined by the X.APIA should only be used by people writing X.400 and X.500 systems software.

14. Case Studies

Ministry of Agriculture, Fisheries and Food X.400 UAs & X.500 Directory The Ministry of Agriculture, Fisheries, and Food MAFF for short—is a UK government department. It has a number of wide and varied business aims including food safety, environmental protection, animal welfare, and the EC Common Agricultural Policy. MAFF has approximately 8,000 employees based in some 200 offices across the UK. These range from large headquarters buildings to small offices manned on a part-time basis. We interviewed John McKinnon, Value Added Data Communications Manager, whose responsibilities include messaging system support; and Richard Syrett, As- sistant Director of Information Technology, whose responsibilities included planning and organization of the overall messaging effort.

Computing Environment The computing environment (figure 14.1) consists primarily of UNIX servers connecting to Windows PCs. These connect over Ethernet LANs using LAN Manager as NOS and TCP/IP as transport. MAFF still has a number of asynchronous PAD-connected VT-100 terminals, but these are being replaced by Windows PCs, All 200 offices connect using a private X.25 network known as MAFFnet. This also connects to British Telecom's public X.25 network, GNS. Workstations connect in several ways: • LAN-based Windows PCs use LAN Manager protocols running over TCP/

337 14 Case Studies

IP to provide server-based file and print services. UNIX servers run LM/X, the version of LAN Manager that runs under UNIX. So, as far as LAN-based PCs are concerned, the UNIX servers look like any conventional PC network server. • VT-100 terminals are asynchronously connected to MAFFnet PADs. Users can connect to any MAFFnet host that they have access to, and run programs there. The same thing applies to traveling VT-100s, and VT-100s being used at home. • PCs at small offices without a LAN typically use VT-100 emulation, and dial in to a local MAFFnet PAD. They can then connect to any MAFFnet host, and run programs there. The same applies to traveling PCs, or PCs being used at home. • Access from outside MAFFnet is provided by DNS or direct dialup to MAFFnet. Having been validated by the gateway, access is as if by direct connection. There are about 5,000 workstations, of which 90% are PCs running Windows, and the rest are VT-100's. Currently there are about 40 UNIX servers distributed across MAFFnet.

FIGURE 14.1 MAFF'S COMPUTING ENVIRONMENT _____ si UNIX Server

LAN Manager & TCP/IP

Window s PC UNIX Serve

MAFFnet (Private X.25 Network) LAN Manager & TCP/IP

GNS Window (UK Public s PC X.25 ) International Terminal at Terminal at X25 small office/ small office/ Services WIndov,r VT-100 hornet , PC home/ traveling traveling workstation workstation

External Organizations Larger offices have UNIX servers and Windows PC workstations, connected over TCP/IP and Microsoft's LAN Manager. Offices and remote workstations are connected by a private X.25 network.

MAFF also runs some Prime minicomputers and an Amdahl mainframe. However, users have been migrating to the UNIX-machines-plus-PCs platform over the last two years, and only a few users of these aging systems remain.

Messaging Environment MAFF currently has about 5,000 e-mail users, of which roughly: • 4,000 use Enterprise Mail, an X.400 user agent from Boldon James that runs on a variety of platforms. • 500 use Banyan's BeyondMail. • 200 use Microsoft Mail. This group is a small business area that likes to run its computers independently. • 100 use PrimeMailPlus, a VT-100 interface to Prime X.400. Of the Enterprise Mail users: • About 3,500 use the Windows version. • 250 use a version of Enterprise Mail that runs in a UNIX server, and which is used by the VT-100s. • 500 use PCmail. This is a special client/server version of the standard Enterprise Mail Windows client. The server-based component handles message store and MTA access, while the Windows client software deals mainly with user presentation. The two processes communicate using remote procedure calls. It was developed by Boldon James at MAFF's request, and is now a standard Boldon James product offering. All three flavors of Enterprise Mail reference the same mailboxes. Many users will therefore use the Windows LAN version of Enterprise Mail when in the office, and PCmail and/or the VT-100 version when at home or on the road.

Why X.400? MAFF makes heavy use of X.400 user agents, but in fact has no objection to the use of proprietary clients. It chose X.400 primarily as a backbone technology, ie, as a vehicle to tie different messaging systems together. The main alternative considered was SMTP/MIME. MAFF opted for X.400 because: • Binary files can be transferred, but this often isn't the case with SMTP/ MIME implementations. • They wanted to provide service-level guarantees, and were worried that SMTP/MIME does not readily support confirmations.

339 14 Case Studies

• They also wanted reliable external connectivity. Commercial ADMDs can provide delivery confirmations and failure notifications, while Internet services have more of a "send-and-hope-it-gets-through" character. • It satisfies UK GOSIP requirements. • The technology was likely to be mainstream for the foreseeable future.

System Design

Message Transfer System MAFF uses a hub and spoke architecture (figure 14.2). Three central MTAs, each running on a UNIX server, act as central routing hubs. These machines are dedicated to an MTA and DSA process. No mailboxes are associated with them. Each hub MTA connects to a series of satellite MTAs located in offices. There are currently some 30 end system MTAs. Most end system MTAs run on a departmental UNIX server, along with other business applications. Each end system MTA can connect to all three hubs, which provides for resilience should the primary hub be unavailable for any reason, such as for maintenance. Most of the MTA software is Systems and Software Engineering's OpenPath.MAIL This is based on ISODE Consortium code. Some other MTA software is used, notably from Retix, Prime, and that which is bundled with the MS Mail gateway.

Routing MAFF considered linking end system MTAs directly to each other, rather than via a hub-and-spoke architecture. This was not favored because: • Not all MTAs are able to dynamically reference the directory for routing and connect information. This is still true. • Despite MTAs claiming X.400 conformance, there remain numerous problems in getting two MTAs to connect reliably. Mesh topologies suffer greatly from internetworking problems compounded by system/software upgrades. • A hub topology makes it easy to provide a manageable, secure gateway to external services. Thus a hub-and-spoke approach was adopted because it simplifies routing table maintenance. Hub MTAs need to have complete routing information, but an end system MTA needs to know only about the users it supports directly.

FIGURE 14.2 MAFF'S MTA-MTA LAYOUT

Office MTAs

MTA • • M TA

ATTMaiI

Beyond BeyondMail Mail Gateway

CWMaiI

Prime Guildford MTA Mail Gateway Prime Mail OSPMail

Londo York n MTA MTA

MTA

MTA s Office MTAs • MTA Office MTAs M TA MS Mail Gatmay

MS Mail

MAFF has a hub-and-spoke layout. Each end system MTA knows how to connect to each of the three hubs, and each hub knows how to connect to every end system MTA. Thus an inter-office message transits three MTAs.

Hub MTA routing is simple. Internal messages are routed simply by looking at their 0 and OU attributes. Each 0 and OU pair is associated with an end system MTA. Each end system MTA knows how to connect to all three central hub MTAs. It is configured to connect to a second hub MTA if for any reason it can't connect to its normal hub MTA; and if that second hub option fails, it will try the third hub. Among other benefits, this approach allows a given hub to be taken off-line for maintenance purposes.

341 14 Case Studies

Addressing The typical address of a MAFF user is: C=GB; A=ATTmail; P=MAFF400; 0=MAFF; OU=ITDS; S=Mckinnon; I=JJ Currently, there are two O's supported, MAFFand ADAS, and more are expected. There are many OU partitions. Often, several OUs are served by the same end system MTA. The selection of OU, S, and I matches precisely what is contained in internal hardcopy MAFF directories. This makes it easy to determine a colleague's address. When a new user has the same surname and initials as someone else in the same organization unit, a unique address is given by adding or dropping an initial. In the worst case, it takes 24 hours to get a new user registered and the address propagated across all routing tables.

FIGURE 14.3 MAFF'S UNIX SERVERS

MAFfnet

Client-Server VT-100 UNIX Version of Version of Server Enterprise Mail Enterprise Mail

Business Business iiMessage Store in Conventional Application Application Directories

LAN Manager over TCP/IP

Enterprise Windows Mail Windows PC Ghent PC

In additional to their portfolio of business applications, departmental UNIX servers contain an MTA and an unintelligent message store. They also run the UNIX-based version of Enterprise Mail, and a client-server version which connects to remote PC client software via remote procedure calls. LAN-based Windows clients access their message stores by conventional file redirection.

Message Store Architecture User mailboxes are located on departmental UNIX servers. How a user connects to their mailbox depends on the workstation and software being used (figure 14.3): • Enterprise Mail, running on a LAN on a Windows PC, uses file redirection to access a mailbox directory. • VT100 terminals log into the appropriate UNIX host and invoke the VT- 100 version of Enterprise Mail from the command line. This software is co- resident with its mailboxes, and accesses them directly. • Dialin PCs can emulate VT-100s, in which case they connect to the appropriate server and run the UNIX version of Enterprise Mail, as above. • Dialin PCs can also run PCmail. Here, PCmail connects to the appropriate server, and to its server-based code. This is co-resident with the user's message store, and accesses it directly. MAFF went to great lengths to design the system so it would allow users to access their mail from any office, their home, or anywhere else. Regardless of what interface a user has at any given time, he/she sees the same mailbox. Obviously, the cross-platform support has its limits. In particular, a dumb terminal user will not be able to view binary attachments sent by a Windows correspondent. So MAFF encourages users to send messages in straight ASCII text whenever possible.

Gateways Non-X.400 messaging systems connect as follows: • The BeyondMail users are an independent group. They run their own X.400 gateway. This contains an MTA, which links to the Guildford hub MTA. • PrimeMail uses an X.400 gateway, whose MTA connects to the Guildford hub. • The MTA contained in the MS Mail gateway connects to the York hub. An Internet connection takes place via a third party, EUnet, discussed later. EUnet runs an gateway that does the necessary conversion between X.400 and SMTP.

Directories

Architecture All name, address, and routing information is stored in an X.500 directory (figure 14.4). Each workgroup has its own DSA and controls its own user data.

343 14 Case Studies

FIGURE 14.4 MAFF'S DSAs

Office DSAs DSA • • • DSA

Guildford DSA

London York DSA DSA

Directory DSA Synchronization • DSA • • Office DSAs

DSA Office DSAs DSA

MAFF's DSA layout parallels its MTA one. All DSA contain an image of the entire directory, and are updated nightly.

The DSA network is very similar to that of the MTAs. Three central hub DSAs shadow the local DSAs, ie, each of the three hub DSAs contains a complete copy of the entire directory. If a local DSA can't resolve a query, any of the hub DSAs can do so. The routing tables used by central hub MTAs are automatically generated every evening from the directory. This process runs on one of the hub UNIX machines and the resulting configuration table is simply mailed to the other two. The DSA software used is Software and Systems Engineering's OpenPathDIR. This is also ISODE Consortium-based code. MAFF connects to the Paradise Project, a leading X.500 trial. All X.400 UAs—whether Windows-, PCmail-, or UNIX-based—use the lightweight

directory access protocol, LDAP, to access their local DSA. Boldon James doesn't support a full DAP connection.

Updating The Directory New users are entered by local administrators on the end systems, using a VT-100 screen front end developed by MAFF. The new user's data is normally propagated in the evening, during the general directory synchronization process. Since users are usually registered several days in advance of their needing to access the system, the time lag presents no problems. Occasionally, a directory entry must be propagated immediately, and the software lets the operator specify such processing if necessary.

Synchronization With Other E-Mail Directories Directory synchronization with Microsoft Mail, BeyondMail, and PrimeMailPlus was developed in-house. They are based on exchanging text-based messages and using APIs at both ends.

External Connectivity MAFF provides connections to the Internet and the world-wide X.400 network.

ADMD Connections MAFF connects to three ADMDs, to minimize the cost of sending messages. ATTmail is the main ADMD. It was originally selected because of the wide connectivity it provides, since ADMDs can only relay messages through a maximum of one other ADMD. The others are CVVMAIL, operated by Cable and Wireless, and OSPmail, operated by a low-cost provider called Open Systems People. Central hub MTA routing tables are defined so that the cheapest ADMD is selected for a particular destination. When the central hub MTA is ready to pass a message to a particular ADMD, it modifies the originator address in the P1 header only, such that it indicates the ADMD through which the message is being sent. This is done mainly to allow for delivery notifications being returned through the same ADMD. Although technically each MAFF user has three addresses, only the one containing ATTMail is published. Most MAFF users do not know that any of the three addresses (differing in the ADMD name attribute) could be used to send a message to them.

345 14 Case Studies

The ADMDs normally connect via the Guildford hub, although the London hub provides secondary routing. In connection with ADMDs, MAFF's John McKinnon has a number of interesting observations: • "ADMDs currently route on a peer-to-peer basis. Thus, you have to select an ADMD with the best connectivity now and in the future. This is totally impractical. Guaranteed levels of service are wonderful things but if you do not have the customer base they are meaningless. As a result of the poor connectivity, most of our external traffic goes via the SMTP gateway. Until the ADMDs get their act together, this will not change." • "One of the Internet's great strengths is the DNS, which X.500 replaces in the X.400 world. ADMDs will lose the war unless they provide strong X.500 support quickly; they also need to think of charging for knowledge references as opposed to usage fees." • "The cost of X.400 has GOT to come down. If it does not, commercial ADMD services will be flogging a dead horse and their revenue will lack even further behind their investment. How can you compete against the Internet when it is perceived to be free?"

Internet Connections The connection to the Internet via SMTP is provided through an external service provider, EUnet. The service provider also provides translation from X.400 to SMTP and vice versa. A MAFF X.400 user sends messages to Internet users via addresses with the following format: C=gb; A=attmail; P=maff400; 0=MAFF; OU=SMTP; DDA.RFC-822=smithj(a)acme.com Conversely, an SMTP user sends messages to someone at MAFF with addresses in the form: [email protected] The translation algorithm is the obvious one. The leading characters—j.j.—are converted into initials; mckinnon is converted into a surname; itds becomes the OU. maffgov.uk are used to create the leading attributes of the X.400 address, and A is set to attmail.

Management MAFF feels the tools for management are not as good as they should be. They don't have alarm facilities, so they do not easily know when something goes wrong. At times, their main method of determining when things have gone wrong is to wait until users call in with complaints. Further, the larger the network grows, the longer troubleshooting takes. The backbone architecture they adopted helps to reduce these problems. End system X.400 configurations are pretty much standardized across the network, with the only volatile components being those relating to the local user base. This reduces the likelihood of problems, since end system administrators need only maintain their local user base and nothing else. Three people working part time are sufficient to provide the required troubleshooting and maintenance. OpenPathMAIL will probably support the MADMAN MIB at some point, and this should provide some help. With hindsight, MAFF wishes it had paid more attention to messaging management at an early stage of implementation. Nevertheless, things work reasonably well, and they feel it would now be difficult to develop a business case for an expensive new management system.

Traffic Recent message traffic is shown in figure 14.5. For January 1995, the average message size is 9KB, with a maximum of 5.3MB. The largest message ever recorded was 11.5MB.

FIGURE 14.5 MAFF TRAFFIC INlo______

September 1994 52,134 October 1994 56,488 November 1994 76,119 December 1994 73,322 January 1995 103,823 February 1995 109,968

Messages transiting MAFF hubs. The average message size is about 9KB.

347 14 Case Studies

Traffic per user is light. The hubs process an average of about 4,500 messages per day, or 1 message per user per day. MAFF estimates that 80% of all messages don't go beyond their local end system MTA. So each user averages about 5 messages per day; or each user sends about 2.5 messages per day and receives about 2.5 messages per day. Today, a figure of 5 to 10 messages sent per user per day, and 5 to 10 received, is more typical of large organizations. Each message transits just one of the three hubs. Thus each hub processes an average of about 33,000 messages per month, or about 1,500 messages per day. At peak periods, hubs have to handle relay rates of some 400-500 messages per hour. While these traffic figures are not high, they are increasing rapidly. MAFF has sufficient capacity, and monitors utilization to ensure that it continues to have it in the future.

Service Guarantees The formal service guarantees are: • 90% of all urgent messages will be delivered within 4 hours • 90% of all non-urgent messages will be delivered within 12 hours However, most messages within MAFF are delivered in two to five minutes.

1984 vs. 1988 UAs The X.400 MTAs are a mix of 1984 and 1988 systems, and they interoperate well. However, MAFF found that the same cannot be said of 1984 and 1988 UAs, and its UAs are all of the 84 variety: • It found that solid 88-conformant UA products are rare. • For attachments, MAFF uses body part 14 (unidentified body part), commonly accepted among 1984-conformant implementations as a file transfer mechanism. A 1988 implementation is more likely to use body part 15 (externally defined body part). This is set in the UA, and therefore, mixing 1984- and 1988-conformant UAs causes problems. • A 1984-conformant UA uses the P2 format, while 1988 UAs uses the P22 format. Although they are very similar, X.400 does not specify how to downgrade from P22 to P2. So even if the downgrading works within MAFF, confusion can be expected with external users. • Using 1988 would require use of a 1988 message store. MAFF has held off from implementing this, for a number of reasons. The 1988 message store is very flat, and it's unclear how it will be used. Also, the software required for

the P7 protocol would probably be too demanding for PC workstations, and implementations are rare. Migration to 1988 would be further complicated by transitional issues, when some users are 1988 and the rest still 1984-based. Nevertheless, MAFF recognizes the benefits of a 1988 service, and is currently investigating the conversion issues.

Authors' Observations

System Design • The use of X.500 makes most directory synchronization work go away. It also provides a smooth migration path for connection to the world- wide X.500 directory. • It's unclear why the DSA hub architecture directly mirrors the MTA architecture. However, having three DSAs provides for better resilience and load balancing. • We like MAFF's approach that an individual should be able to get his or her messages from anywhere. A message store and clients able to communicate via the P7 protocol would have greatly simplified the implementation efforts, had they been available. • Addressing is too complex. The built-in routing information does reduce hub MTA routing table maintenance, but at the sacrifice of user convenience. The normal address should be something like: G=john; S=smith; P=maff; A=attmail; C=gb • We agree with MAFF that it would be preferable to allow end system MTAs to route directly to other end MTAs. This would reduce delivery times, and make more efficient use of the network. For further discussion, see chapter 4, section 6. • MAFF's use of 3 ADMD carriers is interesting. Multiple providers can be a powerful cost-reduction tool for organizations with large external message volumes. X.400 simplifies having multivendor connections because the connection is standardized.

Management • MAFF is unusual in that it has been able to standardize on X.400 (almost) everywhere, including UAs. This greatly simplifies the support work, and makes it easier to ensure timely message delivery and troubleshoot delayed messages. • Loads on the hub MTAs are currently low (peak rates of 400-500 9KB

349 14 Case Studies

messages per hour). They'll grow by an order of magnitude over the next few years, and MAFF should have the capacity readily available. • The use of TCP/IP everywhere means it's possible to run MTA management programs (which today run on the MTA host machine) from a central location, using a Telnet connection. This is an important advantage. Also, the hub and spoke architecture makes the MTAs (both hub and end-system MTAs) very consistent in configuration, and reduces problems. • MAFF is right to look forward to OpenPathMAIL support for the MAD- MAN MIB. This will certainly help detect and fix many message transfer problems, but it's far from a panacea.

Other • MAFF has done quite a lot of programming to make things work together, notably to get directory synchronization working, and to develop the client/ server version of Enterprise Mail for remote PCs. Don't expect an X.400 backbone to be a plug-and-play affair. • Restricting interpersonal messages to be 1984 conformant is sensible. There are no real benefits to 1988 conformance for MAFF at this time. MAFF would like to use the 1988 security extensions, but the migration problems, in particular for binary file transfer, are enormous.

Richard Syrett (1947 - 1995) Sadly, Richard Syrett—Assistant Director of IT and the first person we interviewed at MAFF—died during the preparation of this case study. His colleague and co-interviewee John McKinnon prepared the following tribute: Richard meant a lot to his colleagues at MAFF. He touched many different peoples' lives in many different ways. He was a great man who you would always want on your side. Not least of his many fine qualities was his ability to respect you, so that once you had gained his confidence he would take whatever you said without question. A man of power, he was never one to mess with, and never suffered fools lightly. In his own words, he took incompetence in others as the norm and anything else as a bonus. He was totally committed to his work: when necessary, he would finish in the early hours of the morning, and he relished the challenge of a tight deadline. Yet he was also a family man who always found time for those closest to him and spoke about them with great affection. Amongst all this he found the time to work with charities. The brash exterior hid a deeper Richard who will be missed and mourned for a long time to come. God rest his soul.

Richard was a striking man, even if you met him only briefly. In September, 1994, I spent several hours with him on the phone discussing X.400 and what MAFF had done. Shortly afterward I spent an evening with him and several colleagues at his favorite restaurant in San Francisco. They were on a flying visit to the the US, meeting with various vendors. The conversation was lively, full of good-humored iconoclastic banter, and ranged from advanced computer architectures to the French government's rural policies. Two weeks later, he discovered he had an advanced case of leukemia. He then undertook several drastic therapies, and kept a log of his experiences. This he e- mailed every week to concerned parties until his death in February, 1995. He kindly included me in his distribution list. It was a troubling and gripping experience to read the diary, which was delivered from his bedside to recipients over the world within minutes. One read about his marriage to his long-time girlfriend, June; the visits of family and friends and many people from MAFF; the treatments; the hospital food; the battles with hospital wiring and telex systems to get electronically connected when he moved to a new room; and so on. He endured the hardships with great courage. He used e-mail to bring many people close to him; and likewise, e-mail was a good, unintrusive way to communicate with him. He died very suddenly, within a few hours of his last message, to the shock and distress of many. David Ferris

351 14 Case Studies

Florida Power Corporation Florida Power Corporation—FPC for short—is a power utility for the northern, central, and western areas of Florida. It has 4,000 employees, at 19 locations. We spoke to Ted Kimer and Jim Wells there, both systems analysts. Kimer was responsible for planning the new messaging environment, while Wells is in charge of implementation.

Computing Environment Most of FPC's systems run on a NetWare LAN platform. There are now: • 3,200 PCs. They all run Windows, and connect to conventional HP- based file servers using NFS. • 150 VAX terminals, connecting to 8 VAXes. They are normally PCs and do terminal emulation into their host. • 200 Sun workstations. Recently, the company has been migrating to a platform consisting of Windows PCs connected to UNIX servers with TCP/IP and NFS. About 40% of the PCs are still connected by NetWare: FPC expects the migration to be complete by January 1996.

Messaging Environment The NetWare-based environment uses ON Technology's eMAIL, which used to be sold by Da Vinci. However, a new messaging system is being installed along with the migration to the TCP/IP environment. This is based on Hewlett-Packard's OpenMail (figure 14.6). OpenMail runs under UNIX, and provides a message store, directory services, and MTA. The message store is based on a 1988 X.400 message store, although the model has been substantially enhanced. The directory service is proprietary to HP. Messages can be moved around either in X.400 format using X.400 MTAs, or using UNIX' Sendmail utility. The message store, directory, and MTA services run on centralized UNIX servers. Several types of client software can be used, notably cc:Mail and Microsoft Mail. At FPC, PCs run cc:Mail as clients, and messages are moved around with X.400. Thus, the current messaging environment is: • 2,600 cc:Mail users, connected to OpenMail. • 2,400 users of ON Technology's eMAIL.

FIGURE 14.6 OPENMAIL ARCHITECTURE

X 400 or Sendrnail Trains•ort Proprietary Message Store & Proprietary Directory Access Protocol Message Store X.400 or Sendmail Transport User Proprietary Interface Directory 1983 X.400 Ease - Message Store UNIX Server

Proprietary Typically a PC Directory' running cc:Mail UNIX Server X 400 or Sendrna Transport

Proprietary' Message Store

Proprietary Directory UNIX Server Network of Servers connected by X.400 or Sendmail over TCP/IP

HP's OpenMail uses scalable UNIX servers to provide a proprietary message store and directory. Messages are moved around with X.400 or SMTP, both running over TCP/IP.

• 200 users of HP's OpenMail client for Sun Solaris. This is a proprietary front end from HP that runs on Sun workstations, and connects to OpenMail. • 150 VMSmail users.

Why OpenMail? FPC was attracted by: • Response to RFP. FPC send out a request for proposal to 12 vendors. Only three responded, HP being one of them. • Client of choice. FPC wanted to let users run cc:Mail as the main user interface. They evaluated several choices, and cc:Mail emerged as the clear client of choice. They looked at things like: meeting Windows GUI functionality requirements, providing folders, a spellingchecker, etc. • Supports non-PC platforms. OpenMail has a user interface for FPC's Sun workstations. • Scalable message store. They can put many hundreds of users on a single message store. This greatly reduces the administration effort. In practice,

353 14 Case Studies

conventional PC e-mail systems typically max out at about 100 mailboxes per message store. • Efficient network usage. Far less network traffic is generated when a client workstation connects to a server using a protocol, rather than using file redirection. • Server reliability and overall up-time. This is mainly due to the use of UNIX. For conventional PC e-mail systems, message store backup and reorganization is a major headache. Other major reasons FPC chose to go with OpenMail are: • Centralized administration. Because TCP/IP is used everywhere, support personnel at a central location can do terminal emulation (with Telnet) into any server, and thus run management utilities remotely. FPC also liked the availability of two SNMP-based management tools from HP, Open View Network Node Manager and Open View OperationsCenter. • Support. FPC felt HP's support was of good quality. • Proven solution. OpenMail references gave FPC confidence that the system would work for them.

Why X.400 As Transport? FPC chose to use X.400 instead of Sendmail to move messages around, because: • Where possible, they like to be standards-based, and thus be able to choose from many vendors. • Many gateways are available for X.400. • FPC believes X.400 is a superior because Sendmail was not designed for use as an e-mail backbone. This is because, for example, it has better support for binary file transfer (in the absence of MIME), and better traceability. • X.400 provides guaranteed deliveries. Sendmail messages can get stuck without the sender being automatically notified. • Finally, FPC wanted to run OSI over IP, as a result of a corporate decision they took to be OSI compliant.

System Implementation

Message Transfer Architecture MTA's are laid out in a hub and spoke architecture (figure 14.7). There are 19 MTAs in all. Of these, 14 are at regional offices and serve relatively small numbers

of users. Five serve larger offices, and also act as routing hubs. Routing hubs connect on a peer-to-peer basis. The MTAs run on HP UNIX servers, frequently along with non-messaging applications. Only two MTA machines (soon to be 3) are dedicated to messaging. As we've implied, in all cases X.400 runs over TCP/IP. FPC found that machines supporting many mailboxes work out proportionally

FIGURE 14.7 FLORIDA POWER'S MTA LAYOUT

(140) (38) 26

North Anc o Bartow Suncoast e Plant 68 (157) Plant () Earned 3rd & 3rd Tower

(50) (129) Energy South Control Suncoast Center

Gateway to VMSmail (61) (852) GOC Gateway to ON/ (595) Da Vinci eMAIL EOF (126) Allakihh. Lake Crystal Nvirr. Wales River

153 Buena Vista Central Winter Division Park (99) (114) Apopka

(32) Northern Mid James Division Florida town Easter n (59) (30) E (38) (33) MIA's are organized in a hub-and-spoke architecture. MTAs at major offices also act as routing hubs. The numbers in parentheses indicate how many mailboxes are at each location.

355 14 Case Studies

more expensive than ones with less horsepower. On the other hand, software costs are proportional to the number of MTAs. MTA locations were determined using a spread sheet to trade off hardware and software costs. The increased cost of administration of multiple MTAs was not factored in.

Gateways The GOC MTA runs a co-resident NetWare MHS gateway, provided by Worldtalk Corporation. This directly converts ON Technology's eMAIL messages. VMSmail users are connected by Wingra Technologies' Jimafor VMS gateway. This converts between VMSmail and NetWare MHS formats; Worldtalk's NetWare MHS gateway then converts messages between NetWare MHS and backbone formats.

Directory Synchronization OpenMail servers each maintain their own directory, and they update each other using an HP-provided utility. Synchronization takes places every night, in a scheme developed to some extent by trial and error. At 9:00 pm, the first phase starts, and one by one each spoke server pushes its changes to its hub. Concurrent updates by peer spoke servers against their hub have been found not to work well, so each spoke gets its own 15-minute time slot. At midnight, phase 2 starts, and the hubs consolidate changes among themselves. One hour is set aside for this. At 1:00 am, all the hubs are fully synchronized. At 1:00 am, phase 3 starts. Each hub pushes the changes to its spokes, one by one. It's all over by around 3:00 am. Thus a complete synchronization process takes about six hours. FPC arrived at this approach after quite a bit of experimentation. Ideally, all directories would have synchronized directly to a single master directory. However, difficulties with concurrent synchronization, and insufficent memory problems on servers running concurrent applications, made this impractical. Despite FPC's efforts, the current synchronization setup is still unreliable. For example, co-resident server processes such as backups can make files unavailable, or machines can run out of disk space, or there can be memory problems. Also, sometimes there are problems with proliferating duplicate entries.

Addressing Internally, OpenMail uses message addresses of the form: G=james; I=a; S=wells; 0=florida_power; OU1=goc; OU2=openmail; P=flproc; A=mci; A=us The OU/ attribute indicates the department or location, while OU2 indicates the messaging community. eMAIL users, accessed via a NetWare MHS gateway, have X.400 addresses with OU2 set to mhsgw. Eventually, all users will migrate to OpenMail, and the OU2 attribute will be superfluous. Although FPC isn't currently connected to an ADMD, it uses A=mci in the addresses, hoping that if or when FPC connects to the world-wide X.400 network, MCI will offer it a reasonable deal. Users don't normally see their X.400 addresses, since they access the system through a cc:Mail interface. In conventional cc:Mail environments, users browse addresses of the form: Wells, James A. However, in FPC's case, cc:Mail clients display addresses that meld cc:Mail and X.400 formats. A typical entry is: Wells, James A./OU1=goc/OU2=openmail/0=florida_power/C=us/ A=mci /P=flproc FPC decided to include the X.400 attributes so that users can be sure they've got the right person. The plan is to simplify this somewhat, so that cc:Mail users browse addresses like:

Wells, James A./OU1=GOC/OU2=OpenMail

Addressing Idlosyncracies

Unexpected problems crop up when putting a standard to work. FPC gave us a nice example, that of users who need their full middle name and only the initial of their first name, such as: J. Gordon Swayze The trouble arises because X.400's / attribute only allows up to 5 characters. FPC's solution was to cram the first initial and the middle name into the G attribute, as in G=J_Gordon; S=Swayze; 0=florida_power; OU1=goc; OU2=openmail; P=flproc; A=mci; A=us Not elegant, but it works.

357 14 Case Studies

Mail-Enabled APIs FPC has an extensive library of mail-enabled applications running over ON Technology's eMAIL, and anticipates a similarly large portfolio for the new environment. Today, OpenMail-based applications use a proprietary API, called UAL. FPC writes its applications using a generic API it has defined. This isolates UAL, and should allow applications to migrate to standard interfaces as they become available. Early API experience suggests caution. Some FPC applications, such as Excel and Microsoft Word, can make MAPI calls to send a file. This worked fairly quickly for Excel, but took a while to get working with Word. Finally, it was resolved with Microsoft's help, and turned out to be a client configuration error. Nevertheless, PC-based configuration issues are often overly complicated, even for trained help desk personnel and technicians.

Migration Utilities Migrating a user from ON's eMAIL to cc:Mail/OpenMail is quite a task. It requires the creation of a UNIX logon ID on the OpenMail server, creation of an alias on the WorldTalk gateway, deletion of the eMAIL entry, creation of a cc:Mail front end for the user, converting saved messages, and so on. All this is labor-intensive and error-prone, so FPC developed applications which automate much of the process.

External Connectivity Florida Power has no ADMD connection, because there's insufficient demand to warrant the bother and expense of installing an X.25 connection. As we noted above, however, their addressing structure is ready for connection to MCI. Although it's technically simple to connect OpenMail to the Internet, FPC decided not to do so. They're worried about the security risk of hackers somehow compromising their TCP/IP network. Where a user needs Internet access, they let them do so via standalone machines which have no electronic connection to the in-house network.

Observations & Suggestions • FPC was attracted to OpenMail's message store because it can handle large numbers of mailboxes. This makes management cheaper, easier, and better.

• A pure 1988 message store would probably have been inadequate for FPC's needs: it's simply a flat In Tray. • FPC was attracted by the lesser network traffic required by a protocol to access a message store, instead of drive redirection. The use of P7 to connect a user agent to an X.400 message store is rare today—most X.400 UAs use drive redirection to access an MTA message queue. Nevertheless, proper client/server protocols between workstation and message store should become widespread due to their reduced bandwidth demands. • We like FPC's idea of putting an isolation layer in its mail-enabling applications. For the moment, readers wanting to do the same should probably model the insulating API on CMC. • It's a pity end system MTAs don't route directly to each other. This would let messages through more quickly, reduce network traffic, and simplify troubleshooting (see chapter 4, section 6). • The use of X.400 does nothing to ease the problems of directory synchronization. If OpenMail had an X.500 directory, life would be much easier. • FPC users see addresses that are far too complex. When using cc:Mail to browse the directory, they should see normal cc:Mail-style address, ie, addresses in the form: Wells, James A. Disambiguating information such as the department the user works for should be put in the cc:Mail comments field. FPC decided against this solution, since their work force tends to change, and they did not want to have to enter additional information. • The underlying X.400 addresses are too complex. Routing information should be removed. FPC should normally restrict itself to the use of G, S, P, A, and C attributes. • FPC wants users to be able to use a popular front end, in their case cc:Mail. As more and more client software is built on top of MAPI, and as MAPI service providers become available for X.400 and X.500, the use of a major package as front end to X.400/X.500 infrastructure will become common. • FPC has held off connecting to the world-wide X.400 network because of the cost of installing and maintaining X.25 connections. When APS support becomes available, the reduced costs may justify connection. • Connecting to the Internet using machines not on the in-house network makes sense for big TCP/IP shops. Nevertheless there are still security exposures, notably to viruses when a user downloads a binary file and transfers it by floppy disk onto a network machine.

359 14 Case Studies

• FPC has in-house programming resources. These were used to develop several applications, including: a password change script that help desk personnel use to update passwords; tools for public distribution list maintenance; and a UNIX based tracking system that addresses and posts e-mail through the HP provided API. • Note the way FPC evolved its directory synchronization in the light of experience. Conclusion: expect some design to be 5% science, 60% art, 35% alchemy.

Dutch Ministry of Transport The Dutch Ministry of Transport, Public Works, and Water Management is mainly responsible for providing and/or coordinating road, water, and air transportation in Holland. Transport comes first, together with traffic and communications. It has 15,000 employees at 110 different locations. We spoke to Mr. Toine Wayers, an IS strategic planner at the Ministry, about the messaging system.

Computing Environment The computing environment consists of • 30 DEC VAXes, of all sizes. These connect to UNIX and PC workstations. PCs connect to the VAXes using PathWorks, a version of Microsoft's LAN Manager NOS. • About 150 UNIX workstations. Most of these are Suns; a few are from other manufacturers, notably Hewlett-Packard. • 15,000 PCs, of which 80% are DOS, the remainder being Windows. Ethernet LANs connect everything at the various locations. Most of the PCs are clustered into conventional departmental LANs: 80% of the time Microsoft's LAN Manager is the network operating system, usually running over a TCP/IP transport, although occasionally it runs over NetBEUI. The rest of the PC LANs use NetWare, with Novell's proprietary SPX/IPX as transport. See figure 14.8. Locations are connected using several technologies: • For the most part, TCP/IP is used. Each LAN connects to a Cisco router, which then connects to the Ministry's private TCP/IP internetwork. • Some DECnet connections exist. • MTAs exchange X.400 packets over X.25

The running of the WAN as a whole is outsourced to

EDS. Messaging Environment The Ministry has some 2,500 e-mail users: • 2,000 use DOS and Windows 1988 X.400 user agents from NET-TEL. • 400 use Novell's GroupWise (previously known as WordPerfect Office). • 50 use a remote 1988 X.400 user agent, also from NET-TEL. These DOS and Windows clients are used for dialup. • 2 use a Sun-based 1988 X.400 user agent, also from NET-TEL.

361 14 Case Studies

FIGURE 14.8THE DUTCH MINISTRY'S LOCAL COMPUTING PLATFORM

DOS or 1988 Cisco PC UNIX PC Message Router Machine Store

LAN Manager over TCP/IP or NetBEUI NetWare over SPX/IPX

•

Most PC LANs consist of a conventional file server connecting to a PC using Microsoft's LAN Manager over TCP/IP; about 20% use NetWare. A separate MTA transfers messages. The message store is either passive directories in the main file server, or if fully 1988-conformant, resides in a dedicated machine.

The Ministry's ADMD is 400NET from Dutch Telecom. There is also an Internet connection provided by Surfnet. In twelve months, there are expected to be about 4,000 X.400 user agents, most based on DOS and Windows. The GroupWise community is expected to diminish slightly.

Why X.400? In 1992, the Ministry evaluated how best to provide a messaging system spread across its various environments. It chose X.400 for its backbone mainly because the Dutch government encouraged the use of the technology. It briefly considered running proprietary PC packages such as cc:Mail and MS Mail, and letting these attach to the backbone. How- ever, the Ministry felt it was far better to bring X.400 right down to the workstation, because: • X.400 user agents were available for their Sun, DOS, and Windows workstations, as well as for the VT-200 terminals which were in use at the time. The Ministry believed that no proprietary package could do this. • It felt X.400 user agents could do everything users wanted, just as well as proprietary packages. • By standardizing on X.400 UAs, they'd avoid a lot of the problems associated with gateways.

The Ministry never seriously considered putting a proprietary PC e-mail package everywhere, because it believed X.400 systems are far more scalable and will, in the long term, lead to a lower cost of ownership.

Why Go With A Single Vendor? The Ministry decided to go with MTAs, message stores, and UAs from a single vendor, NET-TEL, for three reasons: • The products worked well during rigorous interoperability and conformance testing using the Ministry's OSI and Internet profiles. Several other vendors' products were similarly tested. • The prices were attractive. • It was felt that the system would be more stable with products from a single vendor. As the Ministry gains confidence and experience, it may well purchase elements, notably user agents, from other vendors.

Message Transfer System

MTAs Each office that participates in the messaging system has its own MTA. At the time of writing, 28 offices had installed MTAs; the remaining 80 locations will add their MTA and other messaging infrastructure when they choose to spend the money. There are two central hub MTAs, at The Hague and Spijkenissen (figure 14.9). The MTA software used is supplied by NET-TEL. 60% of the MTAs run on HP/ 9000 UNIX machines. The remainder run on PCs, most of which are DOS-based although some run SCO UNIX. MTAs communicate using CLNS-over-X.25, over the Ministry's WAN. This is surprising, since the WAN predominantly uses TCP/IP. CLNS/X.25 was selected because X.400-over-TCP/IP software was not available for the Hewlett- Packard MTAs at the time. It was also felt that CLNS posed less of a security threat, since hackers are usually unfamiliar with the technology. The Ministry intends to upgrade the MTAs to a TCP/IP transport sometime in the future.

Unreliability of DOS-Based MTAs The Ministry as a whole has a lot of experience with HP UNIX workstations. Nevertheless, many offices' expertise is limited to LAN Manager or NetWare-

363 14 Case Studies NE...Emma.______

FIGURE 14.9 MESSAGE TRANSFER ARCHITECTURE

OS/2 PC DOS PC Group- SMTP Gateway Wise Gate- GroupWise SMTP MTA Gate- way way

UNIX Machine

The Hague Spijkenissen

MTA MTA MTA MTA

MTAs are connected in a conventional hierarchy. An SMTP gateway provides Internet connectivity, and a GroupWise gateway connects the 400 mailboxes in an independent user group.

based PC networks. So, when an office first installs messaging connectivity, they often prefer to use a DOS machine to run the MTA, since this is the most familiar technology, and since PCs are also cheaper than UNIX machines. The Ministry finds that the reliability of DOS-based MTAs is below standard. They can stop functioning for a variety of reasons; and when they do, no alert is generated. In fact, often the first indication that something's wrong is when users complain that mail isn't getting through. Thus users are encouraged to migrate from DOS when they get to about 50 mailboxes: PC-oriented offices tend to run SCO UNIX on a PC, while offices with HP experience usually prefer to use an HP/9000.

Addressing A typical address is: C=NL; A=400NET; P=MINVENW; O=MINVENW; OU1=RWS; OU2=MDI; S=Wayers; I=ARJ where the I value contains the person's initials. This structure contains generous quantities of O's and OU's, they reflect the natural organizational divisions and sub-divisions within the Ministry. There are about ten OUls in all, and each OU1 has up to four 0 U2s below it. To ensure the SMTP gateway doesn't get confused, no blanks are allowed in X.400 addresses.

This convention was adopted in order to have natural and intuitive addresses, and so that users can accurately predict what a colleague's address is. Addresses also contain routing information, because otherwise the Ministry felt managing MTA routing tables would be too labor-intensive. Most of the time, users do not have to deal with these long X.400 addresses. They normally address messages by browsing a list of aliases.

Routing All MTAs have very simple routing tables. A simple pattern match against the 0, OU1, and OU2 attributes determines whether a user is local. If it isn't, outgoing messages are sent to the adjacent hub, either at The Hague or Spijkenissen. The central hubs also route based on the 0 and OU attributes. Their tables have the same structure as that of figure 4.7 (page 107). Because addresses contain routing information, maintenance of hub routing tables is trivial. Message have to go through up to 4 MTAs in transit. The maximal hop case occurs when the messages go between two offices, where one office's MTA is a satellite of the MTA at The Hague, and the other office's MTA is a satellite of the Spijkenissen MTA. Messages arriving at their destination MTA are handled in one of two ways: • The message is placed in a message store directory in the main departmental file server. • If a 1988 message store is used, the MTA transfers the message to the separate machine that runs the message store. Conversely, the MTA normally picks up outbound messages from a file server directory; if the 1988 message store is used, it picks up messages from the message store machine.

Message Stores The Ministry has 28 message stores. All but one are of a mostly-1988 variety. They support many 1988 features such as distribution lists and the P22 protocol. On the other hand, they don't support the P7 protocol, so aren't a full 1988 implementation. Message stores are co-resident with the local MTA if the MTA runs on a UNIX machine—either on an HP/9000 or on a PC running SCO UNIX. Alternatively, if the local MTA runs in a DOS box, the message store is located in LAN Manager or NetWare file server directory.

365 14 Case Studies

1988 Message Stores & Remote User Access As of early 1995, one newly-installed message store is fully 1988-compliant. This is located in a 486 PC with 8MB RAM and 450 MB of hard disk. It supports about 50 mailboxes. The message store machine is used solely for dialin access, and has a modem pool attached. There are about 50 remote user agents, provided by NET-TEL. The software is identical to the LAN-based version, except that it contains special dialup communications software. More specifically, the remote user agent software: • Dials into one of the modems attached to the message store machine • Establishes dialup communications using a proprietary NET-TEL protocol • Exchanges mail using the P7 protocol The Ministry plans to migrate all its message stores to full 1988 implementations in the latter part of 1995, the main reason being to make life easier for remote users. To minimize incompatibility problems, the migration will be done quickly, in one to two months.

Directories Directories are stored locally, and controlled by the NET-TEL user agent software. Every two weeks they are consolidated to a central master directory, and the master is then transmitted back to bring the local directories up-to-date. It's actually a two-tier process. The details are as follows: • Local directories are updated when required by local office administrators. • Every two weeks, a message is sent to all local administrators telling them to send in their address book, otherwise they won't receive the consolidated update. • The address books are sent to a central functional mailbox, with an alias equivalent to "Address Book Update". • A NET-TEL utility produces a new, X.400-system-wide directory from the various directories that have been received. • X.400 aliases and addresses are extracted from the GroupWise directory, and are injected into the consolidated directory (see the following for more details). • The new directory is e-mailed back to local administrators as a file attachment. Installing it is simply a matter of placing the file in a system directory.

A two-week cycle time was chosen as a compromise between currency of directory information, and the effort involved in gathering the latest versions. The approach is seen as a stop-gap measure until the Ministry implements an X.500 directory.

GroupWise/X.400 Directory Synchronization Organizing directory synchronization with the GroupWise environment was not straightforward, notably because the GroupWise gateway has no support for synchronization, and no support for address mapping. In the GroupWise directory, an X.400 address can be defined for each user. This is done manually, by the local administrator. In other words, the local administrator must go in to the GroupWise directory and type in the X.400 address of all their GroupWise users. The GroupWise gateway provides a utility which can export directory information to an ASCII file. Likewise, NET-TEL has a utility which can read in X.400 addresses from an ASCII file with a NET-TEL-defined format, and inject the addresses into the NET-TEL directory. So NET-TEL did some integration work for the Ministry, writing a simple utility that: • Exports up-to-date names and X.400 addresses from the GroupWise directory into a flat ASCII file, using a GroupWise utility • Converts the file into a different, NET-TEL-defined format • Imports the ASCII file into the NET-TEL directory, using the NET- TELprovided import utility

Only A One-Way Process No one has written a utility to inject names and addresses from the main X.400 environment into the GroupWise environment. So GroupWise users can't browse their directories for the names and addresses of X.400 users. Instead, they have to guess or otherwise determine recipients' X.400 addresses, and type them in using an addressing template.

Gateways

SMTP/MIME An SMTP gateway, produced by Hewlett-Packard, runs in a UNIX machine in Spijkenissen. Its co-resident MTA connects to the Spijkenissen hub MTA. To send

367 14 Case Studies

an SMTP message, users insert the SMTP address in an X.400 DDA, as shown in the following example: C=NL; A=400NET; P=MINVENW; O=MINVENW; OU1=SMTPGATEWAY; DDA:rfc822=DDA=a.r.j.wayers(a)mdi.rws.minvenw.nl This is rather lengthy. However, most of the time, users don't have to enter in all the characters. They either select a pre-defined address book entry, or alternatively enter the Internet address using a template (which fills in the rest of the X.400 attributes and values). Addresses are also designed so they convert easily between X.400 and SMTP formats. A natural mapping is used. For example, C=NL; A=400NET; P=MINVENW; O=MINVENW; OU1=RWS; OU2=MDI; S=Wayers; I=ARJ is converted into: [email protected] We leave the algorithm concerned as an exercise for the reader. The SMTP gateway can't handle file attachments, so the Ministry plans to upgrade it soon to a fully MIME-compatible version produced by NET-TEL.

GroupWise The GroupWise messaging community connects via a Novell-provided gateway, which attaches to a NET-TEL MTA running on an OS/2 PC. This in turn connects to the hub MTA at The Hague. The user group concerned is responsible for maintaining the GroupWise gateway and its attached MTA. The GroupWise gateway is a significant source of implementation issues. For example • It can interpret messages in the P2 (1984) format, but not the P22 (1988) format. Messages created by NET-TEL's 1988 user agents containing characters like a or a generate a reject message, or even worse simply disappear. • As we discussed, the gateway lacks support for directory synchronization and address mapping. X.400 addresses must be manually typed in for every GroupWise user, and custom work was required to extract their names and X.400 addresses and inject this into the main X.400 directory. Directory information cannot be extracted from the X.400 side and be injected into the GroupWise environment. All in all, GroupWise users find the connection sufficiently inconvenient that half of them opt to use a NET-TEL X.400 user agent instead when communicating with their X.400-based colleagues.

Enhancement Plans Over the next two years, the Ministry plans to: • Add X.500. The main driver for this will be to provide e-mail directory lookup. • Upgrade the entire system to full 1988 conformance. Specifically, put message stores which can be accessed by P7 everywhere. • Upgrade the system to support Body Part 15, so that file attachments have useful file attributes preserved during transmission. • Experiment with using the remote user agents over wireless. • Upgrade its SMTP gateway so it support MIME, and thus allow file attachments. • Develop messaging-based workflow applications. Today, the main application is just interpersonal messaging.

Authors' Observations & Suggestions

Addresses & Routing • The address convention, eg, C=NL; A=400NET; P=MINVENW; O=MINVENW; OU1=RWS; OU2=MDI; S=Wayers; I=ARJ is unnecessarily complex. The Ministry should dispense with the 0 and OU attributes. Having such a complex structure means that 1) external users who have to type in the addresses have to endure more frustration due to typing mistakes; and 2) when someone moves their department, mail won't get through. Routing information should not be included in the address. • The Ministry believes the maintenance of routing tables would be an oner- ous chore, and hence includes routing information in addresses. We don't see why this need be the case, especially given the simple hub-and-spoke topology that has been adopted. The routing tables need only be maintained at the hubs. Note, however, that in our view the ideal approach is to adopt directory-based routing, and allow office MTAs to address each other directly. See chapter 4, section 6. • Messages between an office connected to The Hague, and an office connected to Spijkenissen, must transit 4 hubs. Even assuming that a hub hierarchy should be adopted, only one hub need be transited: the first hub MTA that a message arrives at should route the message directly to the recipient's local MTA, instead of passing the message on to the other hub MTA first. This would reduce transmission time, and reduce the number of possible points of failure.

369 14 Case Studies

Directory Synchronization • The Ministry does directory synchronization every two weeks. Thus, a new employee might not have an entry in colleagues' address books for as long as two weeks after they had joined. In most organizations, users would want address books to be updated daily. • As noted earlier, due to the lack of synchronization tools provided with the GroupWise gateway, GroupWise users cannot browse their directory for X.400-based names and addresses. • The synchronization process adopted will not scale well for larger organizations. First, it requires manual intervention. Administrators must e-mail in the latest versions of their address books, plus they must replace their out-of- date directory file with the revised directory file they are sent. This is an unnecessary disruption for administrators, although not one that takes a lot of time. More importantly, it means the process has unnecessary points of failure, eg, if one of the administrators is suddenly taken ill, or if an administrator is simply too busy fire-fighting to send in their update. It would be much better to automate the synchronization process. Second, it is impractical for large systems to manually define every user's X.400 address, as is required for the GroupWise gateway.

User Agents • Most of the Ministry's user agents are of the 1988 variety. Problems arise when messages go through the GroupWise gateway, which only supports 1984 user agents. When mixing 1988 UAs with 1984 technology: beware. • No viewers are available with the NET-TEL user agents. The Ministry says this has not presented much of a problem: apparently WordPerfect documents are the only files sent through the system, and everyone can read them. In most organizations, even ones with a fairly homogeneous applications environment, viewers would be needed, since the type of many arriving files would be unclear.

Remote Support • The Ministry is at a very early stage of using a 1988 message store. It has an attached modem pool, and the message store is only used by remote users. As the 1988 environment develops, it will probably be more attractive to provide a central modem pool providing for general connectivity to the TCP/IP network. Users will dial in to this, and then connect to their home message store.

Scalability • The Ministry never seriously considered the option of putting a proprietary PC e-mail package everywhere, because it felt they don't scale well. We agree, but with a couple of caveats. First, the Ministry's current architecture will probably scale poorly, too: consider for example the hub-and-spoke architecture, the addresses containing routing, and the approach to directory synchronization. Second, proprietary PC e-mail systems can currently support some 3,000 to 5,000 mailboxes without too much difficulty, and their scalability is improv- ing all the time. They can probably do what the Ministry needs of them.

371

15 Product Reviews

15. Product Reviews

Two reviews will be sent to readers each month. Upcoming reviews include products by : Accordance Data Connection Enterprise Solutions Limited Lotus Microsoft NET-TEL NEXOR Novell GroupWare Tandem Worldtalk Zoomit

373

16 Glossary

17. Glossary

Access Control. The mechanism to ensure that only authorized users can get connected to a message store or MTA or only authorized MTAs can connect to another MTA. Most access control mechanisms involve password verification, although more sophisticated mechanisms based on public key crytography are starting to be used. See authentication. ADMD or Administrative Management Domain. An ADMD is an X.400 network operated by a service provider. ADMDs operated by various service providers are generally interconnected, creating a worldwide X.400 network. An organization that needs messaging connectivity to other organizations can get connected to an ADMD, obtaining immediate access to all clients of that ADMD as well as the clients of all ADMDs connected to that ADMD. See also PRMD. Alarm. An indicator that something is wrong with a system. For example, a system or communication link may be down, or a message received may cause an MTA to behave improperly. When such an abnormal condition occurs, a good messaging system should generate an alarm that will attract the attention of an operator or administrator so that the abnormal situation can be taken care of as soon as possible. API or Application Program Interface. A messaging API allows the programmer to send and receive messages and access the e-mail system directory, without the need to know the details of the underlying messaging system. This allows applications to become mail-enabled while shielding the programmer from the details of how the messaging system operates. Most APIs consist of a series of subroutine calls and are called programmatic APIs. A dwindling number of APIs, known as file- based APIs, require the programmer to process formatted files. Each formatted file represents a message sent to or received from the messaging system.

375 16 Glossary

APS or Asynchronous Protocol Specification. A specification that describes how to run OSI protocols over a dialup connection. APS significantly reduces the cost of connecting two MTAs, since it replaces dedicated X.25 connections. Authentication. Making sure that a remote entity, such as an MTA or UA, is indeed the intended one. Authentication is usually achieved using passwords. When a higher level of security is needed, more sophisticated mechanisms like public key cryptography are used. Autoregistration. When a gateway receives a message from a sender who is not in its directory, it may autoregister the sender's address. This allows the gateway to assign the sender an address of different type, allowing the recipient to reply back easily. For example, a PROFS X.400 gateway may autoregister and assign a PROFS address to an X.400 sender, allowing the PROFS user to send a message to the X.400 user using a PROFS address. Beta Test. The controlled use of a new service or product by selected users before it is rolled out to wide user populations. Beta tests ensure that problems and bugs that survive testing are taken care of before the service or product becomes available. Billing. The periodic presentation of charges by a service provider to a client. In the past the presentation typically consisted of a paper invoice, but now it often is a diskette, suitable for further processing by the client's internal chargeback system. It is also common to issue invoices in form of an electronic message or EDI message. Body Part. In the P2 content part of an X.400 message, a body part is information that needs to be kept together, separate from other information. For example, a file included in a message is a body part. A single X.400 message can contain multiple body parts. Broadcast. In X.500, when a DSA does not have the information requested and does not know which DSA holds the information, it may send queries to all DSAs it knows to see if any of them has the information. The method of transmitting the query to several DSAs is called broadcast or multicast. CCITT or The International Telegraph And Telephone Consultative Committee. Former name of ITU/TSS. See ITU/TSS. Chaining. In X.500, when a DSA does not have the requested information, it may relay the query to another DSA, which in turn may relay it to a third one, and so on. The reply goes in the opposite direction. The method of relaying requests from one DSA to another is called chaining.

Chargeback. The allocation of costs of a messaging system within an organization to individual users or projects. The basis for chargeback may rely on many methods. In older, mainframe systems, chargeback was based on how long the user was logged on. In newer, client server systems, chargeback is often indirect, perhaps a flat monthly fee. Ideally, it would be proportional to actual services used, eg, number of messages sent or number of directory lookups performed. Proportional charging, however, requires fairly complex billing systems, and is not always feasible. See billing. CMC or Common Messaging Calls. A standard programmatic API used to access messaging systems. It is supported by many major vendors. CMIP or Common Management Information Protocol. A network management protocol for OSI-based networks. It is the OSI counterpart of the SNMP protocol used in TCP/IP networks. Console. The computer terminal that is used to manage a network, typically using SNMP. Content. The actual information that the sender of a message wants to convey to a recipient. During the transmission of the message, the message is typically pre- ceded by a header that contains addressing and other information. Header and content make up the message. Delivery/Nondelivery Notification. Indicates that a message was delivered or not delivered, respectively. A delivery notification tells a sender that a message he or she sent earlier was received by the recipient. What received means is not clear. In most cases, the message has merely been put into the recipient's mailbox. Compare this with a receipt notification or RN, also called read receipt, which indicates that the recipient has seen the message. A nondelivery notification indicates that the message was not delivered to a particular recipient. Dialup. The capability to establish a communication link over a dialed normal voice telephone circuit. A protocol that uses dialup needs to describe how to establish and terminate the call in addition to how data is transmitted. Directory Propagation. In a single messaging environment containing multiple directories, directory propagation allows a user to address another user directly, regardless of which directory is the recipient's "home" directory. In directory propagation, directory entries are copied between directories, so that every directory has up-to-date information. Directory Synchronization. In environments consisting of several different types of messaging system, containing multiple directories and address types, directory synchronization allows a recipient to be addressed in a sender's native address

377 16 Glossary

mode, regardless of where sender and recipient are located. Directory synchronization typically translates users' addresses between the various formats involved. Eg, if a company uses cc:Mail and PROFS, directory synchronization would assign all cc:Mail users PROFS addresses. Thus, PROFS users can send messages to cc:Mail users using PROFS addresses. Similarly, cc:Mail users can send messages to PROFS users using cc:Mail addresses. Directory System. When capitalized as in Directory System, the term indicates an X.500-conformant directory system implementation. Distribution List or DL A list containing addresses. When a distribution list name is used as an address in a message, the message is sent to every member in the list. DDA or Domain-Defined Attribute. A DDA is an X.400 address attribute that allows non-X.400 addresses to be inserted into an X.400 address. A DDA consists of two parts, a type and a value. The type indicated what the address means. The value is the actual string. Eg, a typical type is FAX and the corresponding value could be a telephone number, indicating the DDA contains the telephone number of a fax machine. DSA or Directory System Agent. A computer system that provides directory functionality. It interfaces with its local directory database to look up and modify information, with other DSAs to gain access to information maintained by those DSAs, and with DUAs to receive their queries and provide the results. DUA or Directory User Agent. A computer program that allows a human being or a computer program to access the directory for lookups and updates. DX. A directory synchronization method originally supported by a number of vendors, with the expectation that all these vendors would implement the scheme. Retix was one of the few implementers of DX. See also SoftSwitch DS. E-Mail Backbone. You have an e-mail backbone when you connect different types of e-mail systems by converting everything into a common or canonical format. The most likely common formats are IBM's SNADS, X.400, and SMTP. Warning: the term backbone also has a completely different meaning, where it refers to cabling or a WAN link. For example, the main cable connecting LANs on different floors of a building is called a backbone. Or a high speed WAN link between two major locations might be called a backbone. EDI or Electronic Data Interchange. A method to accurately and concisely exchange commercial information, such as invoices and purchase orders, in e- mail messages. There are a number of industry specific EDI standards that can also be used within X.435-conformant messages.

File format API. An API that allows a programmer to inject messages into the messaging system by writing the message in a file in a special format, and then calling a program that then injects the file into the messaging system. To receive a message, the programmer invokes an application that retrieves a message from the messaging system and puts it into a file with the same format. The application has then to parse the file to use the information contained in it. Header. A header is the portion of the message that contains information indicating how to handle the message. Typical header fields are the recipient list, the sender's e-mail address, the priority, etc. Help Desk. The office where messaging users are helped when they encounter problems (eg, undelivered or lost messages) or need help (eg, how to send mail to a new correspondent). In large organizations, help desk telephone numbers and email addresses should be published to facilitate e-mail acceptance. Housekeeping. The activities that need to be performed periodically to keep a messaging system operational. Eg, messages that have been delivered need to be deleted from disk, otherwise the disk will fill up and prevent the processing of further messages. Other housekeeping tasks include the deletion of old logs, and the cleanup of databases to delete records no longer relevant. Ideally, such tasks should be automated, but some systems require a large amount of manual intervention. The tasks may take up a lot of processing capacity or disk input/output capacity. Therefore, they are often scheduled to be performed when the traffic load is light, during the early morning hours. Gateway. A software system that sits between two different messaging environments, eg, cc:Mail and X.400, and which converts messages between the formats used by the two messaging systems. Gateway Directory. The directory that is kept in a gateway and used to convert addresses between the different formats supported by the database. For example, a gateway between X.400 and cc:Mail would be used to convert cc:Mail addresses into X.400 addresses and vice versa. Interpersonal Message or IPM. An interpersonal message is a special type of X.400 message designed for human beings to send simple textual messages to each other, possibly accompanied by file attachments. An IPM message mimics the format of a business letter. Other types of message, with different formats, can also be transferred through an X.400 network, such as EDI messages. ISODE or ISO Development Environment. A software system developed in academic circles to experiment with ISO (including X.400 and X.500) implementations. The code is freely available and has been included in many major commercial products.

379 16 Glossary

ISODE Consortium. A company set up to maintain and publish controlled versions of the ISODE code. ITU/TSS or International Telecommunication Union/Telecommunication Stan- dardization Sector. An organization within ITU, itself an agency of the United Nations, that publishes recommendations such as the X.400 recommendations. It used to be called CCITT Log. A list of events kept by a system component. For example, an MTA may keep a log of messages it processed or a log of connections it had with other MTAs. Systems that generate alarms frequently keep logs of such alarms. Eg, logs can be processed by programs to determine how many messages and addresses an MTA processed, or how many errors it had during a given time period. Mail-Enabled Application. An application that can automatically process e-mail messages it receives, or generate e-mail messages to send information to users or other applications. For example, an application that can process mail messages containing queries and send back electronic documents is a mail-enabled application. Managed Application. A computer application, often managed using the SNMP protocol. Management Agent. A piece of software that runs along with a managed application or in a managed device. It connects the application or device with the management station. Management Station. The computer that controls managed devices or managed applications, typically using the SNMP protocol. Also called a console. Managed Device. A hardware device, eg, router or modem, often managed using SNMP. MAPI or Messaging APL An API developed by Microsoft. It is very powerful but complex. See also MAPI vO, MAPI vl, VIM. MAPI v0. Another name for Simple MAPI. MAPI v . Also known as Extended MAPI. This term refers to the full MAPI interface, as opposed to Simple MAPI. Message Body. The actual information in a message that needs to be transmitted. It's often an interpersonal message plus one or more file attachments, although it can be other types of information such as an EDI message or a structured form. Message Store. A component of an X.400 system that stores messages for a user, after they have been delivered by a message transfer system. Similarly, when a user

sends a message, the UA submits the message to the message store that, in turn, submits it to the message transfer system. The message store sits logically between an MTA and UA. MHS or Message Handling System. (1) MHS is another term used to indicate an X.400 system. (2) The NetWare MHS is a proprietary messaging environment that is not related to X.400. Message Transfer System or MTS. A network of MTAs, that is responsible for transferring messages between senders and recipients. MIB or Management Information Base. A term used in SNMP, MIB refers to the attributes associated with a particular type of managed device. Eg, a modem has a different set of attributes than a router. SNMP describes how to manage the attributes, but not the actual attributes themselves. Thus, it is easy to extend SNMP support for new devices by defining MIBs for them. MIME or Multi-Purpose Internet Mail Extensions. An extension to SMTP that standardizes the transfer of binary, ie, non-ASCII, information using SMTP. It is specified by RFC 1341. MTA or Message Transfer Agent. An X.400 message switch, ie, a software system that accepts messages from UAs, and delivers them to UAs or relays it to other MTAs for delivery. Multicast. See Broadcast. P1 Content. The part of an X.400 message that is sent from the sender's UA to the recipient's UA. The 131 content contains the P2 header and the P2 content. PI Header. The part of an X.400 message that tells the MTA how to handle the message. The P1 header contains information such as the recipient list, the sender's X.400 address, etc. See also Header, P2 Header. P2 Content. The part of an X.400 message that the originator intended to send the recipient. The rest of the message is administrative overhead, telling MTAs or UAs how to handle the message. The P2 content contains one or more body parts. P2 Header. The part of the X.400 message that tells the recipient's UA how to handle the message. The P2 header contains information such as the sender's and recipient's nicknames and whether the message is private or not. Payload. The information that a sender of a message wants to convey to the recipient. The actual message sent consists of payload plus header information. The header is added to indicate the recipient's address and how the message is to be handled by the messaging system, eg, its priority.

381 16 Glossary

Pilot. The trial period for a new service to verify its feasibility. When pilots are successful, they are often rolled out to wider user populations. POP or Point-of-Presence. A location where a service provider's network can be accessed. The POP is important because the client has typically to pay communications charges (dialup or dedicated) from the client's computer site to the POP. Therefore many service providers have POPs in many cities to gain a competitive advantage. They use internal networks to connect their POP to their actual computer site. Warning: In TCP/IP environments, POP stands for Post Office Protocol, which is a completely different concept. PRMD or Private Management Domain. A private X.400 network that is not set up with the intention of providing X.400 services to other organizations. See also ADMD. Probe. A special X.400 message sent solely for the purpose of determining whether a real message to a particular user agent could have been delivered. When an MTA receives a probe that it should deliver, it does not perform the delivery, but generates a delivery notification as if the probe had been delivered. This indicates to the sender of the probe that a message to that recipient could have been delivered. Probes are more commonly used to determine whether all the MTAs and gateways along the path of the probe are operational or not. Probe Monitor. A software system that keeps track of network connectivity status by sending probes to different, pre-determined destinations. If the monitor does not receive a delivery notification for a probe within a certain time, it knows there is something wrong with the messaging system and generates an alarm. Programmatic API. An API where the programmer interface consists of subroutine calls. Protocol. A packet of information that is formatted in a standard way, and which is transferred between networked computers. Proxy Agent. An SNMP agent that allows an SNMP-compliant management station to control an non-SNMP capable device. The proxy agent performs conversions between the device's internal, non-SNMP controls and the management station's SNMP controls. Receipt/Nonreceipt Notification. Indicates that the recipient read the message or did not read the message. Frequently called read receipt in non-X.400 messaging systems.

Recommendation. A document issued by the ITU/TSS, formerly known as the CC/1 that specifies a particular communication function, eg, the operation of a messaging system. ITU/TSS does not have the authority to issue standards, therefore the specification documents it issues are called recommendations. Nevertheless, many recommendations are followed as if they were standards. Examples are X.25 and X.400. Relay. (1) Action where an MTA transmits a message to another MTA. (2) Action where a DSA transmits information to another DSA. Referral. In an X.500 system, when a DSA does not have the information requested but knows which DSA holds the information, it may reply by providing information about the third DSA. This is called referral. The party originating the query can then directly query that third DSA. RFC or Request for Comment. A technical document that describes some aspect of the Internet. Many RFCs are fairly technical specs that define how the various protocols making up the Internet work. For example, RFC 822 describes the formats of SMTP messages. See the bibliography for a listing of important messaging RFCs as well as how to obtain them. Routing. The action taken by an MTA to determine what to do with the addresses in a message. For each address, the result may be that (a) the message is delivered to a UA served by the MTA, (b) the message is relayed to another MTA for delivery, or (c) the address is unrecognized, in which case a nondelivery notification is generated. Service Provider. An company or organization that provides messaging and communications services for a fee to its clients. Such services can provide messaging connectivity to third parties, using X.400 or other protocols. An X.400 network operated by a service provider is called an ADMD. Simple MAPI. A subset of MAPI. This API provides very basic functionality to send and receive simple messages. See also MAPI vO. SMTP or Simple Message Transfer Protocol. The standard that defines how to exchange messages in the TCP/IP world. It is based on RFCs 821 and 822. SMTP is only used to transfer ASCII messages, unless accompanied by the MIME extension. SNMP or Simple Network Management Protocol. A protocol to monitor and control the operation of an application or a device. It allows an operator to see the device's status, eg, up or down, and perform device-specific actions, such as start or stop the device. The operator uses a management station to perform the actions. The management station communicates with the management agent run-

383 16 Glossary

ning in the device or along with the application being controlled. SNMP was developed in the TCP/IP world. See also CMIP. SoftSwitch DS. A directory synchronization scheme developed and published by SoftSwitch. It allows vendors to synchronize their directories with Lotus/SoftSwitch Central and EMX/LMS systems. See also DX. Tunneling. A useful technique for transferring non-X.400 messages through an X.400 network. The message, with all its special non-X.400 features, is crammed into a single binary file. It's then sent to its destination through the X.400 network. As it passes through intervening gateways, the file isn't changed. When it arrives, matching software is required to dissect the arriving file and recreate the message, with all its non-X.400 features. In this way, things like underlining, bolding, and figures arrive intact. UA or User Agent. A computer program that allows a human being or a computer program to send and receive messages. Eg, when you send a message using cc:Mail, the program you run on your computer is a user agent. VIM. A messaging API originally supported by a number of vendors and intended to counter Microsoft's domination with MAPI. However, VIM has had little success. WAN. A network that spans a large geographical area. Opposite of local area network or LAN. X.25. A transport mechanism that allows the establishment of virtual links between geographically separate computer systems. X.25 Service Provider. A service provider that allows clients to hook up to its X.25 network, with the intention of allowing connectivity to other systems connected to its X.25 network and to systems connected to the X.25 networks of interconnected X.25 service providers. X.400. X.400 is a set of protocols that define how to handle messages. The name derives from the first in a series of related recommendations that include X.400, X.402, X.403, X.407, X.408, X.411, X.413, X.419, X.420, X.435, X.445. X400(84). This term is used when specifically referring to the X.400 series recommendations as they were adopted in 1984. X.400(88). This term is used when specifically referring to the X.400 series recommendations as they were adopted in 1988. X.400 Service Provider. A service provider that operates an ADMD and that allows organizations operating PRMDs to connect to its ADMD. This provides connectivity to the X.400 world at large.

X.400 User Agent or £400 UA. A user agent that has been designed to connect directly to an X.400 e-mail system, without any interim gateways. X.435. The recommendation that specifies how to send EDI interchanges in X.400 messages. X.500. X.500 is a set of protocols that define how to operate and access a directory system. The name derives from the first in a series of related recommendations that include X.500, X.501, X.509, X.500, X.518, X.519, X.520, X.521.

385

17 Bibliography

17. Bibliography

First we give references to various X.400 and X.500 standards and recommendations, as well as related internet RFCs. Then we give chapter references, followed by a description of how to retrieve documents electronically.

17.1 X.400 References

X.400 Recommendations ame grip

X.400 Message Handling System And Service Overview X.402 Overall Architecture X.403 Confirmance Testing For X.400 Based Systems X.407 Abstract Service Definition Conventions X.408 Encoded Information-Type Conversion Rules X.411 Message Transfer System: Abstract Service Definit ion X.413 Message Store: Abstract Service Definition X.419 Protocol Specifications X.420 Interpersonal Messaging System Definition X.421 COMFAX Use Of MHS X.435 Electronic Data Interchange Messaging System X.440 Voice Messaging System X.480 Conformance Testing X.481 P2 Protocol: Protocol Implementation Confomance Statement (PIGS) Proforma X.482 P1 Protocol: Protocol Implementation Confomance Statement (PICS) Proforma X.483 P3 Protocol: Protocol Implementation Confomance Statement (PICS) Proforma X.484 P7 Protocol: Protocol Implementation Confomance Statement (PICS) Proforma X.485 Voice Messaging System Protocol Implementation Confomance. Statement (PICS) Proforma X.208 Specification Of ASN.1 X.209 Basic Encoding Rules For ASN.1 X.214 Transport Service Definition

387 17 Bibliography

X.215 Session Service Definition X.216 Presentation Service Definition X.217 Association Control Service Definition X.218 Reliable Transfer Service Definition X.219 Remote Operations Service Definition X.224 Transport Protocol Specification X.225 Connection Oriented Session Protocol Specification X.226 Connection Oriented Presentation Protocol Specification X.227 Connection Oriented Association Control Protocol Definition X.228 Reliable Transfer Protocol Definition X.229 Remote Operations: Protocol Definition F.400 Message Handling System And Service Overview (Note: This recommendation is identical to X.400) F.401 Naming And Addressing For Public Message Handling Services F.410 The Public Message Transfer Service F.415 Intercommunication With Public Physical Delivery Services F.420 The Public Interpersonal Messaging Service F.421 Intercommunication Between The IPM Service And The Telex Service F.422 Intercommunication Between The IPM Service And The Teletex Service F.423 Intercommunication Between The IPM Service And The Telefax Service F.435 Electronic Data Interchange Messaging Service F.440 The Voice Messaging Service

X.400 RFCs The Internet community has developed a number of interesting X.400 proposals, listed here.

RFC#. Dobai

1685 H. Alvestrand, "Writing X.400 0/R Names", 08/11/1994 1649 R. Hagens, A. Hansen, "Operational Requirements for X.400 Management Domains in the GO-MHS Community", 07/18/1994 1648 C. Cargille, "Postmaster Convention for X.400 Operations", 07/18/1994 1616 E. Huizer, J. Romaguera, RARE WG-MSG Task Force 88, "X.400(1988) for the Aca demic and Research Community in Europe", 05/19/1994 1615 J. Houttuin, J. Craigie, "Migrating from X.400(84) to X.400(88)", 05/19/1994 1566 Mail Monitoring MIB. This is one of the three MADMAN MIBs. It defines a set of counters which indicate the status of an MTA. 1565 Network Services Monitoring MIB. This is one of the three MADMAN MIBs. It defines a very general set of counters for a network application, such as an MTA, directory, or message store. 1514 Host Resources MIB, This MIB contains basic configuration information for a computer. It's useful for managing a computer that runs applications like an MTA or message store. 1506 J. Houttuin, "A tutorial on gatewaying between X.400 and Internet mail", 09/23/1993 1502 H. Alvestrand, "X.400 Use of Extended Character Sets", 08/26/1993 1496 H. Alvestrand, J. Romaguera, K. Jordan, "Rules for downgrading messages from X.400/ 88 to X.400/84 when MIME content-types are present in the messages", 08/26/1993 1495 H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson, "Mapping between X.400 and RFC-822 Message Bodies", 08/26/1993 1494 H. Alvestrand, S. Thompson, "Equivalences between 1988 X.400 and RFC-822 Mes sage Bodies", 08/26/1993 1465 D. Eppenberger, "Routing coordination for X.400 MHS services within a multi protocol / multi network environment Table Format V3 for static routing", 05/26/1993 1405 C. Allocchio, "Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)", 01/20/ 1993

1330 ESCC X.500/X.400 Task Force, "Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESnet Community", 05/22/1992 1328 S. Hardcastle-Kille, "X.400 1988 to 1984 downgrading", 05/18/1992 (Updated by RFC1496) 1327 S. Hardcastle-Kille, "Mapping between X.400 (1988) / ISO 10021 and RFC 822", 05/18/ 1992 (Updated by RFC1495, updates RFC0822, obsoletes RFC1148) 1148 B. Kantor, S. Kille, P. Lapsley, "Mapping between X.400 (1988) /ISO 10021 and RFC 822", 03/01/1990 (Obsoleted by RFC1327, obsoletes RFC0987 1138 S. Kille, "Mapping between X.400 (1988) / ISO 10021 and RFC 822", 12/01/1989 (Up dates RFC1026) 1137 S. Kille, "Mapping between full RFC 822 and RFC 822 with restricted encoding", 12/01/ 1989 (Updates RFC0976) 1026 S. Kille, "Addendum to RFC 987: Mapping between X.400 and RFC-822", 09/01/1987 (Updated by RFC1138, updates RFC0987) 987 S. Kille, "Mapping between X.400 and RFC 822", 06/01/1986 (Obsoleted by RFC1148, updated by RFC1026, updates RFC0822)

17.2 X.500 References

X.500 Recommendations

X.500 The Directory: Overview Of Concepts, Models And Services X.501 The Directory: Models X.509 The Directory: Authentication Framework X.511 The Directory: Abstract Service Definition X.518 The Directory: Procedures For Distributed Operation X.519 The Directory: Protocol Specifications X.520 The Directory: Selected Attribute Types X.521 The Directory: Selected Object Classes X.525 The Directory: Replications X.581 Directory Access Protocol: Protocol Implementation Conformance Statement (PICS) X.582 Directory System Protocol: Protocol Implementation Conformance Statement (PICS) F.500 International Public Directory Services

X.500 RFCs The Internet community has developed a number of interesting X.500 proposals, listed here.

1684 R Jurg, "Introduction to White Pages services based on X.500", 08/11/1994 1632 A. Getchell, S. Sataluri, "A Revised Catalog of Available X.500 Implementations",05/ 20/1994 (Obsoletes RFC1292) 1617 P. Barker, S. Kille, T. Lenggenhager, "Naming and Structuring Guidelines for X.500 Directory Pilots", 05/20/1994 (Obsoletes RFC1384)

389 17 Bibliography

1609 G. Mansfield, T. Johannsen, M. Knopper, "Charting Networks in the X.500 Directory", 03/25/1994 1608 T. Johannsen, G. Mansfield, M. Kosters, S. Sataluri, "Representing IP Information in the X.500 Directory", 03/25/1994 1567 G. Mansfield, S. Kille, "X.500 Directory Monitoring MIB", 01/11/1994 1562 G. Michaelson, M. Prior, "Naming Guidelines for the AARNet X.500 Directory Service", 12/29/1993 1491 C. Weider, R. Wright, "A Survey of Advanced Usages of X.500", 07/261993 1488 T. Howes, S. Hardcastle-Kille, W. Yeong, C. Robbins, "The X.500 String Representation of Standard Attribute Syntaxes", 07/29/1993 1487 W. Yeong, T. Howes, S. Hardcastle-IGIle, "X.500 Lightweight Directory Access Protocol", 07/29/1993 1430 S. Kills, E. Huizer, V. Cerf, R. Hobby, S. Kent, "A Strategic Plan for Deploying an Internet X.500 Directory Service", 02/26/1993 1330 ESCC X.500/X.400 Task Force, "Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESnet Community", 05/22/1992 1309 S. Heker, J. Reynolds, C. Weider, "Technical Overview of Directory Services Using the X.500 Protocol", 03/12/1992 1308 J. Reynolds, C. Weider, "Executive Introduction to Directory Services Using the X.500 Protocol", 03/12/1992 1292 R. Lang, R. Wright, "A Catalog of Available X.500 Implementations", 01/03/1992 (Obsoleted by RFC1632) 1279 S. Kille, "X.500 and Domains", 11/27/1991 1278 S. Hardcasde-Kille, String Encoding of Presentation Address", 11/27/1991 1276 S. Kille, "Replication and Distributed Operations extensions to provide an Internet Directory using X.500", 11/27/1991 1275 S. Kille, "Replication Requirements to provide an Internet Directory using X.500", 11/27/1991 1274 P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", 11/27/1991

17.3 Chapter References

X.400 Technology Background, Part I Ferris E-Mail Analyzer, September 1994. Explanation of the key factors to ensure scalability of a distributed messaging system. Introduction to X.400. Cemil Betanov. Presents an in-depth and complete discussion of how X.400 works. Published by Artech House, 1993. +1 617 769 9750 or +1 800 225 9977.

X.400 Technology Background, Part II Asynchronous Protocol Specification. The specification for APS. Can be obtained from Erik Skovgaard at the PSC Institute, +1 613 736 6111. Also, see below for information on how to get it over the Internet. Ferris E-Mail Analyzer, July 1994. An explanation of public key cryptography, and the main implementation issues.

Ferris E-Mail Analyzer. March 1993. An explanation of TCP/IP, how to connect to the Internet, and what the main implementation issues are.

Directory Services Mail *Hub Administrator's Guide. Control Data Systems. Very helpful to understand how X.500 works, including directory-based routing. ISODE Consortium Code release 2. Volume 4, Administrator's Guide, Messaging Handling Services. ISODE Consortium. Appendix describes directory-based routing. Implementing X.400 And X500: The PP And QUIPU Systems. Steve Kille. Contains the manuals for PP (an X.400 MHS implementation) and QUIPU (an X.500 implementation). Published by Artech House, 1991. +1 617 769 9750 or (800) 225 9977. X.500 Architecture Issues. Useful white paper by the EMA LAN Messaging Com- mittee describing X.500 concepts.EMA, +1 703 524 5550. X.400: S=info; O=ema; A=mci; C=us. Internet: [email protected].

Directory Synchronization Ferris E-Mail Analyzer, March 94. Discusses how PC e-mail directory propagation works, and assesses the strengths and weaknesses of the tools offered by cc:Mail, MS Mail, and WordPerfect Office. Ferris E-Mail Analyzer, June 1994. Discusses cross-platform directory synchronization issues, rules vs. table based addressing. Product reviews.

File Transfer And Conversion

Ferris E-Mail Analyzer, November 1993. Discusses file transfer and conversion issues. External Connectivity Message Handling Systems Interoperability Tests. Published by the National Institute of Standards and Technology, US Department of Commerce. Available from the National Technical Information Service, 5285 Port Royal Road, Springfield, VA 22161, USA. +1 800 553 6847, fax +1 703 321 8547; order number PB91- 112789. Requirements and Generally Accepted Practices for Operating a Production PRMD. Useful short booklet by Chevron's Marion Weiler describing a series of policy issues. EMA, +1 703 524 5550. X.400: S=info; O=ema; A=mci; C=us. Internet: [email protected].

391 17 Bibliography

Domain Name Registration. Useful white paper by Rapport Communication's Gary Rowe describing how to register your PRMD name. EMA, +1 703 524 5550. X.400: S=info; O=ema; A=mci; C=us. Internet: [email protected]. X.400 Reference Guide. Useful white paper by EMA Interoperability Committee describing how to address users of various X.400 service providers. EMA, +1 703 524 5550. X.400: S=info; O=ema; A=mci; C=us. Internet: [email protected]. Ferris E-Mail Analyzer, December 1993. Discusses how to stress test X.400 gateways. Ferris E-Mail Analyzer, December 1992. Discusses how to connect outside with X.400.

Messaging Support Tasks Ferris E-Mail Analyzer, December 1994. Discusses messaging support tasks. Ferris E-Mail Analyzer, January 1995. Discusses how to organize support.

Messaging Management Ferris E-Mail Analyzer, November 1994. Discusses evolving standards in e-mail management. Ferris E-Mail Analyzer, January & February 1994. These issues discuss how to improve performance in an e-mail network. Email Management Requirements, Working Draft. Joint EFIP WG6.5 and 6.6 Elec- tronic Mail Management Working Group. Editors Emily McCoy, Ray Freiwirth. RFC 1514. Host Resources MIB. This MIB contains basic configuration information for a computer. It's useful for managing a computer that runs applications like an MTA or message store. RFC 1565. Network Services Monitoring MIB. This is one of the three MADMAN MIBs. It defines a very general set of counters for a network application, such as an MTA, directory, or message store. RFC 1566: Mail Monitoring MIB. This is one of the three MADMAN MIBs. It defines a set of counters which indicate the status of an MTA. RFC 1567:X.500 Directory Monitoring MIB. This is one of the three MADMAN MIBs. It defines a set of counters which indicate the status of an X.500 DSA. Messenger 400 (1988) Management Control Center Administration Guide. Infonet Software Solutions. 604 436 2922

Messaging Management User Requirements Document. Electronic Messaging As- sociation, Messaging Management Committee.

API Access Lotus VIM Developer's Toolkit for cc:Mail and Lotus Notes Programmers Guide. Describes the VIM interface to access cc:Mail and Lotus Notes. Published by Lotus. cc:Mail Import/Export User's Manual. Describes the older, file based API called import/Export used by cc:Mail. Published by Lotus. Microsoft Mail Software Development Kit File Format APIfor Gateways and Appli- cations. Describes how to interface with Microsoft Mail using the older file format API (FFAPI). Published by Microsoft. Client Developer's Guide, MAPI Software Development Kit. Published by Microsoft. Technical Reference, MS Mail for PC Networks. Published by Microsoft. SMF v71 Programmer's Reference. Describes the file formats used when interfacing with Novell's NetWare MHS. Published by Novell. Novell part number 100001213-001. Ferris E-Mail Analyzer, April f May 1994. An analysis of MAPI, VIM, X.API's CMC and X.400 APIs. OSI-Abstract-Data Manipulation API (XOM). Specification for the Object Man- agement API. X/Open (+1 415 323 7992 and +44 734 508 311). Message Store API (XMS). Specification of the Message Store API. Published by X/Open, +1 415 323 7992 and +44 734 508 311. API to Directory Services (XDS). Specification of the Directory Services API. Published by X/Open, +1 415 323 7992 and +44 734 508 311. Message Transfer API (XMT). Specification of the Message Transfer API. Pub- lished by X/Open, +1 415 323 7992 and +44 734 508 311. Message Access API (XMA). Specification of the Message Access API. Published by X/Open, +1 415 323 7992 and +44 734 508 311.

393 17 Bibliography

17.4 Electronic Retrieval We now present a summary of how to retrieve documents over the Internet.

X.400/X.500 Recommendations You can receive CCITT recommendations by e-mail, Gopher or, in the future, FTP. We recommend using Gopher, if you have a choice. The setup of the directory structure is intuitive and excellent.

FTP As of Mid-April 1995, the ITU is putting together an FTP server. Little information is available, although more may be on offer at a later date. The address of the server is info.itu.ch. To log in, use the user name anonymous, and your e-mail address as password. The root directory contains a README file which gives further information.

E-Mail Send a message to one of the following two addresses: X.400: C=ch; A=arcom; P=itu; S=teledoc Internet: [email protected] Send two messages. The first message should contain a subject field consisting solely of the word HELP. The text of the message is disregarded. This will cause a message with a lot of useful information to be returned, including how to get the actual recommendations. Second, send a message with only the word LIST. This will return a list of available documents.

Gopher Access the Gopher server at address info.itu.ch. Use port 70. This will connect you to the Gopher server operated by the International Telecommunications Union. There is a lot of other information in addition to the text of the recommendations.

Asynchronous Protocol Specification You can get the relevant APS documents by accessing a system operated by Erik Skovgaard of the PSC Institute. He is the technical editor of the APS Specification. His e-mail address is [email protected]. The PSC Institute is at +1 613 736 6111.

FTP To get the documents, access the FTP site at wimsey.com. Log on with the username anonymous and as password use your own e-mail address. Change to the /pub/ APS directory. Retrieve the files: • aps2e.doc (contains the APS spec). • igl.doc (contains the implementer's guide). • apsitux.doc. This is the APS spec in CCITT submission format. x is a letter indicating the current version. All documents are in Microsoft Word 2.0 format.

RFCs You can obtain RFCs over the Internet by e-mail, FTP, and Gopher. We prefer using FTP.

FTP Use anonymous FTP to host ds.internic.net. Use your e-mail address as password. All RFCs and a current index listing are in subdirectory /internet-drafts.

E-Mail Send a message to [email protected]. Leave the subject field empty or insert a dash. Then have the following lines in the text portion of your message: path your-Internet-address (line 1) limit 25k (line 2) document-by-name rfc1381 (line 3) exit (line 4) Each line is structured as follows: • Line 1: Put your own e-mail address following the word path. • Line 2: If your e-mail system has a maximum message limit, then use this line, replacing 2 5k with your system's maximum message size. The RFC will be sent to you in several messages, and you can then paste the messages together to recreate the original RFC. This line is optional if your system does not have a maximum message size. • Line 3: Replace the name of the RFC you require instead of RFC13 81. • Line 4: This indicates the end of your message.

395 17 Bibliography

Gopher Access the Gopher server at address internic.net. Use port 70.

NIST NIST is the National Institute of Standards and Technology. Among various activities, it sponsors workshops that specify how X.400 and X.500 systems operating in the US should behave. These technical workshops are called 0/Ws, or OSI Implementors' Workshops. NIST's FTP server contains many useful documents, including pointers to other sources. Directories of interest include the following: • pub/oiw/ agreements, which contains OSI Implementors' Agreements • pub/osi/dssig, which contains directory implementation related documents, including some XAPIA documents in the xapia subdirectory The address of the FTP server operated by NIST is nemo.ncsl.nistgov. To log in, use ID anonymous and your e-mail address as password.

18. Vendor Yellow Pages

Accordance Corporation Apple Computer Scott Benson Monica Pal VP Sales 10500 N. De Anza 20 Maguire Road Blvd. Cupertino, CA Lexington, MA 02173 95014 Tel: +1 408 974 Tel: +1 617 674 0100 x 234 6796 Fax: +1 408 974 Fax: +1 617 674 1080 9078 [email protected] [email protected] AT&T Advantis Tatiana Kobischcha Ray N.Jones Director of Marketing Sr. Mktg Support Rep 400 Interpace Pkwy 3405 W. Dr. M. L. King Jr. Blvd, L109 Parsippany, NJ 07054 Tampa, FL 33607 Tel: +1 201 331 4280 Tel: +1 813 864 9388 Fax: +1 201 331 4517 Fax: +1 813 878 3674 ATTMail!TKobishcha

Alisa Systems Automated Business Tony Sidiropoulos Solutions Steve Manager, Marketing Communications Schmiedeskamp President 221 East Walnut, Suite 175 2103 Burlington #200 Pasadena, CA 91101 Columbia, MO 65202 Tel: +1 818 792 9474 Tel: +1 314 474 1089 Fax: +1 818 792 4068 Fax: +1 314 474 3898 [email protected] [email protected]

Amadeus Systems BT Business Communications David Edgar Jock Shearer Director of Software Development VP International Marketing 8470 Tyco Road Post Point 216, Holborn Center Vienna, VA 22182 120 Holborn Tel: +1 703 448 8666 London, EC1N 2TE Fax: +1 703 893 1911 United Kingdom [email protected] Tel: +44 171 492 3334 Fax: +44 171 492 3341

397 18 Vendor Yellow Pages

Banyan Systems CompLink Jeff Bernard Neil Luden Industry Consultants Manager President 120 Flanders Road 175 Community Drive Westboro, MA 01581 Great Neck, NY 11021 Tel: +1 508 836 1848 Tel: +1 516 829 1883 Fax: +1 508 836 2880 Fax: +1 516 829 5001 [email protected] Compuserve Baranof Software Mike Finney Peter Zimmer Product Mgr, NetWare MHS Technical Marketing Dir Service 5000 Arlington Center 85 School Street Blvd Columbus, OH 43220 Tel: Watertown, MA 02172 +1 614 538 4113 Fax: +1 614 Tel: +1 617 926 0832, Ext 103 457 0078 Fax: +1 617 926 6636 [email protected] zimmer baranof. corn Computer Mail Boldon James Services Mitch Green Susan Hornung Director, Sales & Marketing Messaging Product Marketing Manager 20300 Civic Center Drive Brundrett House #300 Southfield, MI 48076 Sandbach Road South, Alsager Tel: +1 313 352 6700 Fax: +1 Stoke-On-Trent, Staffs S77 2L7 313 352 8387 United Kingdom [email protected] Tel: +44 270 883 880 Fax: +44 270 883 631 Data Connection [email protected] Tony Downes C=gb; A=tmailuk; P=bj; O=boldon james PR Director limited; S=homung; G=susan 100 Church St Enfield, Middx Boston Software EN2 6BQ Works Ross S.Gale United Kingdom Tel: President +44 81 366 1177 Fax: 177 Milk Street +44 81 363 1468 Boston, MA 02109 Tel: [email protected] +1 617 482 9898 Fax: Also see display ad. +1 617 542 7956 [email protected] Digital Equipment Jeffrey Masors CE Software Product Marketing Mgr, Messaging Jessica Dunker 110 Spitbrook Rd., MS:ZKO2-2/M21 Marcom Manager Nashua, NH 03062 1801 Industrial Circle, Box 65580 Tel: +1 603 881 0801 West Des Moines, IA 50265 Fax: +1 603 881 2550 Tel: +1 515 221 3020 [email protected] Fax: +1 515 221 2694 jessica_dunker%[email protected]

CONNECTION

Messaging And Directory Services

Data Connection Limited (DCL) specialises in the provision of scaleable, high performance, messaging (X.400) and directory services (X.500) to major OEMs including both Lotus and Microsoft, and large corporate users such as Citicorp.

For further information call John Cooper:

Phone: +44 181 366 1177 Fax: +44 181 363 1468 Email: [email protected] c=gb;a=tmailuk;p=dcnets=cooper,g-john

399 18 Vendor Yellow Pages

Eicon Technology GE Information Services Tom Sweeney Gary Cannon Director of Marketing Senior Consultant 2196 32nd Avenue (Lachine) 20 Waterview Blvd, Suite 302 Montreal, PQ HST 3117 Parsippany, NJ 07054 Canada Tel: +1 201 299 2042 Tel: +1 514 631 2592 Fax: +1 201 299 2054 Fax: +1 514 631 3092 [email protected]

Electronic Messaging H & W Computers Association Mariah Crutchfield Susan McDonough Membership Manager 1655 N Marketing Manager 3166 Fort Myer Drive #850 Elder St., POB 15190 Arlington, VA 22209 Tel: +1 Boise, ID 83715-0790 703 524 5550 x232 Tel: +1 208 377 0336 Fax: +1 703 524 5558 [email protected] Hewlett Packard Andrew Ransom Enterprise Solutions Product Manager (OpenMail) Brenda Barnetson 199111 Pruneridge Avenue 9623 Odessa Avenue Cupertino, CA 95014 North Hills, CA 91343 Tel: +1 408 447 6214 Tel: +1 818 892 5192 Fax: +1 408 447 0264 Fax: +1 818 892 2119 [email protected] C=us; A=attmail; O=hp; P=hp; Firefox OU1=hp-cupertino; G=andrew; S=ransom Peter Simkin VP Mktg & Product Strat Hitachi Computers The Courtyard Alan Napier Warwick Road Business Development Manager Solihull, West Midlands, B91 3DA 3101 Tasman Drive United Kingdom Santa Clara, CA 95054 Tel: +44 121 609 6090 Tel: +1 408 986 9770 x408 Fax: +44 121 609 6060 Fax: +1 408 980 9616 [email protected] [email protected]

Fischer International IBM Mary Missal Peter Crotty Vice President, Sales Sr Prgr, OSI Dev Labs, Mktg 4073 Merchantile Avenue Mail Drop E55/B501 Naples, FL 33942 Raleigh, NC 27709 Tel: +1 813 643 1500 x240 Tel: +1 919 254 5074 Fax: +1 813 643 3772 Fax: +1 919 254 6430

ICL ISOCOR Chris Taper David J. Knight Senior Consultant VP Marketing Forest Road 3420 Ocean Park Blvd. Feltham Santa Monica, CA 90405-3306 Middlesex, TW13 7EJ Tel: +1 310 581 8100 United Kingdom Fax: +1 310 581 8111 Tel: +44 181 890 1414 x2523 C=us; A=telemail; P=isocor; S=knight Fax: +44 181 893 2672 [email protected] ISODE Consortium X.400: I=cw; S=taper; 0=icl; OU1=STE0411; Steve Kille P=icl; A=gold 400; C=gb President & CEO The Dome ICL Personal Systems The Square Kimmo Keskinen Richmond, TW9 1DT Marketing Manager, Messaging United Kingdom PO Box 780 Tel: +44 81 332 9091 Helskinki, FIN-00101 Fax: +44 81 332 9019 Finland [email protected] Tel: +358 05696984 kimmo.keskinenft.n1401.iclicielisa.fi Linkage Paul Saunders Infonet General Manager Alex Rassey Heritage Pl., 155 Queen St. # 1100 Senior Product Marketing Manager Ottawa, ON KIP 6L1 2100 East Grand Avenue Canada MS B251 Tel: +1 613 594 9244 El Segundo, CA 90245 Fax: +1 613 233 9625 Tel: +1 310 335 2600 [email protected] Marben Steve Johnson Infonet Software Solutions VP, Marketing & Sales Pauline Moller 3 1/2 N. Santa Cruz Ave. Suite B Director of Development Los Gatos, CA 95030 4400 Dominion St., Ste. 210 Tel: +1 408 399 8888 Burnaby, BC V5G 4G3 Fax: +I 408 399 8890 Canada [email protected] Tel: +1 604 436 2922 Fax: +1 604 436 3192 Marben Jean-Pierre Ansart Innosoft International 11, Rue Curie Dean Hidalgo 92150 Suresnes Marketing Manager France 1050 E. Garvey Ave S. Tel: +33 1 45 06 32 31 West Covina, CA 91793 Fax: +33 1 47 72 55 00 Tel: +1 818 919 3600 [email protected] .fr Fax: +1 818 919 3614 [email protected]

401 18 Vendor Yellow Pages

Mastersoft John Moorjani Karl Forster Director, Product Marketing VP Development 4 Place Farm 8737 East Via De Comercio Wheathampstead, Herts AL4 8SB Scottsdale, AZ 85258 United Kingdom Tel: +1 602 948 4888 x113 Tel: +44 58 283 4222 Fax: +1 602 948 8261 Fax: +44 58 283 4283 [email protected] maXware / Norwegian Telecom Frode Hemes NEXOR Sr. Systems Architect M.Sc. Nick Laszlo Postboks 93 Marketing Office: Drammensveien 175 Manager POB 132 Skoyen, Oslo N-0212 Nottingham, NG7 2UU Norway United Kingdom Tel: +47 2 48 80 69 Tel: +44 602 520 506 Fax: +47 2 73 36 30 Fax: +44 602 520 519 [email protected] Mercury Lesley A. Hay Novell / WordPerfect Product Spec. - Text Msg Brian K. Chapman 1 Brentside Executive Office, PR Specialist, WP Office Profile West, Great West Road 1555 N. Technology Brentford, Middlesex TW8 9DS Way MS: K-1342 United Kingdom Orem, UT 84057-2399 Tel: Tel: +1 44 81 914 3186 +1 801 228 5126 Fax: +1 801 Fax: +1 44 81 914 6682 228 5077 X.400: C=gb; A=cwmail; P=mercury; [email protected] O=messaging; G=lesley; S=hay Also see display ad.

Microsoft ON Technology / Da Vinci Shane Kim Debbie Bird Product Manager, E-Mail Industry Relations One Microsoft Way Manager 507 Airport Blvd. Redmond, WA 98052- Morrisville, NC 27560 6399 Tel: +1 206 936 6835 Tel: +1 919 319 7032 Fax: +1 206 883 7329 Fax: +1 919 319 7088

NCR/AT&T Premenos Peggy Gardner Elizabeth Hudson Messaging & Directory Products Director of Marketing 9900 Old Grove Road 1000 Burnett Ave #200 Rancho Bernardo, CA 92131 Tel: Concord, CA 94520 +1 619 457 1800/485 1220 Fax: +1 Tel: +1 510 602 2036 x2026 619 693 5705 Fax: +1 510 602 2024 [email protected] NET-TEL

(Bagels and donuts not required.)

If you've ever tried to arrange a meeting, you know the id•egree of difficultyis somewhere between nailing a triple gainer * with a half twist and eliminating the nationad l ebt. But a llthat's

about o change. Introducing GroupWise4.1, a new Meeting memberin the family of Novell® GroupWare. 1 GroupWise capitalizes on the advancements of Personal Appointment Personal Appointment Mattach its predecessor—WordPerfect® Office 4.0— offers features not found in any of its competitors. For instance, with the Busy Search feature of the integrated E- mail calendar/schedule program, you can quickly determine the best time for 8 (or 80) people to convene. Regardless of their operating systems. GroupWise integrates task management, so you can delegate an assignment, track its acceptance and manage its completion before the first attendee arrives. With GroupWise, we've made it incredibly easy to set up a meeting. Of course, you still have the daunting task of keeping people awake in one. See the reseller below to learn more about Novell GroupWare, the perfect way to put people together with information. 0401(4 , 4te,orttr,. OA: ......

GroupWise

0 1995 Novell, Inc. GroupWise and InForms are trademarks of Novell, Inc. SoftSolutions is a trademark of SoftSolutions Technology Corporation, a wholly owned subsidiary of Novell, Inc. 18 Vendor Yellow Pages

RSA Data Security Sprint Kurt Stamberger Jay Sheth Technology Marketing Manager Director, Market Support 100 Marine Parkway 12490 Sunrise Valley Drive, Redwood City, CA 94065 VARESF0242 Tel: +1 415 595 8782 Reston, VA 22096 Fax: +1 415 595 1873 Tel: +1 703 689 5661 Fax: +1 703 689 5644 Scitor Sarah Bond StarNine Marketing Manager, Core Services David Thompson Scitor House, Vanwall Business Park Marketing Manager Maidenhead, SL6 4UB 2550 Ninth St #112 United Kingdom Berkeley, CA 94710 Tel: +44 1628 773577 Tel: +1 510 649 4949 Fax: +441628 778097 Fax: +1 510 548 0393 [email protected] Sequent Computer Systems Mike Demshke Systems Compatibility Business Mgr, Enterprise Messaging David Wainwright 15450 SW Koll Parkway VP of Sales MS Co12-306 401 N. Wabash #600 Beaverton, OR 97006-6063 Chicago, IL 60611 Tel: +1 503 578 4252 Tel: +1 312 329 0700 Fax: +1 503 578 7562 Fax: +1 312 670 0820 [email protected] Tandem SITA Jay Macho Alex Drobik Mktg Prog Mgr, Messaging Product Line Manager, Messaging 19191 Vallco Parkway, Capital Place LOC 4-39, 120 Bath Road Cupertino, CA 95014-2594 Hayes, Middlesex, UB3 5AN Tel: +1 408 285 6018 United Kingdom Fax: +1 408 285 5411 Tel: +44 181 730 1358 X.400: C=us; A=telemail; P=tandem; Fax: +44 181 730 1389 S=mackro; G=jay

Software & Systems Engineering Ltd Trusted Information Systems Michael Brady Steve Crocker Fitzwilliam Court Vice President Leeson Close 3060 Washington Road ( Rt. 97) Dublin 2 Glenwood, MD 21738 Ireland Tel: +1 301 854 6889 Tel: +3531 676 9089 Fax: +1 301 854 5363 Fax: +3531 676 7984 [email protected]

Unisys Worldtalk Dennis Peck Erica Olson VP, Mktg & Sales, Client/Server Sys. Sr Marketing Communications Manager 1512 Via Fernandez 475 Alberto Way Palos Verdes Estates, CA 90274 Los Gatos, CA 95032 Tel: +1 310 375 6875 Tel: +1 408 399 4033 Fax: +1 408 399 4013 ViaCrypt [email protected] Leonard Mikus President Xcellenet 2104 West Peoria Ave Dean Compton Phoenix, AZ 85029 Development Manager Tel: +1 602 944 0773 5 Concourse Pkway, Ste 200 Fax: +1 602 943 2601 Atlanta, GA 30328 Tel: +1 404 804 7476 Wingra Fax: +1 404 353 2850 Technologies Cynthia C=us; A=bellsouth; P=xcellenet; O=hq; Cauthern Sales DDA=xname=dean 450 Science Drive Madison, WI 53711 Zoomit Tel: +1 608 238 4454 Jackson Shaw Fax: +1 608 238 8986 VP, Sales [email protected] 168 Sunnyside Avenue Ottawa, ONT K1S OR3 Canada Tel: +1 613 730 0566 Fax:+1 613 730 0567 N=jackson shaw; O=software; P=zoomit; A=attmail; C=us [email protected]

405

Index

Symbols single space in X.400 address 63 SMTP/Internet 132 1180 survey of formats 129 @ 180 translation 23, 96, 129, 133, 170, 181 1-off addressing xiii administrator-defined rules 135 administrator-selectable rules 135 A rules-based 135, 136 table-based 135 Access transparency 211 to external services 178 X.400 50, 52, 132 Access control 21 X.400, hierarchical 52 directory 23 X.400, in lower case 53 gateway 24 X.400, problems 62 Account Address translation 117, 129 change 25 administrator defined rules 138 creation 25 administrator selectable rules 138 deletion 25 basic concepts 132 Account administration xiii cc:Mail to X.400 example 137 Accounting management 229 centralized translation requirement 140 ADDMD 55 co-recipients' 148 Address 21 how rules are applied 139 ADMD name in X.400 address 62 inflexibility of older systems 134 BeyondMail 129 multi-hop 146 cc: Mail 130 non-unique 146 CompuServe 130 problems 144 containing routing information 107 rules-based 140 format recommendations 65 table-based 140 formats 21 using DDAs 138 handling those of co-recipients 148 X.400 to cc:Mail example 136 Internet 65 X.400 to SMTP/Internet 137 lookup 97 Addressing 190, 364 mapping. See Address translation Addressing MAFF 342 MCI Mail 130 ADMD xiv, xv, 21, 49, 75, 192 Microsoft Mail 131 attribute in PRMD-PRMD connections 64 NetWare MHS 129 benefits of connecting to 187 ON Technology eMAIL 129 connecting to an ADMD 75 ON Technology Notework 129 correspondents' 193 QuickMail 131 international ADMD-ADMD connections 194 recipients' 41 negotiating with an ADMD 196 sender's 41 non-X.400 services 195 simplifying X.400 addresses 65 organizations with multiple ADMDs 63 selection criteria 192

407 Index

single space 182 Authorizing users 179 single-space ADMD name 211 Auto-answer mailbox 68 ADMD name 62 AutoCAD 161 in organizations with multiple ADMDs 63 Automated housekeeping services 24 in PRMD-PRMD connections 64 Autoregistration 134, 141 single space 63 cryptic names 148 "X" 63 multiple addresses for same person 149 Administration 184 problems 148 centralized 128 centralized vs. distributed 99 B Administration-by-Mail 102 Administrative Directory Management Domain. See Backbone xi, 26, 30 ADDMD basic features 32 Administrative Management Domain. See ADMD PC E-Mail Everywhere 90 Adobe Illustrator 161 requirements 32 Advantis 49, 194 SMTP/MIME Disadvantages 89 Alert 218 transport 35 Alisa Systems 32, 89 using SMTP/MIME 86 Alisamail X.400 alternatives 85 directory synchronization 122 Backward compatible 73 Alprange 297 Banyan 328 Alternate recipient 239 BeyondMail 129, 152, 332, 339 Alternet 89 Intelligent Messaging 22 Amadeus Systems 32 Routing 112 Ancillary services 198 StreetTalk 22, 94 ANSI X.12 78 BBS. See Bulletin API xiii, 19, 26, 43, 313 board Beta test 209 Directory Services 330 BeyondMail. See file-based 315 Banyan Billing 198 Message Access 331 Body Message Store 329 IPM 42 Message Transfer 330 Body part 15, xii, 43, 54, 154 Object Management 329 bilaterally defined 155 programmatic 320 file transfer 156 programmatic vs. file based 321 IA5Text 155 Application program interface. See API multiple 213 Application Toolkit 314 multiple text 172, 183 APS xii, xv, 71, 83, 191, 192, 201 type 14, 15, 43, 155 Archive Boldon James 47, 85, 297 gateway 24 Enterprise Mail 339 MTA 21, 24 Boston Software Works 32, 89 ArCom 187 InterOFFICE ASN.1 74 directory synchronization 122 Asynchronous Protocol Specification 75. See APS Boundary conditions 183, 212 AT&T 187, 199, 328 British Telecom 187 AT&T EasyLink 194 Bulletin board 232 AT&T Global Information Services 85 Attachment 154 large file 214 C ATTmail 49 Cable and Wireless Attribute 50 CWmail ADMD 345 Authentication 20, 73 Cad mover 162 message 22 cc:Mail 35, 188 MTA-MTA 48 address format 130 Authorization 300 ADE 60, 121

bulletin board system 307 eMAIL. See ON Technology Import/Export 314, 319 DAP 57 Router 35 Data Connection Limited 85 tunneling 175 DataViz CCITT 49, 72, 86, 87 MacLinkPlus 161 Character sets DDA 50, 53, 138, 146, 180 international 213 using DDAs in address translation 138 Chargeback 24, 25, 242 DDA type 53 Class 0 72 DDA value 53 Class 4 72 DDE 332 CMC xiii, 74, 314, 318, 322 DEC 32 cmc_send_documents 324 Delay xii CMIP xiv Delivery notification COBOL 22, 23, 44, 170, 175, 182, 212 not dead 245 delivery notification handling xiii Commitment 185 Not present in SMTP 89 Common Messaging Calls. See CMC Delrina CompLink 89 Form Flow 332 CompuServe 214, 328 DGN.DEN 131 address format 130 Dialin-access 366 Confidentiality 300 Dialup connection 190 See also APS Configuration management 229 Dialup users 195 Connectivity DIB 56 external X.400 187 Digital 47, 89, 328 international 194 Directory Synchronization Utility 122 physical 191 Digital Equipment Corporation. See Digital to an ADMD 192 Dir sync. See Directory synchronization to trading partners 190 Direct connection Content 41 advantages 191 Control Data Systems 85, 297 disadvantages 191 Mail*Hub. See Mail*Hub Directory 366 Conversion access control 23 auxiliary element 170, 179 Access Protocol. See DAP backbone-based 161 based routing xii delivery notification 23 custom field definition 23 desktop-based 161 employee 95 file 170 entry maintenance 23 file attribute 23 external access 23, 103 high-end graphics 161 external access problems 103 interpersonal message 170 Information Base. See DIB IPM conversion problems 171 Interface Unit 118 message 23 issues 96 receipt notification 23 lookup services 21 Cost xiii, 55, 82, 87, 159, 182, 196, 200, 215 MTA 207 Country name master 117 in multinational organizations 64 master master 120 Cryptography messaging 95 public key xv propagation 23, 24, 60, 116, 120 CSU/DSU 200 query 98 Cutover 209 reorganization 23, 24 server 118 D services 55, 93 services API 330 Da Vinci services mailbox 68 special purpose 95

409 Index

support services 23 standard mailbox recommendations 67 synchronization xiii, 23, 24, 58, 59, 96, 115, eMAIL. See ON Technology 170, 184, 356, 367 Encapsulation 213. See tunneling system 56, 94 Encryption 20, 22 system Agent. See DSA Encryption certificate 22 system Protocol. See DSP Enterprise Mail. See Boldon James user Agent. See DUA Enterprise Solutions 47, 85, 297 Directory: MAFF 343 X.400 UA for Windows 299 Distribution List EUnet 346 management issues 60 Executive summary xi Distribution list 21, 25, 47, 60 Expiry time 299 expansion 60 Export file 315 member 60 Export program 315 recommendations 61 Extended MAPI. See MAPI technical problems 61 Extensibility 185 DIU. See Directory Interface Unit External access 97, 103 DL. See Distribution list problems 103 DN. See Delivery Notification; See Delivery External Connectivity 21, 345 notification DNS 87 F "DNS" 65 Domain defined attribute. See DDA; See DDA Fault management 229, 237 Domain Name System. See DNS Fax 195 Downgrading 73 Fax number 22 DS 56. See also See Directory System Feasibility 182 DS/P. See Lotus/SoftSwitch: Directory Synchroni- FFAPI xiii, 314, 319 zation Protocol File DSA 56 large 54 DSP 57 viewer 151 DTE number 199 File attributes 54 DUA 56 preserving across X.400 gateways 156 Duplicate names 145 File conversion 54, 55, 170 Dutch Telecom: 400NET 362 backbone 162 DX. See Retix DX backbone benefits 162 backbone disadvantages 163 E desktop 160 location 160 E-Mail 17 problems 164 Ease of installation 185 File format EBCDIC 171 API. See FFAPI ECFORMS 332 preferred 22 EDI 19, 76 File size limits 184 EDI services 195 File transfer xiii, 54, 151, 153, 170, 182 EDIFACT 78 body part. See Body part Education 197 PC e-mail 154 Electronic Data Interchange. See EDI problems with large files 158 Electronic Mail. See E-Mail X.400 154 Electronic Messaging Association. See EMA File-based API 314, 315 EMA 54, 65 Filtering 126 address format recommendations 66 First name 50 attempts to simplify X.400 addressing 65 Florida Power Corporation 352 Message Attachment Working Group Form Flow 332 156, 164, 304 FTE 225 Messaging Management Committee 230

G Housekeeping 23, 24, 249 HP. See Hewlett-Packardl Gateway xiii, 35 Hub-and-spoke architecture 105, 340, 354 address translation 181 problems of 110 administration 184 Hub-and-spoke hierarchy xii API 330 Human resources database 101 archive 24 boundary conditions 183 committment to product 185 cost 182 IA5Text 155 delivery notification 182 IBM directory synchreonization 184 ECFORMS 332 ease of installation 185 IC consultant 230 extensibility 185 IFIP feasibility 182 working group on electronic mail management 229 file size limits 184 Import file 315 file transfer 182 Import program 315 functions 169 ImporUExport xiii, 314, 319 international character sets 183 Importance 300 log 24 Infonet 49 multiple text body parts 183 Infonet Software Solutions 297 must be customizable 171 Informs 332 one-off addressing 181 Initial 50 performance 183 Initial directory load 102 point-to-point 29 Inline addressing 134, 142 restore 24 creates confusing messages 149 security 178 problems 148 selection criteria 181 Innosoft International 85 services 23 Installation single space ADMD 181 hardware & software checklist 203 technical support 184 step-by-step approach 204 X.400 to Netware MHS 356 steps 205 X.400 to SMTP/MIME 367 Installation planning 202 GE Information Services. See GEIS Installation support 196 GEIS 49, 187, 214 Integration software. See Message integration software General management services 25 International character sets 172, 183 GOSIP xiv, 340 International connectivity 194 GroupWise 152, 213 International Standards Organization. See ISO International Telecommunication Union. See ITU H Internet xiv, 21, 83, 86, 87 chaotic 89 Help desk 208 Interoperability xiv, 80 Helpdesk mailbox 68 Interpersonal file transfer 171 Helping users xiii Interpersonal message. See IPM Hewlett-Packard Intrusion 178 Network Node Manager 306 IPM xiii, 17, 41, 42, 171 OpenMail 34, 328, 352, conversion problems 171 UAL API 358 ISO 49, 73 Open View 88 transport protocols 70 OpenView Network Node Manager 354 ISOCOR 47, 85, 297, 328 OpenView OperationsCenter 354 ISODE Consortium 85, 340, 344 Hitachi DSA 104 SynchWare 122 ITU 71, 72. See also International Telecommunication Union. Hop count 222

411 Index

J Management xiii cross-system xiv JetForm 332 domain. See MD Junk mail 178 monitor 218 MAPI xiii, 326 K Extended MAPI 326 Service provider interface 327 Kandu Software Simple MAPI 326 Cad mover 162 v0 326 Keyword Office Technology v1 326 KEYview 152, 161 Marben 85 Kille Master directory 117 Steve Hardcastle- Master-master directory 120 112 Kimer, Ted 352 Master-slave synchronization. 120 Mastersoft Word for Word 161 L Word for Word Windows Edition 152 LAN e-mail 47 MaXware 47, 297 LAN Manager MCI 49, 187 Domain Server 94 REMS accounts 214 Last name 50 REMS X.400 connection 83 Lazy but important people 142 MCI Mail LJL Enterprises 85 address format 130 Log McKinnon, John 337 gateway 24 MD 49. See also Management domain MTA 21, 24 Memo/Forms 332 Loop detection 222 Mercury 214 Lotus xv, 89, 140. See also Lotus/SoftSwitch Message cc:Mail 328 conversion 23, 170 Notes 328 format 41 LMS 32 integration software 31 Lotus/SoftSwitch 89, 122, 140, 178 preparation services 19 Application Toolkit 314 recovery 22 Central 32 routing 20 connecting to ADMD 188 status services 22 Directory synchronization 123 switch 31 Directory Synchronization Protocol 124 tracing 22 LMS tracking xiii, 22, 170, 177 directory synchronization 122 transfer 21 Query-by-Mail 98 Message Access API 331 Message Attachment Working Group. See EMA Message store xiv, xv, 35, 46, 73, 365 M archive 24 backup 24 MacLinkPlus 161 flat 308 MADMAN 88 reorganization 24 MADMAN MIB xiv restore 25 MAFF. See Ministry of Agriculture, Fisheries and services 20 Food Message Store API 329 MAFFnet 337 Message transfer agent. See MTA Mail*Hub Message Transfer API 330 X.500-based routing 112 Messaging Mailbox 20 API. See MAPI address 21 backbone. See Backbone name 21 management xiv, 217 services 37

412 Copyright ©1995 by Ferris Research, Inc. All rights reserved. Reproduction prohibited without permission. Index tunneling 175 Informs 332 NetWare Bindery 94 system 17 NetWare Directory Services 22, 328 Microsoft xv, 89 NetWare Global MHS 22, 328 Exchange 327, 328 NetWare MHS 317 Mail 35, 152, 188, 213, 339. WordPerfect Office. See Novell GroupWise address format 131 NYSERNet/PSI White Pages project 57 Dir Sync 60, 121 External 35 0 FFAPI 314 group scheduling 307 0/R address 50 MIME xii, 86 Object Management API 329 Ministry of Agriculture, Fisheries, and Food 337 Obsoleted messages 299 Ministry of Transport, Public Works, and Water Man OfficeVision. See PROFS/OV 361 OLE 172 Mnemonic ORAddress. See 0/R address ON Technology 317 Moves and changes 231 eMAIL 129, 152, 352 MTA 20, 35, 46, 47, 363 Notework 129 archive 21 One-off addressing 150, 181, 211 directory 207 Open addressing. See Inline addressing functions 47 Open Systems People log 21 low-cost ADMD 345 MTA-MTA connection xii OpenMail. See Hewlett Packard name 48 OpenPathDIR. See Systems and Software Engineer- password 48 ing restore 21 OpenPathMAIL See Systems and Software Engi- routing 105 neering Multi-hop routing 194 OpenView. See Hewlett Packard Multi-purpose Internet Mail Extensions. See MIME Oracle Multiple text body parts 183 PLJSQL 333 Organization name 50 N indigestible 0 and OU attributes 64 Organizational unit 50 NADF. See North American Directory Forum indigestible 0 and OU attributes 64 Name OSI xv mailbox 21 Outside/In. See Systems Compatibility NDS. See Novell NetWare Directory Services NET-TEL 85, 361 P NetWare MHS 317 Network management 229 PO protocol 43, 77 NEXOR 85, 297 P1 PC-DUA 98 header 41 Nondelivery notification 47, 170, 175 protocol 41 Nonreceipt notification 170, 175 P2 42, 78 North American Directory Forum 57 protocol 41 P22 Northern Telecom Secure Networks 85 protocol 43 Norton Desktop 152 P3 301 Notes 328 protocol 46 Notework. See ON Technology P7 301, 304 Notification protocol 46 delivery 170, 182 Packet network 198. See X.25 nondelivery 170 PageMaker 161 nonreceipt 170 Paradise project 57, 88, 344 receipt 170 Novell GroupWise 152, 177, 231, 361, 370 forms processing 307 group scheduling 307

413 Index 11111111111111111 ______

PC e-Mail xii reasons for unreliability 33 scalability 34 QuarkXPress 161 PC E-Mail Everywhere 90 Query-by-Mail 98 advantages 90 QuickMail 188 disadvantages 91 address format 131 PEDI 78 forms processing 307 protocol 43 QUIPU 85 Peer-to-peer synchronization 120 PEM, 86 Performance 183, 214 Performance management 229 Read receipt 44 Performance Systems 89 Receipt notification 22, 23, 45, 170, 175 Physical connection 191 Recipient 19 Pilot test 209 Recovery 22 PL/SQL 333 Related messages 299 Planning Relay 111 installation 202 Remote login xiii Point-of-presence 75, 199 Reply time 300 Point-to-point gateways 29 Request For Comment. See RFC POP 200. See also See Point-of-presence Restore Post office 35. See also See Message store gateway 24 Post-installation support 197 MTA 21 Post-production support 210 Retix 85 Postal delivery 195 DX 125 PP 85 Retix Directory Exchange. See Retix DX PRDMD 56 Revocation list 22 Prime Mail Plus. See Mail Plus RFC 86, 87 Priority 19, 300 1341 86 Privacy Enhanced Mail. See PEM 821 86 Private Directory Management Domain. See PRDMD 822 86 Private Management Domain. See PRMD RN. See Receipt notification PRMD 49, 187 Routing 20, 52, 97, 105 PRMD to PRMD connection 187 direct 110 to ADMD interoperability tests 206 directory-based xii, 110 virtual. See virtual PRMD hubs 108 PRMD name 50 in X.400 addresses xii PRMD-ADMD connection 80 information 22 benefits 82 MTA xii PRMD-PRMD connection 80 table maintenance 105 benefits 82 RSA Data Security 79 using Internet 83 Rules. See address translation rules Probe 222 Problem message queue 222 PROFS 47 S PROFS/OV Security 78, 82, 126, 170, 178, 192 addressing inflexibility 134 by limiting correspondents 49 nickname 131 Security management 229 userid 131 Service Programmatic API 314 ancillary 198 Programming xiii guarantee 34, 219 Proofs of delivery 25 Service provider Public key 22 using service provider's X.400 gateway 83 Public key cryptography 79, 89 interface 327 Public key encryption 88

Shadow file 119 Telex 195 Simple MAPI. See MAPI Telnet 306 Simple Send xiii, 324, 333 Test Single space ADMD xiii, 182, 190, 211 beta 209 SMF 317 pilot 209 SMTP 80, 86 stress 208, 211 address format 132 Threshold 223 SMTP/MIME xii Tie breakers 145 SNADS 32 Time services 24 SNMP xiv Trace 41 SoftSwitch. See Lotus/SoftSwitch Tracing Software and Systems Engineering 85 message 22 Southern Company/COS X.500 pilot 57 Tracking Special character handling 23, 170 message 22 Special characters 180 Trading partners Sprint 49, 187, 194, 199, 214 connecting to 190 SSE. See Systems and Software Engineering Training StarNine Technology users for external X.400 connectivity 209 AOCE/SMTP gateway 179 Transport protocol 70 Stress testing 208, 211 Transport services 20 SunNet Manager 88 Trawling a directory 103 Supplementary Information 176 TSS. See Telecommunication Standardization Sector Support Tunneling 23, 158, 170, 174, 183, 213 installation 196 post-installation 197 post-production 210 technical support for trading partners 197 UA 19, 25, 45, 47, 297 vendor 210 non X.400 47 Switch. See Message switch X.400 297 Symantec X.400 UA strengths 302 Norton Desktop 152 X.400 UA weaknesses 306 Synchronization Unipalm 328 frequency 127 Unisys 85 master-slave 120 UNIX xiii multi-tier 127 UNTDI 78 peer-to-peer 120 User account housekeeping services 25 process 117 User administration 97, 99 Syrett, Richard 337 User Agent. See UA memorial tribute 350 User move 25 System activity reporting 24 User support System/gateway box 190 tasks checklist 231 Systems and Software Engineering Utilities development xiii OpenPathDIR 344 UUDECODE 86 OpenPathMAIL 340 UUENCODE 86 Systems Compatibility Corporation Outside/In 152, 161 V

T Vendor Independent Messaging. See VIM Vendor support 210 TCP/IP xii, xiii, xv, 75, 86, 190, 361 Verimation transport protocols 70 Technical Memo/Forms 332 support 184, 197 Viewer 151 Telecommunication Standardization 72 VIM 319, 324 Sector Telekom 187 Virtual PRMD 214 disadvantages 215, 216

415 Index

w connectivity requirements 188 Gateway API 330 Wayers, Toine 361 source code 85 Wells, Jim 352 X.400 backbone 27 White Pages project 57 X.400 UA xiv, 362 Wild addressing. See Inline addressing X.400: 1984 vs. 1988 348 Wingra Technologies 356 X.435 43, 76, 78 Word for Word. See Mastersoft X.445 71 Word for Word Windows Edition. See Mastersoft X.500 xiii, xv, 55, 73, 88, 97, 103, 127 WordPerfect. See Novell architecture 56 WordPerfect Office. See Novell Groupwise DSA chaining 57 Worldtalk 32, 89, 140, 178, 356 DSA multicasts 57 directory synchronization 122 DSA referral 57 NYSERNet/PSI White Pages project 57 X Paradise project 57, 88 problems 57 X.25 xii, 70, 75, 83, 190 proprietary access controls 104 advantages 199 Southern Company/COS Pilot 57 primer 198 X.API xiii selecting an X.25 carrier 198 strengths 331 tips on reducing charges 201 weaknesses 331 use with X.400 200 X.APIA 74, 322, 329 X.400 X/OPEN 322 1984 vs. 1988 73 XDS 330 alternatives 80 XMA 331 Application Program Interface Association. XMS 329 See X.APIA XMT 330 backbone alternatives 85 XOM 329 benefits 81