Am 19.09.2014 um 15:55 schrieb Noel Jones:
> On 9/19/2014 3:37 AM, li...@rhsoft.net wrote:
>> why does postfix log sometimes "unknown[xx.xx.xx.xx]" when in fact the
>> reason for the reject is the PTR itself? sadly it's also missing in
>> the response in such cases and in case it would have been a legit
>> human person the only relevant debug information is missing
>>
>> (disclaimer: there are 139 DUNNO rules in front to not catch any serverlike)
>> _______________________________________________________________________________
>>
>> 23.107.88.136.rdns.as15003.net (23.107.88.136)
>>
>> RCPT from unknown[23.107.88.136]: 554 5.7.1 <unknown[23.107.88.136]>:
>> Unverified Client host rejected: Generic
>> DNS-Reverse-Lookup (PTR-Rule: 13)
>> _______________________________________________________________________________
>>
>> identical rule hitted but correct logged and rejected
>>
>> RCPT from 64-139-73-50-Chattanooga.hfc.comcastbusiness.net[64.139.73.50]:
>> 554 5.7.1
>> <64-139-73-50-Chattanooga.hfc.comcastbusiness.net[64.139.73.50]>: Unverified
>> Client host rejected: Generic
>> DNS-Reverse-Lookup (PTR-Rule: 13)
>> _______________________________________________________________________________
>>
>> /([0-9]{1,3}(\-|\.)[0-9]{1,3}(\-|\.)[0-9]{1,3}(\-|\.)[0-9]{1,3}.+[a-z0-9]+\.[a-z0-9]{2,6})$/
>> REJECT Generic
>> DNS-Reverse-Lookup (PTR-Rule: 13)
>>
>
>
> Since you're using a regexp already enclosed in (...) the easy fix
> is to use $1 in your response somewhere, something like:
> ... REJECT Generic DNS-Reverse-Lookup (PTR-Rule: 13); $1
dirty workaround, in case of a bot it don't matter, nobody reads it
in case of a bounce we all know how much users read if at all
it is already logged *twice* in the same line
why a workaround to list it a third time
> Postfix does log the offending unverified PTR on a different log line.
which don't help much
> How do you suggest postfix log the unverified PTR in this case? The
> "unknown" signifies the client failed FCrDNS and must not be changed
i already answered that in my previous response
if it is already mentioned *twice* in the same line
unknown[218.62.112.157]: 554 5.7.1 <unknown[218.62.112.157]>
the first unknown signifies the client failed FCrDNS
the second repeat the same instead the PTR i would even call a bug
the client don't need to know about FCrDNS, it needs in doubt
to know the offending string why he was rejected
____________________________________________________________________
> Are you asking for six different "unknown" variants? Why is that
> an improvement?
no
i am asking to log the PTR especially in case the reject reason
is "check_reverse_client_hostname_access" instead "unknown"
see below where the PTR is "157.112.62.218.adsl-pool.jlccptt.net.cn."
that line logs IP/Name twice with a different context
* fine:
RCPT from unknown[218.62.112.157]
reverse/forward match failed
that is information for the admin
* not fine
554 5.7.1 <unknown[218.62.112.157]>: Unverified Client host rejected
that is information for the sender if a MTA which may create a bounce
was rejected
_________________________________________
NOQUEUE: reject: RCPT from unknown[218.62.112.157]: 554 5.7.1
<unknown[218.62.112.157]>: Unverified Client host
rejected: Generic DNS-Reverse-Lookup (PTR-Rule: 13); from=<> to=<***>
proto=ESMTP helo=<WEB-SERVER.YISHENG-PHARM.COM>
