Andrew Derbyshire writes: >It looked like your routine built a wonderful RFC822 header, but didn't >reduce it, or did the original have an odd number of quotes? From a >human standpoint, "Andrew H. Derbyshire" should stay that, not become >"\"Andrew H. Derbyshire\"" or ("Andrew H. Derbyshire"). Also, you >might try quoting the name via parenthesis instead if the special >character "quote" is in the header. Although I agree that the original quoted string should stay as it is rather than having its quotes escaped and extra quotes added, that is a special case. (By the way, I got Eric's version without an odd number of quotes.) It does make sense to quote the "phrase" part of the second (phrase route-addr) definition of "mailbox" when necessary to denature "specials", when it is not already adequately quoted. Your other suggestion (parentheses) has limited applicability and little point, since "s are perfectly valid in "phrase"s if balanced. First, if you comment out the entire "phrase", you have to remove the <> around the "route-addr", which must then conform to "addr-spec" format (no "route" part). Second, if the original "phrase" contained unbalanced parentheses in quotes, it was valid, but the addition of parentheses around the whole thing denatures the quotes and the result becomes invalid. An example of the first point: "Andrew H. Derbyshire" <$AHC@CLVM> cannot become ("Andrew H. Derbyshire") <$AHC@CLVM> but must be ("Andrew H. Derbyshire") $AHC@CLVM instead. (Now, I don't really believe that is *right*, just required by RFC822.) An example of the second point: "Andrew H. Derbyshire (202 555-1212" <$AHD@CLVM> cannot become ("Andrew H. Derbyshire (202 555-1212") <$AHD@CLVM> or even ("Andrew H. Derbyshire (202 555-1212") $AHD@CLVM due to unbalanced parentheses. Silly? Possibly, but it can happen in a world of limited field lengths and human typists. --Mark