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

Re: disturbing TLS error

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.