Following some security hardening on an “older” Ubuntu 12.04.2 LTS VPS, I noticed that messages were not being delivered by the Sendmail MTA.

I run Sendmail in conjunction with Fail2ban to protect common public-facing services from brute-force attempts–using both stock and custom written filters. When an attack is successfully identified and mitigated, a report including a WHOIS is delivered to my personal mailbox.

Additionally, a notification is supposed to be sent out, if and/or when the service’s status changes, i.e. is restarted or stopped.

Messages weren’t flowing. Let’s investigate.

A stock Sendmail configuration logs mail server activity to /var/log/mail.log:

1

$ sudo tail /var/log/mail.log

Here’s the relevant line:

1

localhost sendmail[29980]: to=[email protected], delay=00:00:04, xdelay=00:00:04, mailer=relay, pri=30197, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection timed out with [127.0.0.1]

Well that’s weird. Messages are being deferred as it can’t reach the local host. Can I get in?

1
2

$ telnet 0 25
Trying 0.0.0.0...

Nope. No response–we should be presented the MTA banner instantly.

We need to add an additional rule to our iptables INPUT chain to allow traffic from the local interface:

1

$ iptables -I INPUT -i lo -j ACCEPT

You should now see this:

1
2
3
4

$ iptables -L INPUT -nv
Chain INPUT (policy DROP 9 packets, 420 bytes)
 pkts bytes target     prot opt in     out     source               destination
  625 82192 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0

Now we can get in:

1
2
3
4
5
6
7

$ telnet 0 25
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
220 my.cool.fqdn ESMTP Sendmail 8.14.4/8.14.4/Debian-2ubuntu2;
EHLO localhost
250-my.cool.fqdn Hello localhost [127.0.0.1], pleased to meet you

Sendmail will quickly attempt to re-deliver all the deferred messages in the queue.