This section describes some common Communications Suite deployment best practices and other deployment considerations.
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:
Reduces the load on the stores. Relays are horizontally scalable while stores are not, thus it is a good practice to make the relays perform as much of the processing as possible.
Reduces IOPS by as much as 30 percent by removing the MTA queues from the stores.
Reduces the load on LDAP servers.
The LDAP infrastructure is often the limiting factor in large messaging deployments.
Reduces the number of message queues.
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.
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.
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.
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 NamesTable 5–2 Maintenance Level Logical Names
Example |
Description |
---|---|
relay-in.siroe.com |
Corresponds to a bank of inbound SMTP servers. |
relay-out.siroe.com |
Corresponds to a bank of outbound SMTP servers. |
mmp.siroe.com |
Corresponds to a bank of MMP servers. |
storeAA.siroe.com |
Back-end message store. Select a naming scheme to work with your topology, for example, storeAA.siroe.com through storeZZ.siroe.com. |
calstoreAA.siroe.com |
Back-end calendar store. Select naming scheme to work with topology, for example, calstoreAA.siroe.com through calstoreZZ.siroe.com. |
Table 5–3 Mapping of User Level to Maintenance Level Logical Names
Maintenance Level |
User Level |
---|---|
relay-in.siroe.com |
N/A |
relay-out.siroe.com |
smtp.siroe.com |
mmp.siroe.com |
Any one or more of mmp.siroe.com, pop.siroe.com, and imap.siroe.com |
storeAA.siroe.com - storeZZ.siroe.com |
N/A, hidden from end users |
calstore_aa.siroe.com - calstore_az.siroe.com |
N/A, hidden from end users |