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

Re: disturbing TLS error

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