Recently, in order to qualify for a certification from Hurricane Electric, I had to ensure that I could receive mail using IPv6. Configuring Sendmail to use both IPv6 and IPv4 is not hard on CentOS, but there are some weird gotcha’s to watch out for.
To enable IPv6 for Sendmail, one must first edit their sendmail.mc file, changing the DAEMON_OPTIONS line as follows:
DAEMON_OPTIONS(`port=smtp, Name=MTA, Family=inet6')dnl
Then one must rebuild the configuration, and restart Sendmail, as usual.
make -C /etc/mail
service sendmail restart
By the way, this is contrary to the documentation for sendmail.mc. Apparently, on CentOS (and probably on RHEL too, perhaps) once the daemon is listening on IPv6, it will listen on all IPv4 addresses as well. If you specify both MTA-v6 and MTA-v4 as the docs suggest, both will try to listen on IPv4, causing one to fail to bind.
The big gotcha here is that now Sendmail will listen on all IPv4 addresses, not just the ones you want. It may also use addresses you don’t want for sending outbound mail. If, as was the case in my situation, the machine has addresses that you do not want to use at all for mail, this can pose a problem.
Particularly if your IP for email already has feedback loops set up with ISP’s, if your non-email IP was formerly used by spammers, and/or if your SPF records restrict which IPs may be used, the result can be that your mail gets mistaken for spam.
One interesting feature of netfilter and iptables is Source Network Address Translation, or SNAT. Unlike the MASQUERADE target frequently used with residential-style NATs, connection state does not have to be tracked, since inbound connections do not have to be modified.
For example, let’s assume that you have 2 IPv4 addresses on your machine, $IP1 and $IP2, and only $IP2 is supposed to send emails. You could then add the following to a firewall script, or whatever:
iptables -t nat -A POSTROUTING -s $IP1 -p tcp --dport 25 -j SNAT --to-source $IP2
Now, if Sendmail uses the wrong address to send, it will be transparently corrected by the firewall. Inbound connections to the correct IP will work anyway without modification. Hopefully you already blocked inbound connections on TCP 25 to the incorrect address, so no further iptables tinkering should be needed.
