Although a class macro name can be any ASCII character (any character in the range 0x0 to 0x7f), avoid using any
of the nonletter characters. At the very least they create confusing
reading, and at worst they can cause sendmail to
completely misinterpret your intentions.
Although values can traditionally be made to contain whitespace by
quoting them, class macros will misinterpret those quotes. For
example, "vax ds1" wrongly parses into two class
entries: "vax and ds1", with
the quotes a part of each.
Duplicate values are silently ignored. Therefore, typos in a list of
values can cause an accidentally duplicated entry to be silently
excluded.
Avoid creating a new class macro name without first checking to see
whether it has already been used. That is, don't
create a list of UUCP hosts within class $=U
without first checking both for preexisting
CU and FU definitions and for
rule-set uses of $=U and $~U.
It is perfectly legal for the $=U and
$~U expressions to exist in rule sets without a
corresponding CU or FU
definition. However, such empty references will still cause
sendmail to search the string pool.
Under V8 sendmail you can watch your class macro
definitions being formed by using the -d37.8
debugging switch (-d37.8). Under other versions
of sendmail you can only approximate this
information by using the -d36.9 debugging switch.
The file form's scanf(3)
pattern can produce unexpected results. Remember that the pattern is
applied to a line, not to a stream.
No error checking is performed during reads for the
F form of the class configuration command. An I/O
error reading from a file silently causes the rest of that
file's contents to be ignored. An unreported error
from a program (one that silently returns 0 on both success and
failure) is also silently ignored by sendmail.