Configuring Access Control

By default, everyone in your organization has full access to all features you enable on the GWIA. This includes the capability to collect their email via POP3 or IMAP4 service, as well as to send and receive messages of unlimited size via SMTP/MIME.

For many customers, though, the following are common settings under Access Control:

• There is no POP3 or IMAP4 mailbox access.

• SMTP relay access is turned off.

• No rule-generated messages can be sent through the GWIA.

• Users are limited to a certain message size that they can send through the Internet.

You can administer all of these controls on the GWIA via Access Control. Generally, when you want your Access Control to apply to all users, you configure the Default Class of Service. Imagine, though, that you want to be able to make exceptions to the settings you defined from Default Class of Service. For example, a couple of users will eventually need POP3 access. Here are the steps to accomplish such exceptions:

1.	Open the GWIA object's properties window and go to the Access Control, Settings property page.
2.	To the right of the Class of Service pane, click Create. You should be presented with the dialog box shown in Figure 10.13. Figure 10.13. Creating a new class of service
3.	Enter a name for this class of service, such as POP3 Access. After clicking OK and selecting the POP3 tab, you get the screen shown in Figure 10.14. Figure 10.14. The Edit Class of Service dialog box allows you to define how the service is configured
4.	Beneath the defaults, select Allow Access and leave all other settings at their defaults. Click OK.
5.	You will be presented with a user list, as shown in Figure 10.15. Select the users who can use the GWIA as a POP3 server, and click OK. Figure 10.15. Adding users to a class of service

The users defined under the POP3 Access Class of Service will be able to retrieve their email via POP3, and relay off of the GWIA.

It is important to note that you did not configure any type of SMTP relay on the GWIA, yet these POP3 users are able to relay off of the GWIA. The reason for this is that the GWIA will allow a user who has authenticated via a POP3 session to relay through the GWIA. Because the POP3 session required the user to authenticate as a valid user, the GWIA assumes that the user should be able to use the GWIA as an SMTP relay server.

For your users to be able to use SMTP relay, their POP3 client must be configured to allow authentication to the SMTP server (which is the POP3 server also) before sending SMTP messages to be relayed. Some newer POP3 clients just assume that this is the case, so this option of whether to do it is not even presented to the users.

Let's imagine another scenario. You have deployed Novell's ZENworks server management product. The ZENworks server management product has an alerting mechanism that requires an SMTP relay host. You want your GWIA to allow relaying, but only from the server running the ZENworks server management.

Following are the steps for setting up the GWIA to act as a relay host:

1.	In the GWIA's property pages, select Access Control, SMTP Relay Settings. Confirm that the radio button Prevent Message Relaying is selected.
2.	Under Exceptions, and to the right of the Allow pane, click Create.
3.	In the From field, enter the IP addresses that will be allowed to relay through the GWIA. You do not need to specify a To address.
4.	Click OK, and you will see the new exception as shown in Figure 10.16. Click OK again to save all changes. Figure 10.16. Adding an exception to the SMTP relay access