On 27 Jun 2014, at 5:52, Klaipedaville on Google wrote:
Hello Joni,
Thank you for your suggestion and quick reply.
Well, my actual log entry has been posted in my first message. I only
changed the actual IP address.
There is no reason to do that, which makes it impossible for us to
figure out precisely what your problem is. Your problem seems to be
entirely distinct from the use of "generic" rDNS records, but your
obfuscation of the specific details makes that hard to state with
certainty.
The log is:
Postfix says, "hostname verification errors in FCrDNS:
Does not resolve to address
123.45.67.8 123-45-67-8.my.isp.com”
Now here is the exact copy-paste if it wasn’t really clear for you
from the first time:
---------------Hostname verification errors (FCRDNS)
------------------
Does not resolve to address
123.45.67.8 123-45-67-8.my.isp.com
---------------------------------------------------------------------------------------
Postfix generates no messages in any form like that. It does sometimes
generate log entries like this:
Jun 17 12:44:39 toaster postfix/smtpd[11867]: warning: hostname
br16.srvmatrix.info does not resolve to address 177.11.51.78: nodename
nor servname provided, or not known
That was the result of some spammer using 177.11.51.78 trying to relay
through my server. The same warning would have been generated if they
had been trying to send mail to me. There'sa PTR record for
177.11.51.78 pointing to br16.srvmatrix.info but there's no A or CNAME
record for br16.srvmatrix.info. That DNS error is common enough that it
would be unsafe to have Postfix do anything more that warn about it, but
the warning is good to have in the log because it illuminates why
related log messages refer to the client as "unknown".
It requires no effort on my part to avoid seeing such log messages when
I don't want to, because I don't normally look for them. Whatever is
translating the messages in your Postfix logs into messages like the one
you've included is causing pointless worry.
The domain names were not required in my question therefore I did not
use any of them such as example.com and so on so there isn’t much
for you to translate .
Not so. If you had included an actual Postfix log entry, it would have
been much more clear what your difficulty is.
I have a "business" type account and the reverse DNS is available. In
fact, It even works OK but only one way. The thing that is not working
as per my log entry is the other way around, that is the FCrDNS.
I’ll double-check it with my ISP one more time on that though.
Here's an example of a not-so-random real case of bad DNS that might be
very similar to whatever problem you are trying to solve. First a
"reverse" resolution of an IP address to a name:
# dig +noauth +noadd +nocmd +nostats -x 86.100.96.251
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18478
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;251.96.100.86.in-addr.arpa. IN PTR
;; ANSWER SECTION:
251.96.100.86.in-addr.arpa. 31261 IN PTR
86-100-96-251.klp.balticum.lt.
That's "generic" rDNS: a PTR whose value is clearly derived from the IP
address. Nothing wrong with that, if the only rational alternative is no
PTR at all. However, any name used as a PTR value should have forward (A
or CNAME) resolution, but this generic name does not:
# dig +noadd +nocmd +nostats 86-100-96-251.klp.balticum.lt.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46734
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;86-100-96-251.klp.balticum.lt. IN A
;; AUTHORITY SECTION:
balticum.lt. 6016 IN SOA ns1.balticum.lt.
hostmaster.balticum-tv.lt. 2014050801 10800 1800 604800 86400
And who runs the reverse DNS?
# dig +short 96.100.86.in-addr.arpa. SOA
ns1.balticum.lt. hostmaster.balticum-tv.lt. 2011021402 43200 7200
1728000 7200
The same entity that is running the forward DNS. So this isn't
miscommunication between an ISP and customer, this is an ISP that is
simply incompetent. They could make the generic rDNS name resolve, but
they don't. Simple stupidity, and entirely outside what anyone else can
fix, even the unfortunate person using 86.100.96.251.
However, my question was if I could possibly solve it using only
postfix without getting my ISP involved because as I have already said
in my previous message Postfix has been working absolutely fine
without any problems with delivery or anything else. I’ve been
trying to fix it using check_reverse_client_hostname_access but this
does not seem to solve the issue.
Would highly appreciate any other / more options, comments,
assistance. Many thanks!
If the problem is only with one address, you might be able to quiet the
noise with an entry in your /etc/hosts file to create the missing
IP<->name mapping symmetrically. Most (but not all) systems still check
there first before or in addition to DNS. That will hide the bad DNS
from Postfix.
