One of the most basic anti-spam mechanisms employed by MTAs is to check that the reverse DNS records for the IP address of an incoming connection match the forward DNS records for the domain the connection is claiming to be from. This is a fairly basic way to check if a connection is coming from a properly configured mail server or from a spam zombie. A basic step to take when setting up your own MTA is to ensure that the reverse DNS records for the IP address it’s running on are published properly.
On machines with multiple IP addresses you may want to set up Exim to only listen on particular ones. E.g. a single IPv4 and IPv6 address. This can be useful if your mail server is also a web server, and has dozens of IP addresses. The only alternative is to publish reverse DNS records for every single IP address with the name of your server (which is no good if you want to run more than one mail server, but that’s a fairly niche thing to do).
You specify which addresses to listen on in your Exim configuration using the “local_interfaces” directive (on Debian, this is set in the “update-exim4.conf.conf” file with the “dc_local_interfaces” directive).
This only affects the listen addresses, the addresses used for sending outgoing mail are still picked by the system automatically. This has the undesired side effect of meaning your MTA might choose to send mail using an IP address which doesn’t have reverse DNS set up properly, and can lead to bounced mail (or a high spam ranking).
To fix this it’s necessary to modify the behavior of the SMTP transport. The Debian configuration for Exim comes with one remote SMTP transport by default, a line can be added as such to the template:
# This transport is used for delivering messages over SMTP connections.
debug_print = "T: remote_smtp for $local_part@$domain"
driver = smtp
interface = <; 220.127.116.11; 2001:470:1f09:398::1
(The <; changes the field separator from ":" to ";", which is needed when entering IPv6 addresses)
Obviously it’s better not to hard code this into the template file, so a custom debconf macro can be set up to allow the details to be entered via the config file if needed.
It’s also worth noting that you can specify different interface directives for different SMTP transports, potentially on a domain-by-domain basis. This could be used in a virtual email hosting situation for multiple domains hosted on different IP addresses. This would then give the impression that each domain had its own SMTP server as set up in DNS, providing for an easier transition if you wanted to move hosting to another box or provider.