Sendmail Mail-to-Program Failures: Check smrsh

One of the beauties of using a Linux-based Mail Transport Agent (MTA) like Sendmail is the ability to pipe mail into programs. You can use this in conjunction with a filtering application like procmail, with a custom application that collects data about the email, or anything else you can imagine. Best Practical's popular trouble ticketing system RT uses this concept to deliver email into the ticketing system.

Recently we noticed that one of our mail-to-program aliases was no longer working. When we checked, the logfiles were full of entries like the following. I've snipped out a bit of information for privacy purposes.

Aug 11 19:42:56 <hostname> sendmail[13225]: [ID 801593 mail.info] p7C0guOM013225: from=<email_address>, size=5570, class=0, nrcpts=1, msgid=<msgid>, proto=ESMTP, daemon=MTA, relay=relay_host [relay_ip]
Aug 11 19:42:57 <hostname> sendmail[13226]: [ID 801593 mail.info] p7C0guOM013225: to="|/usr/local/bin/script.pl", ctladdr=user (5696/777), delay=00:00:01, xdelay=00:00:00, mailer=prog, pri=35857, dsn=5.0.0, stat=Service unavailable
Aug 11 19:42:57 <hostname> sendmail[13226]: [ID 801593 mail.info] p7C0guOM013225: p7C0gvOL013226: DSN: Service unavailable

The result was a returned message to the sender with the informative statement: "Service unavailable." Yay!

After digging through all sorts of scenarios, we found that the problem was related to smrsh. smrsh is the Sendmail Restricted SHell. It allows server administrators to control what programs Sendmail is allowed to deliver email to. It does this by only allowing programs in a blessed directory to be executed. If your Sendmail installation uses smrsh for delivery to programs, you should see something similar to the following in your sendmail.cf.

Mprog,          P=/usr/lib/smrsh, F=lsDFMoqeu9, S=EnvFromL/HdrFromL, 
                R=EnvToL/HdrToL, D=$z:/, T=X-Unix/X-Unix/X-Unix,
                A=smrsh -c $u

Many installations use /etc/smrsh or /var/adm/sm.bin to store the allowed applications. It is often customary to create symbolic links (symlink) in this directory to the file's actual location.

In our case, we found that a recent directory re-structuring project had left this particular symlink broken. Fixing the symlink fixed the problem.

Photo by cobrasoft.