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.
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, then 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.
Having passed the peer-address check, the proxy thread next attempts the typical proxy rule match steps (given earlier), except that only the source address is checked. For each rule that matches, an SMTP connection is attempted to the Mail 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
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 (suffix in a named host), or
-
start address [.. end address] (range of one or more IP addresses of unnamed hosts)
Note -No spaces are permitted around the double dots (..) in this construct for the address range.
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 command-line interface, and the mail_spam subcommand of ssadm edit in the administration GUI.
The following is an example of what you would type to display the current set of spam restrictors while logged in to the primary Screen:
admin% ssadm -r primary edit Initial edit> mail_spam list "total-nonsense.org" "0.0.0.0..255.255.255.255" |
The above example listing shows two entries, one to refuse email from the server or servers with registered address in the domain total-nonsense.org, the other to refuse mail from any host that does not have a registered server name (in a reverse-mapping of IP address to DNS name).
The following is an example of what you would type to add an additional restriction while logged in to the primary Screen:
edit> mail_spam add complete-spam.net edit> quit |
The following is an example of what you would type to remove a restriction while logged in to the primary Screen:
edit> mail_spam delete lite-spam.com |
From the command line, 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 Control
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 command-line interface, through the mail_relay subcommand of ssadm edit. The following is an example of what you would 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 would 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 would 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 would 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 would 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 would 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 |
The following is an example of what you would type to define spam restrictors to deny mail from some mail originators you know to be sources of unsolicited mail:
edit> mail_spam add 0.0.0.0..255.255.255.255 edit> mail_spam add dialups.naughty-isp.net |
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 give rise to attempting 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 use 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 is designed to allow 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 multiple Screen management features of SunScreen make 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 actually allow SMTP-based email to be served. A typical configuration often allows outside email to be filtered 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 entirely-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 actually store and forward the incoming email.
- © 2010, Oracle Corporation and/or its affiliates