I run a VERY small mail server (only about 10 users) and I have 194 unmatched messages from policyd-spf listed in the Unmatched Entries section of the postfix part of this morning's logwatch report. These messages started to appear after I upgraded my server from Ubuntu 16.04.5 to 18.04.1. Interestingly, this is an old bug (at least in RedHat) from about 1.5 years ago: https://bugzilla.redhat.com/show_bug.cgi?id=1419274
For reference, here are examples of each of the different "types" of messages I found in the list (with the IP, users and domains sanitized):
Would it be simpler to use the perl non-capture operator (?:) ? The patch with respect to the repository's copy would be the attached file. I don't have the means to test it, though.
I run a VERY small mail server (only about 10 users) and I have 194 unmatched messages from policyd-spf listed in the Unmatched Entries section of the postfix part of this morning's logwatch report. These messages started to appear after I upgraded my server from Ubuntu 16.04.5 to 18.04.1. Interestingly, this is an old bug (at least in RedHat) from about 1.5 years ago: https://bugzilla.redhat.com/show_bug.cgi?id=1419274
For reference, here are examples of each of the different "types" of messages I found in the list (with the IP, users and domains sanitized):
I'm wondering why this "broke" in the Ubuntu upgrade when the message format changed more than 18 months earlier.
I'm seeing the same thing. I took a stab at fixing it in https://sourceforge.net/u/d-rock/logwatch/ci/7a3eec5734b522db7b897e3404f55e3899701f01/. Does that fix it for you?
Would it be simpler to use the perl non-capture operator (?:) ? The patch with respect to the repository's copy would be the attached file. I don't have the means to test it, though.
Thanks, I forgot about non-capturing groups. I tested and that works.
New commit: https://sourceforge.net/u/d-rock/logwatch/ci/b33dc4364d091ca69112d3cdcce6c0bccefc929c/
Thanks; it has been rolled into the repository.