Run sendmail in rule-testing mode, using the current client.cf file and give the nested address shown above to rule set 3:
Clearly, this is wrong. The correct address should have been
R$* < $* > $* $2 basic RFC822 parsing
And here is why:
workspace LHS $* match zero or more < < match exactly a $* match zero < or more b > > match exactly c $* match zero > or more
Because the workspace is scanned left to right, the second
To handle nested angle brackets, another rule needs to be designed.  That new rule looks like this:
R$* < $* < $* > $* > $* $2<$3>$4 de-nest brackets
This new rule matches any address in the workspace that contains nested brackets. Using the count of LHS operators, the RHS strips away the outermost layer:
R$* < $* < $* > $* > $* $2<$3>$4 de-nest brackets $1 $2 $3 $4 $5
To test this new rule, add it to the client.cf file:
S3 # preprocessing for all rule sets R$* <> $* $n handle <> error address
Run sendmail again to test this new rule:
As predicted, the second rule de-nested, thus allowing the third rule to isolate the address part.
Using what you have learned so far, predict how sendmail will handle this address:
Feed it to sendmail in rule-testing mode to see whether you are correct. Remember that sendmail performs minimum matching.
As a general motto when designing your own rule sets, be liberal in what you accept (including addresses such as <<<a>>> ), but conservative in what you create (never send out such ugly addresses).