8.5 The Workspace

Whether the LHS test is true or false is determined by making comparisons. When an address is processed by a rule set for rewriting, sendmail first tokenizes it, then stores those tokens internally in a buffer called the workspace:

"gw" "@" "wash" "." "gov"   in the workspace

When the LHS of a rule is evaluated, it too is tokenized; then those tokens are compared to the tokens in the workspace. If both the workspace and the LHS contain exactly the same tokens, a match is found, and the result of the LHS comparison is true. Now, for illustration, create a demo rule by temporarily adding the following two lines to the end of the client.cf file:

S0
Rleft.side     new.stuff

Don't forget that the LHS is separated from the RHS by tab characters. Now run sendmail in rule-testing mode, just as you did before:

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

In rule-testing mode you can view rules with the =S command (see Section 38.4.1, "Show Rules in a Rule Set with =S"). [7] Try it now:

[7] One of several brand-new -bt commands introduced with V8.7 sendmail.

> =S 0
Rleft . side            new . stuff
>

This shows that sendmail found only one rule for rule set 0, the one we created.

Now enter rule set 0 and a typical email address at the prompt:

> 0 [email protected]
rewrite: ruleset  0   input: gw @ wash . dc . gov
rewrite: ruleset  0 returns: gw @ wash . dc . gov
>

The address was not rewritten by the rule because the workspace and the LHS did not exactly match:

[email protected]                the workspace
      
      don't match
      
Rleft.side     new.stuff      the rule

Now, at the prompt, enter the exact text that appears in the LHS of the demo rule:

> 0 left.side
rewrite: ruleset  0   input: left . side
rewrite: ruleset  0 returns: new . stuff

An amazing thing has happened. The rule has actually rewritten an address. The address left.side was given to rule set 0 and rewritten by the rule in that rule set to become the address new.stuff. This transformation is possible because the workspace and the LHS exactly match each other, so the result of the LHS comparison is true:

left.side          the workspace
      
      exact match, so: ``true''
      
Rleft.side     new.stuff
                 
      if true,      then do this

Before leaving this demo rule set, perform one final experiment. Enter the uppercase text LEFT.SIDE:

> 0 LEFT.SIDE
rewrite: ruleset  0   input: LEFT . SIDE
rewrite: ruleset  0 returns: new . stuff
>

Notice that the workspace and the LHS are still considered to match, even though they now differ by case. This illustrates that all comparisons between the workspace and the LHS of rules are done in a case-insensitive manner. This property enables rules to be written without the need to distinguish between uppercase and lowercase letters.