Relay Control

In addition to controlling incoming spam destined for your site, another important area of control over email is the limitation on accepting email and then relaying it to another location. Relayed mail is responsible for a great deal of the unsolicited email on the Internet. Improper relaying makes spam harder to defeat and leaves the relaying site open to various types of reprisal from the ultimate recipient-victims.

The SMTP proxy allows the configuration of a set of strings that, coupled with policy rules, enables you to restrict the destination domains that the proxy accepts.

Relay restrictions have one of two syntactic forms:

• domain suffix (suffix in recipients to allow)

or

• !domain suffix (suffix in recipients to disallow)

domain suffix is simply an ASCII character string.

See "SMTP Proxy Operation" for details regarding how these restrictors are used.

Relay restrictors are defined using the configuration editor, through the mail_relay subcommand of ssadm edit. The following is an example of what you type to display the current set of relay restrictors while logged into the primary Screen:

admin% ssadm -r master edit Registry
edit> mail_relay list
"your-domain.com"  
"!private.your-domain.com"

This listing shows two entries, one to set a base domain to allow in recipients, the other to block a private subdomain in recipients.

The following is an example of what you type to add an additional restriction while logged into the primary Screen:

edit> mail_relay add !lists.your-domain.com
edit> quit

The following is an example of what you type to remove a restriction while logged into the primary Screen;

edit> mail_relay delete !test.your-domain.com

If relay checking is enabled (for example, NO_RELAY) and yet no relay restrictors are configured, the SMTP proxy defaults to allow only the domain configured for the Screen itself as the valid domain for inbound mail.

The SMTP proxy rules should use the smtp service, and specify the PROXY to be PROXY_SMTP during rule definition in the administration GUI (or the PROXY_SMTP keyword for command-line rule creation). The RELAY (or NO_RELAY) flag is used to specify whether to perform unrestricted versus restricted relaying of mail. Use NO_RELAY in conjunction with the mail_relay restrictors shown above to effect relay control.

The following is an example of what you type, presuming that you already have the following objects defined:

admin% ssadm -r primary edit Initial
edit> list address 
"mta-primary" HOST 1.2.3.4 ... 
"mta-secondary" HOST 1.2.3.5 ... 
"outside" GROUP { } { inside } ...

The following is an example of what you type to define an address group to contain all inside MTAs:

edit> add address mtas GROUP { mta-primary mta-secondary } { }

The following is an example of what you type to define relay restrictors to specify the servers (and perhaps hosts) to be allowed in recipient mailbox names:

edit> mail_relay add prime-server.com
edit> mail_relay add other-server.com
edit> mail_relay add !lists.prime-server.com
edit> mail_relay add !private.other-server.com

Finally, the following is an example of what you would type to define a rule to cause inbound email to pass through the SMTP proxy:

edit> add rule smtp outside mtas ALLOW PROXY_SMTP NO_RELAY
edit> save
edit> quit

Because of the way that SunScreen represents addresses (in numerical order by IP address), rules that refer to multiple destination addresses attempt the MTA connection in numerical order. To obtain finer control over MTA connection ordering, use multiple rules.

Once a connection is established to a willing backend MTA, the proxy thread begins watching information passed by the client to the server (ordinarily, the proxy does not talk to the client). The proxy looks for a MAIL FROM: command from the client. (This command gives the name of the user who originated the message. It is often abused by spam message creators, so its information is often untrustworthy.) The mailbox name in this command is compared with the suffixes in the mail_spam list and if found there, the connection is aborted with a response (455) refusing reception.

Next, the proxy thread looks for one or more RCPT TO: commands from the client. (Such commands give one of the destination mailboxes to which the message is directed. Unlike the MAIL FROM: command, this mailbox name is always a real recipient.) If the rule specifies NO_RELAY, then the mailbox names in these commands are compared against the mail_relay list. The search can be conceptually thought of as a two-pass search. On the first pass, any denial suffixes (ones beginning with !) are sought and if matched, cause a connection abort with a response (454) refusing reception. On the second pass, allowance suffixes are sought (ones not beginning with !). If one matches, the recipient is allowed; if none matches, the connection is aborted with a response (454) refusing reception.

SMTP allows multiple messages (each with one or more recipients) to pass on a single connection. Barring a refusal of service, once all messages have been passed, the proxy closes the connection to the client and backend server and ends the child thread.