Spam Control

Unsolicited electronic mail is colloquially-known as spam. In SunScreen EFS 3.0, 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 non-server (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)

server suffix is simply an ASCII character string.

See the section below entitled "SMTP Proxy Operation" for details regarding how these restrictors are used.

Spam restrictors are defined using the command-line interface, and the mail_spam sub-command of ssadm edit in the administration GUI.

The following is an example of what you 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 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 type to add an additional restriction while logged in to the primary Screen:

edit> mail_spam add complete-spam.net
edit> quit

The mail_spam restrictors are stored in the database used by the vars variables. It is not necessary to type save before quit like above if only authuser, proxyuser, logmacro, or vars entities have been altered. If you attempt to save without changing entities other than these types, you are reminded by a message:

edit> save

lock not held

failed (status 244)

This is a non-fatal message in this situation; you can simply quit the configuration editor at this point.

Once changes have been made to spam restrictors, the current policy must be (re)activated to install the new objects and to propagate these changes to secondary Screens.

The following is an example of what you 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 policy rules, allows you to restrict which destination domains are accepted by the proxy.

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 the section below entitled "SMTP Proxy Operation" for details regarding how these restrictors are used.

Relay restrictors are defined using the command-line interface, through the mail_relay sub-command 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 Registryedit> mail_relay list"your-domain.com" 

"!private.your-domain.com"

The above (example) listing shows two entries, one to set a base domain to allow in recipients, the other to block a private sub-domain 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.comedit> quit

The mail_relay restrictors are really stored in the database used by the vars variables. It is not necessary to enter save before quit above if only authuser, proxyuser, logmacro, or vars entities have been altered. If you attempt to save without changing entities other than these types, you will be reminded by a message:

edit> savelock not held

failed (status 244) 

This is a non-fatal message in this situation; you can simply quit the configuration editor at this point.

Once changes have been made to relay restrictors, the current policy must be (re)activated to install the new objects and to propagate these changes to secondary Screens.

The following is an example of what you type to remove a restriction (while logged into the primary Screen), type:

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

The following is an example of what you 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 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 EFS 3.0 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 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.