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"