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:
In rule-testing mode you can view rules with the
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:
The address was not rewritten by the rule because the workspace and the LHS did not exactly match:
firstname.lastname@example.org 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:
An amazing thing has happened. The rule has actually rewritten an
address. The address
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
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.