A client mentioned that they were having sendmail problems, and later asked if I'd be willing to take a look. Now I have a love/hate relationship with sendmail. At some level it's always been a sort of SysAdmin proving ground. I still have my copy of the "bat" book, but we won't talk about which edition.
Anyway, this particular configuration handed off mail to procmail for processing, but procmail never got started. You could see the queue filling up (to the point that an ls on the directory wouldn't complete) but nothing we tried would get mail moving.
There are two other nodes that serve the same purpose that were working, so we compared them to the broken node. There were many configuration differences, including a different version of sendmail. The two working nodes had a custom compiled version instead of the vendor-supplied version. Assuming that was the problem, I went through the trouble to compile sendmail.
Only to have the same problem.
Digging in, we ran /usr/lib/sendmail -q -v, which processes the queue verbosely. There was an error message "(alias database unavailable)" for every message. Aha! It must be a permissions problem. But comparing permissions (and running "newaliases") shows that it's not.
Finally after much googling I came across this: http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1261082290994+28353475&threadId=137395
Which led us to check /etc/nsswitch.conf and see that aliases was referencing the nisplus database. But this host isn't using nisplus.
Changing the aliases entry to just "files" fixed the problem.
