Page 122
The -d21.12 in the preceding example tells sendmail to turn on level 12 debugging in section 21 of its code. The same command with the option -d21.36 gives more verbose output (debug level 36 instead of 12).
| NOTE |
You can combine one or more debugging specifications separated by commas, as in -d21.12,14.2, which turns on level 12 debugging in section 21 and level 2 debugging in section 14. You can also give a range of debugging sections, as in -d1-10.35, which turns on debugging in sections 1 through 10 at level 35. The specification -d0-91.104 turns on all sections of V8 sendmail's debugging code at the highest levels and produces thousands of lines of output for a single address. |
The -d option is not limited for use with sendmail's address testing mode (-bt); you can also use it to see how sendmail processes rulesets while sending a letter, as the following example shows:
$ sendmail -d21.36 joe@gonzo.gov < /tmp/letter [lots and lots of output...]
Unfortunately, the SIOG doesn't tell you which numbers correspond to which sections of code. Instead, the author suggests that keeping such documentation current is a lot of work (which it is) and that you should look at the code itself to discover the correct debugging formulas.
The function tTd() is the one to look for. For example, suppose you want to turn on debugging in sendmail's address-parsing code. The source file parseaddr.c contains most of this code, and the following command finds the allowable debugging levels:
$ egrep tTd parseaddr.c
if (tTd(20, 1))
[...]
if (tTd(24, 4))
if (tTd(22, 11))
[etc.]
The egrep output shows that debugging specifications such as -d20.1, -d24.4, and -d22.11 (and others) will make sense to sendmail.
If perusing thousands of lines of C code doesn't appeal to you, the O'Reilly book sendmail, 2nd Ed. documents the debugging flags for sendmail.
The -C option allows you to test new configuration files before you install them, which is always a good idea. If you want to test a different file, use -C/path/to/the/file. You can combine it with the -bt and -d flags. For example, a common invocation for testing new configuration files is
sendmail -Ctest.cf -bt -d21.12
Page 123
| WARNING |
For security, sendmail drops its superuser permissions when you use the -C option. You should perform final testing of configuration files as the superuser to ensure that your testing is compatible with sendmail's normal operating mode. |
Before installing a new or modified sendmail.cf, you must test it thoroughly. Even small, apparently innocuous changes can lead to disaster, and as mentioned in the introduction to this chapter, people get really irate when you mess up the mail system.
The first step in testing is to create a list of addresses that you know should work at your site. For example, at gonzo.gov, an Internet site without UUCP connections, the following addresses must work:
joe joe@pc1.gonzo.gov joe@gonzo.gov
If gonzo.gov has a UUCP link, those addresses must also be tested. Other addresses to consider include the various kinds of aliases (for example, postmaster, an :include: list, an alias that mails to a file, and one that mails to a program), nonlocal addresses, source-routed addresses, and so on. If you want to be thorough, you can create a test address for each legal address format in RFC 822.
Now that you've got your list of test addresses, you can use the -C and -bt options to see what happens. At a minimum, you should run the addresses through rulesets 3 and 0 to make sure that they are routed to the correct mailer. An easy way to do so is to create a file containing the ruleset invocations and test addresses and then run sendmail on it. For example, if the file addr.test contains the lines
3,0 joe 3,0 joe@pc1.gonzo.gov 3,0 joe@gonzo.gov
you can test your configuration file test.cf by typing
$ sendmail -Ctest.cf -bt < addr.test rewrite: ruleset 3 input: joe rewrite: ruleset 3 returns: joe [etc.]
You also might want to follow one or more addresses through the complete rewriting process. For example, if an address resolves to the smtp mailer and that mailer specifies R=21, you can test recipient address rewriting by using 3,2,21,4 test_address.
Page 124
If the sendmail.cf appears to work correctly so far, you're ready to move on to sending some real letters. You can do so by using a command like the following:
$ sendmail -v -oQ/tmp -Ctest.cf recipient < /dev/null
The -v option tells sendmail to be verbose so that you can see what's happening. Depending on whether the delivery is local or remote, you can see something as simple as joe... Sent or an entire SMTP dialogue.
The -oQ/tmp tells sendmail to use /tmp as its queue directory. Using this option is necessary because sendmail drops its superuser permissions when run with the -C option and can't write queue files into the normal mail queue directory. Because you are using the -C and -oQ options, sendmail also includes the following warning headers in the letter to help alert the recipient of possible mail forgery:
X-Authentication-Warning: gonzo.gov: Processed from queue /tmp X-Authentication-Warning: gonzo.gov: Processed by joe with -C srvr.cf
sendmail also inserts the header Apparently-to: joe because, although you specified a recipient on the command line, none was listed in the body of the letter. In this case, the letter's body was taken from the empty file /dev/null, so no To: header was available. If you do your testing as the superuser, you can skip the -oQ argument, and sendmail won't insert the warning headers. You can avoid the Apparently-to: header by creating a file like
To: recipient testing
and using it as input instead of /dev/null.
The recipient should be you so that you can inspect the headers of the letter for correctness. In particular, return address lines must include an FQDN for SMTP mail. That is, a header like From: joe@gonzo is incorrect because it doesn't include the domain part of the name, but a header like From: joe@gonzo.gov is fine.
You should repeat this testing for the same variety of addresses you used in the first tests. You might have to create special aliases that point to you for some of the testing.
The amount of testing you do depends on the complexity of your site and the amount of experience you have, but a beginning system administrator should test very thoroughly, even for apparently simple installations. Remember the flaming toaster.
As much as you may love Linux, you have to deal with the reality that you must contend with other operating systems out there. Even worse, many of them aren't even UNIX based. Although the Linux community has forgiven the users of "other" operating systems, there is still a long way to go before complete assimilation will happen. In the meantime, the best thing that can happen is to use tools to tie the two worlds together.