test

SunScreen 3.2 Administrator's Overview

SMTP Proxy

The SMTP proxy provides a basic level of control over incoming electronic mail that is based on the Simple Mail Transport Protocol (SMTP). It can be configured to allow or deny such email based on source addresses, the actual server name of the source host, or the server name of the (claimed) originator of a message. It can be further configured to allow or deny relaying of email based on the destined host or server of a message.

The SMTP proxy can be configured to scan the content of incoming electronic mail messages for virus and other malicious content.

Note -

When you use your SMTP proxy in conjunction with VirusWall scanning, your SMTP proxy examines email attachments for malicious scripting language code and executable content, and scans downloaded data for possible computer viruses. The scanner instructs that the content be blocked, or altered (for example, clean viruses from the content), or returned unaltered. Scanning results are recorded in the SunScreen log entries regarding SMTP transfers. See "VirusWall Content Scanning" for detailed information about VirusWall.

SMTP Proxy Operation

When the SMTP proxy starts, it reads its policy files, determines its local server name for use in relay checking, and listens on the standard SMTP port (25) for connections. When a connection is made, the SMTP proxy starts a new thread to handle the connection, and the main thread resumes listening.

The child thread takes control of the connection from the client. It then attempts to reverse-translate the address of the client (from the connection state) to yield a registered name.

If a registered name is discovered, the suffixes in the mail_spam list are checked against that name. If a suffix matches (the end of) the name of the originating host, the connection is closed with a response (455) refusing reception.

If no name is registered for the address, then the address itself is sought in the mail_spam list (looking for items that contain a single address or a range). If a match is found, the connection is closed with a response (455) refusing reception.

If it passes the peer-address check, the proxy thread next attempts the typical proxy rule match steps ("Policy Rule Matching"), except that only the source address is checked. For each rule that matches, an SMTP connection is attempted to the message transfer agents(MTA) listed as destination for the rule.

Once a connection to a destination server MTA has been established, data are relayed between the client and server MTAs. The content is scanned for commands that introduce source mailbox, destination mailboxes, and the data stream itself. Source mailboxes are checked against the spam list (if any). The destination mailboxes are checked against the relay list.

If configured for content scanning, the body of the e-mail messages which pass the above-mentioned spam and access control mechanisms, are fed to the scanner for inspection. The scanner may instruct that the content be blocked, or may alter the content (clean viruses from it, for example) , or may return it unaltered. Scanning which results in content alteration is reflected in the e-mail messages so modified.. Scanning results are recorded in the SunScreen log entries regarding SMTP transfers.

Spam Control

Unsolicited electronic mail is colloquially known as "spam." The restriction of mail based on originator is known as spam control. The SMTP proxy provides the ability to define a list of one or more restrictors that operate based on either server name (suffix) or nonserver (address range) criteria.

Spam restrictors have one of two syntactic forms:

server suffix is simply an ASCII character string.

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

Spam restrictors are defined using the configuration editor, and the mail_spam subcommand of ssadm edit in the administration GUI.

Examples

Below are examples of working with spam restrictors.

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:

or

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
Note -

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
Note -

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.

Other Mail Configuration Issues

In addition to specifying SunScreen SMTP proxy policy, configuration steps must be taken to cause SMTP-based email to arrive at the proxy for delivery to the servers it is to represent. The typical mechanism is to create MX records in the Domain Name System (DNS) for those servers. The procedure for altering DNS configuration is outside the scope of this document, but should be very familiar to your DNS administrator.

More than one Screen can be configured to operate in parallel to service incoming mail. The centralized management group feature of SunScreen makes doing so a relatively straightforward task. These parallel Screens can then be used within MX records.

By configuring the SMTP proxy on a Screen, the actual SMTP (inbound email) service into that system becomes unavailable. (You can still send email out of the Screen, as necessary.)

SMTP Proxy Rules

After configuring the content filtering, the final step is to create one or more rules that allow SMTP-based email to be served. A typical configuration often allows filtering outside email through the proxy to one or more inside message transfer agents (MTA) such as Solaris mail servers.

The source address for SMTP proxy rules should allow mail from any potential mail-sending address. Restrictions on source addresses in the rule can be useful in blocking abusive mail-originating sites that are stationary with respect to IP addressing.

The destination address for SMTP proxy rules should contain the addresses of one or more MTAs to which the proxy will connect to store and forward the incoming email.