CHAPTER
6 |
IMTA Security and Unsolicited Bulk Email (UBE) Handling |
|
|
"SMTP Access and Relay Restrictions" on page 123 |
|
|
"SMTP AUTH Configuration" on page 140 |
|
|
"Controlling SMTP Connections and Transactions" on page 143 |
|
|
"Controlling Delivery by Email Content and Message Priority" on page 144 |
|
|
"Firewall Configuration" on page 147 |
|
|
"Restricting or Controlling Published Information" on page 150 |
|
|
"Controlling External Stimulation of Message Delivery" on page 153 |
|
|
"SMTP Access Restrictions by IP Address and Port Number" on page 124 |
|
|
"SMTP Access Restrictions by Source and Destination Email Address" on page 125 |
|
|
"SMTP Access Restrictions by IP Address, Port, and Email Address" on page 127 |
|
|
"Limiting the Number of Recipients Per Message or the Number of Messages Per Session" on page 127 |
|
|
"DNS-based Email Access Control" on page 128 |
|
|
"Setting up dns_verify" on page 128 |
|
|
"Access and Relay Restrictions with the Admin Console" on page 131 |
|
|
"Optimizing Access and Relay Restrictions" on page 138 |
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 unsolicited bulk email (UBE) or spam by blocking unwanted mail |
|
|
Limits UBE by not relaying (sending mail from one domain to another) unwanted mail |
|
|
Restricts email usage to internal users |
SMTP access and relay restrictions rules are located in the mapping file at
/etc/opt/SUNWmail/imta/mappings. The mappings file can contain three tables from which to control SMTP access and relay:
|
|
PORT_ACCESS mapping table can be used to control the IP addresses from which IMTA servers will accept connection attempts; the server checks this table when a connection attempt comes in. |
|
|
ORIG_SEND_ACCESS mapping table can be used to control access based on the From address, To address, and the source and destination channels. |
|
|
ORIG_MAIL_ACCESS mapping table can be used to control email access based on both IP addresses, and From address and To addresses. It essentially combines the functionality of PORT_ACCESS and ORIG_SEND_ACCESS. |
SIMS provides a GUI access for adding and modifying rules in these tables (see "Access and Relay Restrictions with the Admin Console" on page 131). However, to implement more complex access controls you'll have to edit the mappings file directly. Refer to the section on the IMTA mapping file in the SIMS Reference Manual.
The SMTP server is able to selectively accept or reject incoming SMTP connections based on IP address and port number. The PORT_ACCESS table is used by the IMTA to selectively accept or reject incoming SMTP connections based on IP address and port number. If the PORT_ACCESS mapping table was present when the IMTA started up, the IMTA checks all connections by formatting the connection information in the form:
The server looks for a match in the PORT_ACCESS table. If the result of the mapping contains $N, the connection is immediately closed. Any other result allows the connection to be accepted. The metacharacter $N may be followed by a rejection message. If present, the message is sent back down the connection just prior to closure. Note that a CRLF terminator is appended to the string before it is sent back down the connection. See TABLE 6-1 on page 126 for additional access mapping flags.
For example, the following mapping will only accept SMTP connections from a single network, except for a particular host singled out for rejection without any message:
Note that if you are using the PORT_ACCESS mapping table you will need to restart the dispatcher after making any changes to this mapping table so that the IMTA will see the new compiled configuration.
The PORT_ACCESS mapping table is specifically intended for performing only IP number-based rejections; for more general control at the email address level or a combination of email address and port access, the ORIG_SEND_ACCESS mapping table or the ORIG_MAIL_ACCESS table can be used.
Note that you must restart the IMTA after changing the PORT_ACCESS mapping.
The ORIG_SEND_ACCESS mapping table may be used to control who may or may not send mail, receive mail, or both. The nature of the mapping is very general and allows per-channel granularity.
If the ORIG_SEND_ACCESS mapping table exists, then for each recipient of every message passing through the IMTA, the IMTA will probe the table with a probe string of the form:
The src-channel is the channel originating the message (that is, queueing the message); from-address is the address of the message's originator; dst-channel is the channel to which the message will be queued; and to-address is the address to which the message is addressed. Use of an asterisk in any of these four fields causes that field to match any channel or address, as appropriate.
If the probe string matches a pattern that is, the left side of an entry in the table, then the resulting output of the mapping is checked. If the output contains the metacharacters $Y then the enqueue for that particular To address is permitted. If the mapping output contains the metacharacters $N then the enqueue to that particular address is rejected. In the case of a rejection, an optional rejection message may be supplied in the mapping output. This string will be returned as a rejection message. If no string is output (other than the $N metacharacter), then a default message will be used. See TABLE 6-1 on page 126 for additional access mapping flags.
Suppose that local users in the domain acme.com, with the exception of the postmaster, can receive but not send mail to the Internet. Then the ORIG_SEND_ACCESS mapping table shown in CODE EXAMPLE 6-1 is one possible way to enforce this restriction. In that example, the local host name is assumed to be acme.com. In the channel name tcp_*, wildcards are used so as to match any possible TCP/IP channel name. In the rejection message, dollar signs are used to quote spaces in the message. Without those dollar signs, the rejection would be ended prematurely and only read "Internet" instead of "Internet postings are not permitted."
CODE EXAMPLE 6-1 Restricting Internet Mail Access on UNIX
The ORIG_MAIL_ACCESS mapping table combines the two previous mapping tables: ORIG_SEND_ACCESS and PORT_ACCESS. The syntax is similar (it should appear on one line):
from-address|dest-channel|to-address
For example, to allow abc.com to relay mail through your domain only if the mail is submitted from the IP address 192.9.9.9, use the following mapping:
ORIG_SEND_ACCESS is looked up first. If ORIG_SEND_ACCESS has a rule which supersedes the rule in ORIG_MAIL_ACCESS, the rules in ORIG_MAIL_ACCESS will not be used at all. See TABLE 6-1 on page 126 for additional access mapping flags.
You can use two SMTP channel options ALLOW_TRANSACTIONS_PER_SESSION and ALLOW_RECIPIENTS_PER_TRANSACTION to implement dynamic rejection mechanisms. The ALLOW_TRANSACTIONS_PER_SESSION option can be used to limit the number of messages accepted during a particular connection. After refusing a number of connection attempts from a particular site, once you do let them connect, they are liable to have a backlog of messages for your site which they will try to deliver during that connection. If you are attempting to "slow down" how much mail you accept from that site, you likely will want to use this option to say, in effect, "enough for now" after some point in the connection. Similarly, the ALLOW_RECIPIENTS_PER_TRANSACTION option can be used to limit the number of recipients allowed for a particular message; this can be useful in protecting against a denial of service attack in the form of messages blanketing large numbers of your users.
These options can be access through the Admin Console. See "To Configure Message Limitation" on page 101 and "To Set Recipient Limitation" on page 106
Spammers often disguise their email address by using a fake From: address with a fake domain name. You can set up your server to only accept mail from addresses that have valid domains in the DNS. dns_verify is a program that allows you to do this. dns_verify can be turned on or off using the mailfromdnsverify keyword (see the SIMS Reference Manual). Note that configuring manually in the mapping files gives more control on error messages.
Given a domain, the dns_verify program queries the DNS to check if either an A record or an MX record exists for the domain. If either record exists, dns_verify accepts, otherwise, it rejects.
The dns_verify program is used in a mapping rule in the mappings file (see section on the Mapping File in the SIMS Reference Manual). The rule can come under either the ORIG_SEND_ACCESS and ORIG_MAIL_ACCESS tables.
Examples for each usage are shown below. Each entry must appear on a single line, even though they are shown here on multiple lines for readability.
/opt/SUNWmail/imta/lib/dns_verify is the library and dns_verify is the function. The complete syntax for these entries is described in "SMTP Access Restrictions by Source and Destination Email Address" on page 125 and the section on the Mapping File in the SIMS Reference Manual.
The argument to dns_verify has three parts delimited by '|' as shown below:
hostname|return-if-good|return-if-bad
The return-if-good and return-if-bad strings are templates for the return string. If hostname has a valid DNS entry, the return-if-good template is used to generate a return string. Otherwise, the return-if-bad template is used.
These are the format characters you can include in the return-if-good and return-if-bad strings:
%a - If successful, the IP address found from the DNS lookup
%n - If successful, the primary name for this host
%e - The error message associated with the lookup
Continuing from the first example above:
$2|$$Y|$$NInvalid$ host:$ $$2$ -$ %e
With this argument string, "$Y" is returned when $2 has a valid DNS entry. If $2 does not have a valid DNS entry, the return string would look something like this:
$NInvalid host: eng.sun.com - authoritative host not found: usr001
~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$2 %eNotice how dollar signs and spaces need to be quoted. They appear as "$$" and "$ " respectively.
It is possible to use dns_verify to look up addresses on a realtime black hole list by setting ENABLE=1 in your Dispatcher configuration file (/etc/opt/SUNWmail/imta/dispatcher.cnf) and by creating the appropriate dns_verify entry in your PORT_ACCESS mapping table in the mappings file. Below is an example:
TCP|*|25|*.*.*.*|* $[/opt/SUNWmail/imta/lib/ dns_verify,dns_verify,\
+$4.$3.$2.$1.rbl.maps.vix.com\
+$$N500$ 5.7.1$ Mail$ from$ $$1.$$2.$$3.$$4\
$ refused,$ see$ http://maps.vix.com/rbl/\
+$$CTCP|$$0|25|$$1.$$2.$$3.$$4|$$5\
+$$CTCP|$$0|25|$$1.$$2.$$3.$$4|$$5]
This dns_verify string checks the DNS for an A record for D.C.B.A.rbl.maps.vix.com. If it finds such a record (indicating that the system with address A.B.C.D is on the RBL), it returns the error "500 5.7.1 Mail from A.B.C.D refused, see http://maps.vix.com/rbl/". If it sees that the DNS query returns that the record didn't exist, or it was unable to determine (DNS "Server failed" error), it will continue the mapping probe looking for other possible matches. If no match is found, the connection is permitted. For detailed information about the syntax, refer to the SIMS Reference Manual.
If you have any other PORT_ACCESS entries, put them after this one. If this one does not find that a particular incoming IP address is on the list, it will continue the probe in the mapping table.
Rejecting mail based on the absence of a DNS record is not supported by Internet RFCs. RFC822 and RFC1123 direct that mail addressed to postmaster must not be rejected. Violation of this is sufficient cause for your domain to be disconnected from the Internet.
Also, if your DNS is unstable or experiences an outage, mail you might otherwise accept will be rejected.
It is strongly recommended that you have a rule accepting all mail to the postmaster before the dns_verify rule is applied. Example,
On systems where nsswitch.conf is configured such that some other source comes after DNS in the hosts database, for example:
hosts: dns nis files
senders with mail domains without A records in DNS will be rejected even if they do have MX records. This bug is due to gethostbyname() not returning the appropriate error code which dns_verify depends on.
This bug will not manifest itself on systems configured with DNS as the last source for the hosts database or with [NOTFOUND=return] for DNS. For example,
hosts: dns
hosts: dns [NOTFOUND=return] nisAlso, dns_verify is not supported by SIMS Admin Console. Changes to the mappings file have to be done by hand using a text editor. The Admin Console will overwrite the dns_verify entries the next time it modifies the mappings file.
 |
Access and Relay Restrictions with the Admin Console |
AdminConsole>IMTA>Access Restrictions
| 1. | In the Sections list of the IMTA property book, click Access Restrictions. |
| A list of the first 50 access restriction rules appears in the display (press Next Set or Prev Set to display the next or previous 50 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 with the message "Relaying not permitted"). 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 an asterisk (*) 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 6-1 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 192.1.2.3 from being delivered to the next domain. |
| 2. |
| a. | Specify the desired Access Restriction parameters and click Done. |
| Enter email addresses for the Source and Destination EMAIL Address fields. Asterisks may be used as a wild card character. If no IP address is entered, the default *.*.*.* is entered. |
| Asterisks will be allowed on source or destination addresses. Otherwise, addresses must contain a local part and a domain part, separated by an @ sign. The wild-card character (*) can be used, with the following restrictions: |
| i. | Wild cards in addresses cannot be used on the right of non-wild-carded 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. For instance, *@*sun.com is illegal. |
| iii. | Wild cards may be used in local parts as long as they replace the entire user name. As such, username*@sun.com is illegal. |
| b. | Resolve conflicting rules. |
| If you try creating a rule that conflicts with previously written rule, the Admin Console will bring up a dialog box that shows all the rules with which the current rule conflicts. You must then resolve the conflict by modifying the fields of the rule. |
An example of a conflicting rule is shown below:
|
| 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 conflict must be resolved before the new rules will be accepted. (More complex rules conflicts might occur; see "Conflicting Access Restriction Rules" on page 135 for a more in-depth 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 you prefer and press Apply to save. |
| 4. | To delete an Access Restriction rule, select the rule and click Delete and Apply. |
| 5. | To search for an Access Restriction rule, click Search and add the search parameters in the Access Restriction Dialog. |
| You can use the wild card (*) character. Search is used for finding a particular set of access restriction rules that you wish to modify, verify, or delete. |
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 might or might not already exist.
The following matrix shows Scenarios 1 and 2, their specified actions (Block or Accept), and the rules needed to create the desired outcomes.
Outcome A
Here are rules resolving Outcome A. (Rule 1 is not necessary, it is displayed for edification.) Rules are displayed in the sorted order: from most to least specific, with Source being the primary key; Destination being the secondary key; and the order in which each rule would be applied to an incoming message before forwarding.
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 the delivery is not matched by Rule 2 and covered by Rule 4: *@hosta.a.com ----> *@<any host but hostb>.b.com |
|
|
Rule 3 is needed because Rule 2 applies to the following scenario. The conflict can be resolved by using the rules 2, 3, and 4. Rule 4 might not be needed if it is covered by a more generic rule. *@hosta.a.com ----> *@hostb.b.com |
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 |
| the delivery is not matched by Rule 2 and covered by Rule 4. |
|
|
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 Rules 2, and 4. Rule 4 might not be needed if it is covered 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 |
| *@<any host but hosta>.a.com ----> *@hostb.b.com |
| the delivery is covered by Rule 4 and doesn't match Rule 1. |
|
|
Rule 3 is not needed because Rule 1 applies to the scenario |
| *@hosta.a.com ----> *@hostb.b.com |
Hence the conflict can be resolved by using Rules 1 and 4. Rule 4 might not be needed if it is covered 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 |
| *@<any host but hosta>.a.com ----> *@hostb.b.com |
| the delivery is not matched by Rule 1 and is covered by Rule 4. |
|
|
Rule 3 is needed because Rule 1 applies to the scenario |
| *@hosta.a.com ----> *@hostb.b.com |
Hence the conflict can be resolved by using Rules 1, 3, and 4. Rule 4 might not be needed if it is covered by a more generic rule.
Note - There is no warning mechanism for rules added by manually editing the IMTA Mappings File. You must be very careful about creating conflicting rules.
Utilities: libimtamap
The SIMS IMTA access and relay restriction feature can cause a reduction in IMTA performance if there are too many anti-spam rules. SIMS provides a set of mapping loadable routines that can be used to increase the efficiency of anti-spamming configurations in the IMTA. Note that these routines can only be used by editing the mapping file. Refer to the section on the IMTA mapping file and the chapter on IMTA Security in the SIMS Reference Manual.
Note - If you use any of these mapping loadable programs, the Access Restriction section of the Admin Console will not be visible, and you will have to view the rules by looking at the mappings file.
In most cases, anti-spamming rules are directed toward a specific goal such as allowing relay for a specified client IP address or blocking mail whose envelope contains a specified string. For these types of rules, the decision is based on a single parameter. For example:
ORIG_SEND_ACCESS
*|spammer1|*|* $NNone$ of$ this$ here
*|spammer2|*|* $NNone$ of$ this$ here
*|spammer3|*|* $NNone$ of$ this$ here
*|spammer4|*|* $NNone$ of$ this$ here
*|spammer5|*|* $NNone$ of$ this$ hereDue to the way mapping tables work, the mapping process goes through all rules sequentially until a definite match is found. If you have more than 30 rules in which a single parameter defines the decision, then you may find that using the process described below will optimize the servers ability to handle multiple rules.
SIMS provides routines that increase the SMTP server performance when a large number of similar mapping rules are used. These routines can be used to replace multiple rules which have a common single parameter that varies in the pattern.
To use these routines, the list of values of this varying parameter are stored in a plain text file called a resource file, one parameter value per line. Several rules can be used to reference different resource files. Each of these resource files is loaded only once per process, the first time it's used.
The format of a rule is as follows:
*|*|*|* $[/opt/SUNWmail/imta/lib/libimtamap.so, <routine>,$1|<resource file>|<string>]
*|*|*|* is the format of a send_access/port_access rule.
libimtamap.so is the library.
<routine> is either immap_is_in_list, immap_is_in_cilist, or immap_is_in_list_of_ip.
$1 refers to the second * in the first argument, which is the source email address in send_access table or server IP address in the port_access table.
<resource file> is the path of the resource file.
<string> the string to put in result if a match is found.
The routines look up the parameter in a hash table created from the resource file and returns successfully if it is found. If successful, the routine can either set the result string according to the argument or to a hard-coded values. Upon failure, the mapping process continues with the next rule.
immap_is_in_list returns successfully if the string parameter is in the resource file. immap_is_in_list is the case-insensitive version of the same function. immap_is_in_list_of_ip returns successfully if the IP address parameter is within one of the networks contained in the resource file.
| |
To Optimize Access and Relay Restrictions Performance |
| 1. | Determine if you have multiple rules with a single changing parameter in each rule. |
| 2. | List of values of the varying parameter in a plain text file. |
| Use one value per line, several rules can be used to reference different resource files. For example, if this is the original table: |
| ORIG_SEND_ACCESS *|spammer1|*|* $NNone$ of$ this$ here *|spammer2|*|* $NNone$ of$ this$ here *|spammer3|*|* $NNone$ of$ this$ here *|spammer4|*|* $NNone$ of$ this$ here *|spammer5|*|* $NNone$ of$ this$ here |
| Then the resource file, which for this example we call /tmp/bad_from.txt, would be: |
| spammer1 spammer2 spammer3 spammer4 spammer5 |
| 3. | Replace the original rules with a single new rule using immap_is_in_list or immap_is_in_list_of_ip |
| ORIG_SEND_ACCESS *|*|*|* $[/opt/SUNWmail/imta/lib/libimtamap.so, immap_is_in_list,$1|/tmp/bad_from.txt|$$NNo$ Spam$ Allowed$ Here] |
| Any mail from someone in the bad_from.txt file will be returned to the sender with the message No Spam Allowed Here. The case-independent version is called immap_is_in_cilist. It is particularly useful when dealing with domains which are case-insensitive.If you are blocking IP addresses, use the command immap_is_in_list_of_ip. |
SMTP AUTH is by default turned off. It can be activated by using the maysaslserver, mustsaslserver, nosaslserver, nosasl, and saslswitchchannel channel keywords in the appropriate SMTP channel blocks (imta.cnf). The channels keywords are described in more detail in the SIMS Reference Manual. Refer to the SIMS Concepts Guide for conceptual information.
nosasl is the default, and means that SASL authentication will not be permitted or attempted. It subsumes nosaslserver.
nosaslserver specifies that SASL authentication will not be permitted.
maysaslserver causes the SMTP server to permit clients to attempt to use SASL authentication.
mustsaslserver specifies that the SMTP server insist that clients use SASL authentication; the SMTP server will not accept messages unless the remote client successfully authenticates.
saslswitchchannel is used to cause incoming connections to be switched to a specified source channel upon a client's successful SASL use. It takes a required value, specifying the channel to which to switch.
A site that generally blocks SMTP relaying through their SMTP server, but wishes to allow such SMTP relaying for specific users who will authenticate themselves using SASL, might use channel definitions similar to these given below. This type of configuration is particularly appropriate for sites wanting to allow roaming users to keep relaying mail through their domain's mail server, while preventing other users to do the same.
In imta.cnf:
tcp-daemontcp_auth smtp mx single_sys mustsaslservertcp-auth-daemon
with an ORIG_SEND_ACCESS mapping table (/etc/opt/SUNWmail/imta/mappings) like this:
tcp_local|*|tcp_local|* $NRelaying$ not$ permitted
An attempt to submit a message with no authentication would go straight back out the tcp_local channel and therefore would be rejected due to the ORIG_SEND_ACCESS entry shown.
But if a connection from an external system performs SASL authentication, the connection is switched to the tcp_auth channel. The tcp_auth channel will not allow messages submission unless the remote connecting client successfully authenticates itself. For connections that do authenticate, the messages will be accepted on the tcp_auth channel, and may be relayed out through the tcp_local channel, should that be the appropriate destination channel.
A similar example would be for a site that also allows relaying by internal clients or systems as well as authenticated external clients. Such a configuration will use the switchchannel keyword and rewrite rules to identify and switch "internal" connections to the tcp_intranet channel:
imta.cnf (rules)
imta.cnf (channel blocks)
with an ORIG_SEND_ACCESS mapping table like this:
Connections from internal systems will be switched to the tcp_intranet channel. That channel will permit SASL use (though clients need not bother to use SASL). Connections from external systems that use SASL to authenticate will be switched to tcp_intranet. Messages from internal users or external users who use SASL authentication will be permitted to be submitted to the Internet. But all other attempted messages submissions from external systems, to attempted Internet destinations, will be rejected due to the ORIG_SEND_ACCESS entry.
The PLAIN SASL mechanism implies that user passwords are sent in clear text. Passwords should never be sent in clear test in an untrusted environment unless over Transport Layer Security protocol (SSL) or other forms of encrypted TCP/IP connection.
What this means is that SMTP AUTH with the PLAIN mechanism can only be used in a trusted network environment. In the near future, SIMS will support encrypted SMTP connections, which will allow the PLAIN SASL mechanism to be used in untrusted environments as well.
|
|
"Identifying the Source of Incoming SMTP Messages" on page 143 |
|
|
"Logging Messages Passing Through IMTA" on page 143 |
|
|
"Snapshot of Message Traffic Through IMTA" on page 144 |
This section points out some message logging and tracking techniques.
SIMS provides a variety of channel keywords (for example, identtcp, identtcplimited) for identifying the sources of incoming SMTP messages. See the Reverse DNS and IDNET Lookups on Incoming SMTP Connections section in the SIMS Reference Manual for more details on these channel keywords.
The logging channel keyword causes IMTA write a log file entry for each pass of a message through a IMTA channel. Note that with logging turned on, the cumulative mail.log file in the IMTA log directory will continue to grow and grow; IMTA itself never does anything with this log file and it is up to you to periodically write it to backup and delete it, or truncate it, or whatever you prefer.
In addition to the base set of data logged when the logging keyword is used, there are options to cause the log output to include additional details, as discussed below.
In addition to the base set of logging enabled via the logging channel keyword, IMTA has options that cause additional information to be included in the entries written to the mail.log* files. Note that logging such additional information tends to incur additional overhead.
In particular, setting LOG_MESSAGE_ID=1, LOG_CONNECTION=1, and LOG_FILENAME=1 in your IMTA option file may be of interest on a IMTA email firewall. Logging the message ID makes it easier to find entries in the log file corresponding to a particular message, or to correlate different entries in the log file corresponding to a single message. Logging the SMTP client connection information can be useful to show just what system really sent the message to your IMTA firewall. Logging the filename can be useful if you wish to correlate log file entries with actual message files currently in the IMTA queue area.
Setting LOG_HEADER=1 may be of interest if you wish to save certain message headers to the mail.log* files.
Additionally, setting LOG_PROCESS=1 and LOG_USERNAME=1 on a IMTA firewall system ought generally to result in fairly monotonous extra information being logged: the process id of the process enqueuing a message on a IMTA firewall system would normally be that of a IMTA Worker Process (for SMTP messages), and the user name would normally just be the user name of the user who last started the IMTA Service Dispatcher. Enable these options if you wish to confirm that the process ids and usernames of processes enqueuing messages are as expected.
IMTA maintains channel counters based on the Mail Monitoring MIB, RFC 1566. These counters can provide "snapshots" of the state of the IMTA queues as well as a feel for the volume of messages passing through IMTA.Refer to the SIMS Reference Manual.
|
|
"Imposing Message Size Limits" on page 145 |
|
|
"Message Priority Limits" on page 145 |
|
|
"Imposing Message Sensitivity Limits" on page 145 |
|
|
"Checking or Filtering Message Content" on page 146 |
This section discusses imposing limits on the size or sensitivity of messages allowed through, and the related issue of setting message priority based on size, and general checking or filtering of message content.
The IMTA options BLOCK_LIMIT and LINE_LIMIT can be used to impose global size limits on all IMTA channels. The channel keywords blocklimit and linelimit can be used to impose size limits on specific channels. These parameters can also be specified using the Admin Console, see "Message Limitation" on page 101.
IMTA jobs pay attention to message priority, i.e., to the presence of a Priority: header in the message. The priority of message that IMTA immediate jobs (those jobs created when a message is first submitted) will handle may be controlled with the immnonurgent, immnormal, and immurgent channel keywords. The priority of message that IMTA periodic jobs (those jobs run periodically by IMTA to retry delivery of previously undelivered messages) will handle may be controlled with the minperiodicpriority and maxperiodicpriority keywords.
Some sites may wish to control the time of day, for instance, at which low priority messages are sent. And note that the nonurgentblocklimit, normalblocklimit, and urgentblocklimit keywords may be used to forcibly downgrade the priority of "large" messages.
The channel keywords sensitivitynormal, sensitivitypersonal, sensitivityprivate, and sensitivitycompanyconfidential may be used to impose an upper limit on the sensitivity of messages that may be enqueued to a channel. For instance, a site wishing not to emit messages of Company-confidential sensitivity might choose to set sensitivityprivate on their channel that sends out to the Internet, generally a tcp_local channel.
The best protection against problematic message content coming into your site is educated users who are committed to implementing your site security policies. The best protection against problematic message content leaving your site is educated users who are committed to conforming to your site security policies. If the users wish to evade your policies, they can generally work around any imposed restrictions, for instance, by encrypting their messages.
If you do wish to check the actual content of message parts, the IMTA conversion channel can be useful. You may use a CONVERSION mapping table to direct that certain message traffic, that is messages coming in certain channels and going out certain channels, pass through the IMTA conversion channel. The IMTA conversion channel can then run whatever content checking or filtering procedure or utility you wish.
For instance, some sites like to have binary message attachments checked by virus sniffing software. A CONVERSION mapping table along the lines of
IN-CHAN=*;OUT-CHAN=tcp_internal;CONVERT Yes
and IMTA conversions file entries along the lines of
where yourviruscheckcommand is a site-supplied command to do virus checking, will run any MIME message parts of type APPLICATION, AUDIO, IMAGE, or VIDEO MIME through your procedure.
Note that when you are using the conversion channel to check message parts on the IMTA firewall system, you are likely to want the defragment channel keyword on outgoing channels, particularly channels that send to internal systems. The MIME format allows for messages to be split into multiple pieces, which are normally not reassembled until arrival at the final destination system. However, if you want the intermediate IMTA firewall system to check the message content, you will want to reassemble the message parts on the IMTA firewall system, so that the message content (rather than message content fragments) can be checked.
|
|
"Separating External and Internal Message Traffic" on page 147 |
An email firewall refers to an enhanced, firewall-oriented email handling component on an Internet firewall system. A basic Internet firewall system generally controls what TCP/IP interactions are allowed between the external world, considered to be unsafe, and an internal, protected environment, considered to be safe. To be an email firewall system, this system should also check and control the email passing between the internal and external environments.
|
|
An email firewall system may perform address transformations, converting external presentation addresses in messages incoming from the external world to actual internal addresses, and transforming internal addresses to external presentation addresses on messages outgoing to the external world. |
|
|
A firewall system may enforce restrictions on what messages are allowed in or out. In particular, an e-mail firewall may disallow certain sorts of message traffic, and may be configured to protect against denial of service attacks. |
|
|
An email firewall is careful in what information it emits in response to external system's possible probe attempts. |
One of the fundamental issues for a firewall configuration tends to be separation between internal and external messages. Separating message traffic allows for tracking and appropriately controlling the different sorts of messages. This means separate channels have to be set up to handle messages originating from external sites versus messages originating from internal systems. Internally, the SMTP internet channel is called tcp_local while the SMTP intranet channel is called tcp_intranet.
A SIMS installation will by default have two SMTP channels, an SMTP intranet and SMTP internet channel, configured for this purpose, if during installation it was specified that this mail server is on a firewall system connected to the internet. This setting can also be done through the Admin GUI's IMTA property book page, after installation. (Refer to "To Configure IMTA Position Relative to the Internet" on page 91).
To achieve the separation of message traffic, rewrite rules are added to associate all internally originating traffic with the tcp_intranet channel. The switchchannel keyword is added to the tcp_local channel. The noswitchchannel keyword is added to all other channels except tcp_intranet, because by default, the IMTA allows any channel to be "switched to"; i.e, the default is allowswitchchannel, and this is not desirable on a firewall system. (Refer to the SIMS Reference Manual for information on channel keywords.)
So in order to allow internal systems to be recognized even if a DNS reverse lookup for the incoming IP connection fails, you should use IP literal rewrite rules to associate internal IP literals (at least during backwards envelope rewriting) with your internet SMTP channel. If you wish to limit the rewriting of internal IP addresses to actual system names in the forward direction, say if you do not wish to allow external users to "probe" for internal IP address/internal system name correspondences, then you may want these IP literal rewrite rules to be backwards envelope specific, i.e., $E$R rewrite rules.
It is possible to tell the IMTA to not perform DNS reverse lookups, in which case these IP-based rules are mandatory in order to distinguished internal traffic from external traffic. The DNS reverse lookup is turned off by using the indentnonenumeric channel keyword.
When a message comes through to the tcp_local channel, the IMTA performs a DNS reverse lookup on the incoming IP address. If the reverse lookup succeeds in returning a domain name, IMTA uses that name (and otherwise uses the literal IP address of the incoming connection) to do a reverse-pointing envelope rewrite looking for an associated channel. The rewrite rules associated with the tcp_intranet channel helps the IMTA determine whether to "switch" or not.
Note that the default incoming TCP/IP channel is tcp_local and only system names recognized as internal system names are "switched" to the tcp_intranet channel. This provides "fail-safe" behavior; systems not specifically recognized (even internal systems, if the MTA configuration has not been set up to recognize them) are handled by the external, "unsafe" channel.
Sample configuration of smtp channels on a firewall system
By adding the noreverse keyword to the tcp_intranet channel, address reversal is not done for internal mail. But for the tcp_local channel, address reversal (transforming internal addresses to external presentation addresses on messages outgoing to the external world) is performed, since reverse is the default setting for an MTA channel.
The remotehost channel keywords is used on the tcp_local channel. The remotehost and noremotehost channel keywords affect the IMTA's handling of bare usernames ("addresses" that are illegally formatted in that they have no domain name). The IMTA always inserts a domain name on such addresses, to make the addresses syntactically legal. The remotehost channel keyword on the tcp_internet channel (handling incoming messages from external sites) tells the IMTA to use the remote sending system's (as determined by a reverse DNS lookup); the default noremotehost channel keyword on the tcp_internet channel (handling incoming messages from internal sites) tells the IMTA to use its own local host name.
The inner keyword causes the IMTA address rewriting to be applied to addresses in embedded message parts (MESSAGE/RFC822 parts) within the message; if you are applying address reversal on outgoing messages, this is liable to be desirable.
|
|
"Restricting SMTP Probe Commands" on page 150 |
|
|
"Removing Internal Names in Received Headers" on page 151 |
This section describes various ways information that you might not wish to publish can leak out and describes ways of blocking this.
During an SMTP connection, a remote sending side (or a person manually telnetting to your SMTP port) can issue commands requesting information such as a check on the validity of addresses. This very useful information can, however, be subject to abuse, for example, by automated search engines checking for valid email addresses on your firewall system. Therefore some sites may have an interest in disabling these helpful features. Refer to section on SMTP Channel Option Files in the SIMS Reference Manual.
Setting DISABLE_EXPAND=1 in your Internet TCP/IP channel option file disables the SMTP EXPN command. The SMTP EXPN command is normally used to expand (get the membership of) mailing lists.
Setting HIDE_VERIFY=1 in your Internet TCP/IP channel option file causes the IMTA to return a "generic" response to the SMTP VRFY command. The SMTP VRFY command is normally used to check whether an address is a legitimate address on the local system. (Note that because it is required that SMTP servers support the VRFY command, the IMTA has to return some sort of response; with HIDE_VERIFY=1, this response is simply a "maybe" sort of response rather than an explicit yes or no.)
Setting DISABLE_ADDRESS=1 in your Internet TCP/IP channel option file causes the IMTA to disable responses to the IMTA's private XADR command, which normally returns information about the channel an address matches.
Setting DISABLE_STATUS=1 in your Internet TCP/IP channel option file causes the IMTA to disable responses to the IMTA's private XSTA command, which normally returns information about the numbers of messages in IMTA queues.
Setting DISABLE_GENERAL=1 in your Internet TCP/IP channel option file causes the IMTA to disable responses to the IMTA's private XGEN command, which normally returns status information about whether an IMTA compiled configuration and character set are in use.
A sample TCP/IP channel option file to disable probing via the SMTP server, for a site using a tcp_local channel, would be as shown in the following example.
Received headers are normally exceptionally useful headers for displaying the routing that a message really took. Their worth is apparent in cases of dealing with what appears to be forged email, or in cases where you are trying to track down what happened to a broken message, or in cases where a message does not appear to be replyable and you are trying to figure out who might know how to respond to the message. Received headers are also used by the IMTA and other mailers to try to detect message loops.
Message-id headers are normally useful for message tracking and correlation.
However, on the converse side, Received headers on messages you send out give the message recipient information about the routing that a message really took through your internal systems and tend to include internal system names and possibly an envelope recipient address. Also, Message-id headers tend to include internal system names. At some sites, this may be considered a security exposure.
If your site is concerned about this information being published, first see if you can configure your internal systems to control what information they put in these headers. For instance, the IMTA options RECEIVED_DOMAIN and ID_DOMAIN can be used on an IMTA system to specify the domain name to use when constructing Received headers and Message-id headers, respectively. Although these options are not usually particularly relevant on the IMTA firewall system itself--the firewall system is by definition a system whose name is intended to be visible to the outside world--if you have the IMTA on internal systems also, the options may be of interest on those internal IMTA systems. In a similar spirit, the channel keyword noreceivedfor can be used on channels on an IMTA system to instruct the IMTA not to include the envelope recipient address in the Received header it constructs, if limiting the exposure of internal "routing" addresses is a concern for your site. Only if you cannot configure your internal systems to control such sorts of information should you consider resorting to stripping off such headers entirely.
Received and Message-id headers should not be removed lightly due to their many and important uses, but if the internal routing and system name information in them is sensitive for your site and if you cannot configure your internal systems to control what information appears in these headers, then you may wish to strip off those headers on messages going out to the Internet via header trimming on your outgoing TCP/IP channel.
Note - Do not remove Received or Message-id headers on general principles or because your users do not like them. Removing such headers (1) removes one of the best tracking mechanisms you have, (2) removes information that may be critical in tracking down and solving problems, (3) removes one of the few (and best) warnings of forged mail you may have, and (4) blocks the mail system's ability to detect and short-circuit message loops. Only remove such headers if you know your site needs them removed.
To implement header trimming, put the headertrim keyword--you will probably want the innertrim keyword as well--on your outgoing external TCP/IP channel or channels, generally tcp_local and possibly other tcp_* channels (possibly every tcp_* channel except your internal channel, tcp_internet), where the x depends upon the TCP/IP package you are using, and create a header trimming file for each such channel. The headertrim keyword causes header trimming to be applied to the outer message headers; the innertrim keyword causes the header trimming to be applied also to embedded message parts (MESSAGE/RFC822 parts) within the message. A sample header trimming file for a site using a tcp_local channel is shown in the following example.
The extended SMTP command ETRN (RFC 1985) allows an SMTP client to request that a remote SMTP server start up processing of the remote side's message queues destined for sending to the original SMTP client; that is, it allows an SMTP client and SMTP server to negotiate "switching roles," where the side originally the sender becomes the receiver, and the side originally the receiver becomes the sender. Or in other words, ETRN provides a way to implement "polling" of remote SMTP systems for messages incoming to one's own system. This can be useful for systems that only have transient connections between each other, for instance, over dial-up lines. When the connection is brought up and one side sends to the other, via the ETRN command the SMTP client can also tell the remote side that it should now try to deliver any messages that need to travel in the reverse direction.
The SMTP client specifies on the SMTP ETRN command line the name of the system to which to send messages (generally the SMTP client system's own name). If the remote SMTP server supports the ETRN command, it will trigger execution of a separate process to connect back to the named system and send any messages awaiting delivery for that named system.
See also Channel Configuration Keywords section in the SIMS Reference Manual for a discussion on the channel keywords that affect the IMTA sending and behavior upon receipt of ETRN commands.
The ETRN command may be quite useful on an e-mail firewall system, particularly if communication partners have only dial-up or other intermittently scheduled connectivity. But for general external SMTP connections, you may wish to limit the number of ETRN commands to which the IMTA will respond in a single session, so that a single remote site cannot attempt to "monopolize" the IMTA system's message delivery processing. For this, the ALLOW_ETRNS_PER_SESSION channel option may be used in the external TCP/IP channel's option file.
Also, in the interest of limiting the amount of information about the firewall's configuration visible externally, you may wish to block the IMTA's normal echo of the name of the IMTA channel an ETRN command domain matches on the tcp_internet channel handling general external SMTP connections. For this, specify the silentetrn channel keyword on the tcp_internet channel.