On 17-Oct-20 18:40, Mark Sapiro wrote:
On 10/17/20 1:31 PM, tlhackque via Mailman-users wrote:
I might also add the rule number or config filename:line, as in
Header "{name}": rule in {file}:{n} matched value "{value}"
This would be helpful when backtracking from a rejected message to the cause.
A sample expansion might be:
Header "X-Spam": rule in foo.conf:83 matched value "yes"
These rules are not in a configuration file. They are in the headermatch table in the database and the rules for a particular list are exposed on the Header filters tab in Postorius or at the REST lists/LISTNAME/header-matches endpoint.
Perhaps something like
{name}: header match rule, pattern "{pattern}" matched value "{value}"
example:
subject: header match rule, pattern "sex|long|list|of|other|bad|words" matched value "This is a post about filtering based on words like sex in the subject."
but that could be just adding more clutter.
I considered including the regex in each message, but that seemed redundant - and potentially long. Thus the pointer. Perhaps number the rules for each list, and use that index? The ROWID would seem to be a candidate for the number.
Then Postorius could simply number the rules in its tab; the REST API can add the ROWID as a rule_ID field in the returned JSON. (The fact that it's a ROWID rather than an index or unique name is an implementation detail.)
If many rules are anticipated, it might want an endpoint or option to fetch a rule by ID. Then it would be easy to drill down on a specific event for diagnosis.
e.g.
shunt_reason: (or whatever) {
cause: "header_match"
header: "subject"
header_value: "This is a post about filtering based on words like sex in the subject."
rule_id: 47 /* or pattern_id? */
}
displays as
subject: header match rule 47, matched value "This is a post about filtering based on words like sex in the subject."
and
lists/LISTNAME/header-matches/47 returns {
rule_id: 47
pattern: "sex|long|list|of|other|bad|words"
position: 3
/* Whatever else is in your table... I haven't looked since I postponed using MM3. eg */
comment:"Required by policy 869.202"
last_updated_by: "Corporate Prude"
last_updated_on: "1-Apr-1762"
}, while
lists/LISTNAME/header-matches returns an array of those structures, presumably as today.
With those capabilities, the UI can be enhanced so that clicking on a shunted message gives the summary reason, and clicking on the summary gives the regex. I expect that the header and value will be sufficient for understanding an issue most of the time. Looking at the regex is less common, and only necessary when it needs to be updated...
I still think that it is more readable and less verbose to order the message as a declarative sentence:
Header "subject": rule 47 matched value "sex"
but that may be a matter of personal taste. The UI can sort that out...
Note that from your description, using ROWID may cause rules in a particular list to have gaps in the rule numbering. I don't think that's a big issue, though Postorious could paper that over - perhaps use the position attribute. Doesn't seem worth doing something more complex. The advantage is that it doesn't require any DB change now. But aliasing it to "rule_id" allows for any future demand to name the rules or use some other numbering scheme.
I may have some details wrong - I found mm3 not ready for my needs and am thus out of date - but I hope the high level approach that I outlined is useful.