Robin Bowes wrote:
> Actually, I might as well post it now. this is jsut the hook_deny sub:
>
> sub hook_deny { # dlog
> }
<snip>
> warn( $self->{_rejectprefix} . ' ' .
> join ",",
> ${$},
you will want to have the PID ${$} preceed the reject prefix, otherwise these
lines won't "line up" with the other log lines.
I'm looking at this code (and trying to see how it is going to integrate into
the larger scheme), and I'm not sure I understand where this is going, but maybe
it is because I haven't made clear what happens now.
The base logging just emits lines via warn() every time some component calls
$self->log(). The current adaptive plugin does that, but it also copies/stores
all of the log lines which are below the minlevel (what you call accept_level).
If the message is rejected, the current plugin notes that fact but does
nothing. When the transaction object is reset (at the end of a SMTP
transaction), if the message was accepted, then any lines which were saved are
emitted; if the message was rejected, no additional lines are output.
What _your_ hook_deny() does is to emit an extra line with details about the
message just rejected. But it isn't clear to me that you also intend to save up
the < reject_level log entries and emit those too? I'm not sure (after playing
around a little) that the current loglevels set in the various plugins are
granular enough to make splitting the lines three ways worthwhile. For your
purposes, it may be enough to log a single lines for rejected messages with all
of the information you are adding, and not log any of the default detailed
lines.
Does that make sense?
John
