postfix rejecting valid mail server

Téssio Fechine

unread,

Jun 28, 2013, 5:50:00 PM6/28/13

to

var/log/mail.log:Jun 28 18:25:43 rt-dq postfix/smtpd[4931]: NOQUEUE: reject: RCPT from unknown[209.85.219.66]: 450 4.7.1 Client host rejected: cannot find your hostname, [209.85.219.66]; from=<tes...@gmail.com> to=<nti-...@quimica.ufpb.br> proto=ESMTP helo=<mail-oa0-f66.google.com>

Then, at this exactly mail server machine:

# nslookup 209.85.219.66
Server:         x.x.x.x
Address:        x.x.x.x#53

Non-authoritative answer:
66.219.85.209.in-addr.arpa      name = mail-oa0-f66.google.com.

Authoritative answers can be found from:
219.85.209.in-addr.arpa nameserver = ns1.google.com.
219.85.209.in-addr.arpa nameserver = ns3.google.com.
219.85.209.in-addr.arpa nameserver = ns2.google.com.
219.85.209.in-addr.arpa nameserver = ns4.google.com.
ns1.google.com internet address = 216.239.32.10

So, postfix is complaining that "cannot find your hostname", but the reverse DNS is working just fine. Any clue!?

Wietse Venema

unread,

Jun 28, 2013, 5:53:26 PM6/28/13

to

T?ssio Fechine:

> var/log/mail.log:Jun 28 18:25:43 rt-dq postfix/smtpd[4931]: NOQUEUE:
> reject: RCPT from unknown[209.85.219.66]: 450 4.7.1 Client host rejected:
> cannot find your hostname, [209.85.219.66]; from=<tes...@gmail.com> to=<
> nti-...@quimica.ufpb.br> proto=ESMTP helo=<mail-oa0-f66.google.com>

If you don't like that don't use reject_unknown_client_hostname.

66.219.85.209.in-addr.arpa domain name pointer mail-oa0-f66.google.com.
mail-oa0-f66.google.com has address 209.85.219.66

Looks like you are using a bad DNS server.

Wietse

Téssio Fechine

unread,

Jun 28, 2013, 6:17:34 PM6/28/13

to

I use reject_unknown_client_hostname at many email servers. Only this one is having a problem.

Why DNS is bad if nslookup works fine?

2013/6/28 Wietse Venema <wie...@porcupine.org>

Wietse Venema

unread,

Jun 28, 2013, 7:07:51 PM6/28/13

to

T?ssio Fechine:
> var/log/mail.log:Jun 28 18:25:43 rt-dq postfix/smtpd[4931]: NOQUEUE:
> reject: RCPT from unknown[209.85.219.66]: 450 4.7.1 Client host rejected:
> cannot find your hostname, [209.85.219.66]; from=<tes...@gmail.com>
> to=<nti-...@quimica.ufpb.br> proto=ESMTP helo=<mail-oa0-f66.google.com>

Wietse:

> > If you don't like that don't use reject_unknown_client_hostname.
> >
> > 66.219.85.209.in-addr.arpa domain name pointer mail-oa0-f66.google.com
> > .
> > mail-oa0-f66.google.com has address 209.85.219.66
> >
> > Looks like you are using a bad DNS server.

T?ssio Fechine:

> I use reject_unknown_client_hostname at many email servers. Only this one
> is having a problem.
> Why DNS is bad if nslookup works fine?

Because YOU are asking as ROOT and Postfix does not?

Wietse

Jeroen Geilman

unread,

Jun 29, 2013, 4:23:23 AM6/29/13

to

On 06/28/2013 11:50 PM, Téssio Fechine wrote:

var/log/mail.log:Jun 28 18:25:43 rt-dq postfix/smtpd[4931]: NOQUEUE: reject: RCPT from unknown[209.85.219.66]: 450 4.7.1 Client host rejected: cannot find your hostname, [209.85.219.66]; from=<tes...@gmail.com> to=<nti-...@quimica.ufpb.br> proto=ESMTP helo=<mail-oa0-f66.google.com>

Then, at this exactly mail server machine:

# nslookup 209.85.219.66

Please don't use nslookup. It has inherent flaws.

So, postfix is complaining that "cannot find your hostname", but the reverse DNS is working just fine. Any clue!?

reject_unknown_client_hostname will reject clients that fail the complete IP -> PTR -> IP lookup.

If this is not what you desire, limit it to reject_unknown_REVERSE_client_hostname only.

-- 
J.

Wietse Venema

unread,

Jun 29, 2013, 8:15:46 AM6/29/13

to

T?ssio Fechine:
> What!? How the user running the client library affects DNS response? This
> makes no sense.

This is a frequent problem with novice system administrators
who mess up file or directory access permissions.

If a program doesn't run as root, then the tests should not
be done as root.

Wietse

Stan Hoeppner

unread,

Jun 29, 2013, 9:31:05 AM6/29/13

to

And if I'm not mistaken, this kind of thing can also happen with a
broken or poorly implemented chroot, wherein the resolver Postfix uses
can be different than the resolver everything outside the Postfix chroot
is using.

I vaguely recall this happening to me many many years ago with Debian,
when I modified /etc/resolv.conf and the change was not picked up in
/var/spool/postfix/etc/resolv.conf. The two resolvers were returning
different results so testing in a root shell with host and dig was
counterproductive and masked the problem.

Wietse helped me identify the chroot as the problem and I was able to
track down how to fix it after I knew where to look. He is trying to do
the same for you here. He is simply not spoon feeding you the complete
answer, complete picture. He's pointing you in the right direction so
you can do the rest of the sleuthing yourself. Some folks here will
hold your hand start to finish at times. But for the most part I think
most folks here try to be enablers, not function as consultants. This
is all volunteer after all.

--
Stan

Téssio Fechine

unread,

Jul 3, 2013, 4:10:13 PM7/3/13

to

The problem was a broken /etc/apt/sources.list in debian.
Someone changed one of the repositories to wheezy, and left the others as squeeze.
A broken package dependency made the postfix resolver stop working, apparently.
After the system was fully upgraded to wheezy, postfix started working as expected.

Thanks everyone.

2013/6/29 Stan Hoeppner <st...@hardwarefreak.com>