The syslog database-map type allows you to log messages directly from inside rule sets. If you are unfamiliar with syslog, see Section 14.3 for a general discussion of syslog-style logging.

The syslog type is declared like this:

Kname syslog switches 

The name is the database-map name you will use in rule sets. The switches are selected from those shown in Table 23-25.

In rule sets, the syslog type is used, for example, like this:

R $*    $: $(name what to log $) 

The information in the position of the key is logged as is via the syslog facility. An empty workspace is returned as a result of logging. That is, for the syslog type, the $( and $) expressions evaluate to an empty string.

Any use of defined macros in the message should use the $& prefix so that the current value is logged. For example, the following might be used to log the load average:

Kdolog syslog
R $*    $: $(dolog The cutoff was caused by a load average of $&{load_average}. $)

If you need to have a sendmail macro or positional macro literally logged as is, just prefix it with an extra $ character. For example, the following shows the macro and logs its value:

R $*    $: $(dolog Failure detected with $$1=$1 $)

Don't use quotation marks to surround macro references. Quotation marks cause the macro's internal binary value to print, instead of its defined value. For example, the following will log $1=^U1:

R $*    $: $(dolog $$1="$1" $)      wrong

If macros are not included inside quotation marks, you can use quotation marks for clarity. They will be stripped from the output:

R $*    $: $(dolog "Aborting the use of ETRN because of high load" $)

In general, this syslog type of database map will be used in conjunction with other database maps that can make decisions about behavior, such as arith (arith). You should avoid the temptation to overlog because rule sets can be parsed every time mail is sent or received, and, if you place a logging rule in the wrong place, you risk flooding your site's syslog facility with extraneous messages.