By default, Messaging Server is 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.
After installation, it is important to manually modify your configuration to match the needs of your site. Specifically, your messaging server should recognize its own internal systems and subnets from which SMTP relaying should always be accepted. If you do not update this configuration, you might encounter problems when testing your MTA configuration.
IMAP and POP clients that attempt to submit messages via 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. Which systems and subnets are recognized as internal is typically controlled by the INTERNAL_IP mapping table, which may be found in the file msg-svr-base/config/mappings.
For instance, on a Messaging Server system whose IP address is 220.127.116.11, the default INTERNAL_IP mapping table would appear as follows:
INTERNAL_IP $(18.104.22.168/32) $Y 127.0.0.1 $Y * $N
The initial entry, using the $(IP-pattern/significant-prefix-bits) syntax, is specifying that any IP address that matches the full 32 bits of 22.214.171.124 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.
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 126.96.36.199 subnet, then the site would want to modify the initial entry so that the mapping table appears as follows:
INTERNAL_IP $(188.8.131.52/24) $Y 127.0.0.1 $Y * $N
Or if the site owns only those IP addresses in the range 184.108.40.206-220.127.116.11, then the site would want to use:
INTERNAL_IP ! Match IP addresses in the range 18.104.22.168-22.214.171.124 $(126.96.36.199/28) $Y ! Match IP addresses in the range 188.8.131.52-184.108.40.206 $(220.127.116.11/30) $Y 127.0.0.1 $Y * $N
Note that the msg-svr-base/sbin/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 msg-svr-base/sbin/imsimta cnbuild and the msg-svr-base/sbin/imsimta restart utilities 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 Chapter 2, Message Transfer Agent Command-line Utilities, in Sun Java System Messaging Server 6.3 Administration Reference. In addition, information on the INTERNAL_IP mapping table can be found in 18.6 To Add SMTP Relaying.