Chapter 7. Message Transfer Agent Configuration
This chapter provides best practices and techniques regarding the setup and configuration of the Message Transfer Agent (MTA) component within the Messaging Server. Due to its complexity, this is an area that can cause significant issues related to security as well as basic functionality. This section dissects the default “out-of-the-box” MTA configuration file to provide a starting point for the reader. Many users of the previous versions of Sun Internet Mail Server (SIMS) or Netscape Messaging Server (NMS) had never seen an Innosoft PMDF product MTA configuration file. Therefore, this area is very intimidating and confusing. This chapter addresses some typical changes in plain English. For a more detailed discussion of issues such as antivirus checking and antispam processing, refer to and “Virus Scanning” on page 198 and “Antispam” on page 199.
This chapter contains a brief overview of the MTA and covers the following topics:
Changing the Mappings
Direct LDAP Lookup
Adding New Domains to the MTA
SMTP Authentication
First, a little history of the MTA that is within the Messaging Server. In March 2000, Sun Microsystems purchased a software company called Innosoft International. Innosoft International was the vendor of a mail product called PMDF. PMDF ran on a variety of platforms including the Solaris OE and VMS and was well respected with regard to performance, stability, scalability, and security.
During the course of the next two years, Sun integrated PMDF into the current version of the messaging product, starting with Messaging Server v5.0. But even before that Sun had OEMed the MTA portion of the PMDF product and it is used in SIMS version 3.5 and 4.0. So people have seen some of the PMDF configuration files in disguise. Administrators who are familiar with PMDF will feel right at home. Those who are not familiar with PMDF will have a little bit of a learning curve to climb.
PMDF was more than just the MTA, it had a message store (it was actually two message stores on VMS, and two on UNIX, one native, and one also based on the Carnegie Mellon University Cyrus mail program). It is a mail interconnect that talks many protocols, such as X.400, and talks to many PC mail systems. The MTA is where 50 percent of the configuration and options are within the mail system—it touches every single message that comes into or goes out of the messaging system.
Now for some basics………
Some people may be familiar with the term MTA. In reality, this is fancy terminology for message router.
According to the Telecom Glossary 2000:
message transfer agent (MTA): An OSI application process used to store and forward messages as described in the X.400 message handling system synonym Internet, also known as a mail agent.
Just as an Ethernet router makes sure packets go where they are supposed to go and keeps them from going where they are not supposed to go, the MTA performs this function for messaging systems. One of the key points to note in the definition is “store and forward.” The MTA does not simply forward or route, but stores a copy locally until it is sure that it has passed the message along or rejected it.
The basic MTA function of receiving and forwarding messages is performed in conjunction with information found in the directory. The MTA is a standalone daemon, and while required on the mail store, it can actually run by itself on a separate server. See Chapter 3, “Messaging Architectures,” on page 15.
Out of the box the MTA is pretty plain, yet secure, in its configuration. However, there are several changes that organizations frequently make.
Typical changes include:
Changing the definition (mapping) of what is local and what is not local
Enabling direct LDAP lookup
Accepting alternative domains
Requiring SMTP authentication
Rewriting domains