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

Re: disturbing TLS error

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