The LHS of any rule is compared to the current contents of the workspace to determine whether the two match. Table 28.1 displays a variety of special operators offered by sendmail that make comparisons easier and more versatile.
| Operator | Description or Use | 
|---|---|
| 
$* | Match zero or more tokens | 
| 
$+ | Match one or more tokens | 
| 
$- | Match exactly one token | 
| 
$@ | Match exactly zero tokens (V8 only) | 
| 
$= | Match any tokens in a class a | 
| 
$~ | Match any single token not in a class | 
The first three operators in  
Table 28.1
 are wildcard operators, which can be used to match arbitrary sequences of tokens in the workspace.  Consider  the following rule, which employs the 
$-
 operator (match any single token):
R$- fred.local
Here, a match is found only if the workspace contains a single token (such as 
tom
). If the workspace contains multiple tokens (such as 
tom@host
), the 
LHS
 does not match. A match causes the workspace to be rewritten by the 
RHS
 to become 
fred.local
. The rewritten workspace is then compared again to the 
$-
, but this time there is no match because the workspace contains three tokens (
fred
,  a dot (
.
), and 
local
). Since there is no match, the 
current
 workspace (
fred.local
) is carried down to the next rule (if there is one).
Note that all comparisons of tokens in the 
LHS
 to tokens in the workspace are done in a case-
in
sensitive manner. That is, 
tom
 in the 
LHS
 matches 
TOM
, 
Tom
, and even 
ToM
 in the workspace.
When a pattern-matching operator can match multiple tokens (
$+
 and 
$*
), 
sendmail
 performs 
minimum matching
. For example, given a workspace of 
xxx.yyy.zzz
 and an 
LHS
 of
$+.$+
the first 
$+
 matches only a single token (
xxx
), but the second 
$+
 matches three (
yyy
, a dot, and 
zzz
). This is because the first 
$+
 matches the minimum number of tokens that it can while still allowing the whole 
LHS
 to match the workspace. Shortly, when we discuss the 
RHS
, we'll show why this is important.
Multiple token-matching operators, such as 
$*
, always try to match the fewest number of tokens that they can. Such a simple-minded approach could lead to problems in matching (or not matching) classes in the 
LHS
. For example, consider the following five tokens in the workspace:
A . B . C
Given the following LHS rule:
R$+.$=X$*
Because the 
$+
 tries to match the minimum number of tokens, it first matches only the 
A
 in the workspace. The 
$=X
 then tries to match the 
B
 to the class 
X
. If this match fails, 
sendmail
 backs up and tries again.
The third time through, the 
$+
 matches the 
A.B
, and the 
$=X
 tries to match the 
C
 in the workspace. If 
C
 is not in the class 
X
, the entire 
LHS
 fails.
The ability of the sendmail program to back up and retry LHS matches eliminates much of the ambiguity from rule design. The multitoken matching operators try to match the minimum but match more if necessary for the whole LHS to match.