SMTP Access and Relay Restrictions

To Configure Access and Relay Restrictions

107

The Message Access and Relay Restriction feature allows you to restrict messages from passing through SIMS based on source/destination email address, IP address, and domain. This feature provides several types of functionality:

Limits spam by blocking unwanted mail

Limits spam by not relaying (sending mail from one domain to another) unwanted mail

Restricts email usage to internal users

Email can be blocked by the following specified elements:

By source or destination domain

By source client IP address

By destination server IP address

By source or destination email address

To Configure Access and Relay Restrictions

AdminConsole>IMTA>Access Restrictions

FIGURE  4-4 Access Restrictions Section

A list of the first fifty access restriction rules appears in the display (press Next Set or Prev Set to display the next or previous fifty rules). An access restriction rule is a rule applied to a message which determines whether SIMS will block or accept the message. The order of rules displayed is the order in which each rule is applied to an incoming message before forwarding the message. The first rule that applies to the message will have its action applied to the message. Each rule consists of the following parameters:

Source EMAIL Address is the address of the sender on which to take action.

Source IP Address is the client IP address from which a message has been sent.

Destination EMAIL Address is the address of the recipient of the mail.

Destination IP Address is the server IP address at which the mail has been received.

Action is the action to take for a message specified by the preceding parameters. It can be Accept (accept message or forward to next stop), Block (refuse message delivery and return to sender), Disable Relay (refuse message from an external domain directed to another external domain and return mail to sender). Rules based on IP addresses alone are applied before all other rules. If the
/etc/opt/SUNWmail/imta/mappings file is edited by hand to include any other action, it will be shown as * in the console.

Rules are automatically sorted from most to least specific with Source EMAIL Address being used as the primary sort key, and Destination EMAIL Address being used as the secondary key. For example, a rule with a source email address as *@stork.env.sunny.com would be higher on the list compared to a rule with source email address *@*.env.sunny.com.

In FIGURE 4-4 the first rule allows clearinghouse@bravo.com to send messages to all-bravo@bravo.com. The second rule blocks mail from wolf@quackadero.com to sheep@bravo.com. The third rule blocks mail from spammer@quackadero.com from being delivered. The fourth rule blocks delivery of mail to all-bravo@bravo.com. The fifth rule stops inter-domain messages from IP address 321.333.268.890 from being delivered to the next domain.

FIGURE  4-5 Restricting Access to Users Within a Company

FIGURE  4-6 Access Restriction Dialog

i. Wild cards in addresses cannot be used on the right of non-wildcarded areas. That is: username@*, username*@*, or username@japan.* are illegal, *@*.com, *@xyz.com are legal.

ii. Wild cards cannot be used within an address token. A wild-card may only replace one or more entire domain part token. So for instance, *@*sun.com is illegal.

iii. Wild-cards may be used in local parts as long as they replace the entire username. As such, username*@sun.com is illegal.

A conflict occurs if a message from usr1@eng.quacky.com is addressed to usr2@eng.bravo.com. Rule A says to block this message, and rule B says to accept this message. This conflict must be resolved before the new rules will be accepted. More complex rules conflict may occur, see "Conflicting Access Restriction Rules" on page 110 for a more indepth discussion.)

c.

After a rule is set press OK to add the rule and keep dialog up, or press Done to add the rule and close the dialog.

To save the rules press Apply. You are prompted to restart the IMTA, which will incorporate the new or modified rule.

3.

To modify an Access Restriction rule, select the rule and click Modify.

Modify parameters as desired and press Apply to save.

4.

To delete an Access Restriction rule, select the rule and click Delete.

Press Apply to save.

5.

To search for an Access Restriction rule, click Search and add the search parameters in the Access Restriction Dialog.

You can use the wildcard (*) character. Search is used for finding a particular set of access restriction rules that you wish to modify, verify, or delete.

Conflicting Access Restriction Rules

The previous section described a very obvious case of rules conflict. A less obvious case of conflict arises when Rule 1 is less specific than Rule 2 according to one parameter, and more specific than rule 2 according to another parameter. For example, suppose we have defined the following two rules:

	Source address:	Destination address:	Action:
Rule 1	*@hosta.a.com	*@*.b.com	Block
Rule 2	*@*.a.com	*@hostb.b.com	Accept

These rules would not resolve the scenario where mail from *@hosta.a.com is to be delivered to *@hostb.b.com. To create a set of rules that would address the various delivery scenarios involved with these two addresses, we need to determine whether to block or deliver in these two specific scenarios:

	Source address:	Destination address:	Action:
Scenario 1	*@hosta.a.com	*@hostb.b.com	?
Scenario 2	*@*.a.com	*@*.b.com	?

The outcomes of these scenarios would be described by Rules 3 and 4 described below in the Outcome sections. These rules may or may not already exist.

Outcome A

Here are the rules needed to resolve Outcome A. (Rules with asterisks should be removed--they are displayed for edification.) The rules are displayed in the order in which they would be sorted (most to least specific with Source being the primary key, and Destination being the secondary key), and the order in which each rule would be applied to an incoming message before forwarding the message.

	Source address:	Destination address:	Action:
Rule 3	*@hosta.a.com	*@hostb.b.com	Block
* Rule 1	*@hosta.a.com	*@*.b.com	Block
Rule 2	*@*.a.com	*@hostb.b.com	Accept
Rule 4	*@*.a.com	*@*.b.com	Block

Rule 1 is not needed because in the following delivery scenario *@hosta.a.com ----> *@<any host but hostb>.b.com

Rule 3 is needed because Rule 2 applies to the scenario *@hosta.a.com ----> *@hostb.b.com

Hence the conflict can be resolved by using the rules 2, 3, and 4. Rule 4 may not be needed if it is coverd by a more generic rule.

Outcome B

Here are the rules needed to resolve Outcome B:

	Source address:	Destination address:	Action:
*Rule 3	*@hosta.a.com	*@hostb.b.com	Accept
*Rule 1	*@hosta.a.com	*@*.b.com	Block
Rule 2	*@*.a.com	*@hostb.b.com	Accept
Rule 4	*@*.a.com	*@*.b.com	Block

Rule 1 is not needed because in the following delivery scenario *@hosta.a.com ----> *@<any host but hostb>.b.com

Rule 3 is not needed because Rule 2 applies to the scenario *@hosta.a.com ----> *@hostb.b.com

Hence the conflict can be resolved by using the rules 2, and 4. Rule 4 may not be needed if it is coverd by a more generic rule.

Outcome C

Here are the rules needed to resolve Outcome C:

	Source address:	Destination address:	Action:
*Rule 3	*@hosta.a.com	*@hostb.b.com	Block
Rule 1	*@hosta.a.com	*@*.b.com	Block
*Rule 2	*@*.a.com	*@hostb.b.com	Accept
Rule 4	*@*.a.com	*@*.b.com	Accept

Rule 2 is not needed because in the following delivery scenario

Rule 3 is not needed because Rule 1 applies to the scenario

Hence the conflict can be resolved by using the rules 1, and 4. Rule 4 may not be needed if it is coverd by a more generic rule.

Outcome D

Here are the rules needed to resolve Outcome D:

	Source address:	Destination address:	Action:
*Rule 3	*@hosta.a.com	*@hostb.b.com	Accept
Rule 1	*@hosta.a.com	*@*.b.com	Block
*Rule 2	*@*.a.com	*@hostb.b.com	Accept
Rule 4	*@*.a.com	*@*.b.com	Accept

Rule 2 is not needed because in the following delivery scenario

Rule 3 is needed because Rule 1 applies to the scenario

Hence the conflict can be resolved by using the rules 1, 3, and 4. Rule 4 may not be needed if it is coverd by a more generic rule.