Bug#317388: [Logwatch-Devel] fwd: Re: Bug#317388: logwatch: Unmatched entries in Postfix section
Willi Mann wrote:
Could anyone who is used to postfix look at this bug please? I'm not
sure what to do with this bug.
http://bugs.debian.org/317388
Willi
I just installed the latest logwatch, and believe the enclosed patch
will correct this issue. I couldn't find any reject_warning in my logs
for verification, but I did verifiy the patch did not break existing
functionality.
The patch includes one additional change to address another unmatched
RBL issue my logs were showing.
The patch is attached as well in case the line wrapping below is fowled up.
*--- postfix.orig 2005-07-23 07:16:26.972833471 -0700*
*+++ postfix2005-07-23 07:35:18.759650895 -0700*
@@ -248,7 +248,7 @@
$UndeliverableMsg{$Reason}++;
} elsif ( (undef,undef,undef,undef) = ($ThisLine =~ /^[a-zA-Z0-9]+: to=([^ ]*),(
orig_to=[^ ]*,)? relay=([^ ]*), delay=\d+, status=deliverable \((.*)\)$/)) {
$Deliverable++;
- #} elsif ( ($Host,undef) = ($ThisLine =~ /reject: RCPT from ([^ ]*\[[^ ]*\]):
[0-9]+ ([^ ]*): Sender address rejected: Domain not found;/)) {
+ #} elsif ( ($Host,undef) = ($ThisLine =~ /[reject|reject_warning]: RCPT from ([^
]*\[[^ ]*\]): [0-9]+ ([^ ]*): Sender address rejected: Domain not found;/)) {
# $RejectDomain{$Host}++;
# above two lines included in generic reject sender on next condition
} elsif ( ($Host,$Sender,$Reason) = ($ThisLine =~ /reject: RCPT from ([^ ]*\[[^
]*\]): [0-9]+ (.*): Sender address rejected: (.*);/)) {
@@ -274,6 +274,9 @@
} elsif ( ($Host,$Site) = ($ThisLine =~ /reject: RCPT from ([^ ]*\[[^ ]*\]):
554 Service unavailable; (?:Client host )?\[[^ ]*\] blocked using ([^ ]*);/)) {
$RejectRBL{$Site}{$Host}++;
$RejectedRBL++;
+ } elsif ( ($Host,$Site) = ($ThisLine =~ /reject: RCPT from ([^ ]*\[[^
]*\]): 554 Service unavailable; (?:Sender address )?\[[^ ]*\] blocked using ([^
]*);/)) {
+ $RejectRBL{$Site}{$Host}++;
+ $RejectedRBL++;
} elsif ( ($Host,$Site,$Reason) = ($ThisLine =~ /warning: ([^ ]*): RBL
lookup error: Name service error for \d+\.\d+\.\d+\.\d+\.([^ ]*): (.*)$/)) {
$Temp = $Host : $Reason;
$RBLError{$Site}{$Temp}++;
--- postfix.orig 2005-07-23 07:16:26.972833471 -0700
+++ postfix 2005-07-23 07:35:18.759650895 -0700
@@ -248,7 +248,7 @@
$UndeliverableMsg{$Reason}++;
} elsif ( (undef,undef,undef,undef) = ($ThisLine =~ /^[a-zA-Z0-9]+: to=([^ ]*),( orig_to=[^ ]*,)? relay=([^ ]*), delay=\d+, status=deliverable \((.*)\)$/)) {
$Deliverable++;
- #} elsif ( ($Host,undef) = ($ThisLine =~ /reject: RCPT from ([^ ]*\[[^ ]*\]): [0-9]+ ([^ ]*): Sender address rejected: Domain not found;/)) {
+ #} elsif ( ($Host,undef) = ($ThisLine =~ /[reject|reject_warning]: RCPT from ([^ ]*\[[^ ]*\]): [0-9]+ ([^ ]*): Sender address rejected: Domain not found;/)) {
# $RejectDomain{$Host}++;
# above two lines included in generic reject sender on next condition
} elsif ( ($Host,$Sender,$Reason) = ($ThisLine =~ /reject: RCPT from ([^ ]*\[[^ ]*\]): [0-9]+ (.*): Sender address rejected: (.*);/)) {
@@ -274,6 +274,9 @@
} elsif ( ($Host,$Site) = ($ThisLine =~ /reject: RCPT from ([^ ]*\[[^ ]*\]): 554 Service unavailable; (?:Client host )?\[[^ ]*\] blocked using ([^ ]*);/)) {
$RejectRBL{$Site}{$Host}++;
$RejectedRBL++;
+ } elsif ( ($Host,$Site) = ($ThisLine =~ /reject: RCPT from ([^ ]*\[[^ ]*\]): 554 Service unavailable; (?:Sender address )?\[[^ ]*\] blocked using ([^ ]*);/)) {
+ $RejectRBL{$Site}{$Host}++;
+ $RejectedRBL++;
} elsif ( ($Host,$Site,$Reason) = ($ThisLine =~ /warning: ([^ ]*): RBL lookup error: Name service error for \d+\.\d+\.\d+\.\d+\.([^ ]*): (.*)$/)) {
$Temp = $Host : $Reason;
$RBLError{$Site}{$Temp}++;
Bug#317388: [Logwatch-Devel] fwd: Re: Bug#317388: logwatch: Unmatched entries in Postfix section
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. Forget that statement, it's not very likely because the original reporter says: You are absolutely right, the reject_warning log line is always written together with the reject log line. So it's possible that it should just be ignored. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317388: [Logwatch-Devel] fwd: Re: Bug#317388: logwatch: Unmatched entries in Postfix section
Who Knows schrieb:
Willi Mann wrote:
Could anyone who is used to postfix look at this bug please? I'm not
sure what to do with this bug.
http://bugs.debian.org/317388
Willi
I just installed the latest logwatch, and believe the enclosed patch
will correct this issue. I couldn't find any reject_warning in my logs
for verification, but I did verifiy the patch did not break existing
functionality.
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.
- #} elsif ( ($Host,undef) = ($ThisLine =~ /reject: RCPT from ([^
]*\[[^ ]*\]): [0-9]+ ([^ ]*): Sender address rejected: Domain not
found;/)) {
+ #} elsif ( ($Host,undef) = ($ThisLine =~ /[reject|reject_warning]:
RCPT from ([^ ]*\[[^ ]*\]): [0-9]+ ([^ ]*): Sender address rejected:
Domain not found;/)) {
And that shows the problem of not really testing the patch: You are matching
t: RCPT from
not
reject: RCPT from
(cf. this small perl script:
my $line = reject: RCPT;
print matches\n if $line =~ /[reject|reject_warning]: RCPT/;
print $.\n;
)
Of course it works, but it confuses everyone. (Maybe it's even slower, but
I'm no regex guru.)
The right expression is:
/(?:reject|reject_warning) ./
} elsif ( ($Host,$Site) = ($ThisLine =~ /reject: RCPT from ([^ ]*\[[^
]*\]): 554 Service unavailable; (?:Client host )?\[[^ ]*\] blocked using ([^
]*);/)) {
$RejectRBL{$Site}{$Host}++;
$RejectedRBL++;
+ } elsif ( ($Host,$Site) = ($ThisLine =~ /reject: RCPT from ([^ ]*\[[^
]*\]): 554 Service unavailable; (?:Sender address )?\[[^ ]*\] blocked using
([^ ]*);/)) {
+ $RejectRBL{$Site}{$Host}++;
+ $RejectedRBL++;
And there's another issue: If you just add it to %RejectRBL, you should use
one regex for that because it's only (Sender address |Client host ) what
makes the difference.
... (?:Sender address |Client host )? should do it.
Willi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317388: [Logwatch-Devel] fwd: Re: Bug#317388: logwatch: Unmatched entries in Postfix section
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]
