POSTFIX_WARNING_* patterns match POSTFIX_QUEUEID in the wrong position

[wolfgangkarall]

They have the optional (%{POSTFIX_QUEUEID:postfix_queueid}: )? before the mandatory %{POSTFIX_WARNING_LEVEL:postfix_message_level}:, but in reality postfix logs e.g.

warning: 4T8Zh133D8zGpCM: recipient_canonical_maps map lookup problem for ...

The severity level always comes first with the msg_warn() and similar functions.

Sorry for not being able to submit a pull request at the moment.

[whyscream]

@wolfgangkarall Thanks for reporting.

Full example after messing with my own config:

Jan 10 11:19:39 hostname postfix/cleanup[777199]: warning: hash:/etc/postfix/sender_canonical_maps is unavailable. open database /etc/postfix/sender_canonical_maps: No such file or directory
Jan 10 11:19:39 hostname postfix/cleanup[777199]: warning: hash:/etc/postfix/sender_canonical_maps lookup error for "sender@example.com"
Jan 10 11:19:39 hostname postfix/cleanup[777199]: warning: 9BECF3F19D: sender_canonical_maps map lookup problem for sender@example.com -- message not accepted, try again later

[whyscream]

Both versions exist, queue-id before and after the warning level. My hunch is that this difference is between 'system' warnings that signal some runtime issue, and user-configurable warnings (f.i. by using the header_checks WARN action), but I didn't look into it too deeply.

Resolved in #183. Thanks for reporting!

[wolfgangkarall]

Yeah, true, I haven't noticed that since I have all of the header_checks-related patterns (where the 'warning' is just one of the POSTFIX_ACTION) set up differently in my local patterns.

Thanks for the update!