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

intermittent DNS lookup failure in combination with reject_unknown_client_hostname

Expand Messages
  • IMAP List Administration
    Hello Folks, I m running a postfix (postfix-2.9.20120102-sasl2) server on OpenBSD v5.1. We have a number of anti-UCE postfix measures in place, including
    Message 1 of 9 , Nov 13, 2012
    • 0 Attachment
      Hello Folks,

      I'm running a postfix (postfix-2.9.20120102-sasl2) server on OpenBSD v5.1. We
      have a number of anti-UCE postfix measures in place, including
      "reject_unknown_client_hostname", which we quite like. It's hard to believe
      there are so many spammers that can't overcome such a low obstacle.

      At any rate, we periodically see (1-5 times per day) a "Client host rejected:
      cannot find your hostname" rejection, followed by a successful retry from the
      remote MTA. When we check the DNS records, they always appear to be in order.
      The remote MTAs belong to various organizations, but typically ones where one
      would expect the DNS config to be well-maintained. (see bottom for an example
      rejection and the ensuing successful retry).

      I've tried to configure DNS (BIND 9.4.2-P2) to log debug information, and it
      logs a fantastic amount, but I am unable to get it to log such queries and their
      results, or maybe I just haven't found the magic combination of logging settings
      yet, or maybe I don't understand the logging output.

      The Questions:
      1) is it possible that we are observing a bug in postfix in conjunction with
      DNS-queries? Are there any such known bugs?
      2) can someone give me a tip on how to configure BIND to log the information I
      need to figure out why DNS lookups may be failing intermittently, and how to
      read it properly?

      thanks,

      Rob Urban

      -----------------------------------------
      the output below has been slightly sanitized of information directly identifying
      the server.

      [example of delivery failure]
      Nov 13 15:10:29 dna prefilter/smtpd[9340]: connect from unknown[8.7.42.206]
      Nov 13 15:10:29 dna prefilter/smtpd[9340]: NOQUEUE: reject: RCPT from
      unknown[8.7.42.206]: 450 4.7.1 Client host rejected: cannot find your hostname,
      [8.7.42.206]; from=<from-address@...> to=<user@...>
      proto=ESMTP helo=<mta925.email.aerlingus.com>

      [subsequent delivery success]
      Nov 13 16:10:58 dna prefilter/smtpd[3578]: connect from
      mta925.email.aerlingus.com[8.7.42.206]
      [...this get passed to amavis...]
      Nov 13 16:10:58 dna amavis[14323]: (14323-09) ESMTP::10024
      /var/amavisd/tmp/amavis-20121113T152153-14323-ExeHjDoN:<from-address@...>
      -> <user@...> Received: from mail.y42.org ([127.0.0.1]) by localhost
      (dna.domain.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP for
      <user@...>; Tue, 13 Nov 2012 16:10:58 +0100 (MET)
      [...and eventually is accepted and delivered...]
      Nov 13 16:11:04 dna prefilter/smtpd[3578]: proxy-accept: END-OF-MESSAGE: 250
      2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 0514F2C88F;
      from=<from-address@...> to=<user@...> proto=ESMTP
      helo=<mta925.email.aerlingus.com>
      Nov 13 16:11:04 dna postfix/lmtp[9872]: 0514F2C88F: to=<user@...>,
      orig_to=<user@...>,
      relay=dna.domain.de[/var/spool/lmtp_to_cyrus/lmtp_socket], delay=0.07,
      delays=0.01/0.01/0/0.05, dsn=2.1.5, status=sent (250 2.1.5 Ok
      SESSIONID=<imapd-24054-1352819464-1>)

      [a quick check reveals no problems...]
      # host 8.7.42.206
      206.42.7.8.in-addr.arpa domain name pointer mta925.email.aerlingus.com.
      # host mta925.email.aerlingus.com
      mta925.email.aerlingus.com has address 8.7.42.206

      [output of "postconf -n"]
      # postconf -n
      alias_database = hash:/etc/postfix/aliases
      alias_maps = hash:/etc/postfix/aliases
      broken_sasl_auth_clients = yes
      command_directory = /usr/local/sbin
      config_directory = /etc/postfix
      daemon_directory = /usr/local/libexec/postfix
      data_directory = /var/postfix
      debug_peer_level = 9
      debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
      $daemon_directory/$process_name $process_id & sleep 5
      header_checks = pcre:/etc/postfix/header_checks
      html_directory = /usr/local/share/doc/postfix/html
      inet_interfaces = www.xxx.yyy.zzz, localhost
      inet_protocols = all
      lists_destination_recipient_limit = 1
      local_recipient_maps = $alias_maps, hash:/etc/postfix/virtual,
      hash:/etc/postfix/transport, hash:/etc/postfix/cyrus_recipients,
      hash:/etc/postfix/local_recipients
      mail_owner = _postfix
      mailq_path = /usr/local/sbin/mailq
      manpage_directory = /usr/local/man
      masquerade_domains = domain.org
      message_size_limit = 40960000
      mydestination = $myhostname, dna.$mydomain, mail.$mydomain, localhost.$mydomain,
      $mydomain, /etc/postfix/local-host-names
      myhostname = mail.domain.org
      mynetworks = www.xxx.yyy.192/29, 127.0.0.0/8
      mynetworks_style = host
      myorigin = $mydomain
      newaliases_path = /usr/local/sbin/newaliases
      queue_directory = /var/spool/postfix
      readme_directory = /usr/local/share/doc/postfix/readme
      recipient_delimiter = +
      sample_directory = /etc/postfix
      sender_canonical_maps = hash:/etc/postfix/canonical-sender
      sendmail_path = /usr/local/sbin/sendmail
      setgid_group = _postdrop
      smtpd_client_restrictions = permit_sasl_authenticated permit_mynetworks
      check_client_access hash:/etc/postfix/client_access
      reject_unknown_client_hostname reject_unauth_pipelining reject_rbl_client
      ix.dnsbl.manitu.net reject_rbl_client zen.spamhaus.org
      smtpd_discard_ehlo_keywords = silent-discard, dsn
      smtpd_helo_required = yes
      smtpd_helo_restrictions = permit_sasl_authenticated permit_mynetworks
      check_helo_access regexp:/etc/postfix/helo_access reject_non_fqdn_helo_hostname
      reject_invalid_helo_hostname
      smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks
      check_recipient_access regexp:/etc/postfix/recipient_access
      reject_unauth_destination reject_non_fqdn_recipient permit
      smtpd_sasl_auth_enable = yes
      smtpd_sasl_authenticated_header = no
      smtpd_sasl_local_domain = dna.domain.org
      smtpd_sasl_security_options = noanonymous, noplaintext
      smtpd_sasl_tls_security_options = noanonymous
      smtpd_sender_restrictions = permit_sasl_authenticated permit_mynetworks
      check_sender_access hash:/etc/postfix/sender_access reject_unknown_sender_domain
      reject_non_fqdn_sender
      smtpd_tls_CAfile = /etc/postfix/certs/ca-bundle.crt
      smtpd_tls_cert_file = /etc/postfix/certs/domain-certificate.pem
      smtpd_tls_key_file = /etc/postfix/certs/domain-privkey.pem
      smtpd_tls_loglevel = 2
      smtpd_tls_received_header = yes
      smtpd_tls_security_level = may
      transport_maps = hash:/etc/postfix/transport, hash:/etc/postfix/cyrus_recipients
      unknown_local_recipient_reject_code = 550
      virtual_alias_maps = hash:/etc/postfix/virtual
    • Wietse Venema
      ... If Postfix replies with 4xx unknown client, Postfix got an soft error FROM THE SYSTEM LIBRARY ROUTINES that the domain could not be looked up. There was
      Message 2 of 9 , Nov 13, 2012
      • 0 Attachment
        IMAP List Administration:
        > 1) is it possible that we are observing a bug in postfix in conjunction with
        > DNS-queries? Are there any such known bugs?

        If Postfix replies with 4xx unknown client, Postfix got an "soft"
        error FROM THE SYSTEM LIBRARY ROUTINES that the domain could not
        be looked up. There was a timeout or some other error that prevented
        THE SYSTEM LIBRARY ROUTINES from receiving the information theat
        Postfix asked for.

        If Postfix replies with 5xx unknown client, Postfix got a "hard"
        error FROM THE SYSTEM LIBRARY ROUTINES that the domain could not
        be looked up. THE SYSTEM LIBRARY ROUTINES received a reply from
        the DNS server that the name does not exist.

        Wietse
      • /dev/rob0
        On Tue, Nov 13, 2012 at 09:55:11PM +0100, ... That s a pre-release snapshot. Postfix 2.9 is up to patchlevel 4. ... Most spam comes from botnets, and spammers
        Message 3 of 9 , Nov 13, 2012
        • 0 Attachment
          On Tue, Nov 13, 2012 at 09:55:11PM +0100,
          IMAP List Administration wrote:
          > I'm running a postfix (postfix-2.9.20120102-sasl2) server on

          That's a pre-release snapshot. Postfix 2.9 is up to patchlevel 4.

          > OpenBSD v5.1. We have a number of anti-UCE postfix measures in
          > place, including "reject_unknown_client_hostname", which we quite
          > like. It's hard to believe there are so many spammers that can't
          > overcome such a low obstacle.

          Most spam comes from botnets, and spammers have no control over the
          reverse DNS of a gazzilion zombies.

          > At any rate, we periodically see (1-5 times per day) a "Client
          > host rejected: cannot find your hostname" rejection, followed
          > by a successful retry from the remote MTA. When we check the
          > DNS records, they always appear to be in order. The remote MTAs
          > belong to various organizations, but typically ones where one
          > would expect the DNS config to be well-maintained. (see bottom
          > for an example rejection and the ensuing successful retry).
          >
          > I've tried to configure DNS (BIND 9.4.2-P2) to log debug

          That's very old. 9.4.3 was EOL almost three years ago.

          > information, and it logs a fantastic amount, but I am unable to get
          > it to log such queries and their results, or maybe I just haven't
          > found the magic combination of logging settings yet, or maybe I

          "rndc querylog" toggles query logging. Beware: query logging plus
          debugging can easily cause a DoS. Don't do this over an extended
          period.

          > don't understand the logging output.
          >
          > The Questions:
          > 1) is it possible that we are observing a bug in postfix in

          I have no idea why you would think that. Postfix simply reports what
          was obtained from the DNS. Nothing here looks bug-like.

          > conjunction with DNS-queries? Are there any such known bugs?

          If there were known bugs, they would be fixed. Some bugs indeed have
          been fixed since the 2.9.20120102 snapshot, including the final
          release and four patchlevels.

          Look at this, done at home on my low-speed ADSL:

          $ for X in 1 2 ; do time host 8.7.42.206 ; done
          206.42.7.8.in-addr.arpa domain name pointer
          mta925.email.aerlingus.com.

          real 0m2.032s
          user 0m0.003s
          sys 0m0.005s
          206.42.7.8.in-addr.arpa domain name pointer
          mta925.email.aerlingus.com.

          real 0m0.009s
          user 0m0.001s
          sys 0m0.006s

          The first time took two seconds. The second time, the cached result
          from localhost was supplied immediately.

          A complete lookup also requires that the PTR corresponds to an A
          record. So *after* that two seconds, I could look up
          "mta925.email.aerlingus.com./IN/A".

          > 2) can someone give me a tip on how to configure BIND to log the
          > information I need to figure out why DNS lookups may be failing
          > intermittently, and how to read it properly?

          Beyond the hints already given, I suggest following up with this on
          bind-users@.... I think that might still be gated to
          Usenet, news://comp.protocols.dns.bind , if you prefer NNTP.

          https://lists.isc.org/mailman/listinfo/bind-users

          You should also consider upgrading to a supported version before
          reporting what could be a bug. (I suspect it's either your
          configuration or one of those networking flukes.)

          http://www.isc.org/software/bind/versions

          > -----------------------------------------
          > the output below has been slightly sanitized of information
          > directly identifying the server.
          >
          > [example of delivery failure]
          > Nov 13 15:10:29 dna prefilter/smtpd[9340]: connect from
          > unknown[8.7.42.206]
          > Nov 13 15:10:29 dna prefilter/smtpd[9340]: NOQUEUE: reject: RCPT
          > from unknown[8.7.42.206]: 450 4.7.1 Client host rejected: cannot
          > find your hostname, [8.7.42.206];
          > from=<from-address@...> to=<user@...>
          > proto=ESMTP helo=<mta925.email.aerlingus.com>

          The timeout takes place before the logging of the connection. Postfix
          wants to be able to tell you who it was, not just "unknown[IP]" if
          possible.

          [snip]
          --
          http://rob0.nodns4.us/ -- system administration and consulting
          Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
        • Jamie Paul Griffin
          / IMAP List Administration wrote on Tue 13.Nov 12 at 21:55:11 +0100 / ... I ve been getting client requests from this ip as well, i ve put it into a permenant
          Message 4 of 9 , Nov 14, 2012
          • 0 Attachment
            / IMAP List Administration wrote on Tue 13.Nov'12 at 21:55:11 +0100 /

            > [example of delivery failure]
            > Nov 13 15:10:29 dna prefilter/smtpd[9340]: connect from unknown[8.7.42.206]

            I've been getting client requests from this ip as well, i've put it into a permenant spamd(8) blacklist.
          • IMAP List Administration
            ... that s highly interesting, but: 1) the sender was legitimate 2) my problem is some sort of intermittent DNS lookup failure 3) that address is just one of
            Message 5 of 9 , Nov 14, 2012
            • 0 Attachment
              On 11/14/2012 11:06 AM, Jamie Paul Griffin wrote:
              > I've been getting client requests from this ip as well, i've put it into a permenant spamd(8) blacklist.
              that's highly interesting, but:

              1) the sender was legitimate
              2) my problem is some sort of intermittent DNS lookup failure
              3) that address is just one of many *legitimate* MTA addresses for which I have
              seen the DNS problem

              but thanks!
            • Wietse Venema
              ... Try debugging this with nsping (name server ping). I suspect that your system suffers from occasional glitches with DNS lookups. Wietse
              Message 6 of 9 , Nov 14, 2012
              • 0 Attachment
                IMAP List Administration:
                >
                > On 11/14/2012 11:06 AM, Jamie Paul Griffin wrote:
                > > I've been getting client requests from this ip as well, i've put it into a permenant spamd(8) blacklist.
                > that's highly interesting, but:
                >
                > 1) the sender was legitimate
                > 2) my problem is some sort of intermittent DNS lookup failure
                > 3) that address is just one of many *legitimate* MTA addresses for which I have
                > seen the DNS problem

                Try debugging this with nsping (name server ping). I suspect that
                your system suffers from occasional glitches with DNS lookups.

                Wietse
              • IMAP List Administration
                [original post at bottom] in the meantime I ve upgraded the OS to OpenBSD v5.2, which offers 2 postfix versions as packages: postfix-2.10.20120630
                Message 7 of 9 , Dec 1, 2012
                • 0 Attachment
                  [original post at bottom]

                  in the meantime I've upgraded the OS to OpenBSD v5.2, which offers 2 postfix
                  versions as packages:

                  postfix-2.10.20120630
                  postfix-2.9.3

                  I chose v2.9.3.

                  bind is still "BIND 9.4.2-P2"

                  On 11/13/2012 10:50 PM, /dev/rob0 wrote:
                  > On Tue, Nov 13, 2012 at 09:55:11PM +0100,
                  > IMAP List Administration wrote:
                  >> I'm running a postfix (postfix-2.9.20120102-sasl2) server on
                  > That's a pre-release snapshot. Postfix 2.9 is up to patchlevel 4.
                  so now I have a release version of postfix.

                  > That's very old. 9.4.3 was EOL almost three years ago.
                  >
                  so no change here.

                  I still see the intermittent DNS lookup failures in postfix when querying my
                  local named.

                  For kicks, I changed /etc/resolv.conf to point to the nameserver of my provider,
                  which means the local named is no longer queried by postfix.

                  There was no change -- the intermittent failures still occur.

                  I tried using nsping to all the nameservers authoritative for one of the domains
                  for which I had a lookup failure. There was no indication of any problem.

                  Summary:
                  - upgraded OS
                  - upgraded Postfix
                  - cut local named out of system

                  but no change. Anyone have a suggestion as to how to pursue this problem?

                  cheers,

                  Robert Urban

                  -- original post --

                  I'm running a postfix (postfix-2.9.20120102-sasl2) server on OpenBSD v5.1. We
                  have a number of anti-UCE postfix measures in place, including
                  "reject_unknown_client_hostname", which we quite like. It's hard to believe
                  there are so many spammers that can't overcome such a low obstacle.

                  At any rate, we periodically see (1-5 times per day) a "Client host rejected:
                  cannot find your hostname" rejection, followed by a successful retry from the
                  remote MTA. When we check the DNS records, they always appear to be in order.
                  The remote MTAs belong to various organizations, but typically ones where one
                  would expect the DNS config to be well-maintained. (see bottom for an example
                  rejection and the ensuing successful retry).

                  I've tried to configure DNS (BIND 9.4.2-P2) to log debug information, and it
                  logs a fantastic amount, but I am unable to get it to log such queries and their
                  results, or maybe I just haven't found the magic combination of logging settings
                  yet, or maybe I don't understand the logging output.

                  The Questions:
                  1) is it possible that we are observing a bug in postfix in conjunction with
                  DNS-queries? Are there any such known bugs?
                  2) can someone give me a tip on how to configure BIND to log the information I
                  need to figure out why DNS lookups may be failing intermittently, and how to
                  read it properly?
                • Viktor Dukhovni
                  ... If you see this for all remote MTAs, the problem is with your DNS software or network connectivity. If it is just for certain remote MTAs and not the rest,
                  Message 8 of 9 , Dec 1, 2012
                  • 0 Attachment
                    On Sat, Dec 01, 2012 at 09:31:41PM +0100, IMAP List Administration wrote:

                    > At any rate, we periodically see (1-5 times per day) a "Client host rejected:
                    > cannot find your hostname" rejection, followed by a successful retry from the
                    > remote MTA. When we check the DNS records, they always appear to be in order.
                    > The remote MTAs belong to various organizations, but typically ones where one
                    > would expect the DNS config to be well-maintained. (see bottom for an example
                    > rejection and the ensuing successful retry).

                    If you see this for all remote MTAs, the problem is with your DNS
                    software or network connectivity. If it is just for certain remote
                    MTAs and not the rest, the problem is with their DNS.

                    > 1) is it possible that we are observing a bug in postfix in conjunction with
                    > DNS-queries? Are there any such known bugs?

                    No such bugs are known, likely or observed by other sites. DNS
                    clients are much simpler than DNS servers, look for bugs in DNS
                    configuration then the DNS servers or in the network.

                    > 2) can someone give me a tip on how to configure BIND to log the information I
                    > need to figure out why DNS lookups may be failing intermittently, and how to
                    > read it properly?

                    This is not simple. First use your Postfix logs to find out which domains
                    or IPs exhibit the transient errors, and whether such errors are
                    random or tied to specific domains.

                    --
                    Viktor.
                    >
                  • Wietse Venema
                    ... Obviously, the above attempts all share the same problem, i.e. the problem is your network or something beyond your network. Try running nsping (name
                    Message 9 of 9 , Dec 1, 2012
                    • 0 Attachment
                      IMAP List Administration:
                      > Summary:
                      > - upgraded OS
                      > - upgraded Postfix
                      > - cut local named out of system
                      >
                      > but no change. Anyone have a suggestion as to how to pursue this problem?

                      Obviously, the above attempts all share the same problem, i.e. the
                      problem is your network or something beyond your network.

                      Try running nsping (name server ping) over a long stretch of time
                      (e.g., 24 hours). It will tell you about dropped queries a variations
                      in response times.

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