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

connect from unknown

Expand Messages
  • Cameron Smith
    Having trouble getting postfix configured correctly to relay to Google Apps some of the time. I am seeing the following error in /var/log/mail.log Dec 8
    Message 1 of 5 , Dec 8, 2012
      Having trouble getting postfix configured correctly to relay to Google Apps some of the time.

      I am seeing the following error in /var/log/mail.log

      Dec 8 21:15:08 vps postfix/master[3924]: daemon started -- version 2.9.3, configuration /etc/postfix
      Dec 8 21:16:05 vps postfix/smtpd[3930]: warning: hostname vps.abw.co does not resolve to address 199.101.51.160
      Dec 8 21:16:05 vps postfix/smtpd[3930]: connect from unknown[199.101.51.160]
      Dec 8 21:16:05 vps postfix/smtpd[3930]: lost connection after RSET from unknown[199.101.51.160]
      Dec 8 21:16:05 vps postfix/smtpd[3930]: disconnect from unknown[199.101.51.160]

      If I use a sendmail command from the CLI I am able to send with a 250 response code.

      I only see the other error when using php and phpmailer.
      Since that makes it probably a phpmailer issue what things could be set incorrectly there that would cause postfix to log the errors listed above

      I have tried removing vps.abw.co from my destination with the same result.

      199.101.51.160 is my server IP
      vps.abw.co is my server hostname

      RDNS is set correctly:
      host 199.101.51.160
      160.51.101.199.in-addr.arpa domain name pointer vps.abw.co

      postconf -n
      alias_database = hash:/etc/aliases
      alias_maps = hash:/etc/aliases
      append_dot_mydomain = no
      biff = no
      config_directory = /etc/postfix
      default_destination_concurrency_limit = 5
      default_transport = smtp
      inet_interfaces = all
      inet_protocols = ipv4
      mailbox_command = procmail -a "$EXTENSION"
      mailbox_size_limit = 51200000
      mydestination = vps.abw.co, localhost.abw.co, localhost
      myhostname = vps.abw.co
      mynetworks = 127.0.0.0/8
      readme_directory = no
      recipient_delimiter = +
      relay_destination_concurrency_limit = 1
      relay_transport = relay
      relayhost = smtp.gmail.com:587
      smtp_connection_cache_destinations = smtp.gmail.com
      smtp_sasl_auth_enable = yes
      smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
      smtp_sasl_security_options = noanonymous
      smtp_sasl_tls_security_options = noanonymous
      smtp_tls_security_level = may
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
      smtpd_tls_CAfile = /root/ssl/ca.pem
      smtpd_tls_ask_ccert = yes
      smtpd_tls_cert_file = /root/ssl/ssl.crt
      smtpd_tls_key_file = /root/ssl/ssl.key
      smtpd_tls_loglevel = 1
      smtpd_tls_received_header = yes
      smtpd_tls_req_ccert = no
      smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
      smtpd_tls_session_cache_timeout = 3600s
      smtpd_use_tls = yes


      Thanks,

      Cameron Smith
    • Michael J Wise
      ... WHOIS says the domain doesn t exist. That would certainly explain the unknown s. It resolves, although it took a good long while. Something is wrong with
      Message 2 of 5 , Dec 8, 2012
        On Dec 8, 2012, at 9:33 PM, Cameron Smith wrote:

        > Dec 8 21:16:05 vps postfix/smtpd[3930]: warning: hostname vps.abw.co does not resolve to address 199.101.51.160

        WHOIS says the domain doesn't exist.
        That would certainly explain the "unknown"s.
        It resolves, although it took a good long while.
        Something is wrong with the registration.

        Aloha,
        Michael.
        --
        "Please have your Internet License
        and Usenet Registration handy..."
      • mouss
        ... postfix found that 199.101.51.160 resolves to vps.abw.co but not the opposite. many possibilities: - transient dns error. - dns misconfiguration (postfix
        Message 3 of 5 , Dec 9, 2012
          Le 09/12/2012 06:33, Cameron Smith a écrit :
          > Having trouble getting postfix configured correctly to relay to Google Apps some of the time.
          >
          > I am seeing the following error in /var/log/mail.log
          >
          > Dec 8 21:15:08 vps postfix/master[3924]: daemon started -- version 2.9.3, configuration /etc/postfix
          > Dec 8 21:16:05 vps postfix/smtpd[3930]: warning: hostname vps.abw.co does not resolve to address 199.101.51.160

          postfix found that 199.101.51.160 resolves to vps.abw.co but not the
          opposite. many possibilities:
          - transient dns error.
          - dns misconfiguration (postfix points to a dns server that doesn't give
          the right answer).
          - postfix is chrooted and /etc/resolv.conf is not copied to the chroot cage.

          to see whether postfix is chrooted, run
          egrep -i "^[0-9a-z].*smtpd" /etc/postfix/master.cf | awk '{print $5}'
          this command should show only 'n'. if you see 'y' or '-', then at least
          one smtpd is chrooted.


          > Dec 8 21:16:05 vps postfix/smtpd[3930]: connect from unknown[199.101.51.160]
          > Dec 8 21:16:05 vps postfix/smtpd[3930]: lost connection after RSET from unknown[199.101.51.160]

          For some reason, the client (or an intermediary router/firewall) dropped
          the connection.
          => postfix did not reject the client.

          > Dec 8 21:16:05 vps postfix/smtpd[3930]: disconnect from unknown[199.101.51.160]
          >
          > If I use a sendmail command from the CLI I am able to send with a 250 response code.

          it is unclear whether your phpmail runs on the same machine as your
          postfix server or whether they run on different boxen. and whether you
          run sendmail on the postfix server or another box. etc.



          >
          > I only see the other error when using php and phpmailer.
          > Since that makes it probably a phpmailer issue what things could be set incorrectly there that would cause postfix to log the errors listed above

          whatever is connecting to your postfix server drops the connection.


          >
          > I have tried removing vps.abw.co from my destination with the same result.
          >
          > 199.101.51.160 is my server IP
          > vps.abw.co is my server hostname
          >
          > RDNS is set correctly:
          > host 199.101.51.160
          > 160.51.101.199.in-addr.arpa domain name pointer vps.abw.co

          for the future (and for the archive), this alone is not enough to s"R is
          set correctly".
          You must test the "forward" query as well. yes, it woks from here (now).
          $ host vps.abw.co
          vps.abw.co has address 199.101.51.160



          > [snip]
          >
          >
          >
          >
          >
        • /dev/rob0
          ... This is not relevant to your stated problem description. Relaying to Google Apps would be a function of smtp(8), the SMTP client. Here we see a client
          Message 4 of 5 , Dec 9, 2012
            On Sat, Dec 08, 2012 at 09:33:47PM -0800, Cameron Smith wrote:
            > Having trouble getting postfix configured correctly to relay to
            > Google Apps some of the time.
            >
            > I am seeing the following error in /var/log/mail.log
            >
            > Dec 8 21:15:08 vps postfix/master[3924]: daemon started -- version
            > 2.9.3, configuration /etc/postfix
            > Dec 8 21:16:05 vps postfix/smtpd[3930]: warning: hostname
            > vps.abw.co does not resolve to address 199.101.51.160
            > Dec 8 21:16:05 vps postfix/smtpd[3930]: connect from
            > unknown[199.101.51.160]
            > Dec 8 21:16:05 vps postfix/smtpd[3930]: lost connection after RSET
            > from unknown[199.101.51.160]
            > Dec 8 21:16:05 vps postfix/smtpd[3930]: disconnect from
            > unknown[199.101.51.160]

            This is not relevant to your stated problem description. "Relaying to
            Google Apps" would be a function of smtp(8), the SMTP client. Here we
            see a client connecting to your smtpd(8), which for reasons known to
            that client only, decided to disconnect before attempting to send
            mail.

            However since it fits your Subject: line I'll guess this is the
            problem you mean to address here. You will have to see the client
            logs and configuration to know what's wrong. But read on; I will
            manage to write something useful, below. :)

            > If I use a sendmail command from the CLI I am able to send with
            > a 250 response code.

            Then your relaying works. This isn't relevant to the client
            disconnect.

            > I only see the other error when using php and phpmailer.
            > Since that makes it probably a phpmailer issue what things could
            > be set incorrectly there that would cause postfix to log the
            > errors listed above

            The client might see something in your EHLO response which makes it
            unable or unwilling to try to send mail. Again, only that client
            would know why it disconnected, and we don't support phpmailer here
            (I don't use it, myself, so I can't help.)

            > I have tried removing vps.abw.co from my destination with the same
            > result.

            If you mean "mydestination", that controls receipt of mail for
            local(8) delivery, not for outbound relaying.

            http://www.postfix.org/BASIC_CONFIGURATION_README.html

            > 199.101.51.160 is my server IP
            > vps.abw.co is my server hostname
            >
            > RDNS is set correctly:
            > host 199.101.51.160
            > 160.51.101.199.in-addr.arpa domain name pointer vps.abw.co

            $ host 199.101.51.160
            160.51.101.199.in-addr.arpa domain name pointer vps.abw.co.
            $ host vps.abw.co.
            vps.abw.co has address 199.101.51.160

            Fine here, the whois problem noted upthread notwithstanding. For some
            reason, the "vps" host from which you showed us logging above was not
            able to resolve vps.abw.co. to 199.101.51.160. Maybe you are yet
            another victim of Debian's ridiculous default chroot, or maybe
            something else is misconfigured in your OS.

            Read your distributor's Postfix packaging documentation, probably a
            "README.Debian" file, and go to them for support of their bad
            decisions.

            > postconf -n
            > alias_database = hash:/etc/aliases
            > alias_maps = hash:/etc/aliases
            > append_dot_mydomain = no
            > biff = no
            > config_directory = /etc/postfix
            > default_destination_concurrency_limit = 5
            > default_transport = smtp
            > inet_interfaces = all
            > inet_protocols = ipv4
            > mailbox_command = procmail -a "$EXTENSION"
            > mailbox_size_limit = 51200000
            > mydestination = vps.abw.co, localhost.abw.co, localhost
            > myhostname = vps.abw.co
            > mynetworks = 127.0.0.0/8

            Above you show us a client, which seems to be on the same host as
            this postconf output, connecting from 199.101.51.160.

            Why is the client using 199.101.51.160 and not 127.0.0.1 for its
            connection? If you want to allow this client to relay, why did you
            not list it in mynetworks, or better yet, remove mynetworks and set
            "mynetworks_style = host"?

            http://www.postfix.org/BASIC_CONFIGURATION_README.html#relay_from
            http://www.postfix.org/postconf.5.html#mynetworks_style

            > readme_directory = no
            > recipient_delimiter = +
            > relay_destination_concurrency_limit = 1
            > relay_transport = relay
            > relayhost = smtp.gmail.com:587

            This performs a MX lookup of the relayhost name. Perhaps you want
            "[smtp.gmail.com]:587" with the brackets?

            http://www.postfix.org/BASIC_CONFIGURATION_README.html#relayhost
            http://www.postfix.org/postconf.5.html#relayhost

            > smtp_connection_cache_destinations = smtp.gmail.com
            > smtp_sasl_auth_enable = yes
            > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
            > smtp_sasl_security_options = noanonymous
            > smtp_sasl_tls_security_options = noanonymous
            > smtp_tls_security_level = may
            > smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
            > smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
            > smtpd_tls_CAfile = /root/ssl/ca.pem
            > smtpd_tls_ask_ccert = yes
            > smtpd_tls_cert_file = /root/ssl/ssl.crt
            > smtpd_tls_key_file = /root/ssl/ssl.key

            There's nothing really wrong with this, because IIUC these are opened
            before dropping privileges and entering the chroot. But this is an
            unusual place to keep your TLS files. Only the last one, the key
            file, needs to be kept secure. Typically this would be under your
            OpenSSL configuration directory, e.g., /etc/ssl/private.

            > smtpd_tls_loglevel = 1
            > smtpd_tls_received_header = yes
            > smtpd_tls_req_ccert = no
            > smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
            > smtpd_tls_session_cache_timeout = 3600s
            > smtpd_use_tls = yes
            --
            http://rob0.nodns4.us/ -- system administration and consulting
            Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
          • mouss
            ... indeed. if the client is configured to use AUTH and/or STARTTLS and doesn t see it in the EHLO response, then that might explain the problem.
            Message 5 of 5 , Dec 9, 2012
              Le 09/12/2012 16:31, /dev/rob0 a écrit :
              > snip]
              > The client might see something in your EHLO response which makes it
              > unable or unwilling to try to send mail.

              indeed. if the client is configured to use AUTH and/or STARTTLS and
              doesn't see it in the EHLO response, then that might explain the problem.



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