I'm not really seeing a pattern here: it's just a message. Using a pattern to parse the line can separate the keywords from the discarding EHLO keywords introduction, but I don't think that many installs have a large set of keyword discards configured (per clientor in general), meaning that it would be useful to have this information available in some structured form. But feel free to create a PR, of course :)

I wasn't looking for a structured form, but mostly not losing the message because of a missing pattern. While this is just informational, it might help in case people report problems.

I did it similar to what POSTFIX_QMGR_INFO is doing. Which might be a case for a named capture too?

Just wondering: your message should never be lost, right? It's already there, normally (i.e. basic syslog format), looking something like: {"program: "postfix/smtpd", "message": "discarding EHLO keywords: CHUNKING"} with some additional stuff.

Your PR proposes to 'enhance' the pristine message with a single new field postfix_message which contains a verbatim copy of the original message field, but only in very specific circumstances. What problem are you trying to solve? Is this a real-world situation that you ran into?

The message stems from a security workaround that was introduced early this year.

While you are right that it only duplicates the message, I'd want it to be set similar to the rest of the postfix_message attributes that are already in use and not get tagged a _grok_postfix_smtpd_nomatch.

If you have a table of postfix data in Kibana, you might not want to have the regular message field in there. Or you might want to have a graph of postfix_message counts by type to see if something is off.