Novell GROUPWISE 7 - MESSAGE TRANSFERT AGENT, GroupWise 7 Message Transfer Agent User Manual

Download

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

novdocx (en) 11 December 2007

Message Transfer Agent

603

novdocx (en) 11 December 2007

604 GroupWise 7 Administration Guide

Understanding Message Transfer

novdocx (en) 11 December 2007

between Domains and Post Offices

A domain organizes post offices into a logical grouping for addressing, routing, and administration purposes in your GroupWise 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

system. Messages are transferred between post offices and domains

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.

Understanding Message Transfer between Domains and Post Offices

605

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.

novdocx (en) 11 December 2007

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.

606 GroupWise 7 Administration Guide

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

novdocx (en) 11 December 2007

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).

Understanding Message Transfer between Domains and Post Offices 607

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

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.

eDirectoryTM user information. This

novdocx (en) 11 December 2007

 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

608 GroupWise 7 Administration Guide

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”

novdocx (en) 11 December 2007

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

Understanding Message Transfer between Domains and Post Offices 609

 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

NetWare MTA Linux MTA Windows MTA

novdocx (en) 11 December 2007

Yes

Post Office on NetWare Yes No

Post Office on Linux No

Post Office on Windows No

Post Office on Macintosh

TCP/IP links are required between the MTA and the POA on Linux. Direct access to post offices is

not available.

The NetWare MTA cannot service a domain or post office on a Windows server because Windows

does not support the required cross-platform connection.

Domains 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.

610 GroupWise 7 Administration Guide

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

novdocx (en) 11 December 2007

NetWare MTA for Source Domain

Destination Domain on NetWare

Destination Domain on Linux

Destination Domain on Windows

Destination Domain on Macintosh

TCP/IP links are required between MTAs in GroupWise 7. Direct access to other domains is not

Yes No

Linux MTA for Source Domain

Windows MTA for Source Domain

Yes

available.

The 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.

Domains 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.

Understanding Message Transfer between Domains and Post Offices 611

novdocx (en) 11 December 2007

612 GroupWise 7 Administration Guide

Configuring the MTA

For detailed instructions about installing and starting the MTA for the first time, see “Installing

GroupWise Agents” in the GroupWise 7 Installation Guide.

As your GroupWise configuration to meet changing system needs. The following topics help you configure the MTA:

system grows and evolves, you will probably need to modify MTA

novdocx (en) 11 December 2007

 Section 41.1, “Performing

Basic MTA Configuration,” on page 613

 Section 41.2, “Configuring

User Access through the Domain,” on page 628

 Section 41.3, “Configuring

Specialized Routing,” on page 631

 Section 41.4, “Configuring

Domain Maintenance,” on page 638

Creating an MTA Object in eDirectory Configuring the MTA in ConsoleOne Changing the Link Protocol between Domains Changing the Link Protocol between a Domain and Its Post Offices Binding the MTA to a Specific IP Address Moving the MTA to a Different Server Adjusting the MTA for a New Location of a Domain or Post Office Adjusting the MTA Logging Level and Other Log Settings

Restricting Message Size between Domains Enabling Live Remote Securing the Domain with SSL Connections to the MTA

Using Routing Domains Scheduling Direct Domain Links Using a Transfer Pull Configuration

Using eDirectory User Synchronization Enabling MTA Message Logging

41.1 Performing Basic MTA Configuration

MTA configuration information is stored as properties of its MTA object in eDirectoryTM. The following topics help you modify the MTA object in ConsoleOne to meet changing system configurations:

and change MTA configuration

 Section 41.1.1, “Creating an MTA Object in eDirectory,” on page 614

 Section 41.1.2, “Configuring the MTA in ConsoleOne,” on page 615

 Section 41.1.3, “Changing the Link Protocol between Domains,” on page 618

 Section 41.1.4, “Changing the Link Protocol between a Domain and Its Post Offices,” on

page 622

 Section 41.1.5, “Binding the MTA to a Specific IP Address,” on page 625

 Section 41.1.6, “Moving the MTA to a Different Server,” on page 626

 Section 41.1.7, “Adjusting the MTA for a New Location of a Domain or Post Office,” on

page 626

 Section 41.1.8, “Adjusting the MTA Logging Level and Other Log Settings,” on page 627

Configuring the MTA

613

41.1.1 Creating an MTA Object in eDirectory

When you create a new domain, an MTA object is automatically created for it. If the original MTA object for a domain gets accidently deleted, you can create a new one for it. Do not attempt to create more than one MTA object for a domain.

To create a new MTA object in Novell

1 In ConsoleOne, browse to and right-click the Domain object for which you need to create an

MTA object, then click New.

2 Double-click GroupWise Agent to display the Create GroupWise Agent dialog box.

eDirectory:

novdocx (en) 11 December 2007

3 Type a unique name for the new MTA. The name can include as many as 8 characters. Do not

use any of the following invalid characters in the name:

ASCII characters 0-13 Comma ,

Asterisk * Double quote "

At sign @ Extended ASCII characters that are graphical or typographical

symbols; accented characters in the extended range can be used

Braces { } Parentheses ( )

Colon : Period .

The Type field is automatically set to Message Transfer.

4 Select Define Additional Properties.

5 Click OK.

The MTA object is automatically placed within the Domain object.

6 Review the information displayed for the first four fields on the Identification page to ensure

that you are creating the correct type of Agent object in the correct location.

614 GroupWise 7 Administration Guide

7 In the Description field, type one or more lines of text describing the MTA. This description

displays on the MTA server console as the MTA runs.

novdocx (en) 11 December 2007

If multiple administrators work at the server where the MTA will run, the description includes a note about who to contact before stopping the MTA. When running multiple MTAs on the same server, the description should uniquely identify each one. See Chapter 42, “Monitoring the

MTA,” on page 645.

8 In the Platform field, select the platform (NetWare, Linux, or Windows) where the MTA will

run.

9 Continue with Section 41.1.2, “Configuring the MTA in ConsoleOne,” on page 615.

41.1.2 Configuring the MTA in ConsoleOne

The advantage to configuring the MTA in ConsoleOne, as opposed to using startup switches in an MTA startup file, is that the MTA configuration settings are stored in eDirectory.

1 In ConsoleOne, expand the eDirectory container where the Domain object is located.

2 Expand the Domain object.

3 Right-click the MTA object, then click Properties.

Configuring the MTA 615

The table below summarizes the MTA configuration settings in the MTA object properties pages and how they correspond to MTA startup switches (as described in Chapter 44, “Using MTA Startup

Switches,” on page 683):

novdocx (en) 11 December 2007

Table 41-1 MTA Configuration Settings

ConsoleOne Properties Pages and Settings

Information Page

Domain Distinguished Name Name Agent Type Description Platform

Agent Settings Page

Scan Cycle Scan High

Attach Retry See Section 43.4, “Adjusting MTA Polling of Closed Locations,” on

Enable Automatic Database

Recovery

Use 2nd High Priority Scanner Use 2nd Mail Priority Scanner

Corresponding Tasks and Startup Switches

See Section 41.1.1, “Creating an MTA Object in eDirectory,” on

page 614.

See Section 43.2.2, “Adjusting MTA Polling of Input Queues in the

Domain, Post Offices, and Gateways,” on page 676.

See also /nodns.

Configuring the MTA 617

novdocx (en) 11 December 2007

ConsoleOne Properties Pages and Settings

Certificate File SSL Key File Password

Corresponding Tasks and Startup Switches

See Section 41.2.3, “Securing the Domain with SSL Connections

to the MTA,” on page 629.

See also /certfile, /keyfile and /keypassword.

After you install the MTA software, you can further configure the MTA using a startup file. To survey the many ways the MTA can be configured, see Chapter 44, “Using MTA Startup Switches,”

on page 683.

41.1.3 Changing the Link Protocol between Domains

How MTAs for different domains communicate with each other is determined by the link protocol in use between the domains. Typically, inbound and outbound links for a domain use the same link protocol, but this is not required. For a review of link protocols, see Section 10.1.3, “Link Protocols

for Direct Links,” on page 141.

If you originally set up an MTA using one link protocol and need to change to a different one, some reconfiguration of the MTA is necessary.

 “Using TCP/IP Links between Domains” on page 618

 “Using Mapped or UNC Links between Domains” on page 621

 “Using Gateway Links between Domains” on page 622

NOTE: The Linux MTA does not support mapped or UNC links between domains. TCP/IP links are required.

Using TCP/IP Links between Domains

To set up TCP/IP links between domains, you must perform the following two tasks:

 “Configuring the MTA for TCP/IP” on page 618

 “Changing the Link Protocol between Domains to TCP/IP” on page 620

Configuring the MTA for TCP/IP

1 Make sure TCP/IP is properly set up on the server where the MTA is running.

2 In ConsoleOne, browse to and right-click the MTA object, then click Properties.

3 Click GroupWise > Network Address to display the Network Address page.

618 GroupWise 7 Administration Guide

4 On the Network Address page, click the pencil icon for the TCP/IP Address field to display the

Edit Network Address dialog box.

novdocx (en) 11 December 2007

5 Select IP Address, then provide the IP address, in dotted decimal format, of the server where

the MTA is running.

Select DNS Host Name, then provide the DNS hostname of the server where the MTA is running.

IMPORTANT: The MTA must run on a server that has a static IP address. DHCP cannot be used to dynamically assign an IP address for it.

Specifying the DNS hostname rather than the IP address makes it easier to move the MTA from one server to another, should the need arise at a later time. You can assign a new IP address to the hostname in DNS, without changing the MTA configuration information in ConsoleOne.

6 Click OK.

7 To use a TCP port number other than the default port of 7100, type the port number in the

Message Transfer Port field.

If multiple MTAs will run on the same server, each MTA must have a unique TCP port number.

8 For optimum security, select Enabled in the SSL drop-down list for the message transfer port.

For more information, see Section 41.2.3, “Securing the Domain with SSL Connections to the

MTA,” on page 629.

9 Click OK to save the network address and return to the main ConsoleOne window.

ConsoleOne then notifies the MTA to restart enabled for TCP/IP.

Configuring the MTA 619

Corresponding Startup Switches You can also use the /ip and /tcpport switches in the MTA startup file to provide the IP address and

the message transfer port number.

MTA Web Console

You can view the MTA TCP/IP information on the Configuration page under the TCP/IP Settings heading.

Changing the Link Protocol between Domains to TCP/IP

Make sure you have configured the MTA for TCP/IP at both ends of each link.

To change the link between the domains from mapped or UNC to TCP/IP:

1 In ConsoleOne, click Tools > GroupWise Utilities > Link Configuration.

2 Click View > Domain Links to display domain links.

novdocx (en) 11 December 2007

3 Select the MTA’s local domain in the drop-down list.

Outbound and inbound links for the selected domain are listed.

4 Double-click a domain in the Outbound Links list.

5 Set Link Type to Direct.

6 Set Protocol to TCP/IP.

Make sure the information displayed in the IP Address and MT Port fields matches the information for the MTA for the domain to which you are linking.

620 GroupWise 7 Administration Guide

7 Click OK.

8 Repeat Step 4 through Step 7 for each domain in the Outbound Links list where you want the

MTA to use a TCP/IP link.

Selecting multiple domains is also allowed.

9 Double-click a domain in the Inbound Links list.

10 Set Link Type to Direct.

11 Set Protocol to TCP/IP.

Make sure the information displayed in the IP Address and MT Port fields matches the information you supplied in “Configuring the MTA for TCP/IP” on page 618.

12 Click OK.

13 Repeat Step 9 through Step 12 for each domain in the Inbound Links list where you want the

MTA to use a TCP/IP link.

Selecting multiple domains is also allowed.

14 Click File > Exit > Yes to save the link changes.

ConsoleOne then notifies the MTA to restart with the new link configuration.

novdocx (en) 11 December 2007

For a sample message flow for this configuration, see “TCP/IP Link Open: Transfer between

Domains Successful” in “Message Delivery to a Different Domain” in GroupWise 7

Troubleshooting 3: Message Flow and Directory Structure.

Using Mapped or UNC Links between Domains

To change to a mapped or UNC link between domains:

1 In ConsoleOne, click Tools > GroupWise Utilities > Link Configuration.

2 Click Vie w > D o main L i nks to display domain links.

3 Select the MTA’s local domain in the drop-down list.

Outbound and inbound links for the selected domain are listed.

4 Double-click a domain in the Outbound Links list.

5 Set Link Type to Direct.

6 Set Protocol to Mapped or UNC.

7 Enter the full path, in the appropriate format, of the directory where the other domain is

located.

8 Click

OK.

9 Repeat Step 4 through Step 8 for each domain in the Outbound Links list where you want the

MTA to use a mapped or UNC link.

Selecting multiple domains is also allowed.

10 Double-click a domain in the Inbound Links list.

11 Set Link Type to Direct.

12 Set Protocol to Mapped or UNC.

13 Enter the full path, in the appropriate format, of the directory where the local domain is located.

14 Click OK.

Configuring the MTA 621

15 Repeat Step 10 through Step 14 for each domain in the Inbound Links list where you want the

MTA to use a mapped link.

Selecting multiple domains is also allowed.

16 Click File > Exit > Yes to save the link changes.

ConsoleOne then notifies the MTA to restart with the new link configuration.

Using Gateway Links between Domains

You can use GroupWise gateways to link domains within your GroupWise system.

 “Using the Async Gateway to Link Domains” on page 622

 “Using the Internet Agent to Link Domains” on page 622

Using the Async Gateway to Link Domains

You can use the Async Gateway to link a domain into your GroupWise system using a modem. For setup instructions, see the Async Gateway documentation at the GroupWise Gateway

Documentation Web site (http://www.novell.com/documentation/gwgateways).

novdocx (en) 11 December 2007

Using the Internet Agent to Link Domains

You can use the Internet Agent to link a domain into your GroupWise system across the Internet. When you use the Internet Agent as the transport mechanism between domains, it encapsulates GroupWise messages (both e-mail messages and administrative messages) within SMTP messages in order to transport them across the Internet. For setup instructions, see Section 51.2, “Linking

Domains,” on page 810

NOTE: A simpler alternative to a gateway link for spanning the Internet is to use MTA to MTA links, as described for linking separate GroupWise systems in “Using Dynamic Internet Links” in the GroupWise 7 Multi-System Administration Guide. The same configuration that can link two separate GroupWise systems can be employed to link a domain within the same GroupWise system.

41.1.4 Changing the Link Protocol between a Domain and Its Post Offices

How messages are transferred between the MTA for the domain and the POA for each post office is determined by the link protocol in use between the domain and each post office. For a review of link protocols, see Section 10.1.3, “Link Protocols for Direct Links,” on page 141.

If you need to change from one link protocol to another, some reconfiguration of the MTA and its link to each post office is necessary.

 “Using TCP/IP Links between a Domain and its Post Offices” on page 623

 “Using Mapped or UNC Links between a Domain and its Post Offices” on page 625

NOTE: The Linux MTA requires TCP/IP links between a domain and its post offices.

622 GroupWise 7 Administration Guide

Using TCP/IP Links between a Domain and its Post Offices

To change from mapped or UNC links to TCP/IP links between a domain and its post offices, you must perform the following two tasks:

 “Configuring the Agents for TCP/IP” on page 623

 “Changing the Link Protocol between a Domain and its Post Offices to TCP/IP” on page 624

Configuring the Agents for TCP/IP

1 If the MTA for the domain is not yet set up for TCP/IP communication, see “Configuring the

MTA for TCP/IP” on page 618.

2 If any post offices do not yet have a POA set up for TCP/IP communication, see Section 36.2.1,

“Using Client/Server Access to the Post Office,” on page 486 to set up the initial TCP/IP

information.

3 In ConsoleOne, expand the Post Office object to display the POA object(s) in the post office.

Only one POA per post office needs to communicate with the MTA. If the post office has multiple POAs, have a POA that performs message file processing communicate with the MTA for best performance. For information about message file processing, see Section 35.5, “Role

of the Post Office Agent,” on page 469.

novdocx (en) 11 December 2007

4 Right-click the POA object, then click Properties.

5 Click GroupWise > Network Address to display the Network Address page.

6 On the Network Address page, click the pencil icon for the TCP/IP Address field to display the

Edit Network Address dialog box.

Configuring the MTA 623

7 In the Message Transfer Port field, specify a unique TCP port on which the POA will listen for

incoming messages from the MTA.

The default is 7101.

8 For optimum security, select Enabled in the SSL drop-down list for the message transfer port.

For more information, see Section 41.2.3, “Securing the Domain with SSL Connections to the

MTA,” on page 629.

9 Click OK to save the TCP/IP information and return to the main ConsoleOne window.

ConsoleOne then notifies the POA to restart with message transfer processing enabled.

Changing the Link Protocol between a Domain and its Post Offices to TCP/IP

1 In ConsoleOne, click Tools > GroupWise Utilities > Link Configuration.

novdocx (en) 11 December 2007

2 In the drop-down list, select the domain where you want TCP/IP links to post offices.

3 Click View > Post Office Links to display post office links.

4 Double-click a Post Office object.

5 In the Protocol field, select TCP/IP.

624 GroupWise 7 Administration Guide

6 Make sure the information displayed in the Edit Post Office Link dialog box matches the

information provided in the Edit Network Address dialog box in “Configuring the Agents for

TCP/IP” on page 623.

7 Click OK.

8 Repeat Step 4 through Step 7 for each post office in the domain where you want to use TCP/IP

links.

9 To exit the Link Configuration tool and save your changes, click File > Exit > Yes.

ConsoleOne then notifies the MTA and POAs to restart using the new link protocol.

For a sample message flow for this configuration, see “TCP/IP Link Open: Transfer between Post

Offices Successful” in “Message Delivery to a Different Post Office” in GroupWise 7

Troubleshooting 3: Message Flow and Directory Structure.

Using Mapped or UNC Links between a Domain and its Post Offices

To change from a TCP/IP link to a mapped or UNC link between a domain and its post offices:

1 In ConsoleOne, click Tools > GroupWise Utilities > Link Configuration.

2 In the drop-down list, select the domain where the post offices reside.

3 Click View Post Office Links to display post office links.

novdocx (en) 11 December 2007

4 Double-click a Post Office object.

5 In the Protocol field, select Mapped or UNC.

6 Provide the location of the post office in the format appropriate to the selected protocol.

7 Click OK.

8 Repeat Step 4 through Step 7 for each post office in the domain.

9 To exit the Link Configuration tool and save your changes, click File > Exit > Yes.

ConsoleOne then notifies the POA and MTA to restart using the new link protocol.

41.1.5 Binding the MTA to a Specific IP Address

If the MTA runs on a server that has multiple IP addresses, you can cause the MTA to bind to a specific IP address. The specified IP address is associated with all ports used by the MTA. Without an exclusive bind, the MTA binds to all IP addresses available on the server.

1 In ConsoleOne, expand the Domain object to display the MTA object in the post office.

2 Right-click the MTA object, then click Properties.

3 Click GroupWise > Network Address to display the Network Address page.

4 If the TCP/IP Address field does not yet display the IP address you want the MTA to use:

4a Click the pencil icon for the TCP/IP Address field to display the Edit Network Address

dialog box.

4b Specify the IP address for the MTA, then click OK.

5 Select Bind Exclusively to TCP/IP Address, then click OK to save the IP address setting.

Corresponding Startup Switches You can also use the /ip switch in the MTA startup file to bind the MTA to a specific IP address.

Configuring the MTA 625

41.1.6 Moving the MTA to a Different Server

As your GroupWise system grows and evolves, you might need to move an MTA from one server to another. For example, you might decide to run the MTA on a different platform, or perhaps you want to move it to a server that has more disk space for the mslocal directory.

1 Stop the existing MTA.

2 Copy the entire mslocal subdirectory structure to wherever you want it on the new server. It

might contain messages that have not yet been delivered.

3 When moving the MTA, pay special attention to the following details:

 In the MTA startup file, set the /work switch to the location of the mslocal directory on the

new server.

 If the original MTA was configured for TCP/IP links between domains, you must

reconfigure the MTA object with the IP address and port number for the MTA on the new server. See “Using TCP/IP Links between Domains” on page 618.

 For the NetWare

offices are located and you are moving it to a different server, you must add the /dn switch or the /user and /password switches to the MTA startup file to give the NetWare MTA access to the server where the domain and post offices are located.

MTA, if it was originally on the same server where its domain and post

novdocx (en) 11 December 2007

4 Install the MTA on the new server. See “Installing GroupWise Agents” in the GroupWise 7

Installation Guide.

5 Start the new MTA, as described in the following sections in the GroupWise 7 Installation

Guide:

 “Starting the NetWare GroupWise Agents”

 “Starting the Linux Agents with a User Interface”

 “Starting the Windows GroupWise Agents”

6 Observe the new MTA to see that it is running smoothly. See Chapter 42, “Monitoring the

MTA,” on page 645.

7 If you are no longer using the old server for any GroupWise agents, you can remove the agents

to reclaim the disk space, as described in the following sections in the GroupWise 7 Installation

Guide:

 “Uninstalling the NetWare GroupWise Agents”

 “Uninstalling the Linux GroupWise Agents”

 “Uninstalling the Windows GroupWise Agents”

41.1.7 Adjusting the MTA for a New Location of a Domain or Post Office

MTA configuration must be adjusted if you make the following changes to your GroupWise system configuration:

 “New Domain Location” on page 627

 “New Post Office Location” on page 627

626 GroupWise 7 Administration Guide

New Domain Location

If you move a domain from one server to another, you need to edit the MTA startup file to provide the new location of the domain directory.

1 Stop the MTA for the old domain location if it is still running.

2 Use an ASCII text editor to edit the MTA startup file.

novdocx (en) 11 December 2007

NetWare and Windows:

Linux: The full domain name is used in the filename. However, all letters are lowercase

Only the first 8 characters of the domain name are used in the filename. The startup file is typically located in the directory where the MTA software is installed.

and any spaces in the domain name are removed. The startup file is located in the / opt/novell/groupwise/agents/share directory.

3 Adjust the setting of the /home switch to point to the new location of the domain directory.

4 Save the MTA startup file.

5 Start the MTA for the new domain location, as described in the following sections in the

GroupWise 7 Installation Guide:

 “Starting the NetWare GroupWise Agents”

 “Starting the Linux Agents with a User Interface”

 “Starting the Windows GroupWise Agents”

New Post Office Location

If you move a post office, you need to adjust the link information for that post office.

1 Click Tools > GroupWise Utilities > Link Configuration.

2 In the drop-down list, select the domain where a post office has moved.

3 Click View > Post Office Links to display post office links.

4 Double-click the post office that has been moved.

5 Provide its new location in the appropriate format.

6 Click OK.

7 Click File > Exit > Yes to save the link changes.

ConsoleOne then notifies the MTA to restart with the new link configuration.

41.1.8 Adjusting the MTA Logging Level and Other Log Settings

When installing or troubleshooting the MTA, a logging level of Verbose can be useful. However, when the MTA is running smoothly, you can set the logging level down to Normal to conserve disk space occupied by log files. See Section 42.3, “Using MTA Log Files,” on page 665.

Configuring the MTA 627

41.2 Configuring User Access through the Domain

Although users do not access the domain as they use the GroupWise client, their messages often pass through domains while traveling from one post office to another.

 Section 41.2.1, “Restricting Message Size between Domains,” on page 628

 Section 41.2.2, “Enabling Live Remote,” on page 629

 Section 41.2.3, “Securing the Domain with SSL Connections to the MTA,” on page 629

41.2.1 Restricting Message Size between Domains

You can configure the MTA to restrict the size of messages that users are permitted to send outside the domain.

1 In ConsoleOne, click Tools > GroupWise Utilities > Link Configuration.

novdocx (en) 11 December 2007

2 Double-click the domain where you want to restrict message size.

3 In the Maximum Send Message Size field, specify in megabytes the size of the largest message

you want users to be able to send outside the post office.

4 If you want to delay large messages, specify the size in megabytes for message files the MTA

can process immediately in the Delay Message Size field.

If a message file exceeds the delay message size, the message file is moved into the low priority (6) message queue, where only one MTA thread is allocated to process very large

628 GroupWise 7 Administration Guide

messages. This arrangement allows typical messages to be processed promptly, while delaying large messages that exceed the specified size. The result is that large messages do not slow down processing of typical messages.

5 Click OK.

6 To exit the Link Configuration Tool and save your changes, click File > Exit > Yes.

ConsoleOne then notifies the MTA to restart using the new message size limits.

If a user’s message is not sent out of the domain because of this restriction, the user receives an email message providing the following information:

Delivery disallowed - Transfer limit is nn MB

However, the message is delivered to recipients in the sender’s own domain.

There are additional ways to restrict the size of messages that users can send, as described in

Section 12.3.4, “Restricting the Size of Messages That Users Can Send,” on page 185.

41.2.2 Enabling Live Remote

novdocx (en) 11 December 2007

You can configure the MTA to redirect GroupWise Remote client requests to other MTAs and POAs. The GroupWise client can establish a client/server connection to an MTA across the Internet, eliminating the queuing and polling process used by earlier Remote clients. The result is significantly improved performance for Remote client users.

To configure the MTA to redirect Remote client requests, add the /liveremote, /lrconn and /

lrwaitdata switches to the MTA startup file.

You can monitor the live remote connections from the MTA server console. See “Displaying Live

Remote Status” on page 653.

As an alternative to live remote connections from outside your firewall, you could set up proxy servers for the POAs, so that client users in Remote mode connect to their mailboxes through the proxy servers rather than through MTAs. Full SSL security is provided through the proxy servers. See Section 36.3.1, “Securing Client/Server Access through a Proxy Server,” on page 496.

41.2.3 Securing the Domain with SSL Connections to the MTA

Secure Sockets Layer (SSL) ensures secure communication between the MTA and other programs by encrypting the complete communication flow between the programs. For background information about SSL and how to set it up on your system, see Chapter 71, “Encryption and

Certificates,” on page 1117.

To configure the MTA to use SSL:

1 In ConsoleOne, browse to and right-click the MTA object, then click Properties.

2 Click GroupWise > Network Address to display the Network Address page.

Configuring the MTA 629

3 To use SSL connections between the MTA and the POAs for its post offices, which provides

optimum security, select Enabled in the Message Transfer SSL drop-down list.

novdocx (en) 11 December 2007

The MTA must use a TCP/IP connection to each POA in order to enable SSL for the connection. See “Using TCP/IP Links between a Domain and its Post Offices” on page 623.

Each POA must also have SSL enabled for the connection to be secure. See Section 36.3.3,

“Securing the Post Office with SSL Connections to the POA,” on page 498.

4 To use SSL connections between the MTA and the MTA Web console displayed in your Web

browser, which provides optimum security, select Enabled in the HTTP SSL drop-down list.

To set up the MTA Web console, see Section 42.2.1, “Setting Up the MTA Web Console,” on

page 657.

5 Click Apply to save the settings on the Network Address page.

6 Click GroupWise > SSL Settings to display the SSL Settings page.

630 GroupWise 7 Administration Guide

For background information about certificate files and SSL key files, see Chapter 71,

“Encryption and Certificates,” on page 1117.

7 In the Certificate File field, browse to and select the public certificate file provided to you by

your CA.

8 In the SSL Key File field:

8a Browse to and select your private key file.

8b Click Set Password.

8c Provide the password that was used to encrypt the private key file when it was created.

8d Click Set Password.

9 Click OK to save the SSL settings.

ConsoleOne then notifies the MTA to restart using the new message size limits.

Corresponding Startup Switches You can also use the /certfile, /keyfile, /keypassword, /httpssl, and /msgtranssl switches in the MTA

startup file to configure the MTA to use SSL.

MTA Web Console

You can list which connections the MTA is using SSL for from the Links page. Click View T CP/IP Connections to display the list if TCP/IP links.

novdocx (en) 11 December 2007

41.3 Configuring Specialized Routing

As you create each new domain in your GroupWise system, you link it to another domain. You can view and modify the links between domains using the Link Configuration Tool. See Chapter 10,

“Managing the Links between Domains and Post Offices,” on page 137. The following topics help

you configure the MTA to customize routing through your GroupWise system:

 Section 41.3.1, “Using Routing Domains,” on page 631

 Section 41.3.2, “Scheduling Direct Domain Links,” on page 633

 Section 41.3.3, “Using a Transfer Pull Configuration,” on page 636

41.3.1 Using Routing Domains

As an alternative to configuring individual links between individual domains throughout your GroupWise system, you can establish a system of one or more routing domains under the following circumstances.

 Domains must connect to the routing domains with TCP/IP links.

 GroupWise 5.5 and later domains can be part of the routing domain system. Domains and

MTAs that are still at a 5.2 or earlier version cannot participate and must use links as provided in the Link Configuration Tool.

A routing domain can serve as a hub in the following situations:

 Messages that are otherwise undeliverable can be automatically sent to a single routing domain.

This routing domain can be set up to perform DNS lookups and route messages out across the Internet. 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.

Configuring the MTA 631

 All messages from a domain can be automatically routed through another domain, regardless of

the final destination of the messages. This provides additional control of message flow through your GroupWise system.

You can set up routing domains on two levels:

 “Selecting a System Default Routing Domain” on page 632

 “Selecting a Specific Routing Domain for an Individual Domain” on page 633

Selecting a System Default Routing Domain

You can establish a single default routing domain for your entire GroupWise system. This provides a centralized routing point for all messages. It takes precedence over specific links established when domains were created or links modified with the Link Configuration Tool.

To set up a system default routing domain:

1 In ConsoleOne, click Tools > GroupWise System Operations > System Preferences > Routing

to display the Routing tab.

novdocx (en) 11 December 2007

2 In the Default Routing Domain field, browse to and select the domain you want to serve as the

default routing domain for your entire GroupWise system.

3 If you want all GroupWise messages to pass through the default routing domain regardless of

the destination of the message, select Force All Messages to This Domain.

If you want only undeliverable GroupWise messages to be routed to the default routing domain, deselect Force All Messages to This Domain.

If you do not force all messages to the system default routing domain, then you have the option of allowing selected MTAs to provide routing domain services in addition to the system default routing domain.

4 Select MTAs Send Directly to Other GroupWise Systems if you want all MTAs in your

GroupWise system to perform DNS lookups and route messages out across the Internet.

Deselect MTAs Send Directly to Other GroupWise Systems if you want to individually designate which MTAs should perform eDirectory lookups and route messages out across the Internet.

5 Click OK to save the routing options you have specified for the system default routing domain.

632 GroupWise 7 Administration Guide

+ 67 hidden pages

Novell GROUPWISE 7 - MESSAGE TRANSFERT AGENT, GroupWise 7 Message Transfer Agent User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual