Controlling Email Access

You can control which users can send messages to which users, what channels can send messages to what channels, impose limits on the size of messages allowed through, and use hooks in the IMTA to allow for dynamic, load-based rejection decisions.


Statically Controlling E-mail Access

In the mapping file (/etc/opt/SUNWmail/imta/mappings) the PORT_ACCESS mapping table can be used to control from what IP numbers IMTA servers will accept connection attempts; the IMTA multithreaded SMTP server checks this table when a connection attempt comes in. The ORIG_SEND_ACCESS mapping table can be used to control, based on From address, To address, and source and destination channel, what messages the IMTA allows to pass through. ORIG_MAIL_ACCESS 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.

Note - ORIG_SEND_ACCESS replaced SEND_ACCESS in SIMS 3.2.
SMTP Connection Control Mapping

The multi-threaded SMTP server is able to selectively accept or reject incoming SMTP connections based on IP address and port number. At SMTP server startup time, the server process will look for a mapping table named PORT_ACCESS. If present, the server will format connection information in the form:

  
TCP|server-address|server-port|client-address|client-port
 

The server will try to match against all PORT_ACCESS mapping entries. If the result of the mapping contains $N, the connection will be immediately closed. Any other result of the mapping indicates that the connection is to be accepted. $N may optionally be followed by a rejection message. If present, the message will be sent back down the connection just prior to closure. Note that a CRLF terminator will be appended to the string before it is sent back down the connection.

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:

  
PORT_ACCESS
  











 



  TCP|*|*|192.123.10.70|*    $N 












 



  TCP|*|*|192.123.10.*|*     $Y 












 



  TCP|*|*|*|*                $N500$ Bzzzzzzzzt$ thank$ you$ for$ playing. 







  		
















Note that if you are using the PORT_ACCESS mapping table you will need to restart the IMTA 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 respectively.






 SMTP Envelope Access Control 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 (note the use of the vertical bar character, |):











 



src-channel|from-address|dst-channel|to-address







  		
















src-channel is the channel originating the message (i.e., 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. 



Now, if the probe string matches a pattern (i.e., the left hand 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. 



Suppose that local users in the domain acme.com, with the exception of the postmaster, are not allowed to send mail to the Internet but can receive mail from there. Then the ORIG_SEND_ACCESS mapping table shown in CODE EXAMPLE 3-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_*, wild cards 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  3-1 	 Restricting Internet Mail Access on UNIX















 



ORIG_SEND_ACCESS












 














 



  *|postmaster@acme.com|*|*  $Y 












 



  *|*|*|postmaster@acme.com  $Y 












 



  l|*@acme.com|tcp_*|*      $NInternet$ postings$ are$ not$ 
permitted 







  		



















 Mail Access Mapping







The third and last access control mapping table combines the two previous mapping tables: ORIG_SEND_ACCESS and PORT_ACCESS. The syntax is similar (it should appear on one line):











 



TCP|server-address|server-port|client-address|client-port|SMTP|MAIL|src-channel|

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_MAIL_ACCESS












 














 



  TCP|*|*|192.9.9.9|*|SMTP|MAIL|tcp_local|*@abc.com|tcp_local|*    $Y












 



  TCP|*|*|*|*|SMTP|MAIL|tcp_local|*@abc.com|tcp_local|*            $N







  		
















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.







 Dynamically Controlling Email Access






When implementing dynamic rejection mechanisms, the TCP/IP channel options ALLOW_TRANSACTIONS_PER_SESSION and ALLOW_RECIPIENTS_PER_TRANSACTION may be of interest. 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. 






 Imposing Message Size Limits







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. 












Copyright © 1999 Sun Microsystems, Inc. All Rights Reserved.