Olaf Kirch - Linux Network Administrator Guide, Second Edition

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.comhost 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

> 3,0 isaac@vXXXX.vbrew.com

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 </</code>

@ vXXXX . vbrew . com >

rewrite: ruleset 95 returns: $# uucp-new $@ moria $: isaac </</code>

@ vXXXX . vbrew . com >

rewrite: ruleset 198 returns: $# uucp-new $@ moria $: isaac </</code>

@ vXXXX . vbrew . com >

rewrite: ruleset 0 returns: $# uucp-new $@ moria $: isaac </</code>

@ 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 moriausing the uucp-newmailer. 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

> 3,0 isaac@linux.org.au

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 </</code>

@ linux . org . au . >

rewrite: ruleset 95 returns: $# uucp-new $@ moria $: isaac </</code>

@ linux . org . au . >

rewrite: ruleset 198 returns: $# uucp-new $@ moria $: isaac </</code>

@ linux . org . au . >

rewrite: ruleset 0 returns: $# uucp-new $@ moria $: isaac </</code>

@ 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.

The sendmail daemon can be run in either of two ways. One way is to have to have it run from the inetd daemon; the alternative, and more commonly used method is to run sendmail as a standalone daemon. It is also common for mailer programs to invoke sendmail as a user command to accept locally generated mail for delivery.

When running sendmail in standalone mode, place the command in an rc file so it starts at boot time. The syntax used is commonly:

/usr/sbin/sendmail -bd -q10m

The -bd argument tells sendmail to run as a daemon. It will fork and run in the background. The -q10m argument tells sendmail to check its queue every ten minutes. You may choose to use a different queue to check time.

To run sendmail from the inetd network daemon, you'd use an entry like:

smtp stream tcp nowait nobody /usr/sbin/sendmail -bs

The -bs argument here tells sendmail to use the SMTP protocol on stdin/stdout, which is required for use with inetd.

The runq command is usually a symlink to the sendmail binary and is a more convenient form of:

# sendmail -q

When sendmail is invoked this way, it processes any mail waiting in the queue to be transmitted. When running sendmail from inetd you must also create a cron job that runs the runq command periodically to ensure that the mail spool is serviced periodically.

A suitable cron table entry would be similar to:

# Run the mail spool every fifteen minutes

0,15,30,45 * * * * /usr/bin/runq

In most installations sendmail processes the queue every 15 minutes as shown in our crontab example, attempting to transmit any messages there.

There are a number of things you can do to make managing a sendmail site efficient. A number of management tools are provided in the sendmail package; let's look at the most important of these.

Mail is queued in the /var/spool/mqueue directory before being transmitted. This directory is called the mail spool. The sendmail program provides a means of displaying a formatted list of all spooled mail messages and their status.