Sun Java System Messaging Server 6 2005Q4 Administration Guide

To Add SMTP Relaying

Messaging Serveris, by default, configured to block attempted SMTP relays; that is, it rejects attempted message submissions to external addresses from unauthenticated external sources (external systems are any other system than the host on which the server itself resides). This default configuration is quite aggressive in blocking SMTP relaying in that it considers all other systems to be external systems.

IMAP and POP clients that attempt to submit messages via the Messaging Server system’s SMTP server destined for external addresses, and who do not authenticate using SMTP AUTH (SASL), will find their submission attempts rejected. Thus, you will likely want to modify your configuration so that it recognizes your own internal systems and subnets from which relaying should always be accepted.

Which systems and subnets are recognized as internal is normally controlled by the INTERNAL_IP mapping table, which may be found in msg_svr_base/config/mappings

For instance, on a Messaging Server whose IP address is 123.45.67.89, the default INTERNAL_IP mapping table would appear as follows:

INTERNAL_IP 

   $(123.45.67.89/32)   $Y
   127.0.0.1            $Y
   *   $N

Here the initial entry, using the $(IP-pattern/signicant-prefix-bits) syntax, is specifying that any IP address that matches all 32 bits of 123.45.67.89 should match and be considered internal. The second entry recognizes the loopback IP address 127.0.0.1 as internal. The final entry specifies that all other IP addresses should not be considered internal. Note that all entries must be preceded by at least one space.

You may add additional entries by specifying additional IP addresses or subnets before the final $N entry. These entries must specify an IP address or subnet (using the $(.../...) syntax to specify a subnet) on the left side and $Y on the right side. Or you may modify the existing $(.../...) entry to accept a more general subnet.

For instance, if this same sample site has a class-C network, that is, it owns all of the 123.45.67.0 subnet, then the site would want to modify the initial entry by changing the number of bits used in matching the address. In the mapping table below, we change from 32 bits to 24 bits. This allows all clients on the class-C network to relay mail through this SMTP relay server.

INTERNAL_IP 

   $(123.45.67.89/24)   $Y
   127.0.0.1   $Y
   *   $N

Or if the site owns only those IP addresses in the range 123.45.67.80-123.45.67.99, then the site would want to use:

INTERNAL_IP 

! Match IP addresses in the range 123.45.67.80-123.45.67.95 
   $(123.45.67.80/28) $Y
! Match IP addresses in the range 123.45.67.96-123.45.67.99 
   $(123.45.67.96/30) $Y 
   127.0.0.1 $Y 
   * $N

Note that the imsimta test -match utility can be useful for checking whether an IP address matches a particular $(.../...) test condition. The imsimta test -mapping utility can be more generally useful in checking that your INTERNAL_IP mapping table returns the desired results for various IP address inputs.

After modifying your INTERNAL_IP mapping table, be sure to issue the imsimta restart command (if you are not running with a compiled configuration) or an imsimta cnbuild followed by an imsimta restart smtp (if you are running with a compiled configuration) so that the changes take effect.

Further information on the mapping file and general mapping table format, as well as information on imsimta command line utilities, can be found in the Messaging Server Reference Manual.

Allowing SMTP Relaying for External Sites

All internal IP addresses should be added to the INTERNAL_IP mapping table as discussed above. If you have friendly or companion systems/sites from which you wish to allow SMTP relaying, the simplest approach is to include them along with your true internal IP addresses in your INTERNAL_IP mapping table.

If you don’t wish to consider these as true internal systems/sites, (for instance, if for logging or other control purposes you wish to distinguish between true internal systems versus the friendly non-internal systems with relay privileges), there are other ways to configure the system.

One approach is to set up a special channel for receiving messages from such friendly systems. Do this by creating a tcp_friendly channel akin to your existing tcp_internal channel with official host name tcp_friendly-daemon, and a FRIENDLY_IP mapping table akin to your INTERNAL_IP mapping table that lists the friendly system IP addresses. Then right after the current rewrite rule:

! Do mapping lookup for internal IP addresses 
[]    $E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon

add a new rewrite rule:

! Do mapping lookup for "friendly", non-internal IP addresses
[]     $E$R${FRIENDLY_IP,$L}$U%[$L]@tcp_friendly-daemon

An alternate approach is to add to your ORIG_SEND_ACCESS mapping table above the final $N entry, new entries of the form

tcp_local|*@siroe.com|tcp_local|*     $Y

where siroe.com is the name of a friendly domain, and to add an ORIG_MAIL_ACCESS mapping table of the form:

ORIG_MAIL_ACCESS 

   TCP|*|25|$(match-siroe.com-IP-addresses)|*|SMTP|MAIL|   \
tcp_local|*@siroe.com|tcp_local|*      $Y 
   TCP|*|*|*|*|SMTP|MAIL|tcp_local|*|tcp_local|* $N

where the $(...) IP address syntax is the same syntax described in the previous section. The ORIG_SEND_ACCESS check will succeed as long as the address is ok, so we can go ahead and also do the ORIG_MAIL_ACCESS check which is more stringent and will only succeed if the IP address also corresponds to an siroe.com IP address.