Sun Java Communications Suite 5 Deployment Planning Guide

Other Deployment Issues

This section describes some common Communications Suite deployment best practices and other deployment considerations.

Implementing Local Message Transfer Protocol (LMTP) for Messaging Server

Best practices say you should implement LMTP to replace SMTP for message insertion. An LMTP architecture is more efficient for delivering to the back-end Message Store because it:

You need a two-tiered architecture to implement LMTP. See To Configure LMTP Delivery in Sun Java System Messaging Server 6.3 Administration Guide for instructions on configuring LMTP.

Note –

By design, LMTP is intended for use in multi-tier deployments. It is not possible to use LMTP with single-system deployments. Also, the Messaging Server's LMTP service as implemented is not designed to work with other LMTP servers or other LMTP clients.

Implementing Realtime Blackhole List (RBL)

The Mail Abuse Protection System’s Realtime Blackhole List (MAPS RBL) is a dynamically updated list of known unsolicited bulk email (UBE) sources identified by source IP address. The Messaging Server SMTP server supports use of the RBL and can reject mail coming from sources identified by the RBL as originators of UBE or spam.

Implementing an RBL should be a consideration of every deployment. In general, a good RBL deployed in front of MTAs reduces traffic to the MTAs by a minimum of 10 percent, and in some cases, much higher.

RBLs, and anti-spam and anti-virus servers, such as BrightMail, can work together. For example, if your anti-spam server rejects 95 to 99 out of 100 emails from a particular IP address, you can add that IP address to the RBL. You can also adjust the RBL for BrightMail’s false positives when you conduct your BrightMail analysis. Thus, you make the RBL much more proactive in handling a specific wave of UBE.

See Sun Java System Messaging Server 6.3 Administration Reference for information on configuring the ENABLE_RBL option of the MTA Dispatcher.

Using Logical Service Names

Design your deployment around the use of logical names for Communications Suite servers. You should use logical names even on a single-system deployment, to position it for ease of future growth and expansion. Using logical names does not impose any additional deployment setup costs other than populating your DNS.

You can think of these logical names as falling into two categories: those that affect end users, such as settings in email client programs; and those affecting back-end administration, such as inbound SMTP servers.

The following tables describes these logical entities.

Table 5–1 User Facing Logical Names



Name of the server from which end users collect their email.

Name of the IMAP server from which end users collect their email.

Name of the POP server from which the end users collect their email.

Name of the SMTP server users set as outgoing mail server. or

Name of the Communications Express (formerly Calendar Express) server. 

Table 5–2 Maintenance Level Logical Names



Corresponds to a bank of inbound SMTP servers.

Corresponds to a bank of outbound SMTP servers.

Corresponds to a bank of MMP servers.

Back-end message store. Select a naming scheme to work with your topology, for example, through

Back-end calendar store. Select naming scheme to work with topology, for example, through

Table 5–3 Mapping of User Level to Maintenance Level Logical Names

Maintenance Level  

User Level


Any one or more of,, and -

N/A, hidden from end users -

N/A, hidden from end users