Problem solve Get help with specific problems with your technologies, process and projects.

The final frontier: Hacking sendmail

While messing with kernel modules isn't trivial, there's a higher peak: hacking sendmail's configuration file. This tip shows you how to ruin your mail system with ease.

Common wisdom on Linux has it that recompiling the Linux kernel is the meanest test of a system administrator's skills. While it's true that messing with kernel modules isn't trivial, there's a higher peak: hacking sendmail's configuration file. This tip shows you how to ruin your mail system with ease.

Sendmail, that crusty and ancient (but also bulletproof) mail program, relies on the /etc/ file. These days, that file is usually generated using a heap of macros, much as a piece of assembly code can be entirely coded in macros. You can, however, hack by hand, as long as you bear all the consequences. In the end it's still a plain text file.

Standard wisdom says: "You can understand if you spend enough time on it, but that time will probably not be well spent." Well, fair enough, but today's an idle day, so let's have a look anyway. really shows its age. It's actually a simple scripting system, where every line is a single command. That's just like Fortran, except every command here is a single letter in column 1 of each row. It's actually easier to see the structure of the file if you make a copy and remove all the comments and blank lines (in the copy!). You'll then see that the file consists of a mess of definition commands of various kinds, followed by a set of what are effectively procedures. Procedures consist of an S command followed by zero or more R commands.

Each R line is like a double-grep command. There are two patterns at work in each line, and the whole point is to crunch up every possible e-mail address into something sensible and standardized. This "canonical" sendmail address format crunching is one of the major reasons why "canonical" became accepted software jargon for fixing messy formats of all kinds. The "Scanonify=3" procedure starts the whole thing off, and all the other procedures are called from there. Blame the wide variety of e-mail addresses during the early phase of the Internet for the complexity of this file.

Changing all those procedures ("rulesets" in sendmail jargon) is a place where even angels fear to tread. A simpler but more rewarding hack is to change the destination of e-mails. That's quite easy.

At the bottom of the file are a couple of M commands. Each of these specifies a program that does the legwork of delivering a received e-mail. This is the spot to hack if you want sendmail to send messages to Exchange, Oracle, Tibco, or any other destination. If your is anything like mine, then for local delivery, there's a procmail delivery agent, perhaps with a line like this:

Mlocal, P=/usr/bin/procmail ... A=procmail -t -Y -a $h -d $u

Well, that's easy. Since the procmail command (type 'man procmail') supports multiple destinations for the -d option, you can change this to:

Mlocal, P=/usr/bin/procmail ... A=procmail -t -Y -a $h -d mailsniffer $u

Now, "mailsniffer" is just a Unix user you've set up for the purpose. You could use "root" instead if you were lazy. A copy of every local e-mail that sendmail handles locally will then accrue in that account.

Sendmail is complex, and there are many ways to achieve similar effects. Struggling for an hour reading is a waste of time that most sysadmins seem to have been through, though. Why read it at all? As mountain climbers say: "Because it's there."

Dig Deeper on Linux servers

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.