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

Problems receiving mail from outlook.com

Expand Messages
  • Alan Munday
    I found a problem in my logs with respect to receiving email from outlook.com. When I looked into it I thought it was due to the TLS certs having expired. I ve
    Message 1 of 16 , Feb 5, 2014
      I found a problem in my logs with respect to receiving email from
      outlook.com. When I looked into it I thought it was due to the TLS certs
      having expired. I've created new certificates (self-signed) but the
      problem is continuing.

      I'm seeing trusted/untrusted/anonymous connections established with
      other relays and mail via these connections is processed OK.

      On mx1 with inbound connections from outlook.com I'm seeing anonymous
      TLS connections established but always followed by "lost connection
      after EHLO".

      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: connect from
      mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: setting up TLS connection from
      mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]:
      mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]: TLS
      cipher list "ALL:+RC4:@STRENGTH"
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:before/accept
      initialization
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 read client
      hello A
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 write server
      hello A
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 write
      certificate A
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 write server
      done A
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 flush data
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 read client
      key exchange A
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 read finished A
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 write change
      cipher spec A
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 write finished A
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 flush data
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]:
      mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]: save
      session
      951C66833DABEBA07BCBFA9F5DAD5E6281408A0C0596DA29A852F370D81191B7&s=smtpd&l=268435459
      to smtpd cache
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: Anonymous TLS connection
      established from
      mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]: TLSv1
      with cipher AES128-SHA (128/128 bits)
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: lost connection after EHLO
      from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
      Feb 5 16:01:21 mx1 postfix/smtpd[22789]: disconnect from
      mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]


      While on mx3 I'm always seeing SSL_accept error. (master.cf and main.cf
      are the same on both mx's.)

      Feb 5 16:00:58 mx3 postfix/smtpd[14898]: connect from
      mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
      Feb 5 16:00:58 mx3 postfix/smtpd[14898]: setting up TLS connection from
      mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
      Feb 5 16:00:58 mx3 postfix/smtpd[14898]:
      mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]: TLS
      cipher list "ALL:+RC4:@STRENGTH"
      Feb 5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:before/accept
      initialization
      Feb 5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:SSLv3 read client
      hello A
      Feb 5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:SSLv3 write server
      hello A
      Feb 5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:SSLv3 write
      certificate A
      Feb 5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:SSLv3 write server
      done A
      Feb 5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:SSLv3 flush data
      Feb 5 16:05:58 mx3 postfix/smtpd[14898]: SSL_accept error from
      mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]:
      Connection timed out
      Feb 5 16:05:58 mx3 postfix/smtpd[14898]: lost connection after STARTTLS
      from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
      Feb 5 16:05:58 mx3 postfix/smtpd[14898]: disconnect from
      mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]


      I've searched the archives and not yet found anything to point me
      towards what's going on or if the problem is my end.


      I thought I'd start by asking if anyone else is seeing/has seen problems
      like this?


      Thanks


      Alan
    • Viktor Dukhovni
      ... Your certificate chain on mx1 is somewhat unusual, the issuer CA certificate has CA:FALSE in basic constraints: Certificate: Data: Version: 3 (0x2)
      Message 2 of 16 , Feb 5, 2014
        On Wed, Feb 05, 2014 at 05:07:27PM +0000, Alan Munday wrote:

        > Feb 5 16:01:21 mx1 postfix/smtpd[22789]:
        > Anonymous TLS connection established
        > from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]:
        > TLSv1 with cipher AES128-SHA (128/128 bits)
        > Feb 5 16:01:21 mx1 postfix/smtpd[22789]:
        > lost connection after EHLO
        > from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]

        Your certificate chain on mx1 is somewhat unusual, the issuer CA
        certificate has "CA:FALSE" in basic constraints:

        Certificate:
        Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=GB, ST=Suffolk, O=Brighthead Technology Limited, OU=Mailserver, CN=mx1.brightheadtechnology.com/emailAddress=postmaster@...
        Validity
        Not Before: Feb 5 12:43:48 2014 GMT
        Not After : Feb 4 12:43:48 2017 GMT
        Subject: C=GB, ST=Suffolk, O=Brighthead Technology Limited, OU=Mailserver, CN=mx1.brightheadtechnology.com/emailAddress=postmaster@...
        Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
        Public-Key: (2048 bit)
        Modulus:
        ...
        Exponent: 65537 (0x10001)
        X509v3 extensions:
        X509v3 Basic Constraints:
        CA:FALSE
        Netscape Comment:
        OpenSSL Generated Certificate
        X509v3 Subject Key Identifier:
        AE:5D:0D:B0:6C:97:D5:A7:BE:D8:D3:AC:33:81:10:2D:65:55:CB:E5
        X509v3 Authority Key Identifier:
        keyid:AE:5D:0D:B0:6C:97:D5:A7:BE:D8:D3:AC:33:81:10:2D:65:55:CB:E5
        ...
        -----BEGIN CERTIFICATE-----
        MIIEZjCCA06gAwIBAgIBADANBgkqhkiG9w0BAQUFADCBtzELMAkGA1UEBhMCR0Ix
        EDAOBgNVBAgMB1N1ZmZvbGsxJjAkBgNVBAoMHUJyaWdodGhlYWQgVGVjaG5vbG9n
        eSBMaW1pdGVkMRMwEQYDVQQLDApNYWlsc2VydmVyMSUwIwYDVQQDDBxteDEuYnJp
        Z2h0aGVhZHRlY2hub2xvZ3kuY29tMTIwMAYJKoZIhvcNAQkBFiNwb3N0bWFzdGVy
        QGJyaWdodGhlYWR0ZWNobm9sb2d5LmNvbTAeFw0xNDAyMDUxMjQzNDhaFw0xNzAy
        MDQxMjQzNDhaMIG3MQswCQYDVQQGEwJHQjEQMA4GA1UECAwHU3VmZm9sazEmMCQG
        A1UECgwdQnJpZ2h0aGVhZCBUZWNobm9sb2d5IExpbWl0ZWQxEzARBgNVBAsMCk1h
        aWxzZXJ2ZXIxJTAjBgNVBAMMHG14MS5icmlnaHRoZWFkdGVjaG5vbG9neS5jb20x
        MjAwBgkqhkiG9w0BCQEWI3Bvc3RtYXN0ZXJAYnJpZ2h0aGVhZHRlY2hub2xvZ3ku
        Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2lsVr97XvgCinkTF
        MBdHiBPZa1tVo2TEnTCJ1aEOGPNwQjrbFtHDtzFxTG3UuOBrG/4Z0hb2Q3pvVF1d
        jh5xj+YJp+lBFpXaTb/xiLLRr063BNIXzLVded8Y8xo/8+9dxAX7BGa+0lm4wSuE
        m/eG252Ejr+/5GOCz6CbX0gJbYiw7kIbA69Z4EW7VWrHXfyxzL8cHWox1WlaLUxH
        lqU4UY559Ntp+4BCTqgJzej+w+WFPLO6I9nlgQ/c8UqkH97LSd41poK7ZuDbx7TH
        5nHVAXIjGVqohxwo5P4xQtrq7KoUIZMNwhEQvM88qki8ErhfZrYSWOC1D/oWYb63
        4tESdQIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NM
        IEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUrl0NsGyX1ae+2NOsM4EQ
        LWVVy+UwHwYDVR0jBBgwFoAUrl0NsGyX1ae+2NOsM4EQLWVVy+UwDQYJKoZIhvcN
        AQEFBQADggEBAEmJtvasouV0I6mXW0RReAg1OrKt/uxBm8W+ll92iTao6oci37/+
        gfXe2xs2IG4BL8Rndg4Z6R0rM9hLCohleGLjEMU086OYB9UPsaSZUv0NAWPnNk9k
        HjpW6UH/RNmnXD+6EE4io28MpCGtLEa2BHXWJcmqZlmBj/yDu8bIglNwemAm3IgH
        sNA8FT2GibMw7UyG0rZdftZHydnmO2HcrxLoZ1oe2Q4EpG+2//ZzWGDcfHAQ9/zC
        ZltUslDBXIeevDYJvmVwYYV4cPVv+KhrI/wVFlVLf4AKnw+vkSHR441/wMSEsGKF
        Fr6/qIeVkfSWxsA0yZ8k0t34nl1DGosnCSA=
        -----END CERTIFICATE-----

        which may trigger fatal errors in Microsoft's TLS validation stack.
        It is a shame that they abort connections with a malformed chain
        even though otherwise self-signed or unverifiable chains are fine.

        For the record the corresponding leaf certificate is:

        Certificate:
        Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=GB, ST=Suffolk, O=Brighthead Technology Limited, OU=Mailserver, CN=mx1.brightheadtechnology.com/emailAddress=postmaster@...
        Validity
        Not Before: Feb 5 12:44:04 2014 GMT
        Not After : Feb 5 12:44:04 2015 GMT
        Subject: C=GB, ST=Suffolk, L=IPSWICH, O=Brighthead Technology Limited, OU=Mailserver, CN=mx1.brightheadtechnology.com/emailAddress=postmaster@...
        Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
        Public-Key: (2048 bit)
        Modulus:
        ...
        Exponent: 65537 (0x10001)
        X509v3 extensions:
        X509v3 Basic Constraints:
        CA:FALSE
        Netscape Comment:
        OpenSSL Generated Certificate
        X509v3 Subject Key Identifier:
        83:FD:9E:9E:0C:8C:35:16:9C:32:74:D8:1B:94:2F:97:80:72:8F:79
        X509v3 Authority Key Identifier:
        keyid:AE:5D:0D:B0:6C:97:D5:A7:BE:D8:D3:AC:33:81:10:2D:65:55:CB:E5
        ...
        -----BEGIN CERTIFICATE-----
        MIIEeDCCA2CgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBtzELMAkGA1UEBhMCR0Ix
        EDAOBgNVBAgMB1N1ZmZvbGsxJjAkBgNVBAoMHUJyaWdodGhlYWQgVGVjaG5vbG9n
        eSBMaW1pdGVkMRMwEQYDVQQLDApNYWlsc2VydmVyMSUwIwYDVQQDDBxteDEuYnJp
        Z2h0aGVhZHRlY2hub2xvZ3kuY29tMTIwMAYJKoZIhvcNAQkBFiNwb3N0bWFzdGVy
        QGJyaWdodGhlYWR0ZWNobm9sb2d5LmNvbTAeFw0xNDAyMDUxMjQ0MDRaFw0xNTAy
        MDUxMjQ0MDRaMIHJMQswCQYDVQQGEwJHQjEQMA4GA1UECAwHU3VmZm9sazEQMA4G
        A1UEBwwHSVBTV0lDSDEmMCQGA1UECgwdQnJpZ2h0aGVhZCBUZWNobm9sb2d5IExp
        bWl0ZWQxEzARBgNVBAsMCk1haWxzZXJ2ZXIxJTAjBgNVBAMMHG14MS5icmlnaHRo
        ZWFkdGVjaG5vbG9neS5jb20xMjAwBgkqhkiG9w0BCQEWI3Bvc3RtYXN0ZXJAYnJp
        Z2h0aGVhZHRlY2hub2xvZ3kuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
        CgKCAQEAp/XQmaZzh1fw/JJRrJDWSbNFrT4/Ucz86edeT22xr3UnYrgegHOti40e
        uOpYvolbRhQh4/8HC7jv4U4HP30AYDQbNnOBfdcqr+4tp/g36Hf6UvpBdS+JjlJf
        JRcvhNB/j48arVYMy3xr4OcUcoaXwhyqygftHZ8fHTAvq7YDnaMb3ggZPJ+tQxDq
        lq+eoXTMTxvqBdCODFKWTQuYVhteXl8jUwRaAHXiHGHt7dCCSus+ua8DnQgqIz+u
        fAFSxarfsI5TEdEaxlfj9UYDjTFoj8CfZPNaKSD2LVU54ygD5qXUvUr8aiZNlb43
        5/YSaQytNJ6pr2TIkRQoYnxoAk2F8QIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCG
        SAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4E
        FgQUg/2engyMNRacMnTYG5Qvl4Byj3kwHwYDVR0jBBgwFoAUrl0NsGyX1ae+2NOs
        M4EQLWVVy+UwDQYJKoZIhvcNAQEFBQADggEBAJVBa8TXfmbtgwnK7V9owKPMfRYJ
        rVk/H3ayyNqb2I1yho6z860rQmHDQ8yTGaJXGt1sBLKJ1sX3VtX68ud/ZYD91aPW
        0y58m2FHni6Q8VuZEeJEhZf1Hw5cpilWHcq5wvtvPcmGqRqFDiOqyJ7cz8mhIsN6
        cbHvq4hQYFWQ3KQhb9YALkW6lNBGvvKu7TPdlRw8RZdCPrSdnMlGyPEncjXTa6Bw
        f4ccOr3f5fdmqySpzdn7SJrpnqS0Z7LIhPJyFDDqUyRhkeKu1UPmUC4MLIrKrvs0
        Fus/9PC/SAkwAkesjZIWuKqOLKEqxMibHD2sT2MKMNhfbznpWnjMIG/2M0o=
        -----END CERTIFICATE-----

        > While on mx3 I'm always seeing SSL_accept error. (master.cf and
        > main.cf are the same on both mx's.)

        When I try to complete a TLS handshake with mx3 from my machine,
        it also fails (hangs after the client SSL HELLO).

        $ posttls-finger -Ldebug -C "[mx3.brightheadtechnology.com]"
        posttls-finger: initializing the client-side TLS engine
        posttls-finger: Connected to mx3.brightheadtechnology.com[88.97.147.157]:25
        posttls-finger: < 220 mx3.brightheadtechnology.com SMTP
        posttls-finger: > EHLO mournblade.imrryr.org
        posttls-finger: < 250-mx3.brightheadtechnology.com
        posttls-finger: < 250-STARTTLS
        posttls-finger: < 250 8BITMIME
        posttls-finger: > STARTTLS
        posttls-finger: < 220 2.0.0 Ready to start TLS
        posttls-finger: setting up TLS connection to mx3.brightheadtechnology.com[88.97.147.157]:25
        posttls-finger: mx3.brightheadtechnology.com[88.97.147.157]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"
        posttls-finger: SSL_connect:before/connect initialization
        posttls-finger: SSL_connect:SSLv2/v3 write client hello A
        ... <long delay> ...
        posttls-finger: SSL_connect error to mx3.brightheadtechnology.com[88.97.147.157]:25: Connection timed out

        That problem is not outlook.com specific.

        > Feb 5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:SSLv3 write
        > server done A
        > Feb 5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:SSLv3 flush data
        > Feb 5 16:05:58 mx3 postfix/smtpd[14898]: SSL_accept error from
        > mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]:
        > Connection timed out
        > Feb 5 16:05:58 mx3 postfix/smtpd[14898]: lost connection after
        > STARTTLS from

        Some sort of network layer problem, any firewalls/load-balancers
        that mishandle TLS? Or path MTU problems? Perhaps you're filtering
        ICMP too aggressively. Have you tried disabling TCP window scaling?

        > I've searched the archives and not yet found anything to point me
        > towards what's going on or if the problem is my end.
        >
        >
        > I thought I'd start by asking if anyone else is seeing/has seen
        > problems like this?

        No problem with inbound TLS from outlook.com reported here IIRC.

        --
        Viktor.
      • Alan Munday
        ... Viktor Thank you. I ll work through the points you ve highlighted. Alan
        Message 3 of 16 , Feb 5, 2014
          Viktor Dukhovni wrote the following on 05/02/14 18:45:
          > On Wed, Feb 05, 2014 at 05:07:27PM +0000, Alan Munday wrote:
          >


          Viktor

          Thank you. I'll work through the points you've highlighted.


          Alan
        • Alan Munday
          ... And re-creating the certificates with CA:TRUE in the [ usr_cert ] section of openssl.cnf appears to resolve the problem. Thanks again. Alan
          Message 4 of 16 , Feb 5, 2014
            Viktor Dukhovni wrote the following on 05/02/14 18:45:
            > On Wed, Feb 05, 2014 at 05:07:27PM +0000, Alan Munday wrote:
            >
            >> Feb 5 16:01:21 mx1 postfix/smtpd[22789]:
            >> Anonymous TLS connection established
            >> from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]:
            >> TLSv1 with cipher AES128-SHA (128/128 bits)
            >> Feb 5 16:01:21 mx1 postfix/smtpd[22789]:
            >> lost connection after EHLO
            >> from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
            >
            > Your certificate chain on mx1 is somewhat unusual, the issuer CA
            > certificate has "CA:FALSE" in basic constraints:

            And re-creating the certificates with CA:TRUE in the [ usr_cert ]
            section of openssl.cnf appears to resolve the problem.

            Thanks again.

            Alan
          • Viktor Dukhovni
            ... Now for the record your leaf certificate is also a CA, which is harmless I imagine, but keep that in mind if you run into problems with some other nitpicky
            Message 5 of 16 , Feb 5, 2014
              On Wed, Feb 05, 2014 at 08:28:51PM +0000, Alan Munday wrote:

              > Viktor Dukhovni wrote the following on 05/02/14 18:45:
              > >On Wed, Feb 05, 2014 at 05:07:27PM +0000, Alan Munday wrote:
              > >
              > >>Feb 5 16:01:21 mx1 postfix/smtpd[22789]:
              > >> Anonymous TLS connection established
              > >> from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]:
              > >> TLSv1 with cipher AES128-SHA (128/128 bits)
              > >>Feb 5 16:01:21 mx1 postfix/smtpd[22789]:
              > >> lost connection after EHLO
              > >> from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
              > >
              > >Your certificate chain on mx1 is somewhat unusual, the issuer CA
              > >certificate has "CA:FALSE" in basic constraints:
              >
              > And re-creating the certificates with CA:TRUE in the [ usr_cert ]
              > section of openssl.cnf appears to resolve the problem.

              Now for the record your leaf certificate is also a CA, which is
              harmless I imagine, but keep that in mind if you run into problems
              with some other nitpicky implementation.

              You're probably better off with just a self-signed cert with CA:FALSE
              and no issuer CA. (Basically your original issuer CA was a perfectly
              good leaf server certificate).

              And of course mx3 is still broken, STARTTLS hangs, because it is
              unable to transmit the server SSL HELLO + certificate, likely due
              to path MTU or other network layer issues.

              --
              Viktor.
            • Alan Munday
              ... I m looking at this now... and this is just my ignorance with TLS and having done the original configuration many years ago. In main.cf I have:
              Message 6 of 16 , Feb 5, 2014
                Viktor Dukhovni wrote the following on 05/02/14 20:44:
                > On Wed, Feb 05, 2014 at 08:28:51PM +0000, Alan Munday wrote:
                >
                >> Viktor Dukhovni wrote the following on 05/02/14 18:45:
                >>> On Wed, Feb 05, 2014 at 05:07:27PM +0000, Alan Munday wrote:
                >>>
                >>>> Feb 5 16:01:21 mx1 postfix/smtpd[22789]:
                >>>> Anonymous TLS connection established
                >>>> from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]:
                >>>> TLSv1 with cipher AES128-SHA (128/128 bits)
                >>>> Feb 5 16:01:21 mx1 postfix/smtpd[22789]:
                >>>> lost connection after EHLO
                >>>> from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
                >>>
                >>> Your certificate chain on mx1 is somewhat unusual, the issuer CA
                >>> certificate has "CA:FALSE" in basic constraints:
                >>
                >> And re-creating the certificates with CA:TRUE in the [ usr_cert ]
                >> section of openssl.cnf appears to resolve the problem.
                >
                > Now for the record your leaf certificate is also a CA, which is
                > harmless I imagine, but keep that in mind if you run into problems
                > with some other nitpicky implementation.
                >
                > You're probably better off with just a self-signed cert with CA:FALSE
                > and no issuer CA. (Basically your original issuer CA was a perfectly
                > good leaf server certificate).

                I'm looking at this now... and this is just my ignorance with TLS and
                having done the original configuration many years ago.

                In main.cf I have:

                smtpd_tls_key_file = /etc/postfix/server.key.pem
                smtpd_tls_cert_file = /etc/postfix/server.cert.pem
                smtpd_tls_CAfile = /etc/postfix/CAcert.pem

                And when I verify with openssl reports OK.

                [root@mx1 postfix]# openssl verify -CAfile /etc/postfix/CAcert.pem
                /etc/postfix/server.cert.pem
                /etc/postfix/server.cert.pem: OK

                server.cert.pem is actually a link to /etc/postfix/mx1 but that also
                verifies OK.

                [root@mx1 postfix]# openssl verify -CAfile /etc/postfix/CAcert.pem
                /etc/postfix/mx1.cert.pem
                /etc/postfix/mx1.cert.pem: OK


                Rather than tie up peoples time is there a reference I can go to and
                I'll work through things from scratch.

                Thanks

                Alan
              • Alan Munday
                ... And replying to my own question, I ve found the TLS-README...
                Message 7 of 16 , Feb 5, 2014
                  Alan Munday wrote the following on 05/02/14 21:29:

                  >
                  > Rather than tie up peoples time is there a reference I can go to and
                  > I'll work through things from scratch.

                  And replying to my own question, I've found the TLS-README...
                • Alan Munday
                  ... As per my last post, I went back to the Postfix TLS docs and started again. First point was that my TLS configuration was all based on the Lutz JΣnicke
                  Message 8 of 16 , Feb 6, 2014
                    Viktor Dukhovni wrote the following on 05/02/14 20:44:
                    > On Wed, Feb 05, 2014 at 08:28:51PM +0000, Alan Munday wrote:
                    >
                    >> Viktor Dukhovni wrote the following on 05/02/14 18:45:
                    >
                    > Now for the record your leaf certificate is also a CA, which is
                    > harmless I imagine, but keep that in mind if you run into problems
                    > with some other nitpicky implementation.

                    > You're probably better off with just a self-signed cert with CA:FALSE
                    > and no issuer CA. (Basically your original issuer CA was a perfectly
                    > good leaf server certificate).

                    As per my last post, I went back to the Postfix TLS docs and started
                    again. First point was that my TLS configuration was all based on the
                    Lutz Jänicke TLS patch so I removed all configuration relating to this
                    and replaced it with only the directives listed in the TLS HowTo.

                    My certificate creation process also followed the old way of doing
                    things. I've updated this to also follow the HowTo. In doing so I needed
                    to edit two values in the openssl.cnf namely:

                    [ CA_default ]
                    unique_subject = no

                    [ usr_cert ]
                    basicConstraints=CA:TRUE

                    I did try CA:FALSE but this was causing outlook.com mail to fail (and,
                    as Viktor stated, mail from other domains as well).

                    In doing this clean-up I also found that the openssl.cnf config files
                    were different between mx1 and mx3. mx1 was the newer (the most recently
                    rebuilt machine) and that some of the defaults had changed. I think this
                    explains some of the differences in behaviour between the machines.
                    Though it takes a while to diagnose things because my mail volumes are low.

                    I'm seeing a variation in behaviour for those connection that fail to
                    establish a TLS connection. Most keep retrying, a few fall-back and
                    connect without TLS. I've not seen any fall-back and try the secondary
                    (which is mx1 in this case).


                    > And of course mx3 is still broken, STARTTLS hangs, because it is
                    > unable to transmit the server SSL HELLO + certificate, likely due
                    > to path MTU or other network layer issues.

                    I am still seeing mx1 establish 100% of TLS connections and mx3 50%
                    (with a significant number of those being retries) so I have looked at
                    the comms. Both boxes are behind firewalls (same make, different models,
                    older OS on the mx3 firewall). They both only allow TCP/25 in, and mx3
                    has no restrictions on outbound traffic (mx1 is restricted to key
                    services). MTU on the firewall interfaces are all set to the same value
                    (1500) and the comms (DSL based) both go to the same ISP. So I could do
                    with some pointers of where to go next with this.

                    Just from a technical perspective I'd to understand and resolve what’s
                    going on. Though I can see it might just be easier to turn TLS off.


                    Alan
                  • Alan Munday
                    ... In the quite of the night I ve been able to take some tcpdump s ... The fragmentation as Viktor predicted. Checking out the MTU on the router and the ISP s
                    Message 9 of 16 , Feb 6, 2014
                      Alan Munday wrote the following on 06/02/14 17:37:
                      > Viktor Dukhovni wrote the following on 05/02/14 20:44:
                      >> On Wed, Feb 05, 2014 at 08:28:51PM +0000, Alan Munday wrote:
                      >>
                      >>> Viktor Dukhovni wrote the following on 05/02/14 18:45:
                      >>

                      >> And of course mx3 is still broken, STARTTLS hangs, because it is
                      >> unable to transmit the server SSL HELLO + certificate, likely due
                      >> to path MTU or other network layer issues.
                      >
                      > I am still seeing mx1 establish 100% of TLS connections and mx3 50%
                      > (with a significant number of those being retries) so I have looked at
                      > the comms. Both boxes are behind firewalls (same make, different models,
                      > older OS on the mx3 firewall). They both only allow TCP/25 in, and mx3
                      > has no restrictions on outbound traffic (mx1 is restricted to key
                      > services). MTU on the firewall interfaces are all set to the same value
                      > (1500) and the comms (DSL based) both go to the same ISP. So I could do
                      > with some pointers of where to go next with this.

                      In the quite of the night I've been able to take some tcpdump's

                      On mx1 I see:

                      > Client Hello
                      > Server Hello, Certificate, Server Hello Done

                      and on mx3:

                      > Client Hello
                      > Server Hello
                      > [TCP segment of a reassembled PDU]
                      > Certificate

                      The fragmentation as Viktor predicted.

                      Checking out the MTU on the router and the ISP's support pages there
                      were two other MTU values to try, neither have resolved the issue so
                      I'll contact the ISP in the morning.

                      Thanks again.

                      Alan
                    • Viktor Dukhovni
                      ... Usually, the CA certificate is created using a different extension section (not usr_cert ). You then have CA:FALSE in usr_cert , and CA:TRUE in the
                      Message 10 of 16 , Feb 7, 2014
                        On Thu, Feb 06, 2014 at 05:37:16PM +0000, Alan Munday wrote:

                        > My certificate creation process also followed the old way of doing
                        > things. I've updated this to also follow the HowTo. In doing so I
                        > needed to edit two values in the openssl.cnf namely:
                        >
                        > [ CA_default ]
                        > unique_subject = no
                        >
                        > [ usr_cert ]
                        > basicConstraints=CA:TRUE
                        >
                        > I did try CA:FALSE but this was causing outlook.com mail to fail
                        > (and, as Viktor stated, mail from other domains as well).

                        Usually, the CA certificate is created using a different extension
                        section (not "usr_cert"). You then have "CA:FALSE" in "usr_cert",
                        and "CA:TRUE" in the CA extension section.

                        > Just from a technical perspective I'd to understand and resolve
                        > what?s going on. Though I can see it might just be easier to turn
                        > TLS off.

                        You now have working TLS on mx1, so that's fine. As for mx3 its
                        problem is not TLS. Almost certainly any large packets sent by
                        mx3 will run into the same MTU issue. For example, it likely can't
                        send bounces... Try to send a large message from mx3 to the outside
                        world. If that works, but sending a TLS certificate to the client
                        does not, I'll be surprised (a less obvious explanation will be
                        required for the reported symptoms, perhaps hardware problems with
                        the NIC that corrupt some data and not other data, ...).

                        --
                        Viktor.
                      • Alan Munday
                        ... I ll try this. ... I did follow-up with the results of some tcpdumps which showed where the problem was. The ISP suggested taking the MTU down to 1400 and
                        Message 11 of 16 , Feb 7, 2014
                          Viktor Dukhovni wrote the following on 07/02/14 19:07:
                          > On Thu, Feb 06, 2014 at 05:37:16PM +0000, Alan Munday wrote:

                          >> I did try CA:FALSE but this was causing outlook.com mail to fail
                          >> (and, as Viktor stated, mail from other domains as well).
                          >
                          > Usually, the CA certificate is created using a different extension
                          > section (not "usr_cert"). You then have "CA:FALSE" in "usr_cert",
                          > and "CA:TRUE" in the CA extension section.

                          I'll try this.

                          > You now have working TLS on mx1, so that's fine. As for mx3 its
                          > problem is not TLS. Almost certainly any large packets sent by
                          > mx3 will run into the same MTU issue. For example, it likely can't
                          > send bounces... Try to send a large message from mx3 to the outside
                          > world. If that works, but sending a TLS certificate to the client
                          > does not, I'll be surprised (a less obvious explanation will be
                          > required for the reported symptoms, perhaps hardware problems with
                          > the NIC that corrupt some data and not other data, ...).
                          >

                          I did follow-up with the results of some tcpdumps which showed where the
                          problem was.

                          The ISP suggested taking the MTU down to 1400 and if that did not work
                          to try changing the encapsulation type from PPPoA to PPPoE. Moving to
                          PPoE was the option that worked.

                          That was at about 17:00 and I've not seen any TLS establishment failures
                          since.

                          Thank you.


                          Alan
                        • Viktor Dukhovni
                          ... Should not be too hard. In your case, as I suggested upstream, a simple self-signed certificate with no issuing CA is quite sufficient: Assuming a
                          Message 12 of 16 , Feb 7, 2014
                            On Fri, Feb 07, 2014 at 10:40:37PM +0000, Alan Munday wrote:

                            > > Usually, the CA certificate is created using a different extension
                            > > section (not "usr_cert"). You then have "CA:FALSE" in "usr_cert",
                            > > and "CA:TRUE" in the CA extension section.
                            >
                            > I'll try this.

                            Should not be too hard. In your case, as I suggested upstream, a
                            simple self-signed certificate with no issuing CA is quite sufficient:

                            Assuming a suitable private key in key.pem, a self-signed cert is just
                            one command:

                            openssl req -x509 -sha1 -new -key key.pem -out newcert.pem \
                            -subj "/CN=$(uname -n)" -days 3650

                            > The ISP suggested taking the MTU down to 1400 and if that did not
                            > work to try changing the encapsulation type from PPPoA to PPPoE.
                            > Moving to PPoE was the option that worked.
                            >
                            > That was at about 17:00 and I've not seen any TLS establishment
                            > failures since.

                            Indeed, looks like you're done. The below is not self-signed, but
                            nobody cares really. No need to post-pend an issuer CA nobody
                            trusts to the chain.

                            $ openssl s_client -showcerts -starttls smtp \
                            -connect "mx3.brightheadtechnology.com:25" 2>/dev/null |
                            openssl crl2pkcs7 -nocrl -certfile /dev/stdin |
                            openssl pkcs7 -print_certs -text
                            Certificate:
                            Data:
                            Version: 3 (0x2)
                            Serial Number:
                            aa:a7:18:c2:d0:a6:8d:40
                            Signature Algorithm: sha1WithRSAEncryption
                            Issuer: C=GB, ST=Suffolk, O=Brighthead Technology Limited, OU=Mailserver, CN=mx3.brightheadtechnology.com/emailAddress=postmaster@...
                            Validity
                            Not Before: Feb 7 22:47:21 2014 GMT
                            Not After : Feb 7 22:47:21 2015 GMT
                            Subject: C=GB, ST=Suffolk, O=Brighthead Technology Limited, OU=Mailserver, CN=mx3.brightheadtechnology.com/emailAddress=postmaster@...
                            Subject Public Key Info:
                            Public Key Algorithm: rsaEncryption
                            Public-Key: (2048 bit)
                            Modulus:
                            00:c0:5c:d0:93:38:64:1c:7a:86:44:df:16:cb:d8:
                            6a:93:ce:3c:f1:6a:7b:f9:a0:d5:52:ea:27:3f:81:
                            83:4f:e1:57:49:f1:c3:96:cd:86:08:60:af:aa:26:
                            58:34:32:91:45:41:b6:b9:09:29:50:17:2c:2b:90:
                            88:8d:c7:a7:8c:30:8b:ed:3e:03:d1:d6:e9:ac:4e:
                            57:d8:56:49:3c:50:c8:c1:10:72:ac:83:3d:08:74:
                            54:2b:69:79:d0:30:73:e4:b7:75:4d:46:6f:d6:09:
                            53:3d:50:aa:ab:c8:43:b9:be:1d:0e:46:70:09:fb:
                            f3:aa:93:64:1e:63:de:4e:75:70:64:72:d7:23:41:
                            3d:db:99:75:38:c5:6a:cd:92:73:8d:57:9b:e6:01:
                            e3:66:a3:27:56:67:c7:8b:b8:8f:ca:64:b5:bf:57:
                            30:d7:04:f8:22:72:b1:26:c9:66:de:1a:65:bf:ac:
                            6e:c5:06:c9:4d:de:41:10:83:01:2d:49:1b:fc:ad:
                            8f:d6:87:d1:94:0a:2b:6d:7d:1f:c1:9f:3a:d3:7b:
                            40:06:a3:f0:94:a1:e8:3f:dd:e7:4b:10:af:51:ef:
                            ae:f2:bb:85:0b:de:42:78:fb:e3:1f:ec:a9:1d:d7:
                            79:aa:b8:b2:43:5c:50:ea:24:a1:e0:eb:0c:88:69:
                            ba:f3
                            Exponent: 65537 (0x10001)
                            X509v3 extensions:
                            X509v3 Basic Constraints:
                            CA:FALSE
                            Netscape Comment:
                            OpenSSL Generated Certificate
                            X509v3 Subject Key Identifier:
                            EC:13:5F:DC:48:44:72:8C:F1:E1:84:C0:C0:58:46:B9:CF:C8:03:64
                            X509v3 Authority Key Identifier:
                            keyid:F3:4C:36:F3:3F:B4:3A:8B:12:AF:2B:DE:37:2E:10:55:9A:6A:5C:A6

                            Signature Algorithm: sha1WithRSAEncryption
                            83:ff:72:0e:35:98:72:1f:3d:40:73:52:dd:52:c9:bd:40:2f:
                            c8:23:d8:9f:5d:13:95:a9:71:05:09:28:46:1c:4f:77:e5:83:
                            10:ca:a5:b0:c5:fa:4a:97:5e:e4:bf:2d:c8:60:69:48:ab:0d:
                            f8:6c:9b:58:28:a9:ac:3e:c6:74:e8:3b:af:ce:ee:ab:93:f2:
                            d6:41:15:74:47:ac:2c:00:cf:fd:7e:5e:64:30:57:b6:cd:26:
                            9c:88:54:6b:2a:9a:66:db:af:27:e9:94:f0:c9:ec:c4:76:e1:
                            1f:a5:a3:f9:d9:a2:09:58:c1:e9:bb:ec:f2:56:e8:9f:c2:83:
                            52:63:d9:24:d4:cb:44:46:30:f2:2b:67:5e:22:e6:cb:ee:61:
                            b6:66:07:88:d7:08:ea:df:50:94:6d:a9:4e:d3:09:38:11:33:
                            84:9c:1f:1c:17:76:bb:62:e8:5d:13:c3:f5:f5:f7:86:29:24:
                            bb:46:48:1a:aa:d3:88:1e:06:d0:43:2c:d6:cb:ac:a3:5a:8c:
                            db:cc:d5:c7:ee:9c:48:c8:96:69:96:49:d6:0e:0b:42:10:df:
                            d4:03:c6:ca:ee:f5:9e:e2:70:a9:c7:4b:5b:30:21:86:8f:fd:
                            61:ac:54:05:e6:f1:9c:c5:18:05:b9:5f:f6:ed:55:5e:b9:b1:
                            af:c5:5f:21
                            -----BEGIN CERTIFICATE-----
                            MIIEbjCCA1agAwIBAgIJAKqnGMLQpo1AMA0GCSqGSIb3DQEBBQUAMIG3MQswCQYD
                            VQQGEwJHQjEQMA4GA1UECAwHU3VmZm9sazEmMCQGA1UECgwdQnJpZ2h0aGVhZCBU
                            ZWNobm9sb2d5IExpbWl0ZWQxEzARBgNVBAsMCk1haWxzZXJ2ZXIxJTAjBgNVBAMM
                            HG14My5icmlnaHRoZWFkdGVjaG5vbG9neS5jb20xMjAwBgkqhkiG9w0BCQEWI3Bv
                            c3RtYXN0ZXJAYnJpZ2h0aGVhZHRlY2hub2xvZ3kuY29tMB4XDTE0MDIwNzIyNDcy
                            MVoXDTE1MDIwNzIyNDcyMVowgbcxCzAJBgNVBAYTAkdCMRAwDgYDVQQIDAdTdWZm
                            b2xrMSYwJAYDVQQKDB1CcmlnaHRoZWFkIFRlY2hub2xvZ3kgTGltaXRlZDETMBEG
                            A1UECwwKTWFpbHNlcnZlcjElMCMGA1UEAwwcbXgzLmJyaWdodGhlYWR0ZWNobm9s
                            b2d5LmNvbTEyMDAGCSqGSIb3DQEJARYjcG9zdG1hc3RlckBicmlnaHRoZWFkdGVj
                            aG5vbG9neS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAXNCT
                            OGQceoZE3xbL2GqTzjzxanv5oNVS6ic/gYNP4VdJ8cOWzYYIYK+qJlg0MpFFQba5
                            CSlQFywrkIiNx6eMMIvtPgPR1umsTlfYVkk8UMjBEHKsgz0IdFQraXnQMHPkt3VN
                            Rm/WCVM9UKqryEO5vh0ORnAJ+/Oqk2QeY95OdXBkctcjQT3bmXU4xWrNknONV5vm
                            AeNmoydWZ8eLuI/KZLW/VzDXBPgicrEmyWbeGmW/rG7FBslN3kEQgwEtSRv8rY/W
                            h9GUCittfR/BnzrTe0AGo/CUoeg/3edLEK9R767yu4UL3kJ4++Mf7Kkd13mquLJD
                            XFDqJKHg6wyIabrzAgMBAAGjezB5MAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8W
                            HU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBTsE1/cSERy
                            jPHhhMDAWEa5z8gDZDAfBgNVHSMEGDAWgBTzTDbzP7Q6ixKvK943LhBVmmpcpjAN
                            BgkqhkiG9w0BAQUFAAOCAQEAg/9yDjWYch89QHNS3VLJvUAvyCPYn10TlalxBQko
                            RhxPd+WDEMqlsMX6Spde5L8tyGBpSKsN+GybWCiprD7GdOg7r87uq5Py1kEVdEes
                            LADP/X5eZDBXts0mnIhUayqaZtuvJ+mU8MnsxHbhH6Wj+dmiCVjB6bvs8lbon8KD
                            UmPZJNTLREYw8itnXiLmy+5htmYHiNcI6t9QlG2pTtMJOBEzhJwfHBd2u2LoXRPD
                            9fX3hikku0ZIGqrTiB4G0EMs1suso1qM28zVx+6cSMiWaZZJ1g4LQhDf1APGyu71
                            nuJwqcdLWzAhho/9YaxUBebxnMUYBblf9u1VXrmxr8VfIQ==
                            -----END CERTIFICATE-----

                            --
                            Viktor.
                          • Alan Munday
                            ... Not difficult at all. ... Does this imply that, for users like me, the Getting started, quick and dirty section of the Postfix TLS support could be
                            Message 13 of 16 , Feb 7, 2014
                              Viktor Dukhovni wrote the following on 07/02/14 23:13:
                              > On Fri, Feb 07, 2014 at 10:40:37PM +0000, Alan Munday wrote:
                              >
                              > Should not be too hard. In your case, as I suggested upstream, a
                              > simple self-signed certificate with no issuing CA is quite sufficient:
                              >
                              > Assuming a suitable private key in key.pem, a self-signed cert is just
                              > one command:
                              >
                              > openssl req -x509 -sha1 -new -key key.pem -out newcert.pem \
                              > -subj "/CN=$(uname -n)" -days 3650
                              >

                              Not difficult at all.

                              >
                              > Indeed, looks like you're done. The below is not self-signed, but
                              > nobody cares really. No need to post-pend an issuer CA nobody
                              > trusts to the chain.

                              Does this imply that, for users like me, the "Getting started, quick and
                              dirty" section of the Postfix TLS support could be further simplified?

                              Thanks

                              Alan
                            • Viktor Dukhovni
                              ... Yes. I did not write that section. It always looked a bit too fancy to me. For a complete self-signed key + cert combination: # cd /etc/postfix #
                              Message 14 of 16 , Feb 7, 2014
                                On Fri, Feb 07, 2014 at 11:49:55PM +0000, Alan Munday wrote:

                                > >Assuming a suitable private key in key.pem, a self-signed cert is just
                                > >one command:
                                > >
                                > > openssl req -x509 -sha1 -new -key key.pem -out newcert.pem \
                                > > -subj "/CN=$(uname -n)" -days 3650
                                > >
                                >
                                > Not difficult at all.
                                >
                                > >Indeed, looks like you're done. The below is not self-signed, but
                                > >nobody cares really. No need to post-pend an issuer CA nobody
                                > >trusts to the chain.
                                >
                                > Does this imply that, for users like me, the "Getting started, quick
                                > and dirty" section of the Postfix TLS support could be further
                                > simplified?

                                Yes. I did not write that section. It always looked a bit too
                                fancy to me. For a complete self-signed key + cert combination:

                                # cd /etc/postfix
                                # tmp=$(mktep .tmpcert.XXXXXX)
                                # certfile=certkey-$(date +"%Y-%m-%d.pem")
                                # umask 077
                                # openssl req -new -newkey rsa:2048 -keyout /dev/stdout -nodes \
                                -x509 -sha1 -subj "/CN=$(uname -n)" -days 3650 >> "$tmp" &&
                                mv "$tmp" "$certfile" &&
                                postconf -e \
                                'smtpd_tls_cert_file = ${config_directory}/'"${certfile}" \
                                'smtpd_tls_key_file = ${smtpd_tls_cert_file}'

                                Note, you need ">> $tmp" not "> $tmp", because on some platforms
                                opening /dev/stdout is surprisingly not a dup() operation and the
                                resulting file descriptor does not share the file offset of the
                                original stdout. Since the key is written to /dev/stdout and the
                                cert to the actual stdout, you don't want the latter to overwrite
                                the former. Opening with O_APPEND (>>) takes care of that.

                                --
                                Viktor.
                              • Alan Munday
                                ... Thank you Viktor.
                                Message 15 of 16 , Feb 8, 2014
                                  Viktor Dukhovni wrote the following on 08/02/14 03:21:
                                  > On Fri, Feb 07, 2014 at 11:49:55PM +0000, Alan Munday wrote:

                                  >> Does this imply that, for users like me, the "Getting started, quick
                                  >> and dirty" section of the Postfix TLS support could be further
                                  >> simplified?
                                  >
                                  > Yes. I did not write that section. It always looked a bit too
                                  > fancy to me. For a complete self-signed key + cert combination:
                                  >
                                  > # cd /etc/postfix
                                  > # tmp=$(mktep .tmpcert.XXXXXX)
                                  > # certfile=certkey-$(date +"%Y-%m-%d.pem")
                                  > # umask 077
                                  > # openssl req -new -newkey rsa:2048 -keyout /dev/stdout -nodes \
                                  > -x509 -sha1 -subj "/CN=$(uname -n)" -days 3650 >> "$tmp" &&
                                  > mv "$tmp" "$certfile" &&
                                  > postconf -e \
                                  > 'smtpd_tls_cert_file = ${config_directory}/'"${certfile}" \
                                  > 'smtpd_tls_key_file = ${smtpd_tls_cert_file}'
                                  >
                                  > Note, you need ">> $tmp" not "> $tmp", because on some platforms
                                  > opening /dev/stdout is surprisingly not a dup() operation and the
                                  > resulting file descriptor does not share the file offset of the
                                  > original stdout. Since the key is written to /dev/stdout and the
                                  > cert to the actual stdout, you don't want the latter to overwrite
                                  > the former. Opening with O_APPEND (>>) takes care of that.

                                  Thank you Viktor.
                                • Paul Hoffman
                                  Ll -- Paul Hoffman On Feb 5, 2014 10:37 PM, Alan Munday
                                  Message 16 of 16 , Feb 8, 2014

                                    Ll

                                    --
                                    Paul Hoffman <paul@...>

                                    On Feb 5, 2014 10:37 PM, "Alan Munday" <postfix45@...> wrote:

                                    I found a problem in my logs with respect to receiving email from outlook.com. When I looked into it I thought it was due to the TLS certs having expired. I've created new certificates (self-signed) but the problem is continuing.

                                    I'm seeing trusted/untrusted/anonymous connections established with other relays and mail via these connections is processed OK.

                                    On mx1 with inbound connections from outlook.com I'm seeing anonymous TLS connections established but always followed by "lost connection after EHLO".

                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: connect from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: setting up TLS connection from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]: TLS cipher list "ALL:+RC4:@STRENGTH"
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:before/accept initialization
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 read client hello A
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 write server hello A
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 write certificate A
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 write server done A
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 flush data
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 read client key exchange A
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 read finished A
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 write change cipher spec A
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 write finished A
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: SSL_accept:SSLv3 flush data
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]: save session 951C66833DABEBA07BCBFA9F5DAD5E6281408A0C0596DA29A852F370D81191B7&s=smtpd&l=268435459 to smtpd cache
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: Anonymous TLS connection established from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]: TLSv1 with cipher AES128-SHA (128/128 bits)
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: lost connection after EHLO from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
                                    Feb  5 16:01:21 mx1 postfix/smtpd[22789]: disconnect from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]


                                    While on mx3 I'm always seeing SSL_accept error. (master.cf and main.cf are the same on both mx's.)

                                    Feb  5 16:00:58 mx3 postfix/smtpd[14898]: connect from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
                                    Feb  5 16:00:58 mx3 postfix/smtpd[14898]: setting up TLS connection from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
                                    Feb  5 16:00:58 mx3 postfix/smtpd[14898]: mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]: TLS cipher list "ALL:+RC4:@STRENGTH"
                                    Feb  5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:before/accept initialization
                                    Feb  5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:SSLv3 read client hello A
                                    Feb  5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:SSLv3 write server hello A
                                    Feb  5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:SSLv3 write certificate A
                                    Feb  5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:SSLv3 write server done A
                                    Feb  5 16:00:58 mx3 postfix/smtpd[14898]: SSL_accept:SSLv3 flush data
                                    Feb  5 16:05:58 mx3 postfix/smtpd[14898]: SSL_accept error from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]: Connection timed out
                                    Feb  5 16:05:58 mx3 postfix/smtpd[14898]: lost connection after STARTTLS from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]
                                    Feb  5 16:05:58 mx3 postfix/smtpd[14898]: disconnect from mail-db3lp0084.outbound.protection.outlook.com[213.199.154.84]


                                    I've searched the archives and not yet found anything to point me towards what's going on or if the problem is my end.


                                    I thought I'd start by asking if anyone else is seeing/has seen problems like this?


                                    Thanks


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