Hello,
we are running Postfix (2.8.4 on SLES10.4 on that particular box, but I
also verified with 2.9.1 on Debian Squeeze) with
smtpd_client_restrictions =
reject_unknown_reverse_client_hostname,
reject_unknown_client_hostname,
(extensive whitelists of course as well). One source that has an
apparently well working reverse DNS fails occasionally
Aug 28 16:17:01 lxmhs18 postfix/smtpd[3596]: NOQUEUE: reject: RCPT from
unknown[134.130.87.26]: 550 5.7.1 Client host rejected: cannot find your
reverse hostname, [134.130.87.26]; from=<x...@xxxx.de> to=<x...@xxx.de>
proto=ESMTP helo=<ZULU.geotechnik.rwth-aachen.de>
DNS is okay ...
ok: 134.130.87.26 -PTR-> domaindnszones.geotechnik.rwth-aachen.de -A->
134.130.87.26
ok: -PTR-> forestdnszones.geotechnik.rwth-aachen.de -A->
134.130.87.26
ok: -PTR-> gc._msdcs.geotechnik.rwth-aachen.de -A->
134.130.87.26
ok: -PTR-> geotechnik.rwth-aachen.de -A->
134.130.87.26
ok: -PTR-> zulu.geotechnik.rwth-aachen.de -A->
134.130.87.26
We suspect (and verified with an internal client with custom rDNS) that
the _msdcs entry is at fault. This hostname does not seem to get
accepted. As soon as I remove the '_' it works fine.
I'm not a C expert, but from first glance at src/util/valid_hostname.c
that case is explicitly handled
/*
* Find bad characters or label lengths. Find adjacent delimiters.
*/
for (cp = name; (ch = *(unsigned char *) cp) != 0; cp++) {
if (ISALNUM(ch) || ch == '_') { /* grr.. */
if (label_length == 0)
label_count++;
Is that a bug in Postfix, in some system routines or is that not a valid
PTR? I could not find any RFC allowing or disallowing it explicitly.
Thanks,
Bernhard
