Loading ...
Sorry, an error occurred while loading the content.

postfix rejecting valid mail server

Expand Messages
  • 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
    Message 1 of 8 , Jun 28, 2013
    • 0 Attachment
      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=<tessiof@...> to=<nti-admin@...> 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
      ... 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.
      Message 2 of 8 , Jun 28, 2013
      • 0 Attachment
        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=<tessiof@...> to=<
        > nti-admin@...> 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
        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
        Message 3 of 8 , Jun 28, 2013
        • 0 Attachment
          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 <wietse@...>
          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=<tessiof@...> to=<
          > nti-admin@...> 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

        • Wietse Venema
          ... Because YOU are asking as ROOT and Postfix does not? Wietse
          Message 4 of 8 , Jun 28, 2013
          • 0 Attachment
            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=<tessiof@...>
            > to=<nti-admin@...> 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
            ... Please don t use nslookup. It has inherent flaws. ... reject_unknown_client_hostname will reject clients that fail the complete IP - PTR - IP lookup. If
            Message 5 of 8 , Jun 29, 2013
            • 0 Attachment
              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=<tessiof@...> to=<nti-admin@...> 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
              ... 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
              Message 6 of 8 , Jun 29, 2013
              • 0 Attachment
                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
                ... 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
                Message 7 of 8 , Jun 29, 2013
                • 0 Attachment
                  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
                • 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
                  Message 8 of 8 , Jul 3 1:10 PM
                  • 0 Attachment
                    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 <stan@...>
                    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


                  Your message has been successfully submitted and would be delivered to recipients shortly.