Willi Mann wrote:
But you didn't find out out whether the reject_warning line is
redundant and what's the difference between the two. Before anyone can
seriously apply the patch, we need to know that. Of course, from the
original report, it's very likely that it's another line which would
be what you intended in your patch, because of the "big" difference in
the two reporting dates (33 secs), but I don't know that for sure.
Okay, I accept my chastisement graciously. From the latest postfix
manpage for postconf.5
warn_if_reject
Change the meaning of the next restriction, so that it
logs a warning instead of rejecting a request (look for logfile records that
contain "reject_warning"). This is useful for testing
new restrictions in a "live" environment without risking unnecessary
loss of mail.
Which basically means the person who configured postfix, didn't want to
REALLY reject a message for some specific reason, however they did want
to be warned that a message would have matched the rejection criteria.
Therefore as far as logwatch is concerned there seems to be 3 options:
1. ignore reject_warning
2. add additional logic in every instance a reject_warning might appear
and differentiate between rejects and warnings
3. leave it as is to print in the unmatched section, leaving it up to
the configurator to remove the warn_if_reject qualifier if they don't
want to see the warnings.
And my vote is for # 3 simply due to the amount of effort required to
implement #2 which would be in my opinion the best choice.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
