Novell GROUPWISE 7 - MESSAGE TRANSFERT AGENT User manual

Message Transfer Agent
X
novdocx (en) 11 December 2007
603
X
Message Transfer Agent
Chapter 40, “Understanding Message Transfer between Domains and Post Offices,” on
page 605
Chapter 41, “Configuring the MTA,” on page 613
Chapter 42, “Monitoring the MTA,” on page 645
Chapter 43, “Optimizing the MTA,” on page 675
Chapter 44, “Using MTA Startup Switches,” on page 683

604 GroupWise 7 Administration Guide
novdocx (en) 11 December 2007

Understanding Message Transfer between Domains and Post Offices
40
novdocx (en) 11 December 2007
605
40
Understanding Message Transfer
between Domains and Post
Offices
A domain organizes post offices into a logical grouping for addressing, routing, and administration
purposes in your GroupWise®system. Messages are transferred between post offices and domains
by the Message Transfer Agent (MTA). The following topics help you understand domains and the
functions of the MTA:
Section 40.1, “Domain Representation in ConsoleOne,” on page 605
Section 40.2, “Domain Directory Structure,” on page 606
Section 40.3, “Information Stored in the Domain,” on page 606
Section 40.4, “Role of the Message Transfer Agent,” on page 608
Section 40.5, “Link Configuration between Domains and Post Offices,” on page 608
Section 40.6, “Message Flow between Domains and Post Offices,” on page 608
Section 40.7, “Cross-Platform Issues between Domains and Post Offices,” on page 609
40.1 Domain Representation in ConsoleOne
In ConsoleOne®, domains are container objects that contain an MTA object, as well as other
domain-related objects, as shown below:
Figure 40-1 ConsoleOne View Showing the MTA Object
Although each post office is linked to a domain, it does not display as subordinate to the domain in
the Console View. However, using the GroupWise View, you can display post offices as subordinate
to the domains to which they are linked in your GroupWise system.

606 GroupWise 7 Administration Guide
novdocx (en) 11 December 2007
Figure 40-2 GroupWise View Showing Post Offices in Relationship to Domains
40.2 Domain Directory Structure
Physically, a domain consists of a set of directories that house all the information stored in the
domain. See “Domain Directory” in GroupWise 7 Troubleshooting 3: Message Flow and Directory
Structure.
40.3 Information Stored in the Domain
The following types of information are stored in the domain:
Section 40.3.1, “Domain Database,” on page 606
Section 40.3.2, “Agent Input/Output Queues in the Domain,” on page 607
Section 40.3.3, “Gateways,” on page 607
No messages are stored in the domain, so GroupWise client users do not need access to the domain
directory. The only person who needs file access to the domain directory is the GroupWise
administrator.
40.3.1 Domain Database
The domain database (wpdomain.db) contains all administrative information for the domain,
including:
Address information about all GroupWise objects (such as users, resources, post offices, and
gateways in the domain)
System configuration and linking information for the domain’s MTA
Address and message routing information to other domains
The first domain you create is the primary domain. In the primary domain, the wpdomain.db file
contains all administrative information for your entire GroupWise system (all its domains, post
offices, users, and so on). Because the wpdomain.db file in the primary domain is so crucial, you
should back it up regularly and keep it secure. See Section 31.1, “Backing Up a Domain,” on
page 407.

Understanding Message Transfer between Domains and Post Offices 607
novdocx (en) 11 December 2007
You can re-create your entire GroupWise system from the primary domain wpdomain.db file;
however, if the primary domain wpdomain.db file becomes unusable, you can no longer make
administrative updates to your GroupWise system.
Secondary domains are automatically synchronized to match the primary domain.
40.3.2 Agent Input/Output Queues in the Domain
Each domain contains agent input/output queues where messages are deposited and picked up for
processing by the MTA.
For a mapped or UNC link between domains, the MTA requires read/write access rights to its input/
output queues in the other domains. For a TCP/IP link, no access rights are required because
messages are communicated by way of TCP/IP.
For illustrations of the processes presented below, see Section 40.6, “Message Flow between
Domains and Post Offices,” on page 608.
MTA Input Queue in the Domain
The MTA input queue in the local domain (domain\wpcsin) is where MTAs for other domains
deposit user messages for the local MTA to route to local post offices or to route to other domains.
Thus the MTA input queue in the local domain is the output queue for the MTAs in many other
domains.
The MTA does not have an output queue for user messages in the local domain. Because its primary
task is routing messages, the local MTA has output queues in all post offices in the domain. See
“POA Input Queue in the Post Office” on page 467. The local MTA also has output queues in all
domains to which it is directly linked.
MTA Output Queue in the Domain
The MTA output queue in the local domain (domain\wpcsout\ads) is where the MTA deposits
administrative messages from other domains for the MTA admin thread to pick up.
MTA Admin Thread Input Queue in the Domain
The MTA admin thread input queue (domain\wpcsout\ads) is, of course, the same as the MTA
output queue in the local domain. The MTA admin thread picks up administrative messages
deposited in the queue by the MTA and updates the domain database.
MTA Admin Thread Output Queue in the Domain
The MTA admin thread output queue (domain\wpcsin) is the same as the MTA input queue in
the local domain. The MTA admin thread deposits administrative messages in the queue for
replication to other domains.
40.3.3 Gateways
Gateways are installed and configured at the domain level of your GroupWise system. For a list of
gateways, see the GroupWise Gateways Documentation Web site (http://www.novell.com/
documentation/gwgateways).

608 GroupWise 7 Administration Guide
novdocx (en) 11 December 2007
40.4 Role of the Message Transfer Agent
You must run an MTA for each domain. The MTA:
Routes messages between post offices in the local domain.
Routes messages between domains.
Routes messages to and from gateways installed in the local domain.
Routes messages between GroupWise systems across the Internet if appropriate DNS lookup
capabilities have been set up. See “Using Dynamic Internet Links” in “Connecting to
GroupWise 5.x, 6.x, and 7.x Systems” in the GroupWise 7 Multi-System Administration Guide.
Schedules routing of messages across expensive links. See Section 41.3.2, “Scheduling Direct
Domain Links,” on page 633.
Controls the size of messages that can pass across links. See Section 41.2.1, “Restricting
Message Size between Domains,” on page 628.
Updates the domain database (wpdomain.db) whenever GroupWise users, resources, post
offices, or other GroupWise objects are added, modified, or deleted.
Replicates updates to all domains and post offices throughout your GroupWise system. This
keeps the Address Book up to date for all GroupWise users.
Synchronizes GroupWise user information with Novell®eDirectoryTM user information. This
handles updates made in ConsoleOne without the GroupWise Administrator snap-in running.
See Section 41.4.1, “Using eDirectory User Synchronization,” on page 638.
Synchronizes GroupWise object information throughout your GroupWise system as needed.
Detects and repairs invalid information in the domain database (wpdomain.db).
Provides improved performance for GroupWise Remote client users. See Section 41.2.2,
“Enabling Live Remote,” on page 629.
Provides logging and statistics about GroupWise message flow. See Section 41.4.2, “Enabling
MTA Message Logging,” on page 643.
40.5 Link Configuration between Domains and
Post Offices
In GroupWise, a link is defined as the information required to route messages between domains,
post offices, and gateways in a GroupWise system. Links are created and configured when new
domains, post offices, and gateways are created.
For more specific information about how domains are linked to each other, and about how domains
and post offices are linked, see Chapter 10, “Managing the Links between Domains and Post
Offices,” on page 137.
40.6 Message Flow between Domains and Post
Offices
Section 40.6.1, “Message Flow between Post Offices in the Same Domain,” on page 609
Section 40.6.2, “Message Flow between Different Domains,” on page 609

Understanding Message Transfer between Domains and Post Offices 609
novdocx (en) 11 December 2007
40.6.1 Message Flow between Post Offices in the Same
Domain
To see what happens to message flow within the domain when the domain is closed, view the
following message flow diagrams:
“TCP/IP Link Open: Transfer between Post Offices Successful”
“TCP/IP Link Closed: Transfer between Post Offices Delayed”
These diagrams are found in “Message Delivery to a Different Post Office” in GroupWise 7
Troubleshooting 3: Message Flow and Directory Structure. If you are using mapped/UNC links,
refer to GroupWise 6.5 Troubleshooting 3: Message Flow and Directory Structure.
40.6.2 Message Flow between Different Domains
To see what happens to message flow when the destination domain is closed, view the following
message flow diagrams:
“TCP/IP Link Open: Transfer between Domains Successful”
“TCP/IP Link Closed: Transfer between Domains Delayed”
These diagrams are found in “Message Delivery to a Different Domain” in GroupWise 7
Troubleshooting 3: Message Flow and Directory Structure. If you are using mapped/UNC links,
refer to GroupWise 6.5 Troubleshooting 3: Message Flow and Directory Structure.
40.7 Cross-Platform Issues between Domains
and Post Offices
Domains can be located on the following platforms:
Novell NetWare®
Windows Server
Linux
The GroupWise agents can run on the following platforms:
Novell NetWare
Windows Server
Linux
In general, GroupWise is most efficient if you match the agent platform with the network operating
system. Ideally, the MTA as well as the domain and post offices should be on the same platform.
However, those with mixed networks may wonder what combinations are possible. You have several
alternatives.
Section 40.7.1, “MTA Platform Dependencies Because of Direct Access Requirements to Post
Offices,” on page 610
Section 40.7.2, “MTA/Post Office Platform Independence through TCP/IP Links,” on page 610
Section 40.7.3, “MTA Platform Dependencies Because of Direct Access Requirements to the
Domain,” on page 610

610 GroupWise 7 Administration Guide
novdocx (en) 11 December 2007
Section 40.7.4, “MTA/Domain Platform Independence through TCP/IP Links,” on page 611
Section 40.7.5, “MTA/Domain Platform Independence through the Transfer Pull
Configuration,” on page 611
40.7.1 MTA Platform Dependencies Because of Direct Access
Requirements to Post Offices
The MTA must always have direct access to the domain directory. In addition, if using mapped or
UNC links to post offices, the MTA must have direct access to each post office directory as well. If
the MTA is installed on a remote server, it must be able to log in to servers where the post offices are
located.
The table below summarizes the various combinations of MTA and post office platforms, and
indicates which combinations work for direct access and which ones do not:
Table 40-1 MTA Platforms and Post Office Platforms
1TCP/IP links are required between the MTA and the POA on Linux. Direct access to post offices is
not available.
2The NetWare MTA cannot service a domain or post office on a Windows server because Windows
does not support the required cross-platform connection.
3Domains and post offices cannot be created on Macintosh computers.
40.7.2 MTA/Post Office Platform Independence through TCP/IP
Links
To overcome platform dependencies for post offices, create a TCP/IP link for any post office located
on a platform where the domain MTA cannot gain direct access. See “Using TCP/IP Links between
a Domain and its Post Offices” on page 623.
40.7.3 MTA Platform Dependencies Because of Direct Access
Requirements to the Domain
If using mapped or UNC links between domains, the source domain MTA must have direct access to
its input queues in the destination domain directory. If the MTA is installed on a remote server, it
must be able to log in to the server where its domain located.
NetWare MTA Linux MTA Windows MTA
Post Office on NetWare Yes No1Yes
Post Office on Linux No1No1No1
Post Office on Windows No2No1Yes
Post Office on
Macintosh
No3No3No3

Understanding Message Transfer between Domains and Post Offices 611
novdocx (en) 11 December 2007
The table below summarizes the various combinations of the platform of MTA for the source
domain and the platform where the destination domain is located, and indicates which combinations
work for direct access and which ones do not:
Table 40-2 MTA Platforms and Domain Platforms
1TCP/IP links are required between MTAs in GroupWise 7. Direct access to other domains is not
available.
2The NetWare MTA cannot write message files into its output queue in a destination domain on a
Windows server because Windows does not support the required cross-platform connection.
3Domains cannot be created on Macintosh computers.
40.7.4 MTA/Domain Platform Independence through TCP/IP
Links
To overcome platform dependencies between domains, use TCP/IP links between domains. See
Section , “Using TCP/IP Links between Domains,” on page 618.
40.7.5 MTA/Domain Platform Independence through the
Transfer Pull Configuration
If TCP/IP is not available, another alternative for overcoming platform dependencies is a transfer
pull configuration.
By default the MTA “pushes” message files out to destination domains by writing them into its
output queue in each destination domain. One situation where this method does not work is for the
NetWare MTA on a NetWare server to write message files to its input queue in a destination domain
located on a Windows server.
As an alternative, you can have the Windows MTA for the destination domain “pull” the message
files from the source domain on the NetWare server. This is called a transfer pull configuration. See
Section 41.3.3, “Using a Transfer Pull Configuration,” on page 636 for setup instructions.
NetWare MTA for
Source Domain
Linux MTA for Source
Domain
Windows MTA for Source
Domain
Destination Domain on
NetWare
Yes No1Yes
Destination Domain on
Linux
No1No1No3
Destination Domain on
Windows
No2No1Yes
Destination Domain on
Macintosh
No3No3No3

612 GroupWise 7 Administration Guide
novdocx (en) 11 December 2007