Printing the entries in a sendmail queue

Since I began managing sendmail installations 8-years ago, I have used the mailq command to print the entries in the sendmail queue. While reading through the bat book to find the root cause of my sendmail DNS problems, I came across sendmail’s “-bp” option:

$ /usr/sbin/sendmail -bp

/var/spool/mqueue is empty
                Total requests: 0

This provides the same results as the mailq command:

$ mailq

/var/spool/mqueue is empty
                Total requests: 0

I am still amazed at how complex the sendmail program is. Rule 0, Rule 3, Rule 5, 8000 macros … ge gads!

Optimizing sendmail smart hosts

While debugging an issue last week, I noticed some odd behavior when the Sendmail Smart host configuration directive (DS) was used. Smart hosts allow nodes to delegate mail delivery services to upstream devices, alleviating the need to run a full blown mail relay on each host. Smart hosts are configured with the Sendmail MC SMART_HOST directive, or through the sendmail.cf/submit.cf DS variable:

$ grep DS /etc/mail/submit.cf
DSsmtp-relay.dns.net

While I was performing a packet capture to isolate a problem with mail delivery, I noticed that each outbound message triggered several odd DNS lookups:

$ snoop -d eri0 port 53

s1 -> dnsserver.dns.net DNS C smtp-relay.dns.net. Internet MX ?
dnsserver.dns.net -> s1 DNS R

s1 -> dnsserver.dns.net DNS C smtp-relay.dns.net.internal.dns.net. Internet MX ?
dnsserver.dns.net -> s1 DNS R Error: 3(Name Error)

s1 -> dnsserver.dns.net DNS C smtp-relay.dns.net.corp.dns.net. Internet MX ?
dnsserver.dns.net -> s1 DNS R Error: 3(Name Error) 

s1 -> dnsserver.dns.net DNS C smtp-relay.dns.net.dns.net. Internet MX ?
dnsserver.dns.net -> s1 DNS R Error: 3(Name Error)

s1 -> dnsserver.dns.net DNS C smtp-relay.dns.net. Internet Unknown (28) ?
dnsserver.dns.net -> s1 DNS R

s1 -> dnsserver.dns.net DNS C smtp-relay.dns.net. Internet Addr ?
dnsserver.dns.net -> s1 DNS R smtp-relay.dns.net. Internet Addr 1.2.3.4 

Upon closer inspection, I noticed that sendmail (actually the resolution libraries) were attempting to resolve the SMTP relay along with each entry in the search path. To fix this issue ( I think it’s an issue, since it’s wasting bandwidth and CPU cycles), I fully qualified the smart host in my submit.cf:

$ grep DS /etc/mail/submit.cf
DSsmtp-relay.dns.net.

Once this was changed, and sendmail was restarted, the resolver only requested entries for the FQDN:

s1 -> dnsserver.dns.net DNS C smtp-relay.dns.com. Internet MX ?
dnsserver.dns.net -> s1 DNS R

s1 -> dnsserver.dns.net DNS C smtp-relay.dns.com. Internet Unknown (28) ?
dnsserver.dns.net -> s1 DNS R

s1 -> dnsserver.dns.net DNS C smtp-relay.dns.com. Internet Addr ?
dnsserver.dns.net -> s1 DNS R smtp-relay.dns.com. Internet Addr 1.2.3.4

I just dusted off my bat book, and hope to find an MC setting to disable MX lookups for the smart host. That should kill four more UDP datagrams. :)

Binding sendmail to the loopback interface

The sendmail SMTP server comes with the vast majority of UNIX Operating systems, and is configured to listen for new connections on TCP ports *.25 (SMTP) and *.587 (MSP) by default. For workstation and servers that aren’t responsible for mail delivery, this can cause chaos when a new sendmail exploit is released into the wild. This behavior can be changed by adjusting the “DaemonPortOptions” in the sendmail configuration file (usually /etc/mail/sendmail.cf). The default configuration looks similar to the following:

O DaemonPortOptions=Name=MTA-v4, Family=inet
O DaemonPortOptions=Port=587, Name=MSA, M=E

If we add “Addr=127.0.0.1” to each entry, sendmail will only listen for new connections on the loopback interface:

O DaemonPortOptions=Addr=127.0.0.1,Port=25,Name=MTA
O DaemonPortOptions=Addr=127.0.0.1,Port=587,Name=MSA, M=E

Once the changes are integrated into the sendmail.cf file ( hand editing the sendmail.cf file or using M4 macros ), sendmail needs to be restarted. Once sendmail is restarted, we can view the new behavior with the netstat command:

$ netstat -an | egrep LISTEN | egrep ‘(25|587)’
127.0.0.1.25 *.* 0 0 49152 0 LISTEN
127.0.0.1.587 *.* 0 0 49152 0 LISTEN

Back in the sendmail 8.10/8.11 days, a smart relay could be used to forward mail, alleviating the need to run sendmail as a daemon. I am still trying to find a way to revert back to the old behavior, but the MSP seems to cause some issues when smart relays are in use. More to come …