Configuring the MTA to Support Live Remote

Prior to the GroupWise 5.5 Enhancement Pack, the MTA never "talked" directly with the GroupWise client. Now, however, the GroupWise MTA can communicate with the client, if the client is a GroupWise 5.5 Enhancement Pack (5.5E for short) or GroupWise 6.5 client running in remote mode. This might sound like a funny thing for an MTA to do, but it has an application in some environments. This feature was added to allow GroupWise systems to better support remote-user connections over the Internet.

End users increasingly have their own connections to the Internet. It is natural for GroupWise users to want to connect to their organization's GroupWise system in order to download their GroupWise mail to their GroupWise remote mailbox. Prior to GroupWise 5.5E, the only way administrators could enable this functionality was to allow Internet hosts to contact each post office's POA and speak with the POA at any port. This raised all sorts of security issues. Because of this, most organizations opted not to allow users to access their POA from outside their organization's firewall. Now the GroupWise 6.5 POA supports connectivity via proxy server. For more information on configuring the POA to support proxy server connectivity, read Chapter 8.

The GroupWise MTA can accept a connection from a GroupWise client at the live remote port configured for the MTA. The GroupWise MTA can then open a virtual live remote session with the POA that supports the user's post office. The effect then is that system administrators can tell users that if they have a connection to the Internet, they can configure GroupWise to connect to MTA.WORLDWIDEWIDGETS.COM using port 8100.

The MTA must have two lines enabled in the startup file of the MTA:

/liveremote-port number /lrconn-# of connections

The first line specifies the port that the MTA will use to listen for live remote connections. The second line specifies the maximum number of simultaneous live remote connections that the MTA will allow. Each remote user will require one connection for the duration of their upload and download sequence.

For the MTA to be able to support live remote, every link between this MTA and the rest of the system must be a TCP/IP link. There can be indirect links, but the entire path must be TCP/IP, all the way down to the POA. This applies even if your POA and MTA are on the same file server.

Take the following scenario:

• USERA is the live remote user.

• POSTOFFICEA is USERA's post office.

• DOMAIN1 is USERA's domain.

• DOMAIN2 is another domain in the GroupWise system whose MTA is configured to receive live remote connections.

The message flow will run as detailed here:

1. USERA establishes a live remote connection with the DOMAIN2 MTA.

2. The DOMAIN2 MTA establishes a live remote connection with DOMAIN1 on behalf of USERA.

3. The DOMAIN1 MTA establishes a live remote connection with the POSTOFFICEA POA.

4. The POSTOFFICEA POA accesses the information store on behalf of USERA and passes responses back along the live remote chain to the user.

Note

Live remote connections can be monitored on the MTA. The DOMAIN2 MTA will register USER1 as a live remote user. The MTA will also show a domain link to DOMAIN1 under F-10, live remote status. The DOMAIN1 MTA will register DOMAIN2's MTA and POSTOFFICEA as live remote connections under F-10, live remote status. The POSTOFFICEA POA will register USER1 in the log as the live remote user.

The GroupWise remote client does not need a special kind of live remote connection type. GroupWise remote client simply specifies another TCP/IP connection as though the MTA that is listening for live remote connections is a POA.