postfix rejecting valid mail server

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

postfix rejecting valid mail server

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=<[hidden email]> to=<[hidden email]> 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!?

Reply | Threaded
Open this post in threaded view
|

Re: postfix rejecting valid mail server

Wietse Venema
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=<[hidden email]> to=<
> [hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: postfix rejecting valid mail 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?


2013/6/28 Wietse Venema <[hidden email]>
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=<[hidden email]> to=<
> [hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: postfix rejecting valid mail server

Wietse Venema
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=<[hidden email]>
> to=<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: postfix rejecting valid mail server

Jeroen Geilman
In reply to this post by Téssio Fechine
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=<[hidden email]> to=<[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: postfix rejecting valid mail server

Wietse Venema
In reply to this post by Téssio Fechine
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
Reply | Threaded
Open this post in threaded view
|

Re: postfix rejecting valid mail server

Stan Hoeppner
On 6/29/2013 7:15 AM, Wietse Venema wrote:
> 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.

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

Reply | Threaded
Open this post in threaded view
|

Re: postfix rejecting valid mail server

Téssio Fechine
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 <[hidden email]>
On 6/29/2013 7:15 AM, Wietse Venema wrote:
> 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.

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