On 17-Oct-20 14:31, Mark Sapiro wrote:

On 10/17/20 10:39 AM, Torge Riedel wrote:

...

The message is being held because:

    Header "Yes" matched a header rule

At your convenience, visit your dashboard to approve or deny the request.

I think this is wrong, it should read 'Header "x-spam" matched a header rule'. Cause the header rule is configured for header "x-spam" and pattern "Yes".

The message is defined as

'Header "{}" matched a header rule'

where {} is replaced with the value of the matching header. I agree it would be better if it were something like

'Header value "{}" matched a header rule for {}:'

with {}s replaced with the header value and name. That would make it in your case

'Header value "Yes" matched a header rule for x-spam:'

...

I haven't found a bug report for this yet on gitlab. If someone of the developers confirm this is wrong, I will file a bug on gitlab for it.

Please do file a bug. It won't be fixed until after the upcoming 3.3.2 final release because we not making i18n changes between the candidate and final releases. Also, if you don't like my suggestion, feel free to suggest something else.

FWIW, I suggest:

Header "{name}": rule matched value "{value}"

Name tends to be short and must be simple ASCII.  Value can be very long and encoded, so it may wrap.  Name will be short and recognizable.  Plus the name provides the context for the value - and name:value is the way the header appears in the e-mail.  So I think name before value obeys the UI principle of least surprise.

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"

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.

Am 17.10.20 um 20:31 schrieb Mark Sapiro:

Please do file a bug. It won't be fixed until after the upcoming 3.3.2 final release because we not making i18n changes between the candidate and final releases. Also, if you don't like my suggestion, feel free to suggest something else.

Hi Mark,

thanks for your answer.

Filed as https://gitlab.com/mailman/mailman/-/issues/785

I also added a suggestion similar to the ones you did. And also the idea of a comment field for each rule to give additional information to the moderator.

Kind regards Torge