Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

Whitepapers

Boundary Messaging

Summary

This white paper looks at the evolving model of message service provision, and introduces the approach of 'Boundary Messaging', based on industry trends and on the experience of deployment by Isode customers. The advantages of Boundary Messaging are explained, and in particular the key relationship between Directory Services and Boundary Messaging.

Elements of Messaging Provision

This section considers the server infrastructure components of a typical medium to large messaging configuration. There are a number of elements to this:

• Workgroup. This is provision of messaging submission and storage for a group of local users. Traditionally, this is the role of LANMail systems. This function is now being provided by products such as Microsoft Exchange and Lotus NotesMail, and by open solutions using IMAP4 servers and SMTP message switches.

  Small organizations may operate as a single workgroup, whereas large organizations will typically have many workgroups, reflecting different parts of the organization. Grouping corporate message provision as a number of workgroups enables better autonomy for different parts of the organization, and gives flexibility to address requirements from different parts of the organization in different ways.

• Backbone. A backbone system is simply a distributed collection of message switches, used to interconnect workgroups. In a "classic" backbone system, each workgroup is configured to connect only to the backbone, and the backbone has the knowledge to glue the whole system together.
• Legacy Gateway. Most enterprises have a range of older message systems. Rather than having an 'n by n' interconnect and conversion, the usual approach is to deploy a 'mail gateway', from vendors such as Soft*Switch or CDC, which support a wide range of mail systems, and can enable connectivity from each of these to the backbone.
• Firewall. Where enterprises deploy an Intranet/Internet firewall, they will usually also deploy a messaging firewall. This will provide controls on flow of messages in and out of the enterprise, and controls such as virus checking and anti-spam. Such services are usually implemented by simple 'rule based' systems such as Sendmail, which can be bundled with a firewall product or implemented as an add on to an existing messaging infrastructure.
• Boundary Messaging. A new element, introduced in this white paper and described below. Boundary messaging provides value added firewall services, and provides connectivity between internal and external services.

The Old Model

Figure 1: Firewall/Backbone model

Figure 1 shows a 'classic' backbone/workgroup/firewall configuration. The firewall sits on the edge of the enterprise, and controls access to the backbone. The backbone interconnects all of the workgroups and the firewall.

Changes in Messaging Provision

There are a number of trends in the evolution of messaging provision, which relate to Boundary Messaging:

• Workgroups are getting larger. The primary reason for this is that products which support workgroups are becoming much more scalable and can be managed for a large number of users. The consequence of this is that enterprises are now able to structure workgroups in a manner which supports their business needs, rather than being constrained by scaling limits in workgroup products. This will quite often lead to larger workgroups.
• Legacy gateways are becoming less important. An increasing number of products on the market support SMTP (Internet Mail) including upgrades to older products. As a consequence of this, an increasing percentage of all systems can be interconnected using open protocols. This means that the requirement to have an expensive special purpose legacy gateway will be reduced.
• Backbones are becoming less important. In part, this is a consequence of workgroups becoming larger, so there is less to interconnect. With a reduced number of workgroups and increased sophistication of workgroup products, direct interconnection of workgroups will also make more sense. While there is often still a role for the backbone function (connection of 'odd' workgroups; 'fall back' routing; interconnection of special services and centrally provided services) this role is becoming less important in modern configurations.
• Firewall provision is becoming more important. Organizations require an increasing level of firewall type services, in particular anti-spam and virus control.

The consequences of these trends is that the classic workgroup/backbone/firewall model is becoming less appropriate to modern organizations. Boundary Messaging is a new model, which is more appropriate to this new structure.

Boundary Messaging

Figure 2: Boundary Messaging model

Boundary Messaging provides connectivity and firewall functionality between external and internal messaging services, and integrates internal messaging services.

The easiest way to understand Boundary Messaging is as an evolution of a firewall, which provides value added functionality. The key distinction between a traditional firewall and Boundary Messaging, is that Boundary Messaging has detailed knowledge of the structure of the enterprise. This is represented in Figure 2.

Because it has knowledge of the internal configuration, the Boundary Messaging system is able to replace the functionality of the backbone. Note that that there is some workgroup direct connectivity, with fall back routing provided by the Boundary Messaging.

The Benefits of Boundary Messaging

Apart from the clear cost savings from coalescing the firewall and backbone functionality, there are a number of key benefits to the boundary messaging approach. The main benefit with respect to the backbone is that this model more accurately reflects the residual backbone services, which have a reduced role.

The benefits over a traditional firewall relate to the Boundary Messaging knowledge of the internal structure of the enterprise. Services that can be provided based on this knowledge are:

• 'Friendly Names' mapping. This service maps internal names which are used to partition an organizations internal mail structure to enable routing (e.g., 'juser@xxx54.corp.com') and external 'friendly names' (e.g., 'J.User@corp.com'). This approach enables the internal infrastructure to be totally hidden externally, and to have a much reduced internal visibility. This allows users a clean location independence, and allows local mail provision to be altered without affecting external connectivity. This mapping and the associated routing can be handled in both directions by the Boundary Messaging system.
• Optimal Routing. Because the Boundary Messaging system has good knowledge of the internal configuration, it is always able to route messages efficiently and optimize the transfer of external messages directly to their final internal destinations.
• Per user authorization. Knowledge of individual users allows the Boundary Messaging system to apply controls on a per user basis. This will enable control of access to internal and external services, with a much finer granularity than would be available with a rule based system.

Example Deployments

The Boundary Messaging model was based on observations of how large organizations were using the M-Switch. This section describes generic aspects of this type of solution, based on actual deployments. Aspects of common configurations are:

• Primarily SMTP (Internet Mail) based. Although Isode offers X.400, the primary configurations are SMTP based, and so there is effectively an Internet Mail backbone.
• Microsoft Exchange as the general corporate strategy for workgroup provision. While the Boundary Messaging model can be used with any workgroup products, our experience has been using it to complement Exchange.
• Isode based Boundary Messaging is viewed as a fundamental part of the operation, and complementary to workgroup services.
• Centralized registration of all users that are given external mail access. The management of the service has been handled in conjunction with centralized registration, which is integral to managing the Boundary Messaging configuration.

The typical goals of an organization adopting a Boundary Messaging approach are:

• Separation of mailbox services and external access/interconnect.
• Providing a 'Friendly Names' service.
• Providing firewall services, including virus checking and anti-spam.
• Mail authorization and controls on a per user level, possibly extending to personal Service Level Agreements (SLAs).
• Efficient overall message routing and dispatch within the enterprise.

There are two basic ways in which the M-Switch is deployed to achieve Boundary Messaging services. Typically, there will be multiple instances of such configurations, often at widely dispersed geographical locations.

Figure 3: Single Message Switch

The simplest approach to Boundary Messaging is to deploy message switches within the enterprise. This is illustrated in Figure 3. These can be configured with knowledge of internal and external connectivity. The network level firewall is controlled to allow only message traffic to and from the Boundary Message switches. The firewall functionality is achieved by correct configuration of the message switch, to separate internal and external information. This simple approach works well, and is appropriate for many organizations.

Figure 4: Paired Message Switches

An alternate approach is to have message switches inside and outside of the organization, typically separated by a 'stub firewall' (usually a minimal network connecting the machines operating the Boundary Messaging system). This may be done with a pair of message switches, or with multiple message switches on each side of the firewall.

The advantage of this system is that the process for making configuration information available to 'internal' and 'external' message switches can systematically ensure that internal configuration information remains hidden from the outside. This approach is appropriate for organizations that need a very high level of assurance that internal configuration information remains hidden.

Directory and Boundary Messaging

Although directory services are not essential for Boundary Messaging, it is anticipated that directory services will form an integral part of most Boundary Messaging systems. The basic reason for this is that Boundary Messaging relies on access to enterprise wide information. While this can be achieved with a central database, use of directory is better for the following reasons:

• It allows the data to be distributed naturally across the enterprise.
• It provides for client/server data management.
• It uses open standards (LDAP and X.500).
• Message switches at multiple locations can cleanly share common configuration information, without the need for ad hoc replication.
• It facilitates timely update of configuration, rather than batch processing.
• An existing directory infrastructure can be used, and thus costs will be reduced by the sharing of a common data management resource.

Conclusions

This paper has introduced the concept of Boundary Messaging, which is a highly desirable approach, as it enables new value added services to be introduced over conventional firewall functionality and it replaces residual backbone functionality. Boundary Messaging is best used in conjunction with directory services for configuration management.