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

disturbing TLS error

Expand Messages
  • Mathieu R.
    Hello, i ve just setted up a postfix server, and i constantly have such error in my logs : Sep 13 21:31:34 effraie01 postfix/smtpd[12650]: SSL_accept error
    Message 1 of 15 , Sep 13, 2013
    • 0 Attachment
      Hello,

      i've just setted up a postfix server, and i constantly have such error
      in my logs :


      Sep 13 21:31:34 effraie01 postfix/smtpd[12650]: SSL_accept error from
      ng17.bullet.mail.bf1.yahoo.com

      (ever from yahoo servers)
      i can't figure out wher my mistake come from.

      here is my postconf -n : http://paste.debian.net/39693/
      postfix version is : 2.9.6-2 (debian stable package)

      can please somebody give me some help (i fear loosing some emails from
      yahoo)

      thanks in advance

      --
      Mathieu R.
    • Viktor Dukhovni
      ... There is generally more information in the log than this when the TLS handshake fails. DO NOT over-summarize the logs. ... Record a full packet PCAP file
      Message 2 of 15 , Sep 13, 2013
      • 0 Attachment
        On Fri, Sep 13, 2013 at 09:44:38PM +0200, Mathieu R. wrote:

        > Sep 13 21:31:34 effraie01 postfix/smtpd[12650]: SSL_accept error
        > from ng17.bullet.mail.bf1.yahoo.com

        There is generally more information in the log than this when the
        TLS handshake fails. DO NOT over-summarize the logs.

        > (ever from yahoo servers)
        > i can't figure out wher my mistake come from.

        Record a full packet PCAP file containing a session from a Yahoo
        host. Filter this capture file to contain full packets from exactly
        one TCP session. Run that through wireshark, see where in the TLS
        handshake the problem starts. Make the full capture available (post
        a URL, ...).

        > here is my postconf -n : http://paste.debian.net/39693/
        > postfix version is : 2.9.6-2 (debian stable package)
        >
        > can please somebody give me some help (i fear loosing some emails
        > from yahoo)

        TLS to your domain looks good when I test. Your server certificate
        is self-signed, but that's hardly unique to you.

        The expiration date on the self-signed cert could arguably give
        some systems indigestion, perhaps a 2-10 year lifetime is more
        reasonable than 1000 years.

        Certificate:
        Data:
        Version: 1 (0x0)
        Serial Number:
        b5:81:fb:cf:95:9e:77:db
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=FR, ST=France, L=Paris, O=effraie.org, OU=effraie.org, CN=effraie.org/emailAddress=root@...
        Validity
        Not Before: Sep 13 18:28:24 2013 GMT
        Not After : Jan 14 18:28:24 3013 GMT
        Subject: C=FR, ST=France, L=Paris, O=effraie.org, OU=effraie.org, CN=effraie.org/emailAddress=root@...
        Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
        Public-Key: (1024 bit)
        Modulus:
        00:c4:59:01:87:4a:39:ad:c9:81:42:78:f0:01:2f:
        ef:b0:56:d9:0b:96:7d:ef:28:4a:d1:68:63:33:dd:
        17:2c:08:3c:ac:be:93:f0:dd:11:e0:4a:33:19:77:
        b1:aa:0d:21:d5:08:3e:ff:c6:43:68:11:22:52:b4:
        e9:30:df:08:b1:c3:20:a7:3f:ea:a3:3b:48:ed:fb:
        6c:41:f0:4d:c4:8a:f2:d9:be:32:e4:7d:b8:91:66:
        a7:14:61:95:e3:9f:a6:d3:b2:18:7a:5d:1f:4a:84:
        1a:e3:20:96:c3:5a:91:d8:cc:14:02:a5:df:7a:ea:
        6f:fe:e9:79:83:d2:59:0b:a1
        Exponent: 65537 (0x10001)
        Signature Algorithm: sha1WithRSAEncryption
        76:2a:93:c9:0a:6a:1a:2f:ba:d1:a2:70:05:01:33:a6:fb:d4:
        1f:ae:05:bb:92:1c:a1:b7:4b:f9:ec:18:6e:a1:1c:2e:ae:16:
        e2:14:8a:b6:b3:d0:38:72:63:ee:a4:e4:da:ac:5b:66:9f:79:
        8e:87:ee:bd:c5:ec:dc:94:20:0b:0f:a0:19:53:72:cc:60:62:
        a1:99:b7:1c:b3:56:bf:5a:b1:52:3a:a5:18:b9:31:fa:8f:05:
        0a:3b:86:6a:10:59:bd:9f:bf:d3:4c:41:b8:db:c9:dd:73:c9:
        41:61:07:31:8a:e6:dc:6d:09:1b:28:69:8d:12:ab:43:51:4b:
        da:91
        -----BEGIN CERTIFICATE-----
        MIICnTCCAgYCCQC1gfvPlZ532zANBgkqhkiG9w0BAQUFADCBkTELMAkGA1UEBhMC
        RlIxDzANBgNVBAgMBkZyYW5jZTEOMAwGA1UEBwwFUGFyaXMxFDASBgNVBAoMC2Vm
        ZnJhaWUub3JnMRQwEgYDVQQLDAtlZmZyYWllLm9yZzEUMBIGA1UEAwwLZWZmcmFp
        ZS5vcmcxHzAdBgkqhkiG9w0BCQEWEHJvb3RAZWZmcmFpZS5vcmcwIBcNMTMwOTEz
        MTgyODI0WhgPMzAxMzAxMTQxODI4MjRaMIGRMQswCQYDVQQGEwJGUjEPMA0GA1UE
        CAwGRnJhbmNlMQ4wDAYDVQQHDAVQYXJpczEUMBIGA1UECgwLZWZmcmFpZS5vcmcx
        FDASBgNVBAsMC2VmZnJhaWUub3JnMRQwEgYDVQQDDAtlZmZyYWllLm9yZzEfMB0G
        CSqGSIb3DQEJARYQcm9vdEBlZmZyYWllLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOB
        jQAwgYkCgYEAxFkBh0o5rcmBQnjwAS/vsFbZC5Z97yhK0WhjM90XLAg8rL6T8N0R
        4EozGXexqg0h1Qg+/8ZDaBEiUrTpMN8IscMgpz/qoztI7ftsQfBNxIry2b4y5H24
        kWanFGGV45+m07IYel0fSoQa4yCWw1qR2MwUAqXfeupv/ul5g9JZC6ECAwEAATAN
        BgkqhkiG9w0BAQUFAAOBgQB2KpPJCmoaL7rRonAFATOm+9QfrgW7khyht0v57Bhu
        oRwurhbiFIq2s9A4cmPupOTarFtmn3mOh+69xezclCALD6AZU3LMYGKhmbccs1a/
        WrFSOqUYuTH6jwUKO4ZqEFm9n7/TTEG428ndc8lBYQcxiubcbQkbKGmNEqtDUUva
        kQ==
        -----END CERTIFICATE-----

        --
        Viktor.
      • Mathieu R.
        ... Sep 13 22:58:40 effraie01 postfix/smtpd[22230]: SSL_accept error from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99] lost connection Sep 13 22:58:40
        Message 3 of 15 , Sep 13, 2013
        • 0 Attachment
          Le 13/09/2013 22:29, Viktor Dukhovni a écrit :
          > On Fri, Sep 13, 2013 at 09:44:38PM +0200, Mathieu R. wrote:
          >
          >> Sep 13 21:31:34 effraie01 postfix/smtpd[12650]: SSL_accept error
          >> from ng17.bullet.mail.bf1.yahoo.com
          >
          > There is generally more information in the log than this when the
          > TLS handshake fails. DO NOT over-summarize the logs.


          Sep 13 22:58:40 effraie01 postfix/smtpd[22230]: SSL_accept error from
          ng4.bullet.mail.bf1.yahoo.com[98.139.164.99] lost connection
          Sep 13 22:58:40 effraie01 postfix/smtpd[22230]: lost connection after
          STARTTLS from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
          Sep 13 22:58:40 effraie01 postfix/smtpd[22230]: disconnect from
          ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]

          i can find anything more about this in my logs.


          >> (ever from yahoo servers)
          >> i can't figure out wher my mistake come from.
          >
          > Record a full packet PCAP file containing a session from a Yahoo
          > host. Filter this capture file to contain full packets from exactly
          > one TCP session. Run that through wireshark, see where in the TLS
          > handshake the problem starts. Make the full capture available (post
          > a URL, ...).

          Hum, i fully agree to do that, but i'm afraid i don't know how... i'm
          starting googling about it, but i you want to tell me how, i'll be
          thankfull.


          >> here is my postconf -n : http://paste.debian.net/39693/
          >> postfix version is : 2.9.6-2 (debian stable package)
          >>
          >> can please somebody give me some help (i fear loosing some emails
          >> from yahoo)
          >
          > TLS to your domain looks good when I test. Your server certificate
          > is self-signed, but that's hardly unique to you.
          >
          > The expiration date on the self-signed cert could arguably give
          > some systems indigestion, perhaps a 2-10 year lifetime is more
          > reasonable than 1000 years.
          >

          you are probably right... i'll change this.

          --
          Mathieu R.
        • Viktor Dukhovni
          ... If your traffic volume is not too heavy, you can temporarily raise the Postfix SMTP server TLS log level to 2 : smtpd_tls_loglevel = 2 this will show more
          Message 4 of 15 , Sep 13, 2013
          • 0 Attachment
            On Fri, Sep 13, 2013 at 11:03:22PM +0200, Mathieu R. wrote:

            > >There is generally more information in the log than this when the
            > >TLS handshake fails. DO NOT over-summarize the logs.
            >
            > Sep 13 22:58:40 effraie01 postfix/smtpd[22230]: SSL_accept error
            > from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99] lost connection
            > Sep 13 22:58:40 effraie01 postfix/smtpd[22230]: lost connection
            > after STARTTLS from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
            > Sep 13 22:58:40 effraie01 postfix/smtpd[22230]: disconnect from
            > ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
            >
            > I can [not] find anything more about this in my logs.

            If your traffic volume is not too heavy, you can temporarily raise
            the Postfix SMTP server TLS log level to "2":

            smtpd_tls_loglevel = 2

            this will show more details of the TLS handshake.

            > >Record a full packet PCAP file containing a session from a Yahoo
            > >host. Filter this capture file to contain full packets from exactly
            > >one TCP session. Run that through wireshark, see where in the TLS
            > >handshake the problem starts. Make the full capture available (post
            > >a URL, ...).
            >
            > Hum, i fully agree to do that, but i'm afraid i don't know how...
            > i'm starting googling about it, but i you want to tell me how, i'll
            > be thankfull.

            # tcpdump -s0 -w /root/yahoo.pcap tcp port 25 and net 98.139.0.0/16 &

            use appropriate filename for your mail log below if not /var/log/maillog:

            # tail -f /var/log/maillog | grep '/smtpd[^ ]*: SSL_accept error from [^ ]*\.yahoo\.com\[98\.139'

            wait until at least one, and ideally two new events are logged. Then
            stop the tcpdump:

            # pkill -INT -x tcpdump

            Now find the first session in the capture whose initial SYN packet
            is recorded:

            # tcpdump -nr /root/yahoo.pcap 'tcp[13] & 0x12 == 0x2'

            Note the yahoo client's tcp port number in the first line of output, below
            assumed to be 62831:

            # tcpdump -s0 -nr /root/yahoo.pcap -w /root/yahoo1.pcap tcp port 62831

            Analyze yahoo1.pcap with wireshark and also upload it somewhere so others
            can inspect it and help you find the problem.

            --
            Viktor.
          • Mathieu R.
            ... not very much more : Sep 13 23:33:09 effraie01 postfix/smtpd[25221]: connect from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99] Sep 13 23:33:44 effraie01
            Message 5 of 15 , Sep 13, 2013
            • 0 Attachment
              Le 13/09/2013 23:26, Viktor Dukhovni a écrit :
              > On Fri, Sep 13, 2013 at 11:03:22PM +0200, Mathieu R. wrote:
              >
              >> >There is generally more information in the log than this when the
              >> >TLS handshake fails. DO NOT over-summarize the logs.
              >>
              >> Sep 13 22:58:40 effraie01 postfix/smtpd[22230]: SSL_accept error
              >> from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99] lost connection
              >> Sep 13 22:58:40 effraie01 postfix/smtpd[22230]: lost connection
              >> after STARTTLS from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
              >> Sep 13 22:58:40 effraie01 postfix/smtpd[22230]: disconnect from
              >> ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
              >>
              >> I can [not] find anything more about this in my logs.
              >
              > If your traffic volume is not too heavy, you can temporarily raise
              > the Postfix SMTP server TLS log level to "2":
              >
              > smtpd_tls_loglevel = 2
              >
              > this will show more details of the TLS handshake.

              not very much more :

              Sep 13 23:33:09 effraie01 postfix/smtpd[25221]: connect from
              ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
              Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: SSL_accept error from
              ng4.bullet.mail.bf1.yahoo.com[98.139.164.99] lost connection
              Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: lost connection after
              STARTTLS from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
              Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: disconnect from
              ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]


              >
              >> >Record a full packet PCAP file containing a session from a Yahoo
              >> >host. Filter this capture file to contain full packets from
              >> exactly
              >> >one TCP session. Run that through wireshark, see where in the TLS
              >> >handshake the problem starts. Make the full capture available
              >> (post
              >> >a URL, ...).

              http://bazar.effraie.org/yahoo1.pcap (i personally do not understand
              anything from this...)

              thank a lot for you help

              --
              Mathieu R.
            • DTNX Postmaster
              ... Hmm, we have the same Postfix version, also on Debian, and we are seeing disconnects at the postscreen level from that IP address; ==
              Message 6 of 15 , Sep 13, 2013
              • 0 Attachment
                On Sep 13, 2013, at 23:51, Mathieu R. <mathieu@...> wrote:

                > Le 13/09/2013 23:26, Viktor Dukhovni a écrit :
                >> If your traffic volume is not too heavy, you can temporarily raise
                >> the Postfix SMTP server TLS log level to "2":
                >>
                >> smtpd_tls_loglevel = 2
                >>
                >> this will show more details of the TLS handshake.
                >
                > not very much more :
                >
                > Sep 13 23:33:09 effraie01 postfix/smtpd[25221]: connect from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
                > Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: SSL_accept error from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99] lost connection
                > Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: lost connection after STARTTLS from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
                > Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: disconnect from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]

                Hmm, we have the same Postfix version, also on Debian, and we are seeing disconnects at the postscreen level from that IP address;

                ==
                2013-09-13T23:58:41.766924+02:00 nenya postfix/tlsproxy[3731]: CONNECT from [98.139.164.99]:33900
                2013-09-13T23:58:47.542529+02:00 nenya postfix/tlsproxy[3731]: DISCONNECT [98.139.164.99]:33900
                2013-09-13T23:58:47.542674+02:00 nenya postfix/postscreen[3698]: HANGUP after 35 from [98.139.164.99]:33900 in tests after SMTP handshake
                2013-09-13T23:58:47.542682+02:00 nenya postfix/postscreen[3698]: DISCONNECT [98.139.164.99]:33900
                ==

                It seems to have been doing that since earlier this evening;

                ==
                2013-09-13T19:33:34.126969+02:00 nenya postfix/postscreen[15218]: HANGUP after 73 from [98.139.164.99]:39792 in tests after SMTP handshake
                2013-09-13T19:52:04.971145+02:00 nenya postfix/postscreen[15218]: HANGUP after 33 from [98.139.164.99]:30926 in tests after SMTP handshake
                2013-09-13T20:01:54.029206+02:00 nenya postfix/postscreen[15218]: HANGUP after 27 from [98.139.164.99]:42963 in tests after SMTP handshake
                2013-09-13T20:12:31.720843+02:00 nenya postfix/postscreen[15218]: HANGUP after 28 from [98.139.164.99]:46613 in tests after SMTP handshake

                [snip]

                2013-09-13T23:43:41.362443+02:00 nenya postfix/postscreen[15218]: HANGUP after 29 from [98.139.164.99]:20120 in tests after SMTP handshake
                2013-09-13T23:48:44.737948+02:00 nenya postfix/postscreen[15218]: HANGUP after 33 from [98.139.164.99]:26140 in tests after SMTP handshake
                2013-09-13T23:53:41.682549+02:00 nenya postfix/postscreen[3698]: HANGUP after 30 from [98.139.164.99]:30328 in tests after SMTP handshake
                2013-09-13T23:58:47.542674+02:00 nenya postfix/postscreen[3698]: HANGUP after 35 from [98.139.164.99]:33900 in tests after SMTP handshake
                ==

                Without delivering anything. Other Yahoo MTAs seem to be fine, it's just this one that's showing this particular behaviour as far as I've been able to tell from a quick scouring of the logs for Friday.

                HTH,
                Joni
              • Viktor Dukhovni
                ... Yahoo sends STARTTLS , Postfix says go ahead and Yahoo disconnects. There s is nothing more to it. Some strange problem on the Yahoo side, unless your
                Message 7 of 15 , Sep 13, 2013
                • 0 Attachment
                  On Fri, Sep 13, 2013 at 11:51:39PM +0200, Mathieu R. wrote:

                  > not very much more :
                  >
                  > Sep 13 23:33:09 effraie01 postfix/smtpd[25221]: connect from
                  > ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
                  > Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: SSL_accept error
                  > from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99] lost connection
                  > Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: lost connection
                  > after STARTTLS from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
                  > Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: disconnect from
                  > ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
                  >
                  > http://bazar.effraie.org/yahoo1.pcap (i personally do not understand
                  > anything from this...)

                  Yahoo sends "STARTTLS", Postfix says "go ahead" and Yahoo disconnects.
                  There's is nothing more to it. Some strange problem on the Yahoo
                  side, unless your firewall is blocking the handshake.

                  17:38:34.652085 IP 98.139.164.99.42311 > 95.142.171.138.25: Flags [P.], seq 37:47, ack 195, win 1040, options [nop,nop,TS val 616343063 ecr 91542692], length 10
                  0x0000: 4500 003e 611a 4000 3506 d298 628b a463 E..>a.@.5...b..c
                  0x0010: 5f8e ab8a a547 0019 6738 edab 0462 d552 _....G..g8...b.R
                  0x0020: 8018 0410 a555 0000 0101 080a 24bc a617 .....U......$...
                  0x0030: 0574 d4a4 5354 4152 5454 4c53 0d0a .t..STARTTLS..
                  17:38:34.652231 IP 95.142.171.138.25 > 98.139.164.99.42311: Flags [P.], seq 195:225, ack 47, win 453, options [nop,nop,TS val 91544215 ecr 616343063], length 30
                  0x0000: 4500 0052 6a67 4000 4006 be37 5f8e ab8a E..Rjg@.@..7_...
                  0x0010: 628b a463 0019 a547 0462 d552 6738 edb5 b..c...G.b.Rg8..
                  0x0020: 8018 01c5 124c 0000 0101 080a 0574 da97 .....L.......t..
                  0x0030: 24bc a617 3232 3020 322e 302e 3020 5265 $...220.2.0.0.Re
                  0x0040: 6164 7920 746f 2073 7461 7274 2054 4c53 ady.to.start.TLS
                  0x0050: 0d0a ..
                  17:38:34.859123 IP 98.139.164.99.42311 > 95.142.171.138.25: Flags [.], ack 225, win 1040, options [nop,nop,TS val 616343269 ecr 91544215], length 0
                  0x0000: 4500 0034 68de 4000 3506 cade 628b a463 E..4h.@.5...b..c
                  0x0010: 5f8e ab8a a547 0019 6738 edb5 0462 d570 _....G..g8...b.p
                  0x0020: 8010 0410 e0d6 0000 0101 080a 24bc a6e5 ............$...
                  0x0030: 0574 da97 .t..
                  17:38:39.379757 IP 98.139.164.99.42311 > 95.142.171.138.25: Flags [F.], seq 47, ack 225, win 1040, options [nop,nop,TS val 616347791 ecr 91544215], length 0
                  0x0000: 4500 0034 c72e 4000 3506 6c8e 628b a463 E..4..@.5.l.b..c
                  0x0010: 5f8e ab8a a547 0019 6738 edb5 0462 d570 _....G..g8...b.p
                  0x0020: 8011 0410 cf2b 0000 0101 080a 24bc b88f .....+......$...
                  0x0030: 0574 da97 .t..
                  17:38:39.380192 IP 95.142.171.138.25 > 98.139.164.99.42311: Flags [F.], seq 225, ack 48, win 453, options [nop,nop,TS val 91545397 ecr 616347791], length 0
                  0x0000: 4500 0034 6a68 4000 4006 be54 5f8e ab8a E..4jh@.@..T_...
                  0x0010: 628b a463 0019 a547 0462 d570 6738 edb6 b..c...G.b.pg8..
                  0x0020: 8011 01c5 122e 0000 0101 080a 0574 df35 .............t.5
                  0x0030: 24bc b88f $...
                  17:38:39.522307 IP 98.139.164.99.42311 > 95.142.171.138.25: Flags [.], ack 226, win 1040, options [nop,nop,TS val 616347932 ecr 91545397], length 0
                  0x0000: 4500 0034 0147 4000 3506 3276 628b a463 E..4.G@.5.2vb..c
                  0x0010: 5f8e ab8a a547 0019 6738 edb6 0462 d571 _....G..g8...b.q
                  0x0020: 8010 0410 c9ff 0000 0101 080a 24bc b91c ............$...
                  0x0030: 0574 df35 .t.5

                  --
                  Viktor.
                • Mathieu R.
                  ... My firewall is not doing such rude things. Thank you a lot for your help. So, there is nothing i can do ? -- Mathieu R.
                  Message 8 of 15 , Sep 13, 2013
                  • 0 Attachment
                    Le 14/09/2013 03:23, Viktor Dukhovni a écrit :
                    > On Fri, Sep 13, 2013 at 11:51:39PM +0200, Mathieu R. wrote:
                    >
                    >> not very much more :
                    >>
                    >> Sep 13 23:33:09 effraie01 postfix/smtpd[25221]: connect from
                    >> ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
                    >> Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: SSL_accept error
                    >> from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99] lost connection
                    >> Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: lost connection
                    >> after STARTTLS from ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
                    >> Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: disconnect from
                    >> ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
                    >>
                    >> http://bazar.effraie.org/yahoo1.pcap (i personally do not understand
                    >> anything from this...)
                    >
                    > Yahoo sends "STARTTLS", Postfix says "go ahead" and Yahoo
                    > disconnects.
                    > There's is nothing more to it. Some strange problem on the Yahoo
                    > side, unless your firewall is blocking the handshake.

                    My firewall is not doing such rude things.
                    Thank you a lot for your help.
                    So, there is nothing i can do ?


                    --
                    Mathieu R.
                  • Jan P. Kessler
                    ... If you don t need TLS for yahoo you can disable it for that server. Take a look at
                    Message 9 of 15 , Sep 14, 2013
                    • 0 Attachment
                      > So, there is nothing i can do ?

                      If you don't need TLS for yahoo you can disable it for that server. Take
                      a look at

                      http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps
                    • Viktor Dukhovni
                      ... There is nothing you should do. This may not even be a problem. Perhaps Yahoo have a reason for doing what they re doing. If it is a problem, they ll fix
                      Message 10 of 15 , Sep 14, 2013
                      • 0 Attachment
                        On Sat, Sep 14, 2013 at 08:45:05AM +0200, Mathieu R. wrote:

                        > >Yahoo sends "STARTTLS", Postfix says "go ahead" and Yahoo
                        > >disconnects.
                        > >There's is nothing more to it. Some strange problem on the Yahoo
                        > >side, unless your firewall is blocking the handshake.
                        >
                        > My firewall is not doing such rude things.
                        > Thank you a lot for your help.
                        > So, there is nothing i can do ?

                        There is nothing you should do. This may not even be a problem.
                        Perhaps Yahoo have a reason for doing what they're doing. If it is
                        a problem, they'll fix it.

                        --
                        Viktor.
                      • James Cloos
                        The mx lookup on effraie.org returns mx.effraie.org. The cert mx.effraie.org sends has a number of dnsnames, but not mx.effraie.org. I bet that is why the
                        Message 11 of 15 , Sep 15, 2013
                        • 0 Attachment
                          The mx lookup on effraie.org returns mx.effraie.org. The cert
                          mx.effraie.org sends has a number of dnsnames, but not mx.effraie.org.

                          I bet that is why the session failed.

                          The mx for 400iso.net, mx.400iso.net, sends the same cert and also
                          likely will fail tls negotiation with some senders.

                          In general, the name returned by the MX lookup is used as the TLS server
                          name when tls verification is attempted.

                          -JimC
                          --
                          James Cloos <cloos@...> OpenPGP: 1024D/ED7DAEA6
                        • Viktor Dukhovni
                          ... I noticed this, but I thought it unlikely that a sender willing to accept self-signed certificates, would object to the peername in such a certificate.
                          Message 12 of 15 , Sep 15, 2013
                          • 0 Attachment
                            On Sun, Sep 15, 2013 at 03:31:38PM -0400, James Cloos wrote:

                            > The mx lookup on effraie.org returns mx.effraie.org. The cert
                            > mx.effraie.org sends has a number of dnsnames, but not mx.effraie.org.
                            >
                            > I bet that is why the session failed.

                            I noticed this, but I thought it unlikely that a sender willing to
                            accept self-signed certificates, would object to the peername in
                            such a certificate. SMTP clients SHOULD NOT attempt to perform
                            *any* verification of SMTP server certificates without out-of-band
                            information about how to do that (local secure-channel configuration,
                            or DANE TLSA).

                            Yes, the possibility does exist that you're right anyway, and the
                            conservative (Postel) configuration is to have a matching CN or
                            subjectAltName even in a self-signed certificate.

                            > In general, the name returned by the MX lookup is used as the TLS server
                            > name when tls verification is attempted.

                            In general, with SMTP, when TLS is used it all it is TLS opportunistic
                            and unauthenicated. I still think that either that Yahoo host was
                            configured to perform some sort of probe function, or it was not performing
                            as intended.

                            --
                            Viktor.
                          • Mathieu R.
                            ... As it seem to be a good advice, I did change my dns entries for mx to mail.effraie.org, wich is covered by the (new) cacert certificat of the mail server.
                            Message 13 of 15 , Sep 15, 2013
                            • 0 Attachment
                              James Cloos <cloos@...> a écrit :
                              >The mx lookup on effraie.org returns mx.effraie.org. The cert
                              >mx.effraie.org sends has a number of dnsnames, but not mx.effraie.org.
                              >
                              >I bet that is why the session failed.
                              >
                              >The mx for 400iso.net, mx.400iso.net, sends the same cert and also
                              >likely will fail tls negotiation with some senders.
                              >
                              >In general, the name returned by the MX lookup is used as the TLS
                              >server
                              >name when tls verification is attempted.
                              >
                              >-JimC


                              As it seem to be a good advice, I did change my dns entries for mx to mail.effraie.org, wich is covered by the (new) cacert certificat of the mail server.

                              I still have the same error in logs


                              --
                              Mathieu R.
                              Envoyé depuis un téléphone. Excusez la brièveté.
                            • Wietse Venema
                              ... It does not matter what the server certificate says, because it is never sent. The evidence shows that the client hangs up before the TLS handshake.
                              Message 14 of 15 , Sep 15, 2013
                              • 0 Attachment
                                Mathieu R.:
                                > As it seem to be a good advice, I did change my dns entries for
                                > mx to mail.effraie.org, wich is covered by the (new) cacert
                                > certificat of the mail server.
                                >
                                > I still have the same error in logs

                                It does not matter what the server certificate says, because it is
                                never sent. The evidence shows that the client hangs up before the
                                TLS handshake.

                                Wietse
                              • John Allen
                                I ran into a problem that seems to have some of the same attributes. In my case Google was rejecting my email, however they may have been a little more polite
                                Message 15 of 15 , Sep 15, 2013
                                • 0 Attachment
                                  I ran into a problem that seems to have some of the same attributes. In
                                  my case Google was rejecting my email, however they may have been a
                                  little more polite about doing so.

                                  Have you checked your DNS and reverse DNS entries. Is your server a
                                  dedicated system with a single IP address.

                                  In my case I was running a multi-use server which had multiple IP
                                  addresses. This resulted in email being sent out on a IP address whose
                                  reverse DNS did not resolve to the published server. Google rejected my
                                  email, but they did issue an error message.

                                  I wonder if Yahoo is doing some sort of DNS to IP check and finding a
                                  mismatch just dropping the connection instead of issuing a valid error
                                  code. Not very polite of them, but past experience with not particularly
                                  unusual for them.

                                  To solve my problem, the first thing I did was to ensure that the rDNS
                                  for my sever was correct.
                                  Next added smtp_bind_address to the smtp entry in my master.cf.

                                  the effect of this is to ensure that the address and reverse address
                                  match, and that any DNS look up will not result in an error.

                                  I don't know if this will solve you problem. but I hope it helps.
                                Your message has been successfully submitted and would be delivered to recipients shortly.