|
| |
| Sun Java System Communications Services 6 2004Q2 Enterprise Deployment Planning Guide | |
Chapter 3
Understanding Product Requirements and ConsiderationsThis chapter describes requirements and considerations that impact the design of your deployment. You need to understand these requirements and considerations to accurately determine your Communications Services architecture.
This chapter contains the following sections:
Planning for Various ComponentsWhen designing your deployment architecture, take into account the requirements of the various component products of your deployment. For example, if you have a technical requirement to integrate Communications Services with other Java System products, you need to choose your schema accordingly. Inter-product dependencies, for example, how Communications Services access and place load on Directory Server, present deployment choices as well.
Understanding the individual components of each product enables you to plan for the type of architecture to best suit your requirements. Depending on your deployment, you need to potentially understand and plan for the following components:
Understanding Service Components and Service Tiers
When planning a Communications Services deployment for multiple component products or services, you need to understand the composition of each component product (or service) itself.
Figure 3-1 illustrates how you can separate each service into components that can be deployed on separate hosts, and the particular tier each component occupies. Though you can deploy all components on a single host, or deploy a particular service’s components on the same host, consider moving to a tiered architecture. A tiered architecture, whether it be single-tiered, or two-tiered, provides a number of benefits. See Benefits of a Single Tier Architecture and Benefits of a Two Tier Architecture for more information.
Figure 3-1 Communications Services Components
In the preceding figure, the client components consist of the Outlook Connector plugin, thick clients such as Evolution, browsers, and standard email applications. These components reside on end users’ client computers. The access layer components consist of front-end services from Messaging Server (MMP, MTA, and MEM); Calendar Server; Communications Express (which must be collocated with MEM); Instant Messaging (Instant Messaging Proxy); Portal Server (SRA and Core); Identity Server (for authentication) and a corporate directory, which provides address book lookup. The data layer components consist of back-end services from Directory Server (which, in itself, can consist of front-end and back-end components); Messaging Server (Message Store); Calendar Server (Calendar Store); and Instant Messaging. A Storage Area Network (SAN) “cloud” represents the physical data storage.
The following sections explain these various components in more detail.
LDAP Directory Information Tree RequirementsThe Directory Information Tree (DIT) is a way to organize directory entries in a tree structure, or schema, with nodes representing domains, subdomains, users, and groups. Sun Java Enterprise System introduces a fundamental change to how the directory is structured by implementing a one-tree structure.
Changes in the DIT Structure
Messaging Server and Calendar Server have introduced a one-tree structure, where there is no Domain Component (DC) Tree. All domain information is held in domain nodes in the Organization Tree. Aliasing is handled entirely differently in the new one-DIT structure.
The bottom half of Figure 3-2 illustrates a one-tree LDAP structure.
Figure 3-2 Two-Tree LDAP Structure Compared With One-Tree Structure
Benefits of a One-Tree DIT Structure
The main advantages to using the one-tree structure Schema 2 native mode are:
As illustrated in the following figure, in the two-tree structure, some nodes point directly to a node in the Organization Tree (using the attribute inetDomainBaseDN). Other nodes are aliased nodes, which instead of pointing directly to an Organization Tree node, point to another DC Tree node, using the aliasedObjectName attribute.
Figure 3-3 Two-Tree Aliasing With aliasedDomainName and inetDomainBaseDN
In the previous figure, sesta.com in the DC Tree points to siroe.com in the DC Tree using aliasedObjectName, and siroe.com points to the like named node in the Organization Tree, using inetDomainBaseDN.
Furthermore, as shown in Figure 3-4, there could be one or more nodes in the DC Tree using inetDomainBaseDN to point directly to the same node in the Organization Tree. In this case, a “tie-breaker” attribute, inetCanonicalDomainName, is necessary on one of the DC Tree nodes to designate which is the “real” domain name (the domain where the mail actually resides and where the mail is routed).
Figure 3-4 Two-Tree Aliasing With inetCanonicalDomainName
By contrast, a one-tree structure contains only an Organization Tree, as shown in the following figure.
Figure 3-5 One-Tree Aliasing With associatedDomain
In the one-tree structure, domain nodes in the Organization Tree contain all the domain attributes formerly found on the DC Tree. Each domain node is identified by the sunManagedOrganization object class and sunPreferredDomain attribute, which contains the DNS domain name. A domain node can also have one or more associatedDomain attributes, which list the alias names this domain is known by. Contrary to the two-tree structure, there are no duplicate nodes for the alias names.
A one-tree DIT structure is beneficial in how you partition data for organization-specific access control. That is, each organization can have a separate subtree in the DIT where user and group entries are located. Access to that data can be limited to users in that part of the subtree. This allows localized applications to operate securely.
In addition, for new deployments of Calendar Server or Messaging Server, a one-tree structure maps better to existing single-DIT LDAP applications.
Schema RequirementsBefore you install any of the Communications Services products, you need to understand which schema you will use. The schema is the set of definitions describing what types of information can be stored as entries in the directory. Two schema choices, Sun Java™ System LDAP Schema 1 and Sun Java™ System LDAP Schema 2, are available and supported with Communications Services. Your choice of schema depends on the following criteria:
Use Schema 2 if you:
- Want to use Identity Server 6 2004Q2 (formerly Sun ONE Identity Server 6.1), either for user provisioning or single sign-on (SSO)
- Are installing Communications Services components for the first time
- Are integrating Communications Services with other Java Enterprise System products, such as Portal Server
Use Schema 1 if you:
- Have an existing version of any of the Communications Services components, for example, if you are upgrading from Messaging Server 5.2
- Do not need to provision users through Identity Server (unless Identity Server SSO is also a requirement)
- Want to use Delegated Administrator to do your user provisioning
See the Sun Java System Messaging Server Deployment Planning Guide for more information on schema choices:
Directory Server ConsiderationsSun Java System Directory Server provides flexible, multi-tiered data storage for intranet, network, and extranet information. Directory Server integrates with existing systems and acts as a centralized repository for the consolidation of employee, customer, supplier, and partner information. You can extend Directory Server to manage user profiles and preferences, as well as extranet user authentication.
All custom LDAP schemas, such as those from Portal Server, Identity Server, Messaging Server, Calendar Server, and Instant Messaging Server, install into a single Directory.
There are many ways to architect your data environment and many factors to consider that depend on your business objective and expected usage patterns. Your directory design should address the following areas:
- Directory schema and object class definitions
- The Directory Information Tree (DIT)
- Groups and membership definitions
- A strategy for Access Control Lists (ACLs) including static and dynamic groups
- Directory architecture for high availability and performance, including failover, replication, and referrals
- Management of the directory
See the Sun Java System Directory Server Deployment Planning Guide for a complete description of these factors and suggestions about how to architect your data environment:
Directory Server and Tiered Architecture Considerations
In moving from a single tier architecture to a multiple tier architecture, Directory Server should be the first component that you “split out” onto its own machine. At a certain point of load, Directory Server and Messaging Server on the same host have inherent performance impacts. This is due to the way Messaging Server is architected to work with Directory Server. Separating Directory Server onto its own machine is the first step to improve performance for a deployment.
See the Sun Java System Messaging Server Deployment Planning Guide for more information on tiered architectures:
Directory Server Topology Considerations
Though it is feasible to build a deployment around an instance of Directory Server installed on a single machine, the other Communications Services components depend upon the directory as a core service to function. Thus, beyond trivial deployments, you should plan to deploy Directory Server in a redundant or highly availability configuration.
The first step toward making Directory Server more available is to establish a pair of master directory servers. Next, multi-master replication can be used to improve the LDAP write throughput and availability. If Sun Cluster is used for a high-availability deployment, then the two LDAP masters are clustered together. See Making the Directory Highly Available for more information.
Directory Server Capacity Planning
While there are no hard and fast rules for Directory Server capacity planning, actively monitoring the directory is essential to ensure that performance metrics are met. When the system is not meeting these metrics, then it is time to add an additional directory consumer. Typically, you will want to monitor:
Evaluate the above metrics against a target response time of 10 Milliseconds. The IOWAIT should not exceed 10 Milliseconds, and the sum of the CPU utilization in this tier should not exceed 70 percent.
Directory Server and Calendar Server Interaction Considerations
Calendar Server performs multiple writes to user entries stored in Directory Server. The bulk of these writes occur when the user logs into Calendar Server for the first time and when the user performs certain actions. These actions include creating a calendar, subscribing to a calendar, changing a preference, and so on. If you do not take these actions into consideration, the Directory Master Server can experience heavy loads.
If you use Directory replication, the LDAP Master Server is replicating entries to the LDAP Replica servers. As Calendar users perform one of these actions, Calendar Server will only be able to write changes to the Master Directory Server. This is because the Replicas are read-only.
The second interaction consideration exists in these replicated Directory structures. As users make preference changes, their changes mighty not be rendered successful until the change is successfully replicated from the Master Directory Server to the Directory Replica, which is in use by the Calendar Server. A workaround is available, in which you configure Calendar Express (cshttpd) attempts to cache the change locally to avoid this latency delay.
Directory Server and Personal Address Book Considerations
The Messenger Express Client supports the concept of a Personal Address Book (PAB). This enables users to store personal contacts (for example, business contacts, friends, and family) in the Directory Server. Each time a new personal contact is added to the user’s PAB, a write is made on the Directory Server. If you do not take these actions into consideration, the LDAP Master Server can face heavy loads (regardless of the Directory replication strategy).
One method to avoid performance issues on the User and Group Directory Server is to place the PAB information on a separate Directory Server. This enables PAB interactions to avoid placing a load on the LDAP Master Server.
Directory Server and Communications Express Considerations
The Communications Express client requires some configuration changes on the Directory Server. The Communications Express configuration requires the comms_dssetup.pl script, which ships with Java Enterprise System 2004Q2. This script is different from the one that shipped with Sun ONE Calendar Server 6.0 and Sun ONE Messaging Server 6.0 as part of Java Enterprise System 2003Q4.
Messaging Server ConsiderationsIn developing your Communications Services architecture, you need to evaluate the performance aspects of the following Messaging Server components:
The following sections provide an overview of the considerations for each of these components. For a complete discussion of the performance aspects of these components, and potential hardware solutions, see the Sun Java System Messaging Server Deployment Planning Guide:
Message Store Considerations
Message store performance is affected by a variety of factors, including:
The preceding factors list the approximate order of impact to the Message Store. Most performance issues with the Message Store arise from insufficient disk I/O capacity. Additionally, the way in which you lay out the store on the physical disks can also have a performance impact. For smaller standalone systems, it is possible to use a simple stripe of disks to provide sufficient I/O. For most larger systems, segregate the file system and provide I/O to the various parts of store.
Message Transfer Agent (MTA) Considerations
MTA performance is affected by a number of factors including, but not limited to:
- Disk performance
- Use of SSL
- The number of messages/connections inbound and outbound
- The size of messages
- The number of target destinations/messages
- The speed and latency of connections to and from the MTA
- The need to do spam or virus filtering
- The use of SIEVE language filtering rules and the need to do other message parsing (like use of the conversion channel)
The MTA router is both CPU and I/O intensive. The MTA uses two different file systems for the queue directory and the logging directory. For a small host (four processors or less) functioning as an MTA router, you do not need to separate these directories on different file systems. The queue directory is written to synchronously with fairly large writes. The logging directory is a series of smaller asynchronous and sequential writes.
In most cases, you will want to plan for redundancy in the MTA in the disk subsystem to avoid permanent loss of mail in the event of a spindle failure. (A spindle failure is by far the single most likely hardware failure.) This implies that either an external disk array or a system with many internal spindles is optimal.
In addition, with respect to placement of MTAs, you should always deploy the MTA at your firewall.
MTA and LMTP Considerations
The Messaging Server’s LMTP service as implemented is not designed to work with other LMTP servers or other LMTP clients. See the Sun Java System Messaging Server Release Notes for information on setting up a mix of LMTP and SMTP servers in your deployment:
Mail Message Proxy (MMP) Considerations
The MMP uses no disk I/O other than for logging. The MMP is completely CPU and network bound. Unlike all the other Messaging Server components, the MMP is not multiprocess and multithreaded. The primary execution code is single process and multithreaded. Thus, because the MMP is not sufficiently a multiprocess, it does not scale as well as the other components.
The MMP does not scale beyond four processors, and scales less than linearly from two to four processors. Two processor, rack mounted machines are good candidates for MMPs.
In deployments where you choose to put other component software on the same machine as the MMP (MEM, Calendar Server front end, Communications Express Web Client, LDAP proxy, and so on), look at deploying a larger, four processor SPARC machine. Such a configuration reduces the total number of machines that need to be managed, patched, monitored, and so forth.
Messaging Express Multiplexor (MEM) Considerations
The MEM provides a middle-tier proxy for the Webmail client. This client enables users to access mail and to compose messages through a browser. The benefit of the MEM is that end users only connect to the MEM to access email, regardless of which back-end server is storing their mail. MEM accomplishes this by managing the HTTP session information and user profiles via the user’s LDAP information. The second benefit is that all static files and LDAP authentication states are located on the Messaging Server front end. This benefit offsets some of the additional CPU requirements associated with web page rendering from the Message Store back end.
The MEM has many of the same characteristics as the MMP. The MEM will scale beyond four processors, but in most environments, there is no particular value in doing so. Also, in the future, the Webmail component will be offloaded from the Message Store and onto access layer machines that are running the XML rendering as Java servlets under the web server. Java servlets do not presently scale well beyond two processors. Thus, plan your hardware choice around either SPARC or Intel two-processor machines for the MEM, or assume that you will repurpose your current two-processor MEM hardware to be replaced by smaller machines when the next generation solution becomes available.
You can put the MMP and MEM on the same set of servers. The advantage to doing so is if a small number of either MMPs or MEMs are required, the amount of extra hardware for redundancy is minimized. The only possible downside to collocating the MMP and MEM on the same set of servers is that a denial of service attack on one protocol can impact the others.
Calendar Server ConsiderationsCalendar Server consists of five major services:
- HTTP Service (cshttpd) listens for HTTP requests. It receives user requests and returns data to the caller.
- Administration Service (csadmind) is required for each instance of Calendar Server. It provides a single point of authentication and administration for the Calendar Servers and provides most of the administration tools.
- Notification Service (csnotify) sends notifications of events and to-dos using either email or the Event Notification Service.
- Event Notification Service (enpd) acts as the broker for event alarms.
- Distributed Database Service (csdwpd) links multiple database servers together within the same Calendar Server system to form a distributed calendar store.
In a scalable Calendar Server deployment, you deploy an instance of HTTP Service and Administration Service together as a Calendar front-end system. (You would deploy one instance of the cshttpd per machine. On each machine, you would configure one cshttpd process per CPU on that machine.) An instance of Notification Service, Event Notification Service, Distributed Database Service and Administration Service are deployed together as the Calendar back-end system.
Authentication and XML / XSLT transformation are two Calendar Service activities that generate heavy load. Additional CPUs can be added to meet quality of service requirements.
Calendar back-end services usually require half the number of CPUs sized for the Calendar front-end services. To support quality of service by the Calendar front-end system, the Calendar back-end system should use around two-thirds of the front-end CPUs.
You will want to consider early on in a deployment separating the Calendar Service into front-end and back-end services.
The Calendar Server HTTP process that is typically a component of the front-end services is a dominant user of CPU time. This suggests care should be taken in accounting for peak calendar usage and choosing sufficient front-end processing power to accommodate the expected peak HTTP sessions. Typically, you would make the Calendar Server front end more available through redundancy, that is, by deploying multiple front-end hosts. As the front-end systems do not maintain any persistent calendar data, they are not good candidates for HA solutions like Sun Cluster or Veritas. Moreover, the additional hardware and administrative overhead of such solutions make deploying HA for Calendar Server front ends both expensive and time-consuming.
A good choice of hardware for the Calendar Server front ends is a single or dual processor SPARC or Intel server. You would deploy one instance of the Calendar Server cshttpd process per machine. Such a deployment affords a cost-effective solution, enabling you to start with some level of initial client concurrency capability and add client session capacity as you discover peak usage levels on your existing configuration.
When you deploy multiple front ends, a load balancer (with sticky/persistent connections) is necessary to distribute the load across the front-end services.
Note
Communications Express does not scale beyond two processors. The same hardware choices explained previously for Calendar Server apply to Communications Express deployments.
The Calendar Server back-end services are well balanced in resource consumption and show no evidence of bottleneck formation either in CPU or I/O (disk or network). Thus, a good choice of hardware for the back end would be a SPARC server with a single striped volume. Such a machine presents considerable capacity for large-peak calendar loads.
If your requirements include high availability, it makes sense to deploy the Calendar Server back end with either Sun Cluster or Veritas cluster, as the back end does contain persistent data.
Note
In a configuration with both front-end and back-end Calender Server hosts, all hosts must be running:
Instant Messaging ConsiderationsAs with other Communications Services components, you can create an architecture in which you separate Instant Messaging into front-end (Instant Messaging multiplexor) and back-end components (server and store).
See the Sun Java System Instant Messaging Deployment Planning Guide for more information regarding Instant Messaging considerations:
Portal Server ConsiderationsYou can install Communications Services products with Portal Server to provide an “umbrella” front end to access messaging, calendar, and instant messaging applications. The integration of Portal Server includes single sign-on capabilities between Portal Server, Calendar Express web client, Messaging Express web client and Communications Express client. In addition, the Messaging Express, Calendar Express, and Instant Messaging clients are made available to users through the Portal Server desktop.
See the Sun Java System Portal Server Deployment Guide and the Sun Java System Identity Server Deployment Planning Guide for more information:
Connector for Microsoft Outlook ConsiderationsThis section describes some deployment issues you will encounter deploying Connector for Microsoft Outlook. For complete information, see the Connector for Microsoft Outlook documentation:
Sun Java System Connector for Microsoft Outlook enables Outlook to be used as a desktop client with Sun Java Enterprise System. Connector for Microsoft Outlook is an Outlook plug-in that must be installed on the end-user’s desktop. Connector for Microsoft Outlook queries Messaging Server for folder hierarchies and email messages. It converts the information into Messaging API (MAPI) properties that Outlook can display. Similarly, it uses the WCAP protocol to query Calendar Server for events and tasks which are then converted into MAPI properties. With this model, Connector for Microsoft Outlook builds an end-user Outlook view from two separate information sources: mail from Messaging Server and calendar information from Calendar Server.
Connector for Microsoft Outlook Component Product Dependencies
To use Connector for Microsoft Outlook, both Sun Java System Messaging Server and Sun Java System Calendar Server are required in the same deployment. See those products’ release notes for information on supported versions.
For Connector for Microsoft Outlook to function correctly, the following LDAP attributes in the Sun Java System Directory Server should be indexed for at least presence and equality to improve the overall performance:
See the Sun Java System Connector for Microsoft Outlook Release Notes for a complete list of product dependencies.
Migrating Sun ONE Calendar Server Data
If you are using a version of Calendar Server prior to Sun ONE Calendar Server 6.0, you need to engage Sun Professional ServicesSM to convert and migrate the data to the new format. This Calendar Server data migration is required for the use of Outlook, and is necessary because of the underlying changes in the storage and management of recurring events. No migration service is required for new customers of Sun Java System Calendar Server.
Migrating Exchange Server Data
Connector for Microsoft Outlook does not convert Microsoft Exchange Server messages on the Exchange Server. You need to engage with Sun Professional Services to convert the data.
Communications Express ConsiderationsSun Java System Communications Express is a webserver-based application that can be accessed by using a browser. The Communications Express offering consists of three client modules: Calendar, Address Book, and Mail. The Calendar, Address Book, and Mail client modules are deployed as a single application in web containers and are collectively referred to as the Communications Express client.
Communications Express depends upon the following Sun Java System component products:
You install Communications Express as a front-end server (in a multi-tier environment). You must install the complete set of Messaging Server packages on the same host that Communications Express is running on. The Messaging Server is used to provide the Messenger Express interface directly to the Message Store, or to provide the MEM, which connects to a back-end store running Messenger Express. In addition, you can configure the AddressBook server of Communications Express on the front-end machine to store its data either in the LDAP directory infrastructure or on an LDAP server other than the Communications Express machine. See the Sun Java Communications Express Administration Guide for more information:
Communications Express communicates with the local (typically on the same machine) cshttp daemons for Calendar Server. In turn, these daemons communicate to the Calendar Server back end by using DWP. Communications Express utilizes Messenger Express (Webmail) to communicate with the Message Store.
When using a load balancer or port director type device, make sure to utilize “sticky” (persistent) connections such that users are continually routed to the same front-end server for the duration of their session.
Security ConsiderationsSecurity for a Communications Services enterprise deployment is managed by taking a “defense in depth” approach. By individually securing the network, hardware platform, operating system, and applications themselves, you make each layer of the architecture secure. Security includes hardening each layer by closing unnecessary network ports and access mechanisms. You also minimize the number of installed software packages so that only those packages required by the system are available. Finally, you secure and insulate the layers from unintended access within the network.
You can implement a Messaging Server proxy server to augment data security. A proxy server placed on the firewall with the Messaging Server behind it prevents attacks on the information on the Messaging Server.
Calendar Server provides a number of security levels to protect users against eavesdropping, unsanctioned usage, or external attack. The basic level of security is through authentication. Calendar Server uses LDAP authentication by default, but also supports the use of an authentication plugin for cases where an alternate means of authentication is desired. Integration with Identity Server enables Calendar Server to take advantage of its single sign-on capability.
Instant Messaging ensures the integrity of communications through its multiple authentication mechanisms and secure SSL connections. Integration with Portal Server and Identity Server bring additional security features, services-based provisioning access policy, user management, and secure remote access.
For more information on security, see the Sun Java System Messaging Server Deployment Planning Guide, the Sun Java System Calendar Server Administration Guide, and the Sun Java System Instant Messaging Deployment Planning Guide.
Note
To ensure a completely security environment, the deployment needs a time server to synchronize the internal clocks of the hosts being secured.
Network Security
The recommended deployment configuration, to support both horizontal scalability and service security, is to place the access layer of the architecture behind a firewall. In a two-tier architecture, use two firewalls, creating a DMZ. This enables access to the information delivery elements, the calendar and messaging front ends, while protecting the main service elements on the internal network behind a second firewall. Such a configuration also enables the access layer and data layer elements to be scaled independently, accommodating traffic and storage elements.
Operating System Security
Reduce potential risk of security breaches in the operating environment by performing the following, often termed “system hardening:”
- Minimize the size of the operating environment installation. When installing a Sun server in an environment that is exposed to the Internet, or any untrusted network, reduce the Solaris installation to the minimum number of packages necessary to support the applications to be hosted. Achieving minimization in services, libraries, and applications helps increase security by reducing the number of subsystems that must be maintained.
- Track and monitor file system changes. Within systems that require inclusion of security, a file change control and audit tool is indispensable as it tracks changes in files and detects possible intrusion. You can use a product such as Tripwire for Servers, or Solaris Fingerprint Database (available from SunSolve Online).
Application Security
The Communications Services product portfolio provides features that ensure the security and integrity of business communications. Communications Services offer extensive “built-in” security features, such as:
Implementing Secure Connections
Communications Services support security standards such as SSL/TLS, S/MIME, and SAML. SSL/TLS enables all communication between clients and servers to take place inside an encrypted session.Through integration with Portal Server, additional authentication mechanisms are available out-of-the-box, as well as single sign-on capabilities across the applications.
If you want to implement public key data security, you must select mail clients that support public key infrastructure and key choice. Communications Services products are capable, out of the box, of participating in the transmission and storage of messages so encrypted. However, the Webmail client is not capable of generating or decoding the messages.
A more commonly used mechanism for data security protects the data across the wire only (that is, from client to server) by using SSL encryption on the connections used to transmit data between various messaging agents. This solution is not as complete as public key encryption, but is far easier to implement and is supported by many more products and service providers.
What problem does this solve? The enterprise assumes that it controls its own corporate network and that data transmitted on that network is safe from non-employees. Mail sent to anyone from outside the corporate network using the corporation’s infrastructure transmits the data over an encrypted connection to the corporation’s network. Likewise, all mail picked up by a corporate user from outside the corporate network will be transmitted over an encrypted connection. Thus, if the enterprise’s assumption about the safety of the internal network is true, and its employees use only sanctioned servers for transmission between themselves and other employees, mail between employees is safe from external attack.
What doesn’t this solution solve? First of all, this approach does not protect the data from unintended viewing by non-intended recipients of the data who have access to the enterprise’s internal network. Secondly, there is no protection offered for data being transmitted between employees and their external partners, customers, or suppliers. The data travels across the public Internet in a completely insecure fashion.
However, this problem can be remedied by configuring SSL encryption between MTA routers at both the enterprise’s and customer’s network. This type of solution requires setup for each private connection you want to use. In so doing, you add an important additional layer of security with customer or partner data being sent or received via email. Using Communications Services’ MTA and SSL, companies can save money by using the public Internet as the transport, but force the MTAs to use SSL for their partners. This solution does not take into account other network traffic to and from partners. Nevertheless, mail is usually a large proportion of the traffic, and because companies can pay based on data transmitted, using the public Internet is usually cheaper.
Implementing Secure Connections Using Two Different Certificate Authorities (CAs)
You can implement SSL connections between server and clients, for example, from Messaging Server, and to other servers in your deployment as well (Web Server, Calendar Server, Directory Server). If desired, you can use two different Certificate Authorities (CAs), one for the server and one for the client.
In such a scenario, you can use one CA to issue server certificates, and another CA to issue client certificates. If you want the client to accept the server’s certificate as genuine, you will need to load the CA certificate for the server into the client’s cert DB. If you want the server to accept the client as genuine, you will need to load the CA certificate for the client into the server’s cert DB.
