Robert A. Uhl

We’ve a few Exchange admins at work this week for a special project (for those of you outside the technorati, Microsoft Exchange is a mail server). One of them dropped by my cube because he was interested in the software I use to relay mail (it, too, is a mail server — I’ve just configured it to pass on mail rather than holding onto it). So I gave him a quick overview of the commands I use to see how many messages are sitting in the queue, to count the number of probably spams, and to track the progress of a message through the system, from arrival, through processing and to departure to its final destination.

The look on his face was priceless. Stunned, he said something along the lines of ‘Now I understand why you guys love Unix so much; it’d have taken us twenty minutes to do that, and with no guarantee of the correct result.’ It had taken me something rather less than a minute.

Yes, Unix has a bit of a learning curve, but once learnt it is part of one’s being, and its capabilities are tools which lie ready for one’s hand. All useful skills require a bit of learning, but the payoff is worth it.

For those who are curious, mailq is a command which prints out a list of the messages currently queued up, whom they’re from, whom they’re to & their status, and finally prints the number of messages sitting in the queue & the number of bytes their contents sum to. tail is another command which shows the end of a file (its tail, you see); so I simply typed mailq | tail -1, which shows the very last line of the output from mailq.

Since I know that a message sitting in the queue for MAILER-DAEMON is probably a bounce from a spam (genuine MAILER-DAEMON messages are almost always delivered instantaneously), I just search the output of mailq for the string MAILER-DAEMON. Fortunately enough, there is a Unix command to search for things: the general regular expression parser (which can do much more complex things than look for a particular string, of course), or grep, so I can run mailq | grep MAILER-DAEMON and see only those lines which contain that string. Of course, that’s not overly useful — I don’t really care to see them; I just wish to count them. There is another command, wc, which counts the number of characters, words and lines in a file (the name comes from word count), so all I need to do is run mailq | grep MAILER-DAEMON | wc -l (the -l tells wc that I just want the line count, not the rest of the info); since each line corresponds to a single message, I know the number of messages. So now I know how many messages there are for MAILER-DAEMON, and I know that messages for MAILER-DAEMON sitting in the queue are almost certainly undeliverable bounces from spams, I know how many of the messages in queue are likely to be caused by spam.

Likewise, when tracing the progress of a message through the system, I just have to examine the logs. They’re simple text files which I can search with grep, perhaps looking for the address of the sender or the recipient — from that found line I can get the ID of the message, and from that I can search the logs for only those lines pertaining to that message. I can see it arrive; I can see the mail server (postfix, a truly excellent bit of software) pass it back-and-forth as it determines where it needs to go & examines it to see whether it might be spam, and I can see it leave.

All these examples use standard bits of the Unix toolkit. Unix was first used for word processing, and those text-oriented tools make searching through system logs dead simple. Since a large portion of a sysadmin’s work involves examining logs, that means that Unix makes my job dead simple.

I pity those stuck with less-capable systems.