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

lost connection with ]server] while receiving the initial server greeting

Expand Messages
  • postfix@...
    I recently moved out mail operations to a new server. The old server is running Postfix 2.8 and the new server 2.10. We had some initial problems with some
    Message 1 of 21 , May 2, 2014
      I recently moved out mail operations to a new server. The old server is
      running Postfix 2.8 and the new server 2.10.

      We had some initial problems with some private blacklists and the new IP
      but those were resolved. However, I had a curious problem sending mail
      to icloud.com addresses. Postfix was reporting:

      lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while
      receiving the initial server greeting

      to all MX servers for adadns.net.

      To get around this initial problem I began relaying outbound mail thru
      the old server until the blacklisting was all resolved. However, I am
      still unable to send to the adadns.net servers, still getting dropped
      connections. They were no help at all resolving the issue.

      Finally I tried to send an email by telnet to port 25 at the above IP
      from the new server and sure enough the email went through without
      issue.

      I've looked through the release notes for 2.9 and 2.10 and didn't see
      anything related concerning configuration that might explain this.

      Any ideas of what I can try next?

      postconf -n (irrelevant lines removed/edited):

      broken_sasl_auth_clients = yes
      command_directory = /usr/local/sbin
      config_directory = /usr/local/etc/postfix
      daemon_directory = /usr/local/libexec/postfix
      data_directory = /var/db/postfix
      inet_interfaces = all
      local_transport = virtual
      mail_owner = postfix
      mailq_path = /usr/local/bin/mailq
      manpage_directory = /usr/local/man
      master_service_disable =
      message_size_limit = 50000000
      mydestination = $myhostname, localhost.$mydomain, localhost
      myhostname = xxx.xxx.xxx
      myorigin = $myhostname
      newaliases_path = /usr/local/bin/newaliases
      queue_directory = /var/spool/postfix
      readme_directory = no
      sample_directory = /usr/local/etc/postfix
      sendmail_path = /usr/local/sbin/sendmail
      setgid_group = maildrop
      smtp_tls_note_starttls_offer = yes
      smtp_use_tls = yes
      smtpd_delay_reject = yes
      smtpd_helo_required = yes
      smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname,
      reject_invalid_hostname, permit
      smtpd_recipient_restrictions = check_recipient_access
      hash:/usr/local/etc/postfix/reject_recipients, reject_unauth_pipelining,
      reject_non_fqdn_recipient, reject_unknown_recipient_domain,
      check_recipient_maps, permit_sasl_authenticated, permit_mynetworks,
      reject_unauth_destination, permit
      smtpd_sasl_auth_enable = yes
      smtpd_sasl_local_domain =
      smtpd_sasl_path = smtpd
      smtpd_sasl_security_options = noanonymous
      smtpd_sender_restrictions = permit_sasl_authenticated,
      permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain,
      permit
      smtpd_tls_cert_file = /usr/local/etc/postfix/ssl/xxxxx.pem
      smtpd_tls_key_file = $smtpd_tls_cert_file
      smtpd_tls_loglevel = 1
      smtpd_tls_received_header = yes
      smtpd_tls_session_cache_timeout = 3600s
      smtpd_use_tls = yes
      tcp_windowsize = 1400
      tls_random_source = dev:/dev/urandom
      unknown_local_recipient_reject_code = 550
    • Wietse Venema
      ... What is your servers s public IP address? I suspect that PTR or A lookups are taking too long when the remote SMTP server is trying to determine your
      Message 2 of 21 , May 2, 2014
        postfix@...:
        > I recently moved out mail operations to a new server. The old server is
        > running Postfix 2.8 and the new server 2.10.
        >
        > We had some initial problems with some private blacklists and the new IP
        > but those were resolved. However, I had a curious problem sending mail
        > to icloud.com addresses. Postfix was reporting:
        >
        > lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while
        > receiving the initial server greeting
        >
        > to all MX servers for adadns.net.

        What is your servers's public IP address? I suspect that PTR
        or A lookups are taking too long when the remote SMTP server is
        trying to determine your server's hostname.

        Wietse
      • postfix@...
        ... 209.170.151.3 It doesn t seem to be taking long (from 3rd party location 191 msec) and wouldn t that have affected as well dong a telnet?
        Message 3 of 21 , May 2, 2014
          On , wietse@... wrote:
          > postfix@...:
          >> I recently moved out mail operations to a new server. The old server
          >> is
          >> running Postfix 2.8 and the new server 2.10.
          >>
          >> We had some initial problems with some private blacklists and the new
          >> IP
          >> but those were resolved. However, I had a curious problem sending
          >> mail
          >> to icloud.com addresses. Postfix was reporting:
          >>
          >> lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while
          >> receiving the initial server greeting
          >>
          >> to all MX servers for adadns.net.
          >
          > What is your servers's public IP address? I suspect that PTR
          > or A lookups are taking too long when the remote SMTP server is
          > trying to determine your server's hostname.
          >
          > Wietse

          209.170.151.3

          It doesn't seem to be taking long (from 3rd party location 191 msec) and
          wouldn't that have affected as well dong a telnet?
        • Wietse Venema
          ... You haven t said if this is a persistent problem. One telnet may work now, but that does not exclude the possibility of an eralier problem. What does
          Message 4 of 21 , May 2, 2014
            postfix@...:
            > On , wietse@... wrote:
            > > postfix@...:
            > >> I recently moved out mail operations to a new server. The old server
            > >> is
            > >> running Postfix 2.8 and the new server 2.10.
            > >>
            > >> We had some initial problems with some private blacklists and the new
            > >> IP but those were resolved. However, I had a curious problem sending
            > >> mail to icloud.com addresses. Postfix was reporting:
            > >>
            > >> lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while
            > >> receiving the initial server greeting
            > >>
            > >> to all MX servers for adadns.net.
            > >
            > > What is your servers's public IP address? I suspect that PTR
            > > or A lookups are taking too long when the remote SMTP server is
            > > trying to determine your server's hostname.
            > >
            > > Wietse
            >
            > 209.170.151.3
            >
            > It doesn't seem to be taking long (from 3rd party location 191 msec) and
            > wouldn't that have affected as well dong a telnet?

            You haven't said if this is a persistent problem. One telnet may
            work now, but that does not exclude the possibility of an eralier
            problem.

            What does Postfix log with "delay=a/b/c/d" when a connection is lost?

            Are you going through a stateful firewall/NAT that drops sessions
            to soon?

            I can speculate until the cows come home, but I prefer not to.

            Wietse
          • postfix@...
            ... Sorry, I m not trying to be difficult but I don t know what your speculation might run and therefore what questions you ll have. There is NO NAT or
            Message 5 of 21 , May 2, 2014
              On , wietse@... wrote:
              > postfix@...:
              >> On , wietse@... wrote:
              >> > postfix@...:
              >> >> I recently moved out mail operations to a new server. The old server
              >> >> is
              >> >> running Postfix 2.8 and the new server 2.10.
              >> >>
              >> >> We had some initial problems with some private blacklists and the new
              >> >> IP but those were resolved. However, I had a curious problem sending
              >> >> mail to icloud.com addresses. Postfix was reporting:
              >> >>
              >> >> lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while
              >> >> receiving the initial server greeting
              >> >>
              >> >> to all MX servers for adadns.net.
              >> >
              >> > What is your servers's public IP address? I suspect that PTR
              >> > or A lookups are taking too long when the remote SMTP server is
              >> > trying to determine your server's hostname.
              >> >
              >> > Wietse
              >>
              >> 209.170.151.3
              >>
              >> It doesn't seem to be taking long (from 3rd party location 191 msec)
              >> and
              >> wouldn't that have affected as well dong a telnet?
              >
              > You haven't said if this is a persistent problem. One telnet may
              > work now, but that does not exclude the possibility of an eralier
              > problem.
              >
              > What does Postfix log with "delay=a/b/c/d" when a connection is lost?
              >
              > Are you going through a stateful firewall/NAT that drops sessions
              > to soon?
              >
              > I can speculate until the cows come home, but I prefer not to.
              >
              > Wietse

              Sorry, I'm not trying to be difficult but I don't know what your
              speculation might run and therefore what questions you'll have.

              There is NO NAT or firewall.

              relay=mx4.icloud.com.akadns.net[17.172.34.67]:25, delay=177,
              delays=0.3/0.01/177/ 0, dsn=4.4.2, status=deferred (lost
              connection with mx4.icloud.com.akadns.net[17.172.34.67] while receiving
              the initial server greeting)
            • Wietse Venema
              ... 0.3 = No congestion within the Postfix queue. 0.01 = TCP completes immediately. 177 = Postfix waits for the 220 greeting until the connection is dropped. I
              Message 6 of 21 , May 3, 2014
                postfix@...:
                > There is NO NAT or firewall.
                >
                > relay=mx4.icloud.com.akadns.net[17.172.34.67]:25, delay=177,
                > delays=0.3/0.01/177/0, dsn=4.4.2, status=deferred (lost
                > connection with mx4.icloud.com.akadns.net[17.172.34.67] while receiving
                > the initial server greeting)

                0.3 = No congestion within the Postfix queue.
                0.01 = TCP completes immediately.
                177 = Postfix waits for the 220 greeting until the connection is dropped.

                I suggest that you take Postfix out of the loop, and diagnose this
                further with plain old telnet.

                Wietse
              • postfix@...
                ... Wietse, thank you for your efforts. Telnet isn t telling me anything new: Trying 17.172.34.70... Connected to st11p00mm-mx006.me.com. Escape character is
                Message 7 of 21 , May 3, 2014
                  On , wietse@... wrote:
                  > postfix@...:
                  >> There is NO NAT or firewall.
                  >>
                  >> relay=mx4.icloud.com.akadns.net[17.172.34.67]:25, delay=177,
                  >> delays=0.3/0.01/177/0, dsn=4.4.2, status=deferred (lost
                  >> connection with mx4.icloud.com.akadns.net[17.172.34.67] while
                  >> receiving
                  >> the initial server greeting)
                  >
                  > 0.3 = No congestion within the Postfix queue.
                  > 0.01 = TCP completes immediately.
                  > 177 = Postfix waits for the 220 greeting until the connection is
                  > dropped.
                  >
                  > I suggest that you take Postfix out of the loop, and diagnose this
                  > further with plain old telnet.
                  >
                  > Wietse

                  Wietse, thank you for your efforts. Telnet isn't telling me anything
                  new:

                  Trying 17.172.34.70...
                  Connected to st11p00mm-mx006.me.com.
                  Escape character is '^]'.
                  220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
                  Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))

                  As you can see, I'm getting an immediate 220 from them which postfix
                  apparently is not getting. I can, of course, continue the telnet
                  session and send a complete email which is received by the recipient.
                • Stan Hoeppner
                  ... 17.172.34.67 ... 17.172.34.70 ... Note that you are manually telnet testing against a different host than the one logged by Postfix with the greet timeout.
                  Message 8 of 21 , May 3, 2014
                    On 5/3/2014 7:54 AM, postfix@... wrote:
                    > On , wietse@... wrote:
                    ...
                    >>> relay=mx4.icloud.com.akadns.net[17.172.34.67]:25, delay=177,
                    >>> delays=0.3/0.01/177/0, dsn=4.4.2, status=deferred (lost
                    >>> connection with mx4.icloud.com.akadns.net[17.172.34.67] while receiving
                    >>> the initial server greeting)

                    17.172.34.67

                    >> 0.3 = No congestion within the Postfix queue.
                    >> 0.01 = TCP completes immediately.
                    >> 177 = Postfix waits for the 220 greeting until the connection is
                    >> dropped.
                    >>
                    >> I suggest that you take Postfix out of the loop, and diagnose this
                    >> further with plain old telnet.
                    >>
                    >> Wietse
                    >
                    > Wietse, thank you for your efforts. Telnet isn't telling me anything new:
                    >
                    > Trying 17.172.34.70...
                    > Connected to st11p00mm-mx006.me.com.
                    > Escape character is '^]'.
                    > 220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
                    > Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))

                    17.172.34.70

                    > As you can see, I'm getting an immediate 220 from them which postfix
                    > apparently is not getting. I can, of course, continue the telnet
                    > session and send a complete email which is received by the recipient.

                    Note that you are manually telnet testing against a different host than
                    the one logged by Postfix with the greet timeout. Also note there are
                    12 MX hosts in the me.com/mac.com inbound farm. Depending on the nature
                    of the problem, you may only see it with 17.172.34.67, and the other 11
                    may be fine.

                    You need to perform proper and thorough testing in order to determine if
                    this problem exists with only one of the 11 farm hosts, or more than
                    one, and if it is transient or ongoing.


                    > ;; QUESTION SECTION:
                    > ;mac.com. IN MX
                    >
                    > ;; ANSWER SECTION:
                    > mac.com. 3600 IN MX 10 mx4.mac.com.akadns.net.
                    > mac.com. 3600 IN MX 10 mx3.mac.com.akadns.net.
                    > mac.com. 3600 IN MX 10 mx1.mac.com.akadns.net.
                    > mac.com. 3600 IN MX 10 mx5.mac.com.akadns.net.
                    > mac.com. 3600 IN MX 10 mx2.mac.com.akadns.net.
                    > mac.com. 3600 IN MX 10 mx6.mac.com.akadns.net.
                    >
                    > ;; ADDITIONAL SECTION:
                    > mx3.mac.com.akadns.net. 300 IN A 17.172.34.65
                    > mx5.mac.com.akadns.net. 300 IN A 17.172.34.69
                    > mx2.mac.com.akadns.net. 300 IN A 17.172.34.12
                    > mx4.mac.com.akadns.net. 300 IN A 17.172.34.67
                    > mx2.mac.com.akadns.net. 300 IN A 17.172.34.11
                    > mx4.mac.com.akadns.net. 300 IN A 17.172.34.66
                    > mx6.mac.com.akadns.net. 300 IN A 17.172.34.71
                    > mx1.mac.com.akadns.net. 300 IN A 17.172.34.9
                    > mx1.mac.com.akadns.net. 300 IN A 17.172.34.10
                    > mx3.mac.com.akadns.net. 300 IN A 17.172.34.64
                    > mx5.mac.com.akadns.net. 300 IN A 17.172.34.68
                    > mx6.mac.com.akadns.net. 300 IN A 17.172.34.70

                    > ;; QUESTION SECTION:
                    > ;me.com. IN MX
                    >
                    > ;; ANSWER SECTION:
                    > me.com. 3600 IN MX 10 mx4.me.com.akadns.net.
                    > me.com. 3600 IN MX 10 mx5.me.com.akadns.net.
                    > me.com. 3600 IN MX 10 mx3.me.com.akadns.net.
                    > me.com. 3600 IN MX 10 mx6.me.com.akadns.net.
                    > me.com. 3600 IN MX 10 mx1.me.com.akadns.net.
                    > me.com. 3600 IN MX 10 mx2.me.com.akadns.net.
                    >
                    > ;; ADDITIONAL SECTION:
                    > mx1.me.com.akadns.net. 300 IN A 17.172.34.9
                    > mx6.me.com.akadns.net. 300 IN A 17.172.34.70
                    > mx4.me.com.akadns.net. 300 IN A 17.172.34.66
                    > mx2.me.com.akadns.net. 300 IN A 17.172.34.12
                    > mx5.me.com.akadns.net. 300 IN A 17.172.34.69
                    > mx4.me.com.akadns.net. 300 IN A 17.172.34.67
                    > mx3.me.com.akadns.net. 300 IN A 17.172.34.65
                    > mx6.me.com.akadns.net. 300 IN A 17.172.34.71
                    > mx1.me.com.akadns.net. 300 IN A 17.172.34.10
                    > mx5.me.com.akadns.net. 300 IN A 17.172.34.68
                    > mx2.me.com.akadns.net. 300 IN A 17.172.34.11
                    > mx3.me.com.akadns.net. 300 IN A 17.172.34.64


                    Cheers,

                    Stan
                  • postfix@...
                    ... Stan, thank you I should have been clearer. Postfix 2.10.2 runs through all mx records for the domain (icloud.com) and fails with all. I tested telnet
                    Message 9 of 21 , May 3, 2014
                      On , Stan Hoeppner wrote:
                      > On 5/3/2014 7:54 AM, postfix@... wrote:
                      >> On , wietse@... wrote:
                      > ...
                      >>>> relay=mx4.icloud.com.akadns.net[17.172.34.67]:25, delay=177,
                      >>>> delays=0.3/0.01/177/0, dsn=4.4.2, status=deferred (lost
                      >>>> connection with mx4.icloud.com.akadns.net[17.172.34.67] while
                      >>>> receiving
                      >>>> the initial server greeting)
                      >
                      > 17.172.34.67
                      >
                      >>> 0.3 = No congestion within the Postfix queue.
                      >>> 0.01 = TCP completes immediately.
                      >>> 177 = Postfix waits for the 220 greeting until the connection is
                      >>> dropped.
                      >>>
                      >>> I suggest that you take Postfix out of the loop, and diagnose this
                      >>> further with plain old telnet.
                      >>>
                      >>> Wietse
                      >>
                      >> Wietse, thank you for your efforts. Telnet isn't telling me anything
                      >> new:
                      >>
                      >> Trying 17.172.34.70...
                      >> Connected to st11p00mm-mx006.me.com.
                      >> Escape character is '^]'.
                      >> 220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
                      >> Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))
                      >
                      > 17.172.34.70
                      >
                      >> As you can see, I'm getting an immediate 220 from them which postfix
                      >> apparently is not getting. I can, of course, continue the telnet
                      >> session and send a complete email which is received by the recipient.
                      >
                      > Note that you are manually telnet testing against a different host than
                      > the one logged by Postfix with the greet timeout. Also note there are
                      > 12 MX hosts in the me.com/mac.com inbound farm. Depending on the
                      > nature
                      > of the problem, you may only see it with 17.172.34.67, and the other 11
                      > may be fine.
                      >
                      > You need to perform proper and thorough testing in order to determine
                      > if
                      > this problem exists with only one of the 11 farm hosts, or more than
                      > one, and if it is transient or ongoing.
                      >
                      >
                      >> ;; QUESTION SECTION:
                      >> ;mac.com. IN MX
                      >>
                      >> ;; ANSWER SECTION:
                      >> mac.com. 3600 IN MX 10
                      >> mx4.mac.com.akadns.net.
                      >> mac.com. 3600 IN MX 10
                      >> mx3.mac.com.akadns.net.
                      >> mac.com. 3600 IN MX 10
                      >> mx1.mac.com.akadns.net.
                      >> mac.com. 3600 IN MX 10
                      >> mx5.mac.com.akadns.net.
                      >> mac.com. 3600 IN MX 10
                      >> mx2.mac.com.akadns.net.
                      >> mac.com. 3600 IN MX 10
                      >> mx6.mac.com.akadns.net.
                      >>
                      >> ;; ADDITIONAL SECTION:
                      >> mx3.mac.com.akadns.net. 300 IN A 17.172.34.65
                      >> mx5.mac.com.akadns.net. 300 IN A 17.172.34.69
                      >> mx2.mac.com.akadns.net. 300 IN A 17.172.34.12
                      >> mx4.mac.com.akadns.net. 300 IN A 17.172.34.67
                      >> mx2.mac.com.akadns.net. 300 IN A 17.172.34.11
                      >> mx4.mac.com.akadns.net. 300 IN A 17.172.34.66
                      >> mx6.mac.com.akadns.net. 300 IN A 17.172.34.71
                      >> mx1.mac.com.akadns.net. 300 IN A 17.172.34.9
                      >> mx1.mac.com.akadns.net. 300 IN A 17.172.34.10
                      >> mx3.mac.com.akadns.net. 300 IN A 17.172.34.64
                      >> mx5.mac.com.akadns.net. 300 IN A 17.172.34.68
                      >> mx6.mac.com.akadns.net. 300 IN A 17.172.34.70
                      >
                      >> ;; QUESTION SECTION:
                      >> ;me.com. IN MX
                      >>
                      >> ;; ANSWER SECTION:
                      >> me.com. 3600 IN MX 10
                      >> mx4.me.com.akadns.net.
                      >> me.com. 3600 IN MX 10
                      >> mx5.me.com.akadns.net.
                      >> me.com. 3600 IN MX 10
                      >> mx3.me.com.akadns.net.
                      >> me.com. 3600 IN MX 10
                      >> mx6.me.com.akadns.net.
                      >> me.com. 3600 IN MX 10
                      >> mx1.me.com.akadns.net.
                      >> me.com. 3600 IN MX 10
                      >> mx2.me.com.akadns.net.
                      >>
                      >> ;; ADDITIONAL SECTION:
                      >> mx1.me.com.akadns.net. 300 IN A 17.172.34.9
                      >> mx6.me.com.akadns.net. 300 IN A 17.172.34.70
                      >> mx4.me.com.akadns.net. 300 IN A 17.172.34.66
                      >> mx2.me.com.akadns.net. 300 IN A 17.172.34.12
                      >> mx5.me.com.akadns.net. 300 IN A 17.172.34.69
                      >> mx4.me.com.akadns.net. 300 IN A 17.172.34.67
                      >> mx3.me.com.akadns.net. 300 IN A 17.172.34.65
                      >> mx6.me.com.akadns.net. 300 IN A 17.172.34.71
                      >> mx1.me.com.akadns.net. 300 IN A 17.172.34.10
                      >> mx5.me.com.akadns.net. 300 IN A 17.172.34.68
                      >> mx2.me.com.akadns.net. 300 IN A 17.172.34.11
                      >> mx3.me.com.akadns.net. 300 IN A 17.172.34.64
                      >
                      >
                      > Cheers,
                      >
                      > Stan

                      Stan, thank you I should have been clearer. Postfix 2.10.2 runs through
                      all mx records for the domain (icloud.com) and fails with all. I
                      tested telnet with all and they all returned 220 instantaneously.

                      % dig icloud.com mx

                      ; <<>> DiG 9.8.4-P2 <<>> icloud.com mx
                      ;; global options: +cmd
                      ;; Got answer:
                      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21113
                      ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

                      ;; QUESTION SECTION:
                      ;icloud.com. IN MX

                      ;; ANSWER SECTION:
                      icloud.com. 3600 IN MX 10
                      mx4.icloud.com.akadns.net.
                      icloud.com. 3600 IN MX 10
                      mx1.icloud.com.akadns.net.
                      icloud.com. 3600 IN MX 10
                      mx6.icloud.com.akadns.net.
                      icloud.com. 3600 IN MX 10
                      mx2.icloud.com.akadns.net.
                      icloud.com. 3600 IN MX 10
                      mx3.icloud.com.akadns.net.
                      icloud.com. 3600 IN MX 10
                      mx5.icloud.com.akadns.net.

                      ;; Query time: 76 msec
                      ;; SERVER: 208.79.80.18#53(208.79.80.18)
                      ;; WHEN: Sat May 3 19:38:34 2014
                      ;; MSG SIZE rcvd: 169


                      % telnet mx4.icloud.com.akadns.net 25
                      Trying 17.172.34.67...
                      Connected to mx4.icloud.com.akadns.net.
                      Escape character is '^]'.
                      220 st11p00mm-smtpin009.mac.com -- Server ESMTP (Oracle Communications
                      Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))

                      % telnet mx1.icloud.com.akadns.net 25
                      Trying 17.172.34.10...
                      Connected to mx1.icloud.com.akadns.net.
                      Escape character is '^]'.
                      220 st11p00mm-smtpin003.mac.com -- Server ESMTP (Oracle Communications
                      Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))

                      % telnet mx6.icloud.com.akadns.net 25
                      Trying 17.172.34.70...
                      Connected to mx6.icloud.com.akadns.net.
                      Escape character is '^]'.
                      220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
                      Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))

                      % telnet mx2.icloud.com.akadns.net 25
                      Trying 17.172.34.12...
                      Connected to mx2.icloud.com.akadns.net.
                      Escape character is '^]'.
                      220 st11p00mm-smtpin014.mac.com -- Server ESMTP (Oracle Communications
                      Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))
                      % telnet mx3.icloud.com.akadns.net 25
                      Trying 17.172.34.65...
                      Connected to mx3.icloud.com.akadns.net.
                      Escape character is '^]'.
                      220 st11p00mm-smtpin011.mac.com -- Server ESMTP (Oracle Communications
                      Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))

                      % telnet mx5.icloud.com.akadns.net 25
                      Trying 17.172.34.68...
                      Connected to mx5.icloud.com.akadns.net.
                      Escape character is '^]'.
                      220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
                      Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))



                      Yes, me.com and mac.com are affected as well (as you can see mac.com at
                      least shares some mx servers in common).

                      I have the existing (old) server running 2.8.7 which connects without
                      incident. I've tested 2.8.17 on a new server which shares the same
                      problem with 2.10.2.
                    • Wietse Venema
                      ... And so can Postfix. One SINGLE SMTP connection from Postfix is likely to proceed just as well. Wietse
                      Message 10 of 21 , May 3, 2014
                        postfix@...:
                        > Wietse, thank you for your efforts. Telnet isn't telling me anything
                        > new:
                        >
                        > Trying 17.172.34.70...
                        > Connected to st11p00mm-mx006.me.com.
                        > Escape character is '^]'.
                        > 220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
                        > Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))
                        >
                        > As you can see, I'm getting an immediate 220 from them which postfix
                        > apparently is not getting. I can, of course, continue the telnet
                        > session and send a complete email which is received by the recipient.

                        And so can Postfix. One SINGLE SMTP connection from Postfix is likely
                        to proceed just as well.

                        Wietse
                      • postfix@...
                        ... Why do you think it s a single connection? It s multiple connections from Postfix to multiple servers over multiple emails over multiple days and not ONE
                        Message 11 of 21 , May 3, 2014
                          On , wietse@... wrote:
                          > postfix@...:
                          >> Wietse, thank you for your efforts. Telnet isn't telling me anything
                          >> new:
                          >>
                          >> Trying 17.172.34.70...
                          >> Connected to st11p00mm-mx006.me.com.
                          >> Escape character is '^]'.
                          >> 220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
                          >> Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))
                          >>
                          >> As you can see, I'm getting an immediate 220 from them which postfix
                          >> apparently is not getting. I can, of course, continue the telnet
                          >> session and send a complete email which is received by the recipient.
                          >
                          > And so can Postfix. One SINGLE SMTP connection from Postfix is likely
                          > to proceed just as well.
                          >
                          > Wietse

                          Why do you think it's a single connection? It's multiple connections
                          from Postfix to multiple servers over multiple emails over multiple days
                          and not ONE has successfully connected. Yet telnet to all of those same
                          multiple servers from the same host that is running Postfix, that is
                          unable to connect, succeed, multiple times, without a single failure.

                          Meanwhile, a separate box running Postfix 2.8.7 can connect to those
                          same servers without failure.
                        • Wietse Venema
                          ... I made a telnet connection from my own machine without trouble. What system did YOU make the connection from? ... Indeed, the problem is making multiple
                          Message 12 of 21 , May 3, 2014
                            postfix@...:
                            > >> Trying 17.172.34.70...
                            > >> Connected to st11p00mm-mx006.me.com.
                            > >> Escape character is '^]'.
                            > >> 220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
                            > >> Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))

                            I made a telnet connection from my own machine without trouble.
                            What system did YOU make the connection from?

                            > >> As you can see, I'm getting an immediate 220 from them which postfix
                            > >> apparently is not getting. I can, of course, continue the telnet
                            > >> session and send a complete email which is received by the recipient.
                            > >
                            > > And so can Postfix. One SINGLE SMTP connection from Postfix is likely
                            > > to proceed just as well.
                            >
                            > Why do you think it's a single connection?
                            > It's multiple connections from Postfix to multiple servers over
                            > multiple emails over multiple days

                            Indeed, the problem is making multiple connections in the past.
                            Your telnet test was today, making one connection.

                            You may learn more by capturing a few failed SMTP sessions with
                            tcpdump.

                            Wietse
                          • postfix@...
                            ... No where did I state the telnet tests were all done today. No where did I say no test via Postfix were run today.
                            Message 13 of 21 , May 3, 2014
                              On , wietse@... wrote:
                              > postfix@...:
                              >> >> Trying 17.172.34.70...
                              >> >> Connected to st11p00mm-mx006.me.com.
                              >> >> Escape character is '^]'.
                              >> >> 220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
                              >> >> Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))
                              >
                              > I made a telnet connection from my own machine without trouble.
                              > What system did YOU make the connection from?
                              >
                              >> >> As you can see, I'm getting an immediate 220 from them which postfix
                              >> >> apparently is not getting. I can, of course, continue the telnet
                              >> >> session and send a complete email which is received by the recipient.
                              >> >
                              >> > And so can Postfix. One SINGLE SMTP connection from Postfix is likely
                              >> > to proceed just as well.
                              >>
                              >> Why do you think it's a single connection?
                              >> It's multiple connections from Postfix to multiple servers over
                              >> multiple emails over multiple days
                              >
                              > Indeed, the problem is making multiple connections in the past.
                              > Your telnet test was today, making one connection.
                              >
                              > You may learn more by capturing a few failed SMTP sessions with
                              > tcpdump.
                              >
                              > Wietse


                              No where did I state the telnet tests were all done today. No where did
                              I say no test via Postfix were run today.
                            • postfix@...
                              ... Wietse, You are correct, I learned more but not enough for me, at least, to figure out what it means. Clarification, thru all this I ve talked about
                              Message 14 of 21 , May 3, 2014
                                >
                                > You may learn more by capturing a few failed SMTP sessions with
                                > tcpdump.
                                >
                                > Wietse

                                Wietse,

                                You are correct, I learned more but not enough for me, at least, to
                                figure out what it means.

                                Clarification, thru all this I've talked about connecting to icloud.com
                                mx. For the purposes of this test I did a tcpdump for the subnet that
                                all the mx servers reside on. The PTR records return a different result
                                (xxx.me.com) but are the same servers.

                                There were several attempts from postfix to connect to 6 different mx
                                servers to deliver one email. They all have the same result so I'm only
                                including the dump of the first here:

                                reading from file postfix.cap, link-type EN10MB (Ethernet)
                                2014-05-03 22:29:50.755792 IP smtp.bestwny.com.36708 >
                                nk11p00mm-mx006.me.com.smtp: Flags [S], seq 3314275386, win 1400,
                                options [mss 1460,nop,wscale 6,sackOK,TS val 170874802 ecr 0], length 0
                                E..<.e@.@..........r.d.....:.......x...............

                                /W.....
                                2014-05-03 22:29:50.803327 IP nk11p00mm-mx006.me.com.smtp >
                                smtp.bestwny.com.36708: Flags [S.], seq 851616152, ack 3314275387, win
                                33304, options [nop,nop,TS val 803912023 ecr 170874802,mss
                                1460,nop,wscale 1,nop,nop,sackOK], length 0
                                E(.@$b@.2..p...r.......d2......;.....V.....
                                /..W
                                /W.............
                                2014-05-03 22:29:50.803385 IP smtp.bestwny.com.36708 >
                                nk11p00mm-mx006.me.com.smtp: Flags [.], ack 1, win 21, options
                                [nop,nop,TS val 170874848 ecr 803912023], length 0
                                E..4.o@.@..........r.d.....;2..............

                                /W./..W
                                2014-05-03 22:29:51.926871 IP nk11p00mm-mx006.me.com.smtp >
                                smtp.bestwny.com.36708: Flags [S.], seq 851616152, ack 3314275387, win
                                33304, options [nop,nop,TS val 803912136 ecr 170874802,mss
                                1460,nop,wscale 1,nop,nop,sackOK], length 0
                                E(.@$c@.2..o...r.......d2......;...........
                                /...
                                /W.............
                                2014-05-03 22:29:51.926896 IP smtp.bestwny.com.36708 >
                                nk11p00mm-mx006.me.com.smtp: Flags [.], ack 1, win 21, options
                                [nop,nop,TS val 170875972 ecr 803912136], length 0
                                E..4..@.@..........r.d.....;2..............

                                /\D/...
                                2014-05-03 22:29:54.195922 IP nk11p00mm-mx006.me.com.smtp >
                                smtp.bestwny.com.36708: Flags [S.], seq 851616152, ack 3314275387, win
                                33304, options [nop,nop,TS val 803912362 ecr 170874802,mss
                                1460,nop,wscale 1,nop,nop,sackOK], length 0
                                E(.@$d@.2..n...r.......d2......;...........
                                /...
                                /W.............
                                2014-05-03 22:29:54.195953 IP smtp.bestwny.com.36708 >
                                nk11p00mm-mx006.me.com.smtp: Flags [.], ack 1, win 21, options
                                [nop,nop,TS val 170878242 ecr 803912362], length 0
                                E..4..@.@..c.......r.d.....;2..............

                                /e"/...
                                2014-05-03 22:29:58.713053 IP nk11p00mm-mx006.me.com.smtp >
                                smtp.bestwny.com.36708: Flags [S.], seq 851616152, ack 3314275387, win
                                33304, options [nop,nop,TS val 803912814 ecr 170874802,mss
                                1460,nop,wscale 1,nop,nop,sackOK], length 0
                                E(.@$e@.2..m...r.......d2......;.....?.....
                                /..n
                                /W.............
                                2014-05-03 22:29:58.713079 IP smtp.bestwny.com.36708 >
                                nk11p00mm-mx006.me.com.smtp: Flags [.], ack 1, win 21, options
                                [nop,nop,TS val 170882759 ecr 803912814], length 0
                                E..4..@.@..........r.d.....;2..............

                                /v./..n
                                2014-05-03 22:30:07.717105 IP nk11p00mm-mx006.me.com.smtp >
                                smtp.bestwny.com.36708: Flags [S.], seq 851616152, ack 3314275387, win
                                33304, options [nop,nop,TS val 803913715 ecr 170874802,mss
                                1460,nop,wscale 1,nop,nop,sackOK], length 0
                                E(.@$f@.2..l...r.......d2......;...........
                                /...
                                /W.............
                                2014-05-03 22:30:07.717136 IP smtp.bestwny.com.36708 >
                                nk11p00mm-mx006.me.com.smtp: Flags [.], ack 1, win 21, options
                                [nop,nop,TS val 170891763 ecr 803913715], length 0
                                E..4!.@.@..........r.d.....;2..............

                                /../...
                                2014-05-03 22:30:25.735938 IP nk11p00mm-mx006.me.com.smtp >
                                smtp.bestwny.com.36708: Flags [R.], seq 1, ack 1, win 33304, length 0
                                E(.($g@.2......r.......d2......;P....Y..
                                2014-05-03 22:30:25.736215 IP smtp.bestwny.com.59558 > 17.158.8.71.smtp:
                                Flags [S], seq 3843436255, win 1400, options [mss 1460,nop,wscale
                                6,sackOK,TS val 170909782 ecr 0], length 0
                                E..<%g@.@..........G...............x...............

                                /.V....



                                As you can see, no 220 was returned to Postfix

                                I then did a capture of a telnet session to the same server on port 25:

                                reading from file telnet.cap, link-type EN10MB (Ethernet)
                                2014-05-03 22:35:14.821306 IP smtp.bestwny.com.58803 >
                                nk11p00-smtp-mx003.mac.com.smtp: Flags [S], seq 3396279601, win 65535,
                                options [mss 1460,nop,wscale 6,sackOK,TS val 171198862 ecr 0], length 0
                                E..<t.@.@.C........2.....o.1.......................

                                4I.....
                                2014-05-03 22:35:14.869697 IP nk11p00-smtp-mx003.mac.com.smtp >
                                smtp.bestwny.com.58803: Flags [S.], seq 1071218802, ack 3396279602, win
                                33304, options [nop,nop,TS val 406558553 ecr 171198862,mss
                                1460,nop,wscale 1,nop,nop,sackOK], length 0
                                E(.@`.@.2.em...2........?..r.o.2.....H.....
                                .;.Y
                                4I.............
                                2014-05-03 22:35:14.869751 IP smtp.bestwny.com.58803 >
                                nk11p00-smtp-mx003.mac.com.smtp: Flags [.], ack 1, win 1040, options
                                [nop,nop,TS val 171198912 ecr 406558553], length 0
                                E..4t.@.@.C........2.....o.2?..s...........

                                4I..;.Y
                                2014-05-03 22:35:14.931907 IP nk11p00-smtp-mx003.mac.com.smtp >
                                smtp.bestwny.com.58803: Flags [P.], seq 1:139, ack 1, win 33304, options
                                [nop,nop,TS val 406558560 ecr 171198912], length 138
                                E(..`.@.2.d....2........?..s.o.2.....'.....
                                .;.`
                                4I.220 nk11p00mm-smtpin017.mac.com -- Server ESMTP (Oracle
                                Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug
                                22 2013))

                                2014-05-03 22:35:15.025661 IP smtp.bestwny.com.58803 >
                                nk11p00-smtp-mx003.mac.com.smtp: Flags [.], ack 139, win 1040, options
                                [nop,nop,TS val 171199072 ecr 406558560], length 0
                                E..4t.@.@.C........2.....o.2?..............

                                4J`.;.`
                                2014-05-03 22:35:21.434234 IP smtp.bestwny.com.58803 >
                                nk11p00-smtp-mx003.mac.com.smtp: Flags [P.], seq 1:24, ack 139, win
                                1040, options [nop,nop,TS val 171205472 ecr 406558560], length 23
                                E..Kv`@.@.A........2.....o.2?..............

                                4c`.;.`EHLO smtp.bestwny.com

                                2014-05-03 22:35:21.482488 IP nk11p00-smtp-mx003.mac.com.smtp >
                                smtp.bestwny.com.58803: Flags [.], ack 24, win 33304, options
                                [nop,nop,TS val 406559215 ecr 171205472], length 0
                                E(.4`.@.2.ew...2........?....o.I...........
                                .;..
                                4c`
                                2014-05-03 22:35:21.483075 IP nk11p00-smtp-mx003.mac.com.smtp >
                                smtp.bestwny.com.58803: Flags [P.], seq 139:395, ack 24, win 33304,
                                options [nop,nop,TS val 406559215 ecr 171205472], length 256
                                E(.4`.@.2.dv...2........?....o.I.....>.....
                                .;..
                                4c`250-nk11p00mm-smtpin017.mac.com
                                250-8BITMIME
                                250-PIPELINING
                                250-CHUNKING
                                250-DSN
                                250-ENHANCEDSTATUSCODES
                                250-EXPN
                                250-HELP
                                250-XADR
                                250-XSTA
                                250-XCIR
                                250-XGEN
                                250-XLOOP 5FD8A7158C627CE6C2DD92D78FDB33EF
                                250-ETRN
                                250-NO-SOLICITING
                                250 SIZE 0

                                2014-05-03 22:35:21.575676 IP smtp.bestwny.com.58803 >
                                nk11p00-smtp-mx003.mac.com.smtp: Flags [.], ack 395, win 1040, options
                                [nop,nop,TS val 171205622 ecr 406559215], length 0
                                E..4vk@.@.A........2.....o.I?..............

                                4c..;..
                                2014-05-03 22:35:27.584480 IP smtp.bestwny.com.58803 >
                                nk11p00-smtp-mx003.mac.com.smtp: Flags [F.], seq 24, ack 395, win 1040,
                                options [nop,nop,TS val 171211622 ecr 406559215], length 0
                                E..4w.@.@.@Q.......2.....o.I?..............

                                4{f.;..
                                2014-05-03 22:35:27.632735 IP nk11p00-smtp-mx003.mac.com.smtp >
                                smtp.bestwny.com.58803: Flags [.], ack 25, win 33304, options
                                [nop,nop,TS val 406559830 ecr 171211622], length 0
                                E(.4`.@.2.eu...2........?....o.J...........
                                .;.V
                                4{f
                                2014-05-03 22:35:27.633216 IP nk11p00-smtp-mx003.mac.com.smtp >
                                smtp.bestwny.com.58803: Flags [F.], seq 395, ack 25, win 33304, options
                                [nop,nop,TS val 406559830 ecr 171211622], length 0
                                E(.4`.@.2.et...2........?....o.J...........
                                .;.V
                                4{f
                                2014-05-03 22:35:27.633248 IP smtp.bestwny.com.58803 >
                                nk11p00-smtp-mx003.mac.com.smtp: Flags [.], ack 396, win 1040, options
                                [nop,nop,TS val 171211672 ecr 406559830], length 0
                                E..4w.@.@.@J.......2.....o.J?..............

                                4{..;.V

                                I am clueless as to why telnet would receive a correct response but
                                Postfix not.

                                I know see this is not necessarily a Postfix issue but not sure what the
                                next step would be, so if anyone can offer guidance it would be
                                appreciated.
                              • Stan Hoeppner
                                On 5/3/2014 9:48 PM, postfix@nisny.com wrote: ... The problem is exclusive, as far as we know, to this Akamai hosted MX farm. Wietse is obviously correct.
                                Message 15 of 21 , May 4, 2014
                                  On 5/3/2014 9:48 PM, postfix@... wrote:
                                  ...
                                  > I am clueless as to why telnet would receive a correct response but
                                  > Postfix not.
                                  >
                                  > I know see this is not necessarily a Postfix issue but not sure what the
                                  > next step would be, so if anyone can offer guidance it would be
                                  > appreciated.

                                  The answer to your problem is in your first post:

                                  > We had some initial problems with some private blacklists and the new IP but those were resolved. However, I had a curious problem sending mail to icloud.com addresses...

                                  The problem is exclusive, as far as we know, to this Akamai hosted MX
                                  farm. Wietse is obviously correct. Your telnet sessions work because
                                  they are a single connection. When you allow Postfix to deliver, it is
                                  making parallel connections to the farm because sufficient mail is
                                  queued for domains at that MX farm. You have two options to resolve this:

                                  1. Create relay transports for the problem domains and limit
                                  concurrency to those domains, until your sender reputation with Akamai
                                  has increased to the point they allow parallel deliveries.

                                  2. Contact the Akamai hostmaster and inquire as to what that threshold
                                  is, and when you may expect to surpass it.

                                  This problem is not new. The list archives are littered with threads
                                  dealing with ISPs who limit concurrency or delivery rate of "fresh" IP
                                  addresses. Those threads also contain instructions on how to do what I
                                  describe above to limit Postfix concurrency.


                                  Cheers,

                                  Stan
                                • Stan Hoeppner
                                  On 5/4/2014 3:02 AM, Stan Hoeppner wrote: ... ... I forgot the simplest solution: Give the new server the IP address and forward/reverse DNS name of the old
                                  Message 16 of 21 , May 4, 2014
                                    On 5/4/2014 3:02 AM, Stan Hoeppner wrote:
                                    ...
                                    > 1. Create relay transports for the problem domains and limit
                                    > concurrency to those domains, until your sender reputation with Akamai
                                    > has increased to the point they allow parallel deliveries.
                                    >
                                    > 2. Contact the Akamai hostmaster and inquire as to what that threshold
                                    > is, and when you may expect to surpass it.
                                    ...

                                    I forgot the simplest solution:

                                    Give the new server the IP address and forward/reverse DNS name of the
                                    old Postfix server, same HELO hostname, etc. That should fix this
                                    instantly, assuming this problem did not exist before. Your use of the
                                    term "old" implies you decommissioned the old box, which makes this the
                                    optimal solution.

                                    Cheers,

                                    Stan
                                  • Stefan Foerster
                                    ... [...] ... Wound you mind trying to remove tcp_windowsize = 1400 from you configuration (do not forget to issue a postfix reload afterwards!)? Stefan
                                    Message 17 of 21 , May 4, 2014
                                      > nk11p00mm-mx006.me.com.smtp: Flags [S], seq 3314275386, win 1400,
                                      > options [mss 1460,nop,wscale 6,sackOK,TS val 170874802 ecr 0],
                                      > length 0
                                      > E..<.e@.@..........r.d.....:.......x...............

                                      [...]

                                      > I then did a capture of a telnet session to the same server on port 25:
                                      >
                                      > reading from file telnet.cap, link-type EN10MB (Ethernet)
                                      > 2014-05-03 22:35:14.821306 IP smtp.bestwny.com.58803 >
                                      > nk11p00-smtp-mx003.mac.com.smtp: Flags [S], seq 3396279601, win
                                      > 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 171198862 ecr
                                      > 0], length 0
                                      > E..<t.@.@.C........2.....o.1.......................

                                      Wound you mind trying to remove "tcp_windowsize = 1400" from you
                                      configuration (do not forget to issue a "postfix reload" afterwards!)?


                                      Stefan
                                    • Wietse Venema
                                      ... We see SYN, SYN|ACK, ACK, and a bunch of retransmissions. SYN: Initial client window 1400 (scale 6), options [mss 1460,nop,wscale 6,sackOK,TS] SYN|ACK:
                                      Message 18 of 21 , May 4, 2014
                                        postfix@...:
                                        > There were several attempts from postfix to connect to 6 different mx
                                        > servers to deliver one email. They all have the same result so I'm only
                                        > including the dump of the first here:

                                        We see SYN, SYN|ACK, ACK, and a bunch of retransmissions.

                                        SYN: Initial client window 1400 (scale 6), options [mss 1460,nop,wscale
                                        6,sackOK,TS]

                                        SYN|ACK: Initial server window 33304 (scale 1), options [nop,nop,TS,mss
                                        1460,nop,wscale 1,nop,nop,sackOK].

                                        Then we see SYN|ACK retransmitted, ACK retransmitted, etc., until
                                        the server sends a RESET. The TCP handshake never completes. And
                                        someone may already have posted the solution.

                                        For the telnet connection we have a successful handhake.

                                        SYN: Initial client window 65535 (scale 6), same TCP options as

                                        SMTP client. SYN|ACK: Same initial server window and TCP options
                                        as STMP server.

                                        The only difference I see is the initial 1400 client TCP window
                                        size.

                                        As someone already suggested in one of the first follow-ups:

                                        "Would you mind trying to remove "tcp_windowsize = 1400" from
                                        you configuration (do not forget to issue a "postfix reload"
                                        afterwards!)?"

                                        Wietse
                                      • postfix@...
                                        ... Stefan, Thank you! Of course that worked!
                                        Message 19 of 21 , May 4, 2014
                                          On , Stefan Foerster wrote:
                                          >> nk11p00mm-mx006.me.com.smtp: Flags [S], seq 3314275386, win 1400,
                                          >> options [mss 1460,nop,wscale 6,sackOK,TS val 170874802 ecr 0],
                                          >> length 0
                                          >> E..<.e@.@..........r.d.....:.......x...............
                                          >
                                          > [...]
                                          >
                                          >> I then did a capture of a telnet session to the same server on port
                                          >> 25:
                                          >>
                                          >> reading from file telnet.cap, link-type EN10MB (Ethernet)
                                          >> 2014-05-03 22:35:14.821306 IP smtp.bestwny.com.58803 >
                                          >> nk11p00-smtp-mx003.mac.com.smtp: Flags [S], seq 3396279601, win
                                          >> 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 171198862 ecr
                                          >> 0], length 0
                                          >> E..<t.@.@.C........2.....o.1.......................
                                          >
                                          > Wound you mind trying to remove "tcp_windowsize = 1400" from you
                                          > configuration (do not forget to issue a "postfix reload" afterwards!)?
                                          >
                                          >
                                          > Stefan

                                          Stefan,

                                          Thank you! Of course that worked!
                                        • postfix@...
                                          ... Wietse, Thank you for your patience with me. I tried way too long trying to resolve this on my own. I totally forgot that was in main.cf (from months ago
                                          Message 20 of 21 , May 4, 2014
                                            On , wietse@... wrote:
                                            > postfix@...:
                                            >> There were several attempts from postfix to connect to 6 different mx
                                            >> servers to deliver one email. They all have the same result so I'm
                                            >> only
                                            >> including the dump of the first here:
                                            >
                                            > We see SYN, SYN|ACK, ACK, and a bunch of retransmissions.
                                            >
                                            > SYN: Initial client window 1400 (scale 6), options [mss
                                            > 1460,nop,wscale
                                            > 6,sackOK,TS]
                                            >
                                            > SYN|ACK: Initial server window 33304 (scale 1), options
                                            > [nop,nop,TS,mss
                                            > 1460,nop,wscale 1,nop,nop,sackOK].
                                            >
                                            > Then we see SYN|ACK retransmitted, ACK retransmitted, etc., until
                                            > the server sends a RESET. The TCP handshake never completes. And
                                            > someone may already have posted the solution.
                                            >
                                            > For the telnet connection we have a successful handhake.
                                            >
                                            > SYN: Initial client window 65535 (scale 6), same TCP options as
                                            >
                                            > SMTP client. SYN|ACK: Same initial server window and TCP options
                                            > as STMP server.
                                            >
                                            > The only difference I see is the initial 1400 client TCP window
                                            > size.
                                            >
                                            > As someone already suggested in one of the first follow-ups:
                                            >
                                            > "Would you mind trying to remove "tcp_windowsize = 1400" from
                                            > you configuration (do not forget to issue a "postfix reload"
                                            > afterwards!)?"
                                            >
                                            > Wietse

                                            Wietse,

                                            Thank you for your patience with me. I tried way too long trying to
                                            resolve this on my own.

                                            I totally forgot that was in main.cf (from months ago trying to resolve
                                            a separate issue and missed it in postconf -n output. (the issue in
                                            question is a networking problem at the provider and the main reason for
                                            the move).

                                            The funny thing is that directive is on the old server as well, which
                                            had no problems connecting to akamai,

                                            At any rate, removing the directive and a reload, postqueue -f resolved
                                            the issue completely.

                                            Again, my thanks.
                                          • Stan Hoeppner
                                            Scratch my previous suggestion as it was obviously not the correct solution. Read on. ... Are both the old and new server in the new provider s network at
                                            Message 21 of 21 , May 4, 2014
                                              Scratch my previous suggestion as it was obviously not the correct
                                              solution. Read on.

                                              On 5/4/2014 9:01 AM, postfix@... wrote:
                                              > On , wietse@... wrote:
                                              >> postfix@...:
                                              >>> There were several attempts from postfix to connect to 6 different mx
                                              >>> servers to deliver one email. They all have the same result so I'm only
                                              >>> including the dump of the first here:
                                              >>
                                              >> We see SYN, SYN|ACK, ACK, and a bunch of retransmissions.
                                              >>
                                              >> SYN: Initial client window 1400 (scale 6), options [mss
                                              >> 1460,nop,wscale
                                              >> 6,sackOK,TS]
                                              >>
                                              >> SYN|ACK: Initial server window 33304 (scale 1), options
                                              >> [nop,nop,TS,mss
                                              >> 1460,nop,wscale 1,nop,nop,sackOK].
                                              >>
                                              >> Then we see SYN|ACK retransmitted, ACK retransmitted, etc., until
                                              >> the server sends a RESET. The TCP handshake never completes. And
                                              >> someone may already have posted the solution.
                                              >>
                                              >> For the telnet connection we have a successful handhake.
                                              >>
                                              >> SYN: Initial client window 65535 (scale 6), same TCP options as
                                              >>
                                              >> SMTP client. SYN|ACK: Same initial server window and TCP options
                                              >> as STMP server.
                                              >>
                                              >> The only difference I see is the initial 1400 client TCP window
                                              >> size.
                                              >>
                                              >> As someone already suggested in one of the first follow-ups:
                                              >>
                                              >> "Would you mind trying to remove "tcp_windowsize = 1400" from
                                              >> you configuration (do not forget to issue a "postfix reload"
                                              >> afterwards!)?"
                                              >>
                                              >> Wietse
                                              >
                                              > Wietse,
                                              >
                                              > Thank you for your patience with me. I tried way too long trying to
                                              > resolve this on my own.
                                              >
                                              > I totally forgot that was in main.cf (from months ago trying to resolve
                                              > a separate issue and missed it in postconf -n output. (the issue in
                                              > question is a networking problem at the provider and the main reason for
                                              > the move).
                                              >
                                              > The funny thing is that directive is on the old server as well, which
                                              > had no problems connecting to akamai,

                                              Are both the old and new server in the new provider's network at this
                                              point. It would be informative to compare SMTP session capture of both
                                              systems when "tcp_windowsize = 1400" is configured. I.e. test the old
                                              system and compare to the capture you already have for the new system.

                                              At this point you know what Postfix setting caused the problem on the
                                              new server, but you don't know why it caused a problem, you don't know
                                              the root cause. Knowing that root cause may be very useful in the future.

                                              > At any rate, removing the directive and a reload, postqueue -f resolved
                                              > the issue completely.


                                              Cheers,

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