Bug 6195 - tflag to capture matching text of rule to log?
tflag to capture matching text of rule to log?
Status: NEW
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd
unspecified
Other All
: P5 enhancement
: Undefined
Assigned To: SpamAssassin Developer Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2009-09-08 12:07 UTC by John Hardin
Modified: 2009-09-08 16:53 UTC (History)
1 user (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description John Hardin 2009-09-08 12:07:43 UTC
Anybody think it would be useful to have a tflag that would say "Write the matching text for this rule to the log" ?
Comment 1 Karsten Bräckelmann 2009-09-08 13:42:59 UTC
Sounds like a request for an 80s style printf debugging. :)

Thinking of something like tflags debug, to get the same result as -D for a specific rule, without all of the un-interesting, very verbose debug spewage?

Could be useful to watch rules still in development, or added fresh on a production machine.

However, IMHO it needs to be used with caution. In particular it never should be enabled in the stock rule-set, nor sandboxes. This should be entirely at the discretion of the admin or developer.
Comment 2 John Hardin 2009-09-08 14:00:08 UTC
Actually, it's in response to a thread currently underway on the users list, where the OP was lamenting that SA didn't log the first external IP address (among other bits of the message).

I was thinking such a tflag would be a more-general solution than playing whack-a-mole with hardcoded lists of "what about the message do we want to log?"

Granted you could easily blow your foot off with it... :)
Comment 3 Karsten Bräckelmann 2009-09-08 15:57:56 UTC
(In reply to comment #2)
> Actually, it's in response to a thread currently underway on the users list,
> where the OP was lamenting that SA didn't log the first external IP address
> (among other bits of the message).

That's an entirely different cattle of fish then. That user is missing the spamd logs where it does report all rules hit, the score, user and much more. About all he has are the prefork logs -- a user problem, SA does indeed log more.

(Just noticed: "All he has shown", mind you. The snippet posted to the list is starting and stopping SA minutes later. He didn't even claim he fed spamd a message.)


The last-external is available as templates, and easily could be injected into all messages for dead-simple checking. Well, if he wouldn't "reject" spam.

So the next stop is a simple, custom logging plugin. Easy to log what he asked for -- not sure if it also could log arbitrary rules' matches. Probably not, I'm afraid.

Anyway, he first needs to sort out his log issues. That's outside the scope of this enhancement request. As-is, this cannot possibly help him.


> I was thinking such a tflag would be a more-general solution than playing
> whack-a-mole with hardcoded lists of "what about the message do we want to
> log?"

My interpretation sounds more like a promising reason to ever implement this. ;)

> Granted you could easily blow your foot off with it... :)

Definitely agreed. WRT this reason for the enhancement request, I'd be much more happy with some options to add logging lines or alter existing ones. And restrict its scope to the templates, rather than arbitrary RE matches.
Comment 4 John Hardin 2009-09-08 16:43:20 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Actually, it's in response to a thread currently underway on the users list,
> > where the OP was lamenting that SA didn't log the first external IP address
> > (among other bits of the message).
> 
> That's an entirely different cattle of fish then. That user is missing the
> spamd logs where it does report all rules hit, the score, user and much more.
> About all he has are the prefork logs -- a user problem, SA does indeed log
> more.

I pointed that out to him, I don't know if he picked up on my comment.

> So the next stop is a simple, custom logging plugin. Easy to log what he asked
> for -- not sure if it also could log arbitrary rules' matches. Probably not,
> I'm afraid.

That's why I suggested a tflag rather than a plugin. It's more flexible.
 
> Anyway, he first needs to sort out his log issues. That's outside the scope of
> this enhancement request. As-is, this cannot possibly help him.

Agreed, but it did suggest the idea.

> > I was thinking such a tflag would be a more-general solution than playing
> > whack-a-mole with hardcoded lists of "what about the message do we want to
> > log?"
> 
> My interpretation sounds more like a promising reason to ever implement this.
> ;)

That, too. :)

> > Granted you could easily blow your foot off with it... :)
> 
> Definitely agreed. WRT this reason for the enhancement request, I'd be much
> more happy with some options to add logging lines or alter existing ones. And
> restrict its scope to the templates, rather than arbitrary RE matches.

But what about the Unix philosophy of "here's plenty of rope..."
Comment 5 Karsten Bräckelmann 2009-09-08 16:53:59 UTC
> But what about the Unix philosophy of "here's plenty of rope..."

Don't get too hung on the "restrict".  Instead, read it as altering this enhancement request from tflags to some add_log option, equivalent to the add_header options.

As per comment 1, I do see some use for the tflags, or rather per-rule options, though not exactly in the sense of what triggered this in the first place -- but an aid to watch some yet un-trusted RE matches.