Qpsmtpd now (as of 0.30-dev) supports a plugable logging architecture, so that different logging plugins can be supported. See the example logging plugins in plugins/logging, specifically the plugins/logging/warn and plugins/logging/adaptive files for examples of how to write your own logging plugins.

Any code in the core can call $self→log() and those log lines will be dispatched to each of the registered logging plugins. When log() is called from a plugin, the plugin and hook names are automatically included in the parameters passed the logging hooks. All plugins which register for the logging hook should expect the following parameters to be passed:

  $self, $transaction, $trace, $hook, $plugin, @log

where those terms are:

The object which was used to call the log() method; this can be any object within the system, since the core code will automatically load logging plugins on behalf of any object.

This is the current SMTP transaction (defined as everything that happens between HELO/EHLO and QUIT/RSET). If you want to defer outputting certain log lines, you can store them in the transaction object, but you will need to bind the reset_transaction hook in order to retrieve that information before it is discarded when the transaction is closed (see the logging/adaptive plugin for an example of doing this).

This is the log level (as shown in config.sample/loglevel) that the caller asserted when calling log(). If you want to output the textural representation (e.g. LOGERROR) of this in your log messages, you can use the log_level() function exported by Qpsmtpd::Constants (which is automatically available to all plugins).

This is the hook that is currently being executed. If log() is called by any core code (i.e. not as part of a hook), this term will be undef.

This is the plugin name that executed the log(). Like $hook, if part of the core code calls log(), this wil be undef. See logging/warn for a way to prevent logging your own plugin's log entries from within that plugin (the system will not infinitely recurse in any case).

The remaining arguments are as passed by the caller, which may be a single term or may be a list of values. It is usually sufficient to call join(” ”,@log) to deal with these terms, but it is possible that some plugin might pass additional arguments with signficance.

Note: if you register a handler for certain hooks, e.g. deny, there may be additional terms passed between $self and $transaction. See logging/adaptive for and example.