sendmail, 4th Edition

Pitfalls

• Any text following a rule set number in a $> expression in the RHS sho uld be separated from the expression with a space. If the space is absent and the text is something other th an 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 (Batch Rule-Set Testing on page 319) and selected -d (debugging) switches (Table 15-3 on page 536).

• 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 either be 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 ...