8.6 The Flow of Addresses Through Rules

When rule sets contain many rules, addresses flow from the first rule that is declared through the last (top down). To illustrate, remove the demo rule that you added to the client.cf file, and replace it with three new demo rules:

Rleft.side     new.stuff           remove
Rx     y                           new
Rz     x                           new
Rx     w                           new

Remember that the LHS of each rule must be separated from the RHS by one or more tab characters.

Before you test these new rules, consider what they do. The first rule rewrites any x in the workspace into a y. The second rule rewrites any z in the workspace into an x. The last rule rewrites any x that it finds in the workspace into a w.

Now run sendmail in rule-testing mode once again:

% ./sendmail -Cclient.cf -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
>

Enter rule set 0 and the letter x:

> 0 x
rewrite: ruleset  0   input: x
rewrite: ruleset  0 returns: y

This shows that any x in the workspace is rewritten by the first rule to become a y. The new workspace is carried down to the second rule, where it fails, then to the third rule, where it also fails:

 x           the original workspace
 
 exact match, so: ``true''
 
Rx     y     first rule rewrites
 y              the workspace to be this
 
 does not match, so skip
 
Rz     x     second rule
 y              the workspace is still this
 
 does not match, so skip
 
Rx     w     third rule
 y              the workspace is still this

The important point here is that each rule matches its LHS to the current contents of the workspace. Preceding rules may have modified that workspace. The third rule, for example, tries to match an x but fails because the first rule changed our x into a y.

Now enter rule set 0 and the letter z:

> 0 z
rewrite: ruleset  0   input: z
rewrite: ruleset  0 returns: w

Notice that any z in the workspace is rewritten to be a w. Look at the flow of the z through the rules to see why this happened:

 z           the original workspace
 
 does not match, so skip
 
Rx     y     first rule
 z              the workspace remains this
 
 exact match, so ...
 
Rz     x     second rule rewrites
 x              the workspace to be this
 
 exact match, so ... 
 
Rx     w     third rule rewrites
 w              the workspace to be this

In this instance the first rule does nothing. The second rule matches the z and changes the workspace into an x. The third rule sees the rewritten workspace. It changes the x (the current contents of the workspace) into a w.

Now feed one more letter into sendmail in rule-testing mode. This time, enter anything other than an x or z:

> 0 b
rewrite: ruleset  0   input: b
rewrite: ruleset  0 returns: b

Here, the workspace remains unchanged because b does not match the left-hand side in any of the three rules. If the LHS of a rule fails to match the workspace, that rule is skipped, and the workspace remains unchanged.