Sendmail, 3rd Edition

Pitfalls

• Any text following a rule-set number in a $> expression in the RHS should be separated from the expression with a space. If the space is absent and the text is other than a separating character or an operator, the text is ignored. For example, in $>22xxx, the xxx is ignored.

• Because rules are processed like addresses when the configuration file is read, they can silently change from what was intended if they are parenthesized or if other nonaddress components are used.

• Copying rules between screen windows can cause tabs to invisibly become spaces, leading to rule failure.

• A lone $* in the LHS is especially dangerous. It can lead to endless rule looping and cause all rules that follow it to be ignored (remember the $: and $@ prefixes in the RHS).

• Failure to test new rules can bring a site to its knees. A flood of bounced mail messages can run up the load on a machine and possibly even require a reboot. Always test every new rule both with -bt (testing) mode (Section 8.8) and selected -d (debugging) switches (Table 16-4 in Section 16.6).

• Overloading of operator meanings can confuse the new user, or even the seasoned user when a new release of sendmail appears. Under older versions of sendmail the $: operator, for example, could be either a prefix used to suppress recursion or was a nonprefix used to specify the user in a delivery-agent “triple.” In a later release, it also became the way to specify the default value to return on a failed database-map lookup.