On Thu, Jan 05, 2017 at 10:10:13AM +0100, Johannes Berg wrote: > On Thu, 2017-01-05 at 13:21 +1030, Ron wrote: > > > > Or worst case, we could make one, and let people do something like: > > > > > > antispam_log_prefix = %u > > Interesting, yes, that would probably be easiest.
That's probably the most 'future proof' if something like this is worth adding too ... Then people can prepend almost anything they want. > > > Martin, what _actual_ problem did you have to make you want this? > > > That might be something we can (also?) fix better and simpler? > > > > Just to be clear, there's a lot of permutations here about what > > backend might be run (and you didn't say which you are using), > > and usually the only case where the user might actually matter, > > we're passing that user to an external program (and don't have > > any control over what it outputs) ... > > > > So in most of what -antispam might log, any failure isn't going > > to be due to something "user specific" - which means it would be > > good to know exactly what problem you hit that (you thought?) was. > > > > Otherwise, this could just turn into lots of intrusive busywork > > that doesn't actually solve it, if we don't know what "it" was. > > Well, it's not going to be a lot of work, especially if we make it a > configuration and restrict it to the debug code, but I agree - knowing > what the use case is/was would be useful. Yeah, it might not be too bad after all - I was thinking that the debug context was actually 'global' and created during the module init, and so depending on how we did this, we might need to pass it the user context (which would mean modifying every call site) - but it looks like that's actually created in the mail_user_created() hook, which would make this a smaller patch ... But that still leaves the question of "which" user is the interesting one Martin wanted to see, the mailbox owner, or the process owner ... > PS: Ron, did you see the other email about the 2.2.27 breaking > antispam? This has hit the archive, and I've had to recompile the > antispam plugin with the latest fix I added to the git tree. I did, and was planning to upload that earlier this week, but it turned into "one of those weeks" :) That's done now though, I figured it was an important enough fix to not block it waiting on this or anything else, but I can easily push another one out shortly if we do have more fixes ready to go. Cheers, Ron
