Yes, that works fine.
I'll commit that a little later today then. I've got some other stuff that I can commit too. I really want to add the pre-/post-connection hooks as well as another hook (currently unnamed, but "OK" is likely) so I don't have to hook on reset_transaction() if I want to get the success case.
with the adaptive logger. I'm still getting used to having the "Plugin %s returned %s" message before all the others, out of chronological sequence, and I wonder whether I'll miss being able to see from the timestamps how long parts of the processing are taking.
Well, that line could be suppressed I suppose (since it basically also shows up at the end of each DENY'd "block"), but it is correct in the sense that the act of returning a DENY is what triggers the logging in the first place. Personally, I find it makes a nice bookend to each block of log entries.
In terms of timestamps, you are correct that the timestamp is currently created by multilog on output, not stored when the log entry is created. I don't see that as a major problem, necessarily, and if we tracked the timestamp at time of logging, then that information would be duplicated under the typical multilog implementation.
I'm also trying to figure out a good way to log more info for messages that I'm marking as spam but not rejecting.
There's no reason you cannot write your own logging plugin that collects those lines together and prints them out (with a different prefix so you can isolate those into their own log file). Just copy the slog() sub out of adaptive_logging and add to your own code. As long as you are already running the adaptive_logging plugin, the $self->{_log} array will contain all of the log entries that you can pick over
Now if only I could track down where these "Plugins already loaded" messages are coming from.
It comes from load_plugins() being called in Qpsmtpd::TcpServer::run() for each connection. It's harmless (in that the plugins are only ever actually loaded/compiled once). I wonder if we can eliminate the call entirely; I know we could with forkserver, but I need to see what would happen with the other paths...
John
