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.
