The result of a subroutine call cannot be looked up directly in a database map. Consider this RHS of a rule:
$(uucp $>96 $1 $)
Here, the intention is to pass $1 to rule set 96 and then to look up the result in the uucp database map. Instead, the literal value 96 and the value in $1 are looked up together and fail first. Then $1 is passed to rule set 96, and the result of that subroutine call becomes the result of the RHS.
If you are running a Solaris 2.4 or earlier release of Sun's operating system, your database files should not live on tmpfs-mounted filesystems. File locking was not implemented for tmpfs until Solaris 2.5.
Avoid assuming that all K command switches mean the same thing for all types. The ad hoc nature of database-type submissions by outsiders makes that assumption perilous.
Not all initialization errors or lookup errors are reported. For some of them you will see an indication of an error only if you use the -d38.2 debugging switch (-d38.2).
The sendmail program automatically creates certain database maps as it needs them. This is done without the need to declare them with a K configuration command. For example, consider the following mc configuration line:
When sendmail encounters this AliasFile option (AliasFile), it automatically creates the aliases.files database map so that it can easily look up aliases. sendmail automatically creates the following database maps: aliases.files, aliases.nis, aliases.nisplus, aliases.netinfo, aliases.hesiod, passwd.files, passwd.nis, passwd.nisplus, passwd.hesiod, and users. You should avoid using these database maps in rule sets because they are essentially internal to sendmail and can change without notice.