diff --git a/Changes b/Changes index 74b91e2..d5b50ca 100644 --- a/Changes +++ b/Changes @@ -17,6 +17,7 @@ karma: sprinkled karma awards throughout other plugins - limit poor karma hosts to 1 concurrent connection - allow +3 conncurrent connections to hosts with good karma + - limit recipients to 1 for senders with negative karma Sanitize spamd_sock path for perl taint mode - Markus Ullmann diff --git a/docs/logging.pod b/docs/logging.pod index 63febed..0b2495e 100644 --- a/docs/logging.pod +++ b/docs/logging.pod @@ -127,6 +127,40 @@ plugins in plugins/logging, specifically the L and L files for examples of how to write your own logging plugins. +=head1 plugin authors + +While plugins can log anything they like, a few logging conventions in use: + +=over 4 + +=item * at LOGINFO, log a single entry summarizing their disposition + +=item * log messages are prefixed with keywords: pass, fail, skip, error + +=over 4 + +=item pass: tests were run and the message passed + +=item fail: tests were run and the message failed + +=item fail, tolerated: tests run, msg failed, reject disabled + +=item skip: tests were not run + +=item error: tried to run tests but failure(s) encountered + +=item info: additional info, not to be used for plugin summary + +=back + +=item * when tests fail and reject is disabled, use the 'fail, tolerated' prefix + +=back + +When these conventions are adhered to, the logs/summarize tool outputs each +message as a single row, with a small x showing failed tests and a large X +for failed tests that caused message rejection. + =head1 Internal support for pluggable logging Any code in the core can call C<$self->log()> and those log lines will be