3.18 Logging and Debugging

Depending on its operation mode, mailfromd tries to guess whether it is appropriate to print its diagnostics and informational messages on standard error or to send them to syslog. By default standard error is used if the program is given one of the database management options (see section Databases, or ‘--test’ option (see section Testing Filter Scripts. Otherwise, syslog is used. To alter these defaults, two command line options are provided: ‘--stderr’ to print everything to standard error and ‘--syslog’ to output all diagnostics to syslog.

The data can be sent to syslog using two ways: the syslog function from the system ‘libc’ library, which is a blocking implementation in most cases, and the internal, asynchronous, syslog implementation. See Using non-blocking syslog, for more information on these implementations and for information on how to select the default one. Two options are provided to select the implementation to use at run time: the ‘--syslog-async’ option instructs mailfromd to use asynchronous version, and the ‘--no-syslog-async’ option instructs it to use the blocking version.

The default syslog facility is ‘mail’, and it can be changed with the ‘--log-facility’ option. Argument to this option is a valid syslog facility name, i.e. one of: ‘user’, ‘daemon’, ‘auth’, ‘authpriv(11), ‘mail’, and ‘local0’ through ‘local7’. The argument can be given in upper, lower or mixed cases, and it can be prefixed with ‘log_

Another syslog-related parameter that can be configured is the tag used to identify mailfromd messages. By default the program name is used. The ‘--log-tag’ option can be used to change it.

As all UNIX utilities, mailfromd is very quiet unless it has something important to communicate, for example an error condition or something similar. A set of command line options is provided for controlling the verbosity of its output.

The ‘--trace’ option enables tracing the Sendmail actions executed during the message verification. When this option is given, any accept, discard, continue, etc. triggered during the execution of your filter program will leave their traces in the log file. Here is an example of how it looks like (syslog time stamp, tag and PID removed for readability):

 
k8DHxvO9030656: /etc/mailfromd.mf:45: reject 550 5.1.1 Sender validity
not confirmed

This shows that while verifying the message with IDk8DHxvO9030656’ the reject action was executed by filter script ‘/etc/mailfromd.mf’ at line 45.

The appearance of the message ID in the log deserves a special notice. The program will always identify its log messages with the ‘Message-Id’, when it is available. Your responsibility as an administrator is to make sure it is available by configuring your MTA to export the macro ‘i’ to mailfromd. The rule of thumb is: make ‘i’ available to the very first handler mailfromd executes. It is not necessary to export it to the rest of the handlers, since mailfromd will cache it. For example, if your filter script contains ‘envfrom’ and ‘envrcpt’ handlers, export ‘i’ for ‘envfrom’. The exact instructions on how to ensure it depend on the MTA. For ‘Sendmail’, refer to Using mailfromd with Sendmail..

To push the log verbosity further, use the debug configuration statement (see section Logging and Debugging configuration) or its command line equivalent, ‘--debug’ (‘-d’, see –debug). It takes a numeric argument specifying the relative verbosity level in the range between 0 and 100. Zero means disabling verbose output, while 100 produces impractically verbose output, suitable only for the developers of mailfromd.

There is a more sophisticated form of the ‘--debug’ option, that allows to set debugging levels individually for a set of source modules. In this form, the argument to the option consists of a comma-separated list of debug specifications, each of which has the following form: source[=level]. Here, source is the mailfromd source name, without the suffix, and optional level is the debugging level (an integer between 0 and 100), that you wish to assign to this module. The default level is 100.

For example, the following invocation sets the global debugging level to 1, the level for functions from ‘prog.c’ to 10, and for ‘engine.c’ to 100:

 
$ mailfromd --debug=100,prog=10,engine

You need to have sufficient knowledge about mailfromd internal structure to use this form of the ‘--debug’ option.

To control the execution of the sender verification functions (see section Polling Functions), you may use ‘--transcript’ (‘-X’) command line option which enables the transcript of SMTP sessions in the logs. Here is an example of the output produced running mailfromd --debug=1 --transcript:

 
k8DHxlCa001774: RECV: 220 spf-jail1.us4.outblaze.com ESMTP Postfix
k8DHxlCa001774: SEND: HELO mail.gnu.org.ua
k8DHxlCa001774: RECV: 250 spf-jail1.us4.outblaze.com
k8DHxlCa001774: SEND: MAIL FROM: <>
k8DHxlCa001774: RECV: 250 Ok
k8DHxlCa001774: SEND: RCPT TO: <t1Kmx17Q@malaysia.net>
k8DHxlCa001774: RECV: 550 <>: No thank you rejected: Account
 Unavailable: Possible Forgery
k8DHxlCa001774: poll exited with status: not_found; sent
 "RCPT TO: <t1Kmx17Q@malaysia.net>", got "550 <>: No thank you
 rejected: Account Unavailable: Possible Forgery"
k8DHxlCa001774: SEND: QUIT

Footnotes

(11)

As of mailutils 1.0, ‘authpriv’ is not supported