Best Practices

Following are some practices that have been observed to improve the performance and stability of the GroupWise MTA. They are not hard-and-fast rules, however, and anything published by Novell should likely take precedence.

System Design

Keep in mind that you can have an MTA only where you have a domain. This means that if your system has some natural transfer points (such as on the segment with an edge-router, or at the firewall), you might want to consider putting a domain there so that there will be an MTA at that point.

Assume that you will be building a large system and will be using occasional indirect connections. Here are a couple of rules of thumb:

• Avoid putting any post offices under the primary domain, and don't use the primary domain as a hub for indirectly connected domains.

• If you have more than one domain on a LAN, those domains should all connect directly via IP. The MTAs can handle this easily. Thus, LAN connections should be mesh style.

• If you have multiple LANs as part of a wide area network, consider having one domain at the edge of each LAN acting as a hub for indirect connections between that LAN's domains and others.

• If you have busy gateways (such as the GWIA, which will be covered in the next chapter), you might want to consider devoting a domain (and, therefore, an MTA) to those gateways.

Remember, even though MTAs can communicate directly with any other MTA with a valid IP address, this is not always the best way to connect, especially where there are many router hops between them. Because packets are going to be stored and forwarded on these long routes, you should consider having the MTA store and forward the messages (by using indirect connections). This way you will be less likely to have problems with TCP connection timeouts, and your message transfers will be more efficient.

TCP/IP Versus UNC Links

TCP/IP links between MTAs or between the MTA and the POA are always preferred. This is true even when the MTA and the POA are on the same server. Here's why: When a link between the MTA and the POA is UNC, messages are queued, and then discovered via a polling cycle. The queuing and polling process causes messages to flow at a slower rate than when messages are sent via TCP/IP. The Linux MTA will support only TCP/IP links.

Moving MTAs to New IP Addresses or Ports

First of all, if you are moving an MTA to a new IP address, it is probably because you are moving the entire domain directory to a new server. If that is the case, review Chapter 20, "Troubleshooting Message Flow," for the complete procedure.

Perhaps, though, all you are doing is moving the file server to a new LAN segment and assigning it a new IP address. Here is the procedure you should follow:

1.	Connect to the domain that is being moved.
2.	Change the MTA object's network address to reflect the new address or port. Connections between other domains and this one will now start to drop off. Other domains, and this domain's post office, will show this domain as closed.
3.	Unload the MTA.
4.	Move the server to the new address and/or port, making the appropriate address or port changes at the server level.
5.	Reload the MTA. Check the connection to this MTA from other MTAs on the system, and from this domain's post office's POAs. The connections should begin opening, now that they "see" this MTA at the new address and/or port.

These are just a few simple steps, but they are essential for connectivity.

Tuning the MTA

Typically, a busy MTA needs little tuning to keep up with its queues. If TCP/IP links are used exclusively, the MTA will not need to waste CPU cycles polling or maintaining idle connections and will have the resources it needs.

You might find, however, that some types of messages need to be moved faster than others. Remote users and users making busy searches both use the high-priority queues. To weigh these queues a little more heavily, check the Use 2nd High Priority Router box found on the Agent Settings tab of the MTA detail window. This will spawn an additional thread for the 0 and 1 subdirectories. The more connections the MTA services, the more threads will be spawned. If the server is having trouble keeping up with queues, this will mean that the mail priority queues (27) will back up even further, whereas the 0 and 1 are processed more quickly.

On large systems, an MTA on a Pentium IIclass server should be able to process at least 100,000 messages each day without noticeable backups in any of the queues. Some administrators have seen MTAs that process three times that many messages in a day.