The result of a subroutine call cannot be looked up directly in a database map. Consider this RHS of a rule:
$(uucp $>96 $)
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:
define(`ALIAS_FILE', `/etc/mail/aliases')
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.
