10.4 Nested Angle Brackets

Another kind of address that can cause problems is one containing nested angle brackets. These occur because of bugs in MUAs. [2] For example, consider the following address:

[2] Also because RFC733 misspecified angle bracket use.

<a<b>c>

Run sendmail in rule-testing mode, using the current client.cf file and give the nested address shown above to rule set 3:

> 3 <a<b>c>
rewrite: ruleset  3   input: < a < b > c >
rewrite: ruleset  3 returns: a < b

Clearly, this is wrong. The correct address should have been b, the address inside the innermost of the nested angle brackets. The rule that caused the mistake is this one:

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 < is not seen as anything special. That is, there is no concept in this rule of innermost and outermost angle brackets pairs.

To handle nested angle brackets, another rule needs to be designed. [3] That new rule looks like this:

[3] In Chapter 29, Rule Sets, we show a rule that de-nests a nearly unlimited number of angle brackets.

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
R$* < $* < $* > $* > $*     $2<$3>$4        de-nest brackets           new
R$* < $* > $*       $2                      basic RFC822 parsing

Run sendmail again to test this new rule:

> 3 <a<b>c>
rewrite: ruleset  3   input: < a < b > c >
rewrite: ruleset  3 returns: b

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:

<<<a>>>

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). [4]

[4] Paraphrased from The Robustness Principle, RFC793, TCP specification. Jon Postel, Ed.