The m4 command processes the macro definition files
according to its own syntax rules without understanding anything about correct
sendmail syntax; so there won't be any error messages if
you've gotten anything wrong in your macro definition file. For this reason,
it is very important that you thoroughly test your configuration. Fortunately,
sendmail provides a relatively easy way of doing this.
sendmail supports an “address test” mode that
allows us to test our configuration and identify any errors. In this mode
of operation, we invoke sendmail from the command line,
and it prompts us for a ruleset specification and a destination mail address.
sendmail then processes that destination address using
the rules specified, displaying the output of each rewrite rule as it proceeds.
To place sendmail into this mode, we invoke it with the
–bt argument:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> |
The default configuration file used is the
/etc/mail/sendmail.cf file; you can specify an alternate
configuration file using the –C argument. To test our configuration, we need to select a number of addresses to process
that will tell us that each of our mail-handing requirements are met. To
illustrate this, we'll work through a test of our more complicated UUCP
configuration shown in Example 18-2.
First we'll test that sendmail is able to deliver mail to
local users on the system. In these tests we expect all addresses to be
rewritten to the local mailer on this machine:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 isaac
rewrite: ruleset 3 input: isaac
rewrite: ruleset 96 input: isaac
rewrite: ruleset 96 returns: isaac
rewrite: ruleset 3 returns: isaac
rewrite: ruleset 0 input: isaac
rewrite: ruleset 199 input: isaac
rewrite: ruleset 199 returns: isaac
rewrite: ruleset 98 input: isaac
rewrite: ruleset 98 returns: isaac
rewrite: ruleset 198 input: isaac
rewrite: ruleset 198 returns: $# local $: isaac
rewrite: ruleset 0 returns: $# local $: isaac |
This output shows us how sendmail processes mail addressed
to isaac on this system. Each line shows us what information
has been supplied to a ruleset or the result obtained from processing by a
ruleset. We told sendmail we wished to use rulesets 3 and
0 to process the address. Ruleset 0 is what is normally invoked and we forced
ruleset 3 because it is not tested by default. The last line shows us that
the result of ruleset 0 does indeed direct mail to isaac to the
local mailer.
Next we'll test mail addressed to our SMTP address: [email protected]. We should be able
to produce the same end result as our last example:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 [email protected]
rewrite: ruleset 3 input: isaac @ vstout . vbrew . com
rewrite: ruleset 96 input: isaac < @ vstout . vbrew . com >
rewrite: ruleset 96 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 3 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 0 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 98 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 98 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198 returns: $# local $: isaac
rewrite: ruleset 0 returns: $# local $: isaac |
Again, this test passed. Next we'll test mail to our UUCP style address:
vstout!isaac.
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 vstout!isaac
rewrite: ruleset 3 input: vstout ! isaac
rewrite: ruleset 96 input: isaac < @ vstout . UUCP >
rewrite: ruleset 96 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 3 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 0 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 98 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 98 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198 returns: $# local $: isaac
rewrite: ruleset 0 returns: $# local $: isaac |
This test has also passed. These tests confirm that any mail received
for local users on this machine will be properly delivered irrespective of
how the address is formatted. If you've defined any aliases for your machine, such as virtual hosts, you should repeat these tests for each of the
alternate names by which this host is known to ensure they also work correctly.
Next we will test that mail addressed to other hosts in the
vbrew.com domain is delivered
directly to that host using the SMTP mailer:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 [email protected]
rewrite: ruleset 3 input: isaac @ vale . vbrew . com
rewrite: ruleset 96 input: isaac < @ vale . vbrew . com >
rewrite: ruleset 96 returns: isaac < @ vale . vbrew . com . >
rewrite: ruleset 3 returns: isaac < @ vale . vbrew . com . >
rewrite: ruleset 0 input: isaac < @ vale . vbrew . com . >
rewrite: ruleset 199 input: isaac < @ vale . vbrew . com . >
rewrite: ruleset 199 returns: isaac < @ vale . vbrew . com . >
rewrite: ruleset 98 input: isaac < @ vale . vbrew . com . >
rewrite: ruleset 98 returns: isaac < @ vale . vbrew . com . >
rewrite: ruleset 198 input: isaac < @ vale . vbrew . com . >
rewrite: ruleset 198 returns: $# smtp $@ vale . vbrew . com . /
$: isaac < @ vale . vbrew . com . >
rewrite: ruleset 0 returns: $# smtp $@ vale . vbrew . com . /
$: isaac < @ vale . vbrew . com . > |
We can see that this test has directed the message to the SMTP mailer
to be forwarded directly to the vale.vbrew.com host and
specifies the user isaac. This test confirms that our
LOCAL_NET_CONFIG definition works correctly. For
this test to succeed, the destination hostname must be able to be
resolved correctly, so it must either have an entry in our
/etc/hosts file, or in our local DNS. We can see
what happens if the destination hostname isn't able to be resolved by
intentionally specifying an unknown host:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 [email protected]
rewrite: ruleset 3 input: isaac @ vXXXX . vbrew . com
rewrite: ruleset 96 input: isaac < @ vXXXX . vbrew . com >
vXXXX.vbrew.com: Name server timeout
rewrite: ruleset 96 returns: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 3 returns: isaac < @ vXXXX . vbrew . com >
== Ruleset 3,0 (3) status 75
rewrite: ruleset 0 input: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 199 input: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 199 returns: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 98 input: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 98 returns: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 198 input: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 95 input: < uucp-new : moria > isaac </
@ vXXXX . vbrew . com >
rewrite: ruleset 95 returns: $# uucp-new $@ moria $: isaac </
@ vXXXX . vbrew . com >
rewrite: ruleset 198 returns: $# uucp-new $@ moria $: isaac </
@ vXXXX . vbrew . com >
rewrite: ruleset 0 returns: $# uucp-new $@ moria $: isaac </
@ vXXXX . vbrew . com > |
This result is very different. First, ruleset 3
returned an error message indicating the hostname could not be resolved.
Second, we deal with this situation by relying
on the other key feature of our configuration, the smart host. The smart host
will is to handle any mail that is otherwise undeliverable. The hostname
we specified in this test was unable to be resolved and the rulesets determined
that the mail should be forwarded to our smart host
moria using
the uucp-new mailer. Our smart host might be better connected
and know what to do with the address.
Our final test ensures that any mail addressed to a host not within our
domain is delivered to our smart host. This should produce a result similar
to our previous example:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 [email protected]
rewrite: ruleset 3 input: isaac @ linux . org . au
rewrite: ruleset 96 input: isaac < @ linux . org . au >
rewrite: ruleset 96 returns: isaac < @ linux . org . au . >
rewrite: ruleset 3 returns: isaac < @ linux . org . au . >
rewrite: ruleset 0 input: isaac < @ linux . org . au . >
rewrite: ruleset 199 input: isaac < @ linux . org . au . >
rewrite: ruleset 199 returns: isaac < @ linux . org . au . >
rewrite: ruleset 98 input: isaac < @ linux . org . au . >
rewrite: ruleset 98 returns: isaac < @ linux . org . au . >
rewrite: ruleset 198 input: isaac < @ linux . org . au . >
rewrite: ruleset 95 input: < uucp-new : moria > isaac </
@ linux . org . au . >
rewrite: ruleset 95 returns: $# uucp-new $@ moria $: isaac </
@ linux . org . au . >
rewrite: ruleset 198 returns: $# uucp-new $@ moria $: isaac </
@ linux . org . au . >
rewrite: ruleset 0 returns: $# uucp-new $@ moria $: isaac </
@ linux . org . au . > |
The results of this test indicate that the hostname was resolved, and that the
message would still have been routed to our smart host. This proves that our
LOCAL_NET_CONFIG definition works correctly and it handled
both cases correctly. This test was also successful, so we can happily assume
our configuration is correct and use it.
